Service hardening: User=, ProtectSystem, NoNewPrivileges

By default a service gets everything: it runs as root, writes to any directory, sees home directories and can run sudo. A bug in it is root on the machine. Restrictions are settings in the [Service] section: systemd applies them to the process before ExecStart runs, and the program does not know about them. They go into a drop-in, so the package's unit stays as it is. The general rule is least privilege: a service gets only what it cannot work without.

The lab service demo-web is python3 -m http.server on port 8090. Without restrictions it runs as root with all capabilities:

student@ubuntu:~$ ps -o user,pid,cmd -C python3
USER         PID CMD
root        2382 python3 -m http.server 8090 --bind 127.0.0.1
  --directory /srv/demo
student@ubuntu:~$ sudo grep -E 'Uid|CapEff' /proc/2382/status
Uid:	0	0	0	0
CapEff:	000001ffffffffff

Which user

User= and Group= run the service as the named user. That user needs no password, no login and no home directory:

sudo useradd --system --no-create-home --shell /usr/sbin/nologin demo

The same cat reads /etc/shadow as root and fails as demo:

student@ubuntu:~$ sudo systemd-run --pipe --wait -q -p User=demo \
> cat /etc/shadow
/usr/bin/cat: /etc/shadow: Permission denied

DynamicUser=yes does without useradd: systemd creates a temporary user for the lifetime of the service (uid=64021(run-u50)) and removes it afterwards. The data of such a service lives in /var/lib/private/<name>.

File system

student@ubuntu:~$ sudo systemd-run --pipe --wait -q \
> -p ProtectSystem=strict touch /etc/demo-file
/usr/bin/touch: cannot touch '/etc/demo-file': Read-only file system
student@ubuntu:~$ sudo systemd-run --pipe --wait -q -p ProtectHome=yes \
> ls -la /home
total 4
d---------  2 root root   40 Oct 21 05:05 .
drwxr-xr-x 21 root root 4096 Oct 20 23:33 ..

Logs, cache and sockets have similar settings: LogsDirectory= (/var/log/<name>), CacheDirectory=, RuntimeDirectory= (/run/<name>).

At start demo-web appends a line to /var/lib/demo/started. The directory was created back when the service ran as root, and after User=demo and ProtectSystem=strict the write fails — the service goes down:

student@ubuntu:~$ sudo journalctl -u demo-web -o cat -n 3
/bin/sh: 1: cannot create /var/lib/demo/started: Permission denied
demo-web.service: Main process exited, code=exited,
  status=2/INVALIDARGUMENT
demo-web.service: Failed with result 'exit-code'.

StateDirectory=demo fixes it: systemd hands the directory to demo and opens it for writing, while the rest of the system stays read-only:

student@ubuntu:~$ ls -ld /var/lib/demo
drwxr-xr-x 2 demo demo 4096 Oct 21 05:06 /var/lib/demo

New privileges

NoNewPrivileges=yes sets the no_new_privs flag on the process: neither it nor its children can raise their rights through setuid programs (sudo, su) or file capabilities. sudo inside such a service says so directly:

student@ubuntu:~$ sudo systemd-run --pipe --wait -q -p User=demo \
> -p NoNewPrivileges=yes sudo -n true
sudo: The "no new privileges" flag is set, which prevents sudo from
  running as root.
sudo: If sudo is running in a container, you may need to adjust the
  container configuration to disable the flag.

Without the flag sudo would get as far as the password check (sudo: a password is required) — and further for a user with a sudoers rule.

Capabilities

CapabilityBoundingSet= is the ceiling of the service's capabilities: an empty value takes all of them away, a list keeps only the named ones. A root service with an empty ceiling cannot bypass file permissions or load a kernel module. AmbientCapabilities= gives parts to a service with User=, for example a port below 1024:

[Service]
User=demo
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE

A part from AmbientCapabilities= works only if the ceiling has it too. An empty CapabilityBoundingSet= in another drop-in cuts it off, and the service gets PermissionError: [Errno 13] Permission denied again.

Other settings

systemd-analyze security

systemd-analyze security <unit> checks about 80 settings and prints a table of three columns: NAME, DESCRIPTION, EXPOSURE. ✗ means the protection is off, with its weight on the right; ✓ means it is on. A few rows for demo-web:

The last line is the total, the exposure level from 0 to 10:

student@ubuntu:~$ systemd-analyze security demo-web | tail -1
→ Overall exposure level for demo-web.service: 9.6 UNSAFE :-{

Without a unit name the command prints one line per service: on the lab machine almost all services are 9.5–9.6 UNSAFE, rsyslog is 6.3 MEDIUM, polkit is 1.6 OK. The levels:

How the rating of demo-web changed:

The rating is a sum of row weights. The first settings close the most dangerous holes, but they cover three rows, so the rating drops by only 0.9. Capabilities have the most rows: an empty CapabilityBoundingSet= closes them all at once.

--threshold=N turns the rating into a check. The threshold is in tenths: a rating of 9.6 is 96. Above the threshold the exit code is 1, equal or below it is 0:

student@ubuntu:~$ for t in 95 96; do
>   systemd-analyze security --threshold=$t demo-web >/dev/null
>   echo "threshold=$t rc=$?"
> done
threshold=95 rc=1
threshold=96 rc=0

The rating is computed from the unit's settings: after daemon-reload it is already new, while the running process stays the old one until restart. Check the process too — ps -o user, /proc/<PID>/status.

• systemd — units and drop-ins.
• capabilities — root's parts, the ceiling and the ambient set.
• systemctl — show, restart, daemon-reload.
• journalctl — why the service failed.
• apparmor — confinement by a kernel profile.
• users-groups — system users.
• nologin — the shell of a service user.