ProtectClock closes more than the RTC device
A service that can change the host clock can change the order of events recorded around it. It can also shift timestamps used by applications that assume the operating system clock is outside their control. The systemd ProtectClock= setting reduces that authority in several ways at once.
What the setting changes
When ProtectClock=yes is configured, systemd removes CAP_SYS_TIME and CAP_WAKE_ALARM from the unit's capability bounding set. It also installs a system call filter for operations that can set a clock and applies a read-only device rule to the real-time clock devices.
The effect therefore extends beyond making /dev/rtc0 read-only. A service that previously called clock_settime(), settimeofday(), or an adjacent time-control interface meets both a capability restriction and a system call filter.
The filter is deliberately coarse. The systemd manual explains that the calls are blocked even when a particular argument combination would only read clock state. Applications that need those calls for a legitimate reason need a narrower policy than ProtectClock=yes, or they need to move the operation outside the sandbox.
Where it fits in a service policy
ProtectClock= is most useful as part of an execution profile that already runs the service as an unprivileged user. A process running as root may retain other ways to reach kernel interfaces. Removing CAP_SYS_TIME blocks one path, but mount access, writable kernel settings, and device access still need review.
Keep the service's actual requirements visible. A time daemon needs to adjust the clock. A certificate validation service usually does not. A scheduler may need accurate time, while the database or job runner it supports only needs to consume the clock. Those roles should not share the same unit policy.
Review the related settings together:
[Service]
User=app
ProtectClock=yes
ProtectKernelTunables=yes
ProtectControlGroups=yes
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6
SystemCallFilter=~@mount
The example is a review starting point. Some services need mount operations for their own temporary storage or runtime directories. A denied system call can fail a health check long after the unit starts, so test the full startup and shutdown path.
The host still owns the clock
The setting protects the service from writing the clock. It does not make the host clock trustworthy. A hypervisor, a privileged local process, or an administrator can still change it. Logs from different hosts can still disagree because of clock drift or a broken time source.
Defenders should combine host time synchronization, authenticated time where the environment supports it, and independent log evidence. Application logs should record monotonic durations for local timers when event ordering matters. Central log storage should preserve receipt time separately from the timestamp supplied by the host.
ProtectClock= reduces a service's ability to create a misleading local timeline. It does not repair a timeline that was already altered before the logs left the host.
Verify the effective unit
Start with the expanded unit rather than the fragment in /etc:
systemctl cat example.service
systemctl show example.service -p User -p ProtectClock -p CapabilityBoundingSet
systemd-analyze security example.service
Then exercise the paths that need time access. A harmless application startup is not enough if a maintenance command changes the clock or wakes an alarm through a separate process. Check those helper processes and any command started with a + prefix, because systemd does not apply every sandbox setting to those commands in the same way.
Record the intended result. The service should be able to read time, run its scheduled work, and pass its health checks. It should fail when asked to change host time. If it succeeds, the unit policy is incomplete or the test is running outside the sandbox.
Top comments (0)