Sandboxing and Limits

Identity and Privileges

Everything in this topic goes in [Service]. Start here, because dropping root is worth more than every other directive combined.

[Service]
User=myapp
Group=myapp
NoNewPrivileges=yes
CapabilityBoundingSet=

An empty CapabilityBoundingSet= means no capabilities at all, the right default for an ordinary daemon. To bind port 80 as a non-root user, grant exactly one:

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

AmbientCapabilities= without the matching CapabilityBoundingSet= entry silently gives you nothing, because the bounding set is a ceiling. NoNewPrivileges=yes does not interfere with ambient capabilities, so keep it on.

Filesystem Isolation

The workhorse combination:

[Service]
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
PrivateDevices=yes
StateDirectory=myapp
ReadWritePaths=/srv/myapp/uploads

ProtectSystem=strict is the one that breaks services, and always for the same reason: something needs to write and you did not list it. Prefer StateDirectory= and friends over ReadWritePaths=, because they also create the directory with the right owner. Note that these are per-unit mount namespaces, so the paths still look normal from outside.

Kernel and Namespace Hardening

Syscall and Socket Filters

[Service]
SystemCallFilter=@system-service
SystemCallFilter=~@privileged @resources @obsolete
SystemCallErrorNumber=EPERM
SystemCallArchitectures=native
RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6

List the members of any group before you rely on it:

systemd-analyze syscall-filter                # all known groups
systemd-analyze syscall-filter @system-service
systemd-analyze syscall-filter @privileged

Groups worth knowing: @system-service, @basic-io, @privileged, @resources, @raw-io, @mount, @module, @reboot, @swap, @debug, @clock, @cpu-emulation, @obsolete, @keyring.

Resource Limits

Two different mechanisms, and people mix them up. Limit*= are per-process setrlimit(2) values. Everything else is a cgroup v2 control that applies to the unit as a whole.

[Service]
MemoryHigh=1G
MemoryMax=2G
CPUQuota=200%
TasksMax=512
LimitNOFILE=65535
LimitCORE=infinity
OOMPolicy=stop

LimitCORE=infinity is required if you want the kernel to write a core dump for this unit. MemoryMax= alone is a cliff, MemoryHigh= below it gives you back-pressure and a chance to see the problem in the journal first.

systemctl show -p MemoryMax -p CPUQuotaPerSecUSec -p TasksMax myapp.service
systemd-cgtop                                  # live per-unit resource use
systemd-cgls                                   # the cgroup tree
systemctl set-property myapp.service MemoryMax=4G

Audit What You Wrote

systemd-analyze security myapp.service
systemd-analyze security --no-pager nginx.service | head -40
systemd-analyze security '*.service'

Every directive is scored, with an overall exposure level from 0.0 (hardened) to 10.0 (wide open) and a name from safe through unsafe. It reads only the unit definition, so it is safe to run anywhere, and it is the fastest way to find the one Protect* line you forgot.

Tighten in this order, restarting and testing after each step: User= and NoNewPrivileges=, then ProtectSystem= and ProtectHome=, then the Protect* kernel set, then SystemCallFilter=. Adding all of it at once leaves you with a 226/NAMESPACE or a SIGSYS and no idea which line caused it. journalctl -u myapp -p err plus systemd-analyze security usually names the culprit immediately.