Read a Process's Security Attributes in /proc

Something writes a security context to /proc/<pid>/attr/current and the app starts behaving oddly, because these files are not idle status reports. This guide reads the security attributes exposed for a Linux process, explains which attribute applies to which later operation, and shows when a missing file is a kernel or security-module detail rather than a shell problem. Allow about fifteen minutes.

You need a shell and a process you are allowed to inspect. The main examples read your own process, so they need no elevated privileges. Do not write a security context merely to make an example produce different output: writes can alter a process's security state and can affect files, keys or sockets created afterwards. The examples use Linux man-pages 6.7, installed here as package version 6.7-2.

1. Confirm the installed contract

Start with the local manual page. This is an ordinary, read-only command and does not need sudo:

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

The interface is a directory below /proc/<pid>/attr/. It is present only when the kernel was built with CONFIG_SECURITY. The manual uses SELinux to explain the files, but the interface is meant to be shared by security modules.

2. Read the current attribute

Use self to refer to the shell process running the command:

$ cat /proc/self/attr/current
unconfined

The value is host-specific. On an SELinux system it is the process security context. On this machine the result is unconfined, which is a real observation about the current process, not a result every Linux host should show.

To inspect another process, replace PID with a numeric process ID that you are permitted to read:

$ PID=1234
$ test -r "/proc/$PID/attr/current" && cat "/proc/$PID/attr/current"
system_u:system_r:sshd_t:s0

The context in that second example is illustrative, not a promised default. If the test fails, check the process still exists and its security policy allows the read. Do not fix a permission error by writing to the file.

3. List the interface your kernel exposes

List the directory before assuming every documented node exists:

$ ls -la /proc/self/attr
dr-xr-xr-x 2 ... apparmor
-rw-rw-rw- 1 ... current
-rw-rw-rw- 1 ... exec
-rw-rw-rw- 1 ... fscreate
-rw-rw-rw- 1 ... keycreate
-r--r--r-- 1 ... prev
dr-xr-xr-x 2 ... smack
-rw-rw-rw- 1 ... sockcreate

Ownership, timestamps and the exact set of entries vary. The installed proc_pid_attr(5) page documents current, exec, fscreate, keycreate, prev and socketcreate. This machine exposes sockcreate instead of a file named socketcreate, a useful warning to discover the local directory rather than assume every security module uses the same spelling or supports every attribute.

Subdirectories such as apparmor and smack belong to particular security modules. They are not evidence SELinux is active, and their presence does not mean an application is confined.

4. Understand the attribute names before touching them

These files describe different points in a process lifecycle:

• current represents the process's current security attributes. The manual says SELinux may permit authorised writes, but a successful write is a policy-controlled security transition.
• exec is the attribute to use for a subsequent execve(2) transition. In SELinux it is reset by that exec, and a process can set only its own node.
• fscreate supplies attributes for files created by later open(2), mkdir(2), symlink(2) and mknod(2) calls. In SELinux it persists across several creations until reset, but is reset by exec.
• keycreate supplies the context for keys subsequently created with add_key(2).
• prev reports the process security context before its last exec.
• socketcreate, or the module-specific spelling exposed locally, supplies the context for subsequently created sockets when that security module supports it.

Read a node without assuming its contents are text you can safely reuse:

for name in current exec fscreate keycreate prev sockcreate; do
    path="/proc/self/attr/$name"
    if [ -r "$path" ]; then
        printf '%s: ' "$name"
        if ! IFS= read -r value <"$path"; then
            printf '%s\n' 'read failed'
        else
            printf '%s\n' "$value"
        fi
    else
        printf '%s: unavailable\n' "$name"
    fi
done

Some nodes are write-oriented or can reject a normal read. That is expected: a read failure is not permission to try a write, it may be a deliberate interface restriction.

5. Keep writes out of routine diagnostics

Writing a value to an attribute is not a harmless configuration test. A write to fscreate can change the labels assigned to later files created by the same process, a write to keycreate or a socket-creation attribute can affect later kernel objects, and a write to exec is meant to influence the next program image. These effects can outlive the command that performed the write.

Do not run a command such as this on a production process unless you have verified the security policy, the exact context, the process identity and a recovery plan:

$ printf '%s\n' 'CONTEXT_VALUE' > /proc/self/attr/exec

There is no universal undo command. If a write changes a process attribute, the safest recovery is usually to stop that process and start a fresh one under its normal policy. For service work, prepare the service rollback before testing and use a maintenance window. Do not delete files or restart a service as part of a read-only inspection.

Common traps

• Assuming CONFIG_SECURITY means a module is loaded. If /proc/self/attr is absent, check the mounted proc filesystem and the kernel configuration or security-module setup with your platform documentation. The manual only promises the directory when CONFIG_SECURITY is enabled; it does not promise SELinux, AppArmor, Smack or another module is loaded.
• Treating a missing node as a broken interface. If current reads successfully but a specialised node is missing, use the local listing as the source of truth. A security module can expose its own subdirectory and semantics; a missing keycreate or socket attribute does not mean the whole security interface is broken.
• Retrying a write after a process vanishes. If a process disappears between checking its PID and reading its file, the path can fail or refer to a newly reused PID later. Open and read the relevant path promptly and treat failures as a state change rather than retrying writes. Reading /proc/self/attr/current avoids PID reuse for the process doing the check.

Finally, a readable context does not prove every operation is permitted. It identifies the current or requested security attributes; the active module and its policy decide what those attributes mean.