Using systemd ProtectProc and ProcSubset to limit service process visibility

Linux services often read /proc to discover peers, inspect their own status or collect metrics. The same filesystem can also reveal command lines, environment data and process relationships that a compromised worker does not need. systemd provides ProtectProc= and ProcSubset= for changing the service's view of /proc without rewriting the application.

ProtectProc= controls which processes are visible in /proc to the service. The invisible mode is intended to hide processes outside the service's view while keeping its own processes available. ProcSubset=pid restricts the visible entries to process-related files. These settings are useful complements to PrivateTmp=, ProtectSystem= and NoNewPrivileges=, but they should be applied according to what the service actually needs.

Start with a readable service contract

Record why the service reads /proc. A monitoring agent may need host-wide process data. A web worker usually needs only the contents of its own process namespace. A backup job may need mounted filesystem information, which ProcSubset=pid can hide. The unit file should reflect that requirement rather than adopt the strongest setting that happens to keep the test suite green.

For a typical application worker, start with ProtectProc=invisible and test startup, health checks, thread creation and log collection. Add ProcSubset=pid only when the application does not need non-process entries. Some runtimes inspect /proc/meminfo, /proc/cpuinfo or filesystem tables. If those reads fail, the correct response is to narrow the control or provide the required data another way, not to ignore repeated errors.

Treat process visibility as an authorization boundary

The setting reduces what a process can learn after compromise, but it does not replace Unix permissions. A service running as root can still do far more than one running as an unprivileged account. Use User=, Group= and filesystem permissions as the primary controls, then add process visibility to reduce reconnaissance and accidental data collection.

It also does not protect secrets that the service can already read. Credentials in its environment, files under its writable directories and open descriptors remain part of its authority. Review those paths separately and rotate any value that may have been exposed before the policy change.

Validate the running unit

After deployment, inspect the effective unit properties with systemctl show and run a read-only probe from inside the service context. Confirm that the service can still see its own process entries and that unrelated host processes are absent from the intended view. Exercise failure paths, because a monitoring library may fail open and silently drop metrics rather than stop.

Keep a rollback unit override in the change record. If the service breaks during an incident, responders need to know which setting was intentional and which behavior changed. A short, explicit exception is safer than disabling several sandboxing options at once.

The result is a narrower /proc view, a tested service contract and a clear rollback path. Those details keep the control meaningful during real operations.

References

• systemd.exec execution environment settings
• systemd transient unit settings