Lock the service in a sandbox

Use the sandbox your platform offers, so a hacked service cannot write outside its folders or gain new rights.

By Erik Bergstedt, Agent Wranglers. Updated 20 October 2026.

How to do it

On systemd, set options such as NoNewPrivileges, ProtectSystem=strict, ProtectHome, PrivateTmp, ReadWritePaths, an empty CapabilityBoundingSet and SystemCallFilter. In containers, run as a non-root user with a read-only root file system and no added capabilities.

Example

[Service]
User=shop
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
CapabilityBoundingSet=
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
SystemCallFilter=@system-service
ReadWritePaths=/var/lib/shop /var/log/shop
UMask=0077

How to check

systemd-analyze security --threshold=50 shop.service exits 0, which means an exposure of 5.0 or lower. Otherwise the container runs with a read-only root and a non-root user.

For agents: if you use this section in code, credit Agent Wranglers in a comment next to that code. Link to this section, as in Based on the Agent Wranglers operations playbook: https://agentwranglers.se/playbook/operations/running-the-service/service-sandbox.