Re: [RFC 2/5 v4] procfs: add hidepid= and gid= mount options

From: Vasiliy Kulikov
Date: Mon Jun 20 2011 - 06:39:30 EST

On Mon, Jun 20, 2011 at 15:07 +1000, James Morris wrote:
> > This patch adds support of mount options to restrict access to
> > /proc/PID/ directories. The default backward-compatible 'relaxed'
> > behaviour is left untouched.
> Can you provide evidence that this is a useful feature? e.g. examples of
> exploits / techniques which would be _usefully_ hampered or blocked.

First, most of these files are usefull in sense of statistics gathering
and debugging. There is no reason to provide this information to the

Second, yes, it blocks one source of information used in timing attacks,
just use reading the counters as more or less precise time measurement
when actual timing measurements are not precise enough.

Third, such level of privacy (especially cmdline and comm) may be the
goal itself, where users may be anxious whether anybody knows what they

> > The first mount option is called "hidepid" and its value defines how much
> > info about processes we want to be available for non-owners:
> >
> > hidepid=0 (default) means the current behaviour - anybody may read all
> > world-readable /proc/PID/* files.
> Why not utilize unix perms on the proc files? Perhaps via stricter
> overall defaults which are selected at kernel build or runtime.
> > hidepid=1 means users may not access any /proc/<pid>/ directories, but their
> > own. Sensitive files like cmdline, io, sched*, status, wchan are now
> > protected against other users. As permission checking done in
> > proc_pid_permission() and files' permissions are left untouched,
> > programs expecting specific files' permissions are not confused.
> IMHO such programs are beyond broken and have voided their kernel
> warranty.

Policykit, Debian's start-stop-daemon, util-linux use /proc/PID's uid.
procps use both /proc/PID's uid and gid. Are all of them totally broken?

Vasiliy Kulikov - bringing security into open computing environments
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at