Check a Process's seccomp Mode Without /proc/pid/seccomp

A script that greps /proc/PID/seccomp for sandbox status has been broken since Linux 2.6.23. This guide reads the field that replaced it, Seccomp in /proc/PID/status, and explains why the old file is gone for good. Allow about ten minutes. You need a Linux host with procfs mounted and permission to inspect the target process.

1. Confirm the installed documentation

The local proc_pid_seccomp(5) page comes from the Debian manpages package, version 6.7-2, labelled Linux man-pages 6.7. It describes /proc/PID/seccomp as a historical interface available from Linux 2.6.12 through 2.6.22; Linux 2.6.23 removed it. Do not build a new script around a file modern kernels do not provide.

$ dpkg-query -W -f='${Package} ${Version}\n' manpages
manpages 6.7-2
$ man 5 proc_pid_seccomp

Package versions vary; the useful fact is the history the page states. The old file returned 0 for no seccomp mode and 1 for strict mode, and writing 1 made strict mode irreversible for that process. That write is a security-sensitive state change, so this guide does not demonstrate it.

2. Read the current process status

For a process you own, swap in its numeric process ID for PID. Reading status does not change the process and normally needs no elevated privileges:

$ PID=12345
$ grep '^Seccomp:' "/proc/$PID/status"
Seccomp:        0

The field reports the process's current seccomp mode: 0 means disabled, 1 means strict mode, 2 means filter mode. Spacing varies, so match the field name rather than assuming a fixed column layout. If the process exits between choosing the PID and reading the file, the command can report the path does not exist; get a fresh PID and try again.

3. Check a shell and its child safely

/proc/self is convenient when a program wants to inspect itself. For a shell command, /proc/$$/status names the shell whose PID is in $$:

$ printf 'shell PID: %s\n' "$$"
shell PID: 12345
$ grep '^Seccomp:' "/proc/$$/status"
Seccomp:        0
$ sh -c 'printf "child PID: %s\n" "$$"; grep "^Seccomp:" "/proc/$$/status"'
child PID: 12346
Seccomp:        0

Your PIDs and modes will differ. This is a read-only smoke check for the current environment: it does not install a filter, enter strict mode, or create a sandbox.

4. Understand what the old file could and could not do

The historical file was never a general policy document. Its documented write operation accepted 1, which put the calling process into strict seccomp mode irreversibly; further writes failed with EPERM. Strict mode is deliberately narrow and can make an ordinary program die the moment it calls a system call outside the allowed set.

Do not try to recreate that operation with a guessed path, a redirected write or sudo. A missing /proc/PID/seccomp is the expected result on a current kernel, not a permissions problem, and elevated privileges do not bring back a removed procfs interface.

For current code, the kernel API is seccomp(2) or the related prctl(2) operations. PR_GET_SECCOMP lets a program query its own numeric mode, but the current kernel documentation warns that querying from a filtered process can itself be blocked by the filter. Reading the Seccomp field in /proc/PID/status is the safer inspection method the proc documentation describes.

5. Diagnose a missing or unexpected result

First check that procfs is mounted and the target still exists:

$ test -r "/proc/$PID/status" && echo 'status is readable'
status is readable
$ test -d "/proc/$PID" && echo 'process still exists'
process still exists

• Either test fails. Check the PID, namespace and process lifetime. A process in another PID namespace can have a different visible PID, and a service supervisor, container runtime or orchestrator may replace a process while you inspect it. Use the PID visible from the same namespace as the command doing the read.
• Seccomp: is 2. The process has a seccomp filter. That says nothing by itself about which system calls are allowed, or what action a denied call takes; the filter's policy and the process's other security controls still matter.

6. Recover from an unsafe experiment

Reading /proc/PID/status leaves no state to undo. If a test program has deliberately entered strict or filter mode, its seccomp state cannot be relaxed by writing to procfs. Stop the test process through its normal supervisor, or let it exit, then start a fresh instance from the known-good command and configuration. Do not restart a production service solely to change a diagnostic value; make that a planned maintenance action with a rollback path.