There is now a hidepid
mount option for procfs
that lets you hide arguments from other users, and optionally allow one group to see all processes:
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 old behavior - anybody may read all
world-readable /proc/PID/* files.
hidepid=1 means users may not access any /proc/PID/ directories, but
their own. Sensitive files like cmdline, sched*, status are now
protected against other users. As permission checking done in
proc_pid_permission() and files' permissions are left untouched,
programs expecting specific files' modes are not confused.
hidepid=2 means hidepid=1 plus all /proc/PID/ will be invisible to
other users. It doesn't mean that it hides whether a process exists
(it can be learned by other means, e.g. by kill -0 $PID), but it
hides process' euid and egid. It compicates intruder's task of
gathering info about running processes, whether some daemon runs with
elevated privileges, whether another user runs some sensitive program,
whether other users run any program at all, etc.
gid=XXX defines a group that will be able to gather all processes'
info (as in hidepid=0 mode). This group should be used instead of
putting nonroot user in sudoers file or something. However, untrusted
users (like daemons, etc.) which are not supposed to monitor the tasks
in the whole system should not be added to the group.
hidepid=1 or higher is designed to restrict access to procfs files,
which might reveal some sensitive private information like precise
keystrokes timings:
http://www.openwall.com/lists/oss-security/2011/11/05/3
hidepid=1/2 doesn't break monitoring userspace tools. ps, top, pgrep,
and conky gracefully handle EPERM/ENOENT and behave as if the current
user is the only user running processes. pstree shows the process
subtree which contains "pstree" process.