Secure procfs (/proc filesystem) option

Updated: April 19, 2023

The --secure-procfs option configures the permissions on the procfs (/proc) filesystem. The default for mkqnximage is to enable the option, as should usually be the case on a real system. To see the effect on configuration, you compare with an image with the option set to no.

Changes to this option affect the -d and -u options passed to procnto on boot. In particular, when enabled, both options are set to 0777, which removes all POSIX access permissions from the files in /proc/pid/ (where pid is a process’s PID).

If you build an image, log in and execute:

# ls -l /proc/1 

with the option enabled (--secure-procfs=yes), the output should be:

# ls -l /proc/1 

total 0 

----------   1 root      root         0 Apr 08 10:32 as 

----------   1 root      root         0 Apr 08 10:32 cmdline 

... 

while with the option disabled, the output would be:

# ls -l /proc/1 

total 0 

-rw-------   1 root      root         0 Apr 08 09:55 as 

-rw-r--r--   1 root      root         0 Apr 08 09:55 cmdline 

You can see the effect of this difference if you run the pidin command as a non-root user. For example:

on -u 100 pidin arg 

If run on an image with the option disabled, this displays a complete list of processes though with only their names, not command line arguments. If run on an image with the option enabled, the list of processes would be empty.

It is a good idea on a real system to remove access to procfs. On a production system, most processes do not require access to procfs. Removing access can help mitigate against exploiting vulnerabilities that are discovered post-release. QNX recommends that you grant access selectively to those processes that need it.

As seen above, removing access makes commands such as pidin unusable for non-root users. Another effect is on servers that, as a debugging aid, provide names of clients in log messages instead of simply their PID. Accessing the name of a process requires reading the cmdline file for the process, which is disabled when you enable this option. Finally, debugging requires access to /proc/pid/as.

You can use abilities to selectively re-enable access to files in /proc/pid/. For example, you can run a non-root shell that allows a limited range of the ability PROCMGR_AID_XPROCESS_QUERY:

# on -u 100 -A allow,all,inherit,xprocess_query:20-25 ksh 

$ 

If you run pidin in that shell, it shows a subset of processes:

$ pidin arg 

     pid Arguments 

   16387 slogger2 -U 21:21 -P /pps/slogger2  

   40965 devb-eide cam user=20:20 blk cache=64M,auto=partition,vnode=2000,ncache=2000,commit=low  

  122888 random -t -p -U 22:22 -s /data/var/random/rnd-seed  

  135177 pipe -U 24:24 

These are the processes that have UIDs in the range 20-25. The list does not include the pidin command itself because a process cannot even access the /proc/pid/ files for itself without the necessary abilities.

While this example uses the PROCMGR_AID_XPROCESS_QUERY ability, there are two other abilities that also control what can be done with files in /proc/pid/: PROCMGR_AID_XPROCESS_MEM_READ and PROCMGR_AID_XPROCESS_DEBUG. PROCMGR_AID_XPROCESS_MEM_READ is required by dumper to allow it to generate a core file while both are required to debug a program.