In traditional Linux environments, services (daemons) like NGINX, Redis, or custom Python APIs run with significantly more privileges than they actually need. Even if you drop root privileges and run the service as a dedicated user (e.g., www-data), that user still has broad access to the filesystem, network sockets, and kernel capabilities.
If an attacker discovers a Remote Code Execution (RCE) vulnerability in your web application, they can spawn a shell, read sensitive files in /etc/, execute arbitrary binaries in /bin/, or map memory to execute malicious payloads.
While Docker and Kubernetes provide containerized isolation, you do not need a massive container orchestration platform to secure a basic Linux daemon. Systemd, the init system running on almost every modern Linux distribution, possesses incredibly powerful, built-in sandboxing capabilities leveraging Linux cgroups and namespaces.
This guide explains how to use systemd-analyze security to audit a service and configure the systemd unit file to enforce military-grade daemon hardening.
Step 1: Auditing the Service with systemd-analyze
Before modifying a service, you must measure its current vulnerability footprint. Systemd provides an automated security auditing tool that scores the isolation of any running daemon.
Let’s audit a standard Redis database service:
systemd-analyze security redis-server.service
The output will generate an “Exposure” score, typically looking like this for an unhardened service:
→ Overall exposure level for redis-server.service: 9.2 UNSAFE 😨
An exposure score near 10 indicates the service has near-absolute freedom to modify the system. Our goal is to drive this score below 2.0.
Step 2: Hardening the Filesystem (Namespacing)
The first line of defense is preventing the daemon from reading or writing to the underlying OS filesystem.
Open the systemd unit file for editing (do not edit the file in /lib/systemd/system/ directly; use the systemd override mechanism):
sudo systemctl edit redis-server.service
Add the following parameters under the [Service] block to isolate the filesystem:
[Service]
# Mount / (the entire root filesystem) as strictly Read-Only.
ProtectSystem=strict
# Mount /home, /root, and /run/user as completely inaccessible and invisible.
ProtectHome=yes
# Give the daemon a completely private, isolated /tmp directory.
PrivateTmp=yes
(Note: Because ProtectSystem=strict makes the entire disk read-only, if your application needs to write logs or database files, you must explicitly whitelist specific directories using ReadWritePaths=/var/lib/redis).
Step 3: Stripping Kernel Capabilities
Linux utilizes “Capabilities” to break down root privileges into granular permissions (e.g., CAP_NET_BIND_SERVICE to bind to ports below 1024). A standard daemon usually does not need any of them.
Add these parameters to strip capabilities and secure the kernel boundary:
[Service]
# Drop all root capabilities entirely.
CapabilityBoundingSet=
# Deny access to kernel tunables in /proc/sys, /sys, /proc/sysrq-trigger.
ProtectKernelTunables=yes
# Prevent the daemon from loading custom kernel modules.
ProtectKernelModules=yes
# Prevent the daemon from modifying the system clock.
ProtectClock=yes
Step 4: Network and Execution Isolation
If an attacker compromises the daemon, they will likely try to download malware (using curl or wget) or open a reverse shell.
[Service]
# Prevent the daemon from executing any new binaries not in its original path.
NoNewPrivileges=yes
# Prevent the creation of user namespaces (mitigates many local privilege escalations).
RestrictNamespaces=yes
# Restrict the types of sockets the daemon can create.
# (If it only needs local Unix sockets, restrict AF_INET).
RestrictAddressFamilies=AF_INET AF_INET6
Step 5: Applying and Re-Auditing
After saving the override file, instruct systemd to reload its configuration and restart the daemon.
sudo systemctl daemon-reload
sudo systemctl restart redis-server.service
Ensure the service is actually running and you haven’t broken it by restricting a path it legitimately needs:
sudo systemctl status redis-server.service
If the service is running flawlessly, run the security analyzer again:
systemd-analyze security redis-server.service
You should see a drastically reduced exposure score:
→ Overall exposure level for redis-server.service: 1.1 OK 🙂
Conclusion
Relying solely on user permissions (like running as www-data) is an obsolete defense mechanism against modern exploitation techniques. By leveraging systemd’s built-in namespace, cgroup, and capability isolation features, systems administrators can instantly deploy Docker-level sandboxing directly onto bare-metal Linux daemons, mathematically trapping zero-day exploits inside a highly restricted execution environment.