* Guido Günther <a...@sigxcpu.org>, 2014-03-05, 20:54:
* We're planning to request for hidepid to be enabled by default (to
1). This will squash an entire class of information leaks. If you have
any comments or objections, please get in touch with us.
For the lazy, this is documentation for hidepid:
hidepid=0 means classic mode - everybody may access all /proc/<pid>/
directories (default).
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. This makes it impossible to learn whether
any user runs specific program (given the program doesn't reveal itself
by its behaviour). As an additional bonus, as /proc/<pid>/cmdline is
unaccessible for other users, poorly written programs passing sensitive
information via program arguments are now protected against local
eavesdroppers.
hidepid=2 means hidepid=1 plus all /proc/<pid>/ will be fully invisible
to other users. It doesn't mean that it hides a fact whether a process
with a specific pid value exists (it can be learned by other means, e.g.
by "kill -0 $PID"), but it hides process' uid and gid, which may be
learned by stat()'ing /proc/<pid>/ otherwise. It greatly complicates an
intruder's task of gathering information about running processes,
whether some daemon runs with elevated privileges, whether other user
runs some sensitive program, whether other users run any program at all,
etc.
I looked at the docs and as I read them this would affect uid 0 as
well.
Luckily this is not the case. :) root can see other users' /proc entries
just fine. Perhaps the documentation should be improved.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140305213323.ga9...@jwilk.net