{"id":365,"date":"2026-10-08T07:22:09","date_gmt":"2026-10-08T14:22:09","guid":{"rendered":"https:\/\/blog.canutethegreat.com\/index.php\/2026\/10\/08\/least-privilege-with-systemd-sandboxing\/"},"modified":"2026-10-20T20:23:12","modified_gmt":"2026-10-21T03:23:12","slug":"least-privilege-with-systemd-sandboxing","status":"publish","type":"post","link":"https:\/\/blog.canutethegreat.com\/index.php\/2026\/10\/08\/least-privilege-with-systemd-sandboxing\/","title":{"rendered":"Least privilege with systemd sandboxing"},"content":{"rendered":"\n

Part 2 of 4 in the Hardening a Linux server series. Previously: Part 1, SSH hardening beyond “disable root login”<\/a>.<\/em><\/p>\n\n\n\n

Most services on a Linux box run with far more access than they need. A web app that reads a config file, writes to one data directory and listens on one port can, by default, read most of the filesystem, write anywhere its user owns, call every syscall the kernel offers and open any kind of socket. When that app gets popped through a deserialization bug, all of that becomes the attacker’s starting position.<\/p>\n\n\n\n

systemd has grown a large set of sandboxing directives that fix this with a few lines in a unit file. No containers, no AppArmor profiles to maintain, no code changes. I think they’re the best return on effort in Linux hardening right now, and they’re still rarely used outside of the units systemd itself ships.<\/p>\n\n\n\n

Measure first<\/h2>\n\n\n\n
\"Bar<\/figure>\n\n\n\n

systemd-analyze security<\/code> scores every running service from 0 (locked down) to 10 (wide open) and lists each check it applied:<\/p>\n\n\n\n

systemd-analyze security\nsystemd-analyze security nginx.service<\/code><\/pre>\n\n\n\n
The number is a heuristic, a weighted sum of which directives are set, so don’t treat 2.1 versus 2.4 as meaningful. It is very good at showing you the gaps. On most distributions the bulk of third-party services score 9 or above.<\/p>\n\n\n\n
Measured: one unit, hardened step by step<\/h2>\n\n\n\n
I took a trivial unit (python3 -m http.server<\/code> running as a dedicated user) and added directives in groups, scoring each version with systemd-analyze security<\/code> on systemd 249. The chart near the top of this post shows the result. The baseline scored 9.2. The final unit scored 1.0.<\/p>\n\n\n\n
Here is roughly what that final unit looks like, adjusted for a real service:<\/p>\n\n\n\n
[Service]\nExecStart=\/opt\/webapp\/bin\/webapp\nDynamicUser=yes\nStateDirectory=webapp\nConfigurationDirectory=webapp\n\nNoNewPrivileges=yes\nProtectSystem=strict\nProtectHome=yes\nPrivateTmp=yes\nPrivateDevices=yes\nProtectKernelTunables=yes\nProtectKernelModules=yes\nProtectKernelLogs=yes\nProtectControlGroups=yes\nProtectClock=yes\nProtectHostname=yes\nProtectProc=invisible\n\nCapabilityBoundingSet=CAP_NET_BIND_SERVICE\nAmbientCapabilities=CAP_NET_BIND_SERVICE\n\nSystemCallArchitectures=native\nSystemCallFilter=@system-service\nSystemCallFilter=~@privileged @resources\nSystemCallErrorNumber=EPERM\n\nRestrictAddressFamilies=AF_UNIX AF_INET  \"AF_INET6\nRestrictNamespaces=yes\nRestrictSUIDSGID=yes\nRestrictRealtime=yes\nLockPersonality=yes\nMemoryDenyWriteExecute=yes\nUMask\" =0077<\/code><\/pre>\n\n\n\n
That looks like a lot. Each line is cheap, though, and they fall into a few families.<\/p>\n\n\n\n
Privilege escalation inside the service<\/h2>\n\n\n\n
NoNewPrivileges=yes<\/code> sets the kernel’s no_new_privs<\/code> flag, so nothing the service executes can gain privileges through setuid binaries or file capabilities. An attacker with code execution as the service user can’t then run a vulnerable setuid helper to become root. Several other directives quietly turn it on as well, which is fine.<\/p>\n\n\n\n
Capabilities are the other half. CapabilityBoundingSet=<\/code> with an empty value drops every capability for good. The example keeps exactly one, CAP_NET_BIND_SERVICE<\/code>, and grants it as an ambient capability so a non-root process can bind port 443. That is the right shape for most daemons that historically started as root just to grab a low port.<\/p>\n\n\n\n
DynamicUser=yes<\/code> allocates a throwaway UID when the service starts. It implies a stricter set of defaults (read-only system, private \/tmp<\/code>, no setuid), and combined with StateDirectory=<\/code> systemd creates and chowns \/var\/lib\/webapp<\/code> for you. If the service doesn’t need a stable UID shared with other software, use it.<\/p>\n\n\n\n
Filesystem view<\/h2>\n\n\n\n
ProtectSystem=strict<\/code> mounts the entire filesystem read-only for the service, apart from the API filesystems like \/proc<\/code> and \/sys<\/code>. Writable paths are then opt-in through StateDirectory=<\/code>, CacheDirectory=<\/code>, LogsDirectory=<\/code> or ReadWritePaths=<\/code>. This is the directive that stops an attacker dropping a cron job, a systemd unit or a modified binary for persistence. ProtectHome=yes<\/code> hides \/home<\/code>, \/root<\/code> and \/run\/user<\/code> entirely, which matters more than people think, since home directories are where SSH keys and cloud credentials live.<\/p>\n\n\n\n
PrivateTmp=yes<\/code> gives the service its own \/tmp<\/code>, which closes off the classic symlink and race games other local users can play in a shared \/tmp<\/code>.<\/p>\n\n\n\n
Kernel attack surface<\/h2>\n\n\n\n
A sandbox that lives in userspace can’t save you from a kernel bug, but it can make most kernel bugs unreachable. SystemCallFilter=@system-service<\/code> is an allowlist of syscalls that ordinary services use, curated by systemd. The second line then removes @privileged<\/code> and @resources<\/code>. By default a blocked syscall kills the process with SIGSYS<\/code>; SystemCallErrorNumber=EPERM<\/code> makes it fail with an error instead, which is friendlier while you’re tuning.<\/p>\n\n\n\n
RestrictNamespaces=yes<\/code> deserves a specific mention. A good number of recent Linux privilege escalation bugs are only reachable by unprivileged users through user namespaces, because creating one hands you capabilities inside it. CVE-2022-0185, a heap overflow in the filesystem context code, is the textbook case: exploitation needed CAP_SYS_ADMIN<\/code> in a user namespace, which any unprivileged user could get on distributions that allowed unprivileged user namespaces. A service that can’t create namespaces can’t reach that code path at all.<\/p>\n\n\n\n
PrivateDevices=yes<\/code>, ProtectKernelModules=yes<\/code> and ProtectKernelTunables=yes<\/code> take away raw device nodes, module loading and writes to \/proc\/sys<\/code>. SystemCallArchitectures=native<\/code> blocks the 32-bit syscall ABI on 64-bit hosts, a path that has been used to dodge seccomp filters written for one ABI only.<\/p>\n\n\n\n
Network<\/h2>\n\n\n\n
RestrictAddressFamilies=<\/code> limits which socket types the service may open. Most need AF_UNIX<\/code>, AF_INET<\/code> and AF_INET6<\/code>, nothing else, and certainly not AF_PACKET<\/code> or AF_NETLINK<\/code>. If you want per-service egress control, IPAddressDeny=any<\/code> with a narrow IPAddressAllow=<\/code> uses a cgroup BPF filter to drop traffic to anything else. A compromised internal API that can’t reach the internet is a lot less useful as a staging point.<\/p>\n\n\n\n
Rolling it out without breaking things<\/h2>\n\n\n\n
Don’t edit vendor units. Use systemctl edit webapp.service<\/code> to write a drop-in under \/etc\/systemd\/system\/webapp.service.d\/<\/code>, which survives package upgrades. You can try options on a throwaway command before committing to them:<\/p>\n\n\n\n
sudo systemd-run --pty --wait -p ProtectSystem=strict -p PrivateTmp=yes \\\n  -p SystemCallFilter=@system-service \/opt\/webapp\/bin\/webapp --selftest<\/code><\/pre>\n\n\n\n
The usual breakage is predictable. MemoryDenyWriteExecute=yes<\/code> breaks anything with a JIT, so Node, the JVM and PCRE’s JIT mode will fail in confusing ways. ProtectSystem=strict<\/code> breaks services that write somewhere surprising, which the journal will show as EROFS<\/code> errors. Syscall filters occasionally catch a library doing something unusual, and with SystemCallErrorNumber=EPERM<\/code> the audit log or strace -f<\/code> tells you which call. Add one family at a time and run your integration tests between each.<\/p>\n\n\n\n
This doesn’t replace patching or a proper MAC policy, and it isn’t a VM boundary. What it does is shrink the blast radius of the next RCE in your app from “the box” to “one directory and a socket”. Part 3 covers auditd, so that when something does get through you can see what it tried to do.<\/p>\n\n\n\n
Other parts of the Hardening a Linux server series: Part 1: SSH hardening beyond “disable root login”<\/a>, Part 3: auditd and what to log<\/a>, Part 4: Patching without fear<\/a>.<\/em><\/p>\n\n","protected":false},"excerpt":{"rendered":"
Part 2 of 4 in the Hardening a Linux server series. Previously: Part 1, SSH hardening beyond “disable root login”. Most services on a Linux box run with far more access than they need. A web app that reads a config file, writes to one data directory and listens on one port can, by default, […]<\/p>\n","protected":false},"author":1,"featured_media":367,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[22,21],"tags":[88,95,94,96,93],"class_list":["post-365","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux","category-security","tag-hardening-a-linux-server-series","tag-least-privilege","tag-sandboxing","tag-seccomp","tag-systemd"],"_links":{"self":[{"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/posts\/365","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/comments?post=365"}],"version-history":[{"count":1,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/posts\/365\/revisions"}],"predecessor-version":[{"id":393,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/posts\/365\/revisions\/393"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/media\/367"}],"wp:attachment":[{"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/media?parent=365"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/categories?post=365"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.canutethegreat.com\/index.php\/wp-json\/wp\/v2\/tags?post=365"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}