Sandbox a systemd Service: Confinement Directives and systemd-analyze security

You already know how to ask two questions about a service: is it running? (systemctl status) and how much may it use? (CPUQuota=, MemoryMax=). This lesson is about the third: if this service is compromised, what can the attacker reach?

By default the answer is "everything the service's user can reach", and a lot of services run as root. A bug in a report worker that only ever needed to read one directory and write another hands over every file on the box, every device, every kernel interface, the network, and the chance to escalate further through setuid binaries.

systemd can shrink that, per service, with directives in the unit's [Service] section. Behind the scenes it starts the service in its own mount namespace (so it can make parts of the filesystem read-only or invisible), drops capabilities, sets the kernel's no_new_privs flag, and installs a seccomp system-call filter. You write one line per wall; systemd builds the wall at start-up. You add them the way the overrides lesson taught: in a drop-in, so the vendor's unit file stays untouched.

The filesystem walls decide what the service can see and change. All of them work by giving the service its own mount namespace, so the rest of the system is unaffected.

• `ProtectSystem=` has three strengths, and learners routinely pick the weakest and assume it covered /etc:

- true: /usr, /boot and /efi are read-only. /etc is still writable.

- full: the same plus /etc.

- strict: the entire filesystem is read-only, except the API filesystems /dev, /proc and /sys, and /home, /root and /run/user, which are left to ProtectHome=. This includes /var and /tmp, so the service's own state too.

• `ProtectHome=`: yes makes /home, /root and /run/user empty and inaccessible; read-only leaves them readable; tmpfs mounts an empty, read-only tmpfs over them, onto which you can bind just the paths the service needs.
• `PrivateTmp=yes` gives the service its own empty /tmp and /var/tmp, invisible to everyone else. That stops /tmp races and snooping on other services' temp files.
• Paths: ReadWritePaths=, ReadOnlyPaths= and InaccessiblePaths= adjust single paths. A deeper path overrides a shallower one, so ProtectSystem=strict plus ReadWritePaths=/var/lib/demo is "everything read-only except that directory". The one exception: below an inaccessible path, nothing comes back.
• `StateDirectory=NAME` is the tidy way to hand back state: systemd creates /var/lib/NAME, makes it writable inside the sandbox, and owns it to the service's user.

`NoNewPrivileges=yes` is the cheapest line in the file. It sets the kernel's no_new_privs flag on the service, and the flag is inherited by every child and survives every execve(). From then on, running a setuid or setgid binary, or one with file capabilities, gives the process nothing extra. The hardening lesson's SUID audit finds the binaries that could be abused; this directive makes all of them useless to the confined service, including ones you haven't found yet. Some directives imply it, for example DynamicUser=yes.

`CapabilityBoundingSet=` limits which of root's capabilities (the pieces root's power is split into: CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_DAC_OVERRIDE, and about forty more) the service can ever hold. List the ones to keep, or prefix with ~ to list the ones to drop. An empty value, CapabilityBoundingSet=, keeps none: root in name only. It can still write files it owns, but it can't override permissions, load modules, change the network, or bind ports below 1024.

`User=` runs the service as an ordinary account, and `DynamicUser=yes` invents a throwaway user for each run. DynamicUser= also switches on ProtectSystem=strict, ProtectHome=read-only, PrivateTmp=yes and NoNewPrivileges=yes, which is powerful and easy to forget.

The last group narrows what the service can ask the kernel to do. You don't need to understand seccomp to use these; you need to know what each one closes.

• `ProtectKernelTunables=yes` makes /proc/sys and similar knobs read-only, so the service can't change sysctls.
• `ProtectKernelModules=yes` denies loading or reading kernel modules. `ProtectControlGroups=yes` makes the cgroup tree read-only.
• `RestrictAddressFamilies=` lists the socket types the service may open. A worker that only talks to local daemons needs AF_UNIX; a network service adds AF_INET AF_INET6. Raw packet and netlink sockets, favourites for attackers, are then refused.
• `SystemCallFilter=@system-service` installs a seccomp allow-list of the system calls ordinary services use. Mounting, rebooting, loading modules, swapping, changing the clock and other privileged calls are refused. @system-service is a named group; systemd-analyze syscall-filter shows what is in it.
• `SystemCallArchitectures=native` blocks the old 32-bit call path on a 64-bit box, a classic way around filters.

Keep this step shallow on purpose: the named groups are maintained by systemd for exactly this use, so @system-service is the right default and hand-written call lists are rarely worth it.

systemd-analyze security turns hardening from a checklist into a measurement. Each row is one setting: a tick (✓) when the unit has it, a cross (✗) when it doesn't, with the exposure that row adds in the last column. Rows with no mark don't apply (for example SupplementaryGroups= for a root service). The overall level combines the rows; it is systemd's estimate, from 0.0 to 10.0, of how exposed the system is if this service is taken over.

The demo unit now has three drop-ins, 10-filesystem.conf, 20-privileges.conf and 30-kernel.conf, merged in that order. Splitting by theme makes it obvious later which wall broke something.

The workflow is a loop: measure, pick the expensive crosses, add a wall, measure again. It reads the unit file and every drop-in, from /etc/systemd/system/<unit>.d/, /run/systemd/system/<unit>.d/ and the vendor directories, exactly as systemd would merge them, so you are measuring what would actually run. You can name the unit (demo-report.service) or give its path (/etc/systemd/system/demo-report.service): both load the same drop-ins, so passing the file never means "ignore the overrides".

Two limits to keep in mind. The score covers only systemd's own features, not the program. And it can't tell whether the service still works under the walls you added. That's the next step.

Confinement breaks services, and it breaks them in recognisable ways. The service starts, then fails at the first write or read the sandbox now forbids, and the journal says why:

• `ProtectSystem=strict` on a service that writes its own state: Read-only file system (EROFS) on a path under /var/lib, /var/spool or /tmp. Fix: StateDirectory= or ReadWritePaths= for that path, not ProtectSystem=full.
• `ProtectHome=yes` on a service that reads a user's file: No such file or directory for something you can plainly see in /home. Fix: ProtectHome=read-only.
• `PrivateTmp=yes` on a service that hands files to another one through `/tmp`: no error at all. It writes into its private /tmp, and the other service never sees the files. Fix: turn it off, and don't use DynamicUser=, which implies it.
• An empty `CapabilityBoundingSet=` on a service that binds port 80: bind: Permission denied. Fix: keep CAP_NET_BIND_SERVICE.

On a live host, read it with journalctl -u UNIT -n 20 after a failed start. The rule is the same every time: loosen the one directive that causes the error and keep the rest. Deleting the hardening block because one line hurt throws away nine walls to fix one.

Build one from scratch in your lab terminal, with a different name so nothing collides with the demo. The goal: an overall exposure under 4.5, with /var/lib/try-sbx still writable for the service. Predict each new number before you run the measurement. When you're done, the lab systemd-service-sandbox gives you a real worker with its own ceiling, state directory and one more duty to keep, and grades the merged result with this same analyser.