systemd manages services and, via timers, scheduled tasks. If a unit that runs as root has a writable unit file, a relative-path ExecStart, or relies on a writable directory in the systemd PATH, a low-privilege user can make root execute their code.
What is systemd services & timers?#
A systemd service unit defines a program to run (ExecStart=) and the user it runs as. A timer unit triggers a service on a schedule — the modern replacement for many cron jobs. Units live in /etc/systemd/system/, /lib/systemd/system/ and related paths.
Why LinPEAS checks systemd services & timers#
LinPEAS enumerates service and timer units, the systemd PATH, and the permissions of unit files, flagging writable units and relative ExecStart binaries that can be hijacked.
What a normal configuration looks like#
Unit files are root-owned and writable only by root. ExecStart uses absolute paths. Timers schedule maintenance work under controlled accounts.
Why it can be security-sensitive#
A writable unit file lets you change what root runs. A relative ExecStart (just a binary name) can be resolved from a writable PATH directory. A writable directory referenced by a unit can allow file swapping.
Understanding the concept tells you whether a LinPEAS highlight is a real problem here. The tool flags candidates; you confirm exploitability in context, and only act where authorised.
How to check it manually#
Run these read-only commands to inspect this area yourself and validate what LinPEAS reports:
systemctl list-units --type=service; systemctl list-timers --allfind /etc/systemd/ /lib/systemd/ -name '*.service' -writable 2>/dev/nullsystemctl cat <service>Defensive remediation#
- Keep unit files root-owned and non-writable by others.
- Always use absolute paths in
ExecStart. - Review third-party units for weak permissions.
- Restrict the directories referenced by privileged units.
Sources & references
- HackTricks: Linux privilege escalation
- GTFOBins — abuse techniques for standard binaries
- PEASS-ng repository — reviewed 20260908-dffb9496