A long-running Linux service should have access to the resources it needs, not every writable directory and privilege its host can offer. systemd provides controls that narrow that environment. The challenge is applying them to the service’s actual behavior while checking that the underlying operating system can enforce the chosen restrictions.
The systemd.exec manual describes privilege and filesystem sandboxing settings, along with important limitations. This guide focuses on a small, understandable set: NoNewPrivileges, ProtectSystem, PrivateTmp, and explicit writable paths. It is a service-hardening workflow, not a claim that these settings create a complete isolation boundary for every deployment.
Start with a resource contract
Before adding restrictions, identify the service account, executable, working directory, configuration inputs, state files, logs, temporary files, and required communication endpoints. Include background jobs and maintenance helpers. A service that starts successfully may still fail later when it attempts a scheduled write or calls a separate helper program.
Distinguish application state from operating-system configuration. A network daemon that writes its own database does not necessarily need permission to modify system software or arbitrary home directories. The hardening plan should describe specific resources and why they are required rather than begin with a blanket exception for everything under /var.
Use an authorized staging instance or controlled maintenance window. Capture the existing unit configuration and a supported route to restore it. Keep an independent administration path available where appropriate; hardening a remotely managed service should not accidentally remove the only way to repair the host.
NoNewPrivileges blocks a specific escalation path
The manual says NoNewPrivileges, when true, prevents the service and its children from gaining new privileges through execve, including setuid, setgid, and filesystem capabilities. That is a concrete restriction on privilege gain during execution. It does not remove privileges the process already possessed when it started.
Review the account and existing capabilities separately. Running a service with unnecessary authority and then enabling NoNewPrivileges does not turn that service into an unprivileged application. The starting permissions remain part of the threat model, and access to sensitive resources can still be excessive without a new privilege transition.
Check legitimate helpers before rollout. If the workload depends on an executable that requires one of the blocked transitions, the service may fail under the new setting. Prefer a supported redesign with a clear privilege boundary where feasible rather than disabling the restriction without understanding the dependency.
ProtectSystem narrows filesystem writes
The documented ProtectSystem values have different scopes. A true value makes /usr and the boot-loader directories read-only for the unit’s processes; full additionally includes /etc. Strict extends the read-only treatment broadly across the filesystem hierarchy, subject to the documented exceptions and limitations.
Select the scope that fits the service rather than assuming the strongest-looking word is universally compatible. A daemon that maintains application state needs an approved writable location. A system-management service may have requirements that make broad read-only restrictions unsuitable without a different design.
The restriction is not the same as deleting files or changing the host’s entire filesystem policy. It affects the unit’s execution environment through the relevant mechanisms. Other services can have different views and permissions, which is why validation needs to examine the actual process rather than only the host’s directory listing.
Writable exceptions should be narrow
The manual describes ReadWritePaths as a way to allow specific writable paths within a read-only view. It also identifies managed directory settings, such as StateDirectory and LogsDirectory, that can establish appropriate exceptions. Use the supported unit design that matches the service’s persistence and ownership requirements.
An allow-listed path does not automatically grant ordinary filesystem permissions. The documented access modes still matter, and a genuinely read-only underlying filesystem cannot be made writable merely through ReadWritePaths. Check the service account’s permissions, directory ownership, and actual mount state when diagnosing a failed write.
Avoid expanding an exception to a broad parent directory just because one file operation failed. Find the exact location and reason. A narrowly scoped state directory is easier to audit than a permission change that unintentionally exposes unrelated services’ files to the same process.
PrivateTmp changes sharing assumptions
PrivateTmp gives the service a separate temporary-directory environment where supported. The manual says its /tmp and /var/tmp are not shared with processes outside the namespace, and temporary files created there are removed after the service stops. That can reduce accidental interaction through shared temporary locations.
It can also break a legitimate workflow that uses a shared temporary path to communicate with another process. Identify those dependencies before enabling the setting. Do not interpret a missing file as random application corruption when a newly isolated namespace explains why the processes no longer see the same location.
Temporary storage should not be the only home of durable application data. If the service expects something to survive restarts, use a supported persistent location and lifecycle. PrivateTmp makes an existing architectural mistake more visible; disabling it does not turn temporary files into a reliable persistence strategy.
Check enforcement on the target system
The manual warns that some sandboxing features are unavailable or gracefully disabled when the required underlying mechanisms are absent. Filesystem namespacing may be unavailable in a particular kernel or container environment. Per-user services also have different constraints from services run by the system manager.
Consult the documentation for the installed systemd version and the actual deployment platform. The latest online manual may describe settings or behavior not present on an older distribution build. A unit file containing a directive is not, by itself, proof that the intended restriction is active.
Test from the service’s execution context. Verify a permitted write and a denied write using safe, synthetic locations and supported diagnostic methods. The useful evidence is that the actual workload can use its approved resources and cannot perform the specific unintended operation being tested.
Filesystem protection does not isolate every channel
The manual explicitly notes that read-only directory controls do not prevent programs from communicating with AF_UNIX sockets in those directories. A service may therefore reach another local service even when the surrounding directory cannot be written. Filesystem write restrictions and interprocess communication access are different concerns.
Network access also requires separate consideration. A restricted filesystem does not automatically stop an application from reading sensitive data it can still access and sending it to an allowed network endpoint. Review communication requirements and any supported additional controls according to the workload’s needs.
The manual documents mount-propagation limitations as well. Do not claim that a static directory restriction controls every later submount without checking those conditions. Hardening should retain these boundaries in its explanation rather than simplify them into “the service cannot touch the host.”
Roll out small changes with meaningful tests
Apply a small group of understood controls, reload and restart through the supported service-management process, and check real workflows. Include startup, normal requests, scheduled jobs, log handling, and shutdown. A process that remains running can still be failing its useful work.
When a test fails, inspect sanitized service logs and the resource contract. Adjust the smallest supported requirement and retest. Avoid returning the entire service to unrestricted operation as the first troubleshooting step; that discards the evidence needed to understand which boundary was actually incompatible.
The takeaway is practical: define the service’s resources, narrow privilege transitions and writes, and verify enforcement in the real execution environment. systemd sandboxing can reduce exposure, but the controls have distinct scopes and platform limitations. A documented, tested unit configuration is more defensible than a long list of copied hardening directives whose effects nobody has checked.
