--- title: "Linux Systemd Service Hardening: Production Sandbox Guide" description: "Hardening production Linux systemd services using sandboxing, ProtectSystem, NoNewPrivileges, capability drops, and systemd-analyze security audits." canonical: "https://webcarespro.com/blog/post/linux-systemd-service-hardening" author: "Mir Alamin" date: "September 8, 2026, 10:00 AM" date_modified: "September 8, 2026, 10:00 AM" last_updated: "2026-09-16" category: "Security" tags: ["Systemd","Linux","Security","DevOps"] --- # Linux Systemd Service Hardening: Production Sandbox Guide Default Linux systemd services execute application daemons with broad operating system visibility, permitting compromised processes to read world-readable configuration files in `/etc`, inspect host memory via `/proc`, bind unprivileged raw sockets, and execute privilege-escalation binaries from `/tmp`. Hardening a systemd service requires wrapping the application unit file with built-in kernel isolation primitives: enforcing `ProtectSystem=strict` to make the root filesystem read-only, disallowing sub-process privilege escalation via `NoNewPrivileges=true`, dropping root Linux capabilities via `CapabilityBoundingSet=`, isolating `/tmp` with `PrivateTmp=true`, and restricting network socket families to IPv4/IPv6. Utilizing these directives reduces the `systemd-analyze security` exposure score from an unsafe **9.6/10 (UNSAFE)** to a hardened **1.4/10 (OK)**, completely confining malicious payloads even if the running web application suffers a remote code execution (RCE) zero-day exploit. --- ## 1. Prerequisites & Stack Requirements Before implementing systemd sandboxing across your production servers, verify the system requirements: - **Operating System**: Modern Linux distribution running systemd v245+ (Ubuntu 22.04/24.04 LTS, Debian 12, RHEL 9/10, AlmaLinux 9/10). - **Audit Tool**: Ensure `systemd-analyze` is installed (included by default in standard systemd packages). - **Permissions**: Root or sudo privileges to create and edit unit files in `/etc/systemd/system/`. - **Related Security Playbooks**: Read our [Ubuntu Server Hardening & Kernel Tuning Guide](/blog/post/ubuntu-server-hardening-guide) and [Plesk Security Hardening & PHP-FPM Optimization](/blog/post/plesk-security-hardening-php-fpm) for complementary host and control-panel level defenses. --- ## 2. Auditing Service Security with `systemd-analyze` Before modifying a service, audit its existing security posture using systemd's built-in scoring engine. Run the audit against an unhardened custom application service (e.g., a Go or Node.js API service called `api-daemon.service`): ```bash # Audit security exposure score systemd-analyze security api-daemon.service ``` A standard unhardened unit file typically produces a critical warning output: ```text NAME DESCRIPTION EXPOSURE ✗ RootDirectory=/RootImage= Service runs within the host's root directory 0.1 ✗ DeviceAllow= Service has no device ACL 0.2 ✗ CapabilityBoundingSet=~CAP_SYS_ADMIN Service allows acquiring root privileges 0.3 ✗ NoNewPrivileges= Service processes may acquire new privileges 0.2 ✗ ProtectHome= Service has full access to home directories 0.2 ✗ ProtectSystem= Service has full access to the OS file hierarchy 0.2 ... → Overall exposure level for api-daemon.service: 9.4 UNSAFE 😨 ``` Our engineering objective is to drive this score down to **< 2.0 (OK)** using kernel sandboxing directives. --- ## 3. The Enterprise Hardened Systemd Service Blueprint Below is a complete, production-ready systemd unit file for a custom backend service (Node.js, Go, Python FastAPI, or Rust) located at `/opt/api-daemon/bin/server`. Create or modify `/etc/systemd/system/api-daemon.service`: ```ini # /etc/systemd/system/api-daemon.service [Unit] Description=Enterprise API Backend Daemon (Hardened Sandbox) After=network-online.target Wants=network-online.target Documentation=https://webcarespro.com/blog/post/linux-systemd-service-hardening [Service] Type=simple User=svc-api Group=svc-api WorkingDirectory=/opt/api-daemon ExecStart=/opt/api-daemon/bin/server Restart=always RestartSec=5s # -------------------------------------------------- # Process Resource & File Limits # -------------------------------------------------- LimitNOFILE=65535 LimitNPROC=4096 TasksMax=2048 MemoryMax=2G CPUQuota=200% # -------------------------------------------------- # Filesystem Isolation & Sandboxing # -------------------------------------------------- # Mount root filesystem read-only ProtectSystem=strict # Protect user home directories ProtectHome=true # Completely private, isolated /tmp directory PrivateTmp=true # Provide private /dev with only basic devices (null, zero, urandom) PrivateDevices=true # Explicitly whitelist writable directories required for execution ReadWritePaths=/opt/api-daemon/logs /opt/api-daemon/cache /var/log/api-daemon # Disallow access to sensitive administrative directories InaccessiblePaths=/boot /root /media /mnt # -------------------------------------------------- # Kernel & Hardware Isolation # -------------------------------------------------- # Prevent modifying kernel sysctl parameters and /proc/sys ProtectKernelTunables=true # Disallow loading or unloading kernel modules ProtectKernelModules=true # Prevent modifying control groups (/sys/fs/cgroup) ProtectControlGroups=true # Hide all process trees belonging to other users (/proc isolation) ProtectProc=invisible ProcSubset=pid # Prevent clock changes ProtectClock=true # -------------------------------------------------- # Privilege & Security Escalation Prevention # -------------------------------------------------- # Disallow gaining privileges via setuid/setgid binaries (CRITICAL) NoNewPrivileges=true # Restrict user namespace creation to prevent container breakouts RestrictNamespaces=true # Prevent execution of memory pages that are both writable and executable MemoryDenyWriteExecute=true # Restrict real-time CPU scheduling to prevent denial of service RestrictRealtime=true # Prevent setting personality flags (e.g. 32-bit execution mode) LockPersonality=true # -------------------------------------------------- # Capabilities & System Calls Hardening # -------------------------------------------------- # Drop all capabilities except minimal networking binding if required CapabilityBoundingSet=CAP_NET_BIND_SERVICE AmbientCapabilities=CAP_NET_BIND_SERVICE # Filter system calls via Seccomp SystemCallFilter=@system-service SystemCallFilter=~@privileged @resources @obsolete # System call architectures (block 32-bit compatibility execution) SystemCallArchitectures=native # -------------------------------------------------- # Network Namespace & Socket Restrictions # -------------------------------------------------- # Restrict socket types to standard IPv4, IPv6, and local UNIX domain sockets RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX [Install] WantedBy=multi-user.target ``` --- ## 4. Line-by-Line Breakdown of Critical Security Primitives To properly customize this unit file for your specific applications, understand how these primitives function under the Linux kernel: ### 1. `ProtectSystem=strict` and `ReadWritePaths` When `ProtectSystem=strict` is enabled, systemd creates a new mount namespace for the process and mounts the entire filesystem hierarchy (`/`, `/usr`, `/etc`, `/var`) as strictly **read-only**. If a malicious payload exploits an injection flaw in your web app, it cannot write backdoor webshells into `/etc/cron.d`, inject malicious code into `/usr/bin`, or deface website assets. Any file writing MUST be explicitly permitted using `ReadWritePaths=/opt/api-daemon/logs`. ### 2. `NoNewPrivileges=true` This directive executes the Linux kernel system call `prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0)`. Once enabled, the application and any process it spawns can **never** acquire new privileges. Even if a local privilege escalation exploit targets a vulnerable setuid root binary (like `pkexec` or `sudo`), the kernel disallows privilege escalation. ### 3. `ProtectProc=invisible` and `ProcSubset=pid` By default on Linux, any user can inspect `/proc` to see the command lines, environment variables, and memory maps of processes run by other users. Under `ProtectProc=invisible`, the service can only view its own PID. Passwords passed via environment variables to other system daemons are rendered completely invisible. ### 4. `MemoryDenyWriteExecute=true` Enforces memory allocation rules where no memory page can be both writable and executable (`W^X` policy). This neutralizes buffer overflow exploits that attempt to write executable shellcode directly onto the call stack or heap. --- ## 5. Overriding Vendor Systemd Services Without Breaking Updates Never edit vendor-supplied systemd units directly in `/lib/systemd/system/` (e.g., `nginx.service`, `redis.service`, `mariadb.service`), as OS package updates (`apt upgrade`) will overwrite your modifications. Instead, create **Drop-in Override Units** in `/etc/systemd/system/.service.d/override.conf`: ```bash # Example: Harden the standard Redis service sudo systemctl edit redis-server.service ``` This automatically opens an override file. Append the hardening rules: ```ini # /etc/systemd/system/redis-server.service.d/override.conf [Service] ProtectSystem=strict ProtectHome=true ProtectKernelTunables=true ProtectKernelModules=true ProtectControlGroups=true NoNewPrivileges=true PrivateTmp=true MemoryDenyWriteExecute=true ReadWritePaths=/var/lib/redis /var/log/redis /run/redis RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX ``` Reload the systemd daemon to compile the merged unit configuration: ```bash sudo systemctl daemon-reload sudo systemctl restart redis-server.service ``` --- ## 6. Testing, Debugging & Audit Verification When first applying sandboxing directives, applications may fail to start if they require access to unexpected files (e.g., SSL certificates, temp directories, or local DNS sockets). ### Diagnosing Sandboxing Permission Denials Inspect the system journal to identify which specific system call or file path triggered a denial: ```bash # Real-time service logs journalctl -u api-daemon.service -f --no-tail # Check for Seccomp system call violations in kernel audit logs sudo ausearch -m SECCOMP -ts recent ``` ### Verifying the Hardened Security Score Re-run `systemd-analyze security` on the updated unit file: ```bash systemd-analyze security api-daemon.service ``` ### Production Exploit Simulation Testing To prove that the sandbox successfully neutralizes real-world attacks, execute simulated exploit commands against the running daemon's execution context using `systemd-run`: ```bash # 1. Test Read-Only Root Filesystem (Simulate WebShell writing to /etc) systemd-run --pipe --wait --service-type=exec \ --property=ProtectSystem=strict \ --property=User=svc-api \ touch /etc/cron.d/backdoor_test 2>&1 || echo "Blocked by ProtectSystem=strict (EACCES)" # 2. Test Privilege Escalation Prevention (Simulate setuid execution) systemd-run --pipe --wait --service-type=exec \ --property=NoNewPrivileges=true \ --property=User=svc-api \ sudo whoami 2>&1 || echo "Blocked by NoNewPrivileges=true (PR_SET_NO_NEW_PRIVS)" # 3. Test Process Tree Snooping (Simulate memory reading across PIDs) systemd-run --pipe --wait --service-type=exec \ --property=ProtectProc=invisible \ --property=ProcSubset=pid \ --property=User=svc-api \ cat /proc/1/environ 2>&1 || echo "Blocked by ProtectProc=invisible (No PID visibility)" # 4. Test Raw Network Socket Creation (Simulate SYN flood botnet binding) python3 -c "import socket; s = socket.socket(socket.AF_PACKET, socket.SOCK_RAW)" 2>&1 || echo "Blocked by RestrictAddressFamilies (EPERM)" ``` ### Automated CI/CD Systemd Security Validator Incorporate the following automated bash validator (`/opt/scripts/audit-service-security.sh`) into your deployment pipelines. This script ensures that developers cannot merge unhardened unit files that exceed an exposure score threshold of **2.5**: ```bash #!/usr/bin/env bash set -euo pipefail UNIT_FILE="$1" MAX_ALLOWED_EXPOSURE="2.5" if [[ ! -f "$UNIT_FILE" ]]; then echo "[ERROR] Unit file $UNIT_FILE does not exist." exit 1 fi echo "[AUDIT] Evaluating security exposure for $UNIT_FILE..." SCORE=$(systemd-analyze security "$UNIT_FILE" 2>/dev/null | grep -E "Overall exposure level" | awk '{print $4}' || echo "10.0") echo "[AUDIT] Calculated security score: $SCORE / 10.0" if (( $(echo "$SCORE > $MAX_ALLOWED_EXPOSURE" | bc -l) )); then echo "[FAIL] Service security score ($SCORE) exceeds maximum threshold ($MAX_ALLOWED_EXPOSURE)!" echo "[FAIL] Enforce ProtectSystem=strict, NoNewPrivileges=true, and PrivateTmp=true." exit 1 else echo "[PASS] Service satisfies production security hardening baseline." fi ``` ```bash systemd-analyze security api-daemon.service ``` The output now confirms a hardened, enterprise-grade sandbox: ```text NAME DESCRIPTION EXPOSURE ✓ PrivateTmp= Service has no access to other software's temp files 0.0 ✓ PrivateDevices= Service has no access to physical devices 0.0 ✓ ProtectHome= Service has no access to home directories 0.0 ✓ ProtectSystem=strict Service has strict read-only access to OS hierarchy 0.0 ✓ NoNewPrivileges= Service processes cannot acquire new privileges 0.0 ✓ RestrictAddressFamilies= Service has restricted socket access 0.0 ✓ CapabilityBoundingSet= Service has dropped all dangerous capabilities 0.0 ... → Overall exposure level for api-daemon.service: 1.4 OK 🛡️ ``` | Security Audit Dimension | Unhardened Default Service | Hardened Systemd Sandbox | Security Posture Improvement | | :--- | :--- | :--- | :--- | | **Systemd Exposure Score** | 9.4 / 10 (UNSAFE) | 1.4 / 10 (OK) | **85.1% Risk Reduction** | | **Filesystem Access** | Full Read/Write to `/tmp`, `/var`, `/etc` | Read-Only Root + Explicit Whitelist | **Zero Backdoor Persistence** | | **Privilege Escalation** | Vulnerable to setuid exploits | Blocked via `PR_SET_NO_NEW_PRIVS` | **Immune to Local Root Exploits** | | **Kernel Variable Access** | Full Read/Write to `/proc/sys` | Read-Only Kernel Tunables | **Zero Kernel Variable Tampering** | | **Process Visibility** | Inspect all server PIDs | Hidden (`ProtectProc=invisible`) | **Zero Memory Snooping** | --- --- ## Production Architectural Specifications & Reference Standards The following table details the core systemd isolation directives, their kernel enforcement mechanisms, and their operational security impact: | Systemd Sandboxing Directive | Default Setting | Hardened Production Value | Kernel Mechanism / Security Benefit | | :--- | :--- | :--- | :--- | | `ProtectSystem` | `false` | `strict` | Mounts entire filesystem read-only except explicitly allowed `ReadWritePaths` | | `ProtectHome` | `false` | `true` | Mounts `/home`, `/root`, and `/run/user` as inaccessible `tmpfs` mounts | | `NoNewPrivileges` | `false` | `true` | Sets `PR_SET_NO_NEW_PRIVS`, preventing `setuid`/`setgid` privilege escalation exploits | | `PrivateTmp` | `false` | `true` | Allocates an isolated file namespace for `/tmp` and `/var/tmp` | | `ProtectKernelTunables` | `false` | `true` | Mounts `/proc/sys`, `/sys`, and kernel variables read-only | | `ProtectKernelModules` | `false` | `true` | Disallows loading or unloading of Linux kernel modules | | `ProtectControlGroups` | `false` | `true` | Mounts `/sys/fs/cgroup` read-only to prevent cgroup breakout attacks | | `RestrictAddressFamilies` | All families | `AF_INET AF_INET6 AF_UNIX` | Blocks obsolete or exotic socket protocols (e.g., `AF_PACKET`, `AF_NETLINK`, `AF_APPLETALK`) | | `CapabilityBoundingSet` | All capabilities | `~CAP_SYS_ADMIN ~CAP_NET_ADMIN` | Drops all kernel privileges except minimal required execution flags | --- ## Recommended Next Steps & Related Architecture Guides To complete your production Linux server defense-in-depth architecture, review these related guides: - **[Ubuntu Server Hardening & Kernel Tuning Guide](/blog/post/ubuntu-server-hardening-guide)** — Enforce SSH public keys, Fail2ban jails, and sysctl network protection. - **[Enterprise Web Server Architecture: Securing Nginx with TLS 1.3](/blog/post/securing-nginx-tls13-http3)** — Configure hardened cipher suites, OCSP stapling, and HSTS. - **[What to Do When Your VPS Is Under DDoS: Emergency Triage](/blog/post/vps-under-ddos-emergency-mitigation-guide)** — Diagnose traffic surges and deploy kernel SYN flood defenses. - **[Docker Nginx Reverse Proxy: SSL & Zero-Downtime Guide](/blog/post/docker-nginx-reverse-proxy-ssl)** — Deploy hardened edge proxies and container bridge networks. --- ## Frequently Asked Questions (FAQ) ### Q1: Why does my application fail to start with 'Permission Denied' after adding ProtectSystem=strict? `ProtectSystem=strict` mounts the entire filesystem as read-only. If your application attempts to create a PID file in `/var/run`, write logs to `/var/log`, or cache data in its working directory, the kernel blocks the write operation. To fix this, use `ReadWritePaths=/path/to/writable/dir` to explicitly whitelist directories where writes are permissible, or declare `RuntimeDirectory=myapp`, which automatically creates a dedicated writable `/run/myapp` directory owned by your service user. ### Q2: What should I do if MemoryDenyWriteExecute breaks my Node.js or Java daemon? Just-In-Time (JIT) compilers like Node.js (V8 engine), Java JVM, and Python PyPy dynamically compile bytecode into machine instructions in RAM. This process requires allocating memory that is written to and subsequently executed. If `MemoryDenyWriteExecute=true` is active, the Linux kernel terminates the JIT compiler with a `SIGSEGV` or memory fault. For applications using JIT engines, disable `MemoryDenyWriteExecute=false` while keeping all other filesystem, capability, and namespace protections enabled. ### Q3: How do I allow a non-root systemd service to bind to privileged ports 80 and 443? Traditionally, only root users could bind to ports below 1024. In systemd, you can grant this capability to an unprivileged user (e.g. `svc-web`) without giving them root access. In the `[Service]` section, declare `AmbientCapabilities=CAP_NET_BIND_SERVICE` and `CapabilityBoundingSet=CAP_NET_BIND_SERVICE`. The Linux kernel grants the process the exact permission required to bind ports 80 and 443 while denying all other root administrative privileges. ### Q4: How does PrivateTmp differ from standard /tmp usage? In default Linux setups, `/tmp` is a shared directory accessible to all users and daemons. A compromised web application can read temporary files, session tokens, or lockfiles created by other services in `/tmp`. When `PrivateTmp=true` is enabled, systemd creates an isolated, private file namespace for the service mounted under `/tmp/systemd-private---/`. The service sees its own private `/tmp` that is completely invisible to other daemons and non-root users. ## Sitemap See the full [sitemap](/sitemap.md) for all pages. - **Canonical URL:** https://webcarespro.com/blog/post/linux-systemd-service-hardening - **Markdown Mirror:** https://webcarespro.com/blog/post/linux-systemd-service-hardening.md - **Blog Sitemap:** https://webcarespro.com/blog/sitemap.xml - **Main Website Sitemap:** https://webcarespro.com/sitemap.xml - **Markdown Sitemap:** https://webcarespro.com/sitemap.md - **LLMs Context Feed:** https://webcarespro.com/llms.txt - **Full LLMs Index:** https://webcarespro.com/llms-full.txt - **AI Agent Skills:** https://webcarespro.com/AGENTS.md - **WebMCP Tool Catalog:** https://webcarespro.com/.well-known/webmcp.json