• Vasiliy Kulikov's avatar
    procfs: add hidepid= and gid= mount options · 0499680a
    Vasiliy Kulikov authored
    Add support for mount options to restrict access to /proc/PID/
    directories.  The default backward-compatible "relaxed" behaviour is left
    untouched.
    
    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.
    
    Note: the patch doesn't deal with setuid/setgid issues of keeping
    preopened descriptors of procfs files (like
    https://lkml.org/lkml/2011/2/7/368).  We rely on that the leaked
    information like the scheduling counters of setuid apps doesn't threaten
    anybody's privacy - only the user started the setuid program may read the
    counters.
    Signed-off-by: default avatarVasiliy Kulikov <segoon@openwall.com>
    Cc: Alexey Dobriyan <adobriyan@gmail.com>
    Cc: Al Viro <viro@zeniv.linux.org.uk>
    Cc: Randy Dunlap <rdunlap@xenotime.net>
    Cc: "H. Peter Anvin" <hpa@zytor.com>
    Cc: Greg KH <greg@kroah.com>
    Cc: Theodore Tso <tytso@MIT.EDU>
    Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Cc: James Morris <jmorris@namei.org>
    Cc: Oleg Nesterov <oleg@redhat.com>
    Cc: Hugh Dickins <hughd@google.com>
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    0499680a
proc.txt 71.6 KB