linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vasiliy Kulikov <segoon@openwall.com>
To: James Morris <jmorris@namei.org>
Cc: kernel-hardening@lists.openwall.com,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: Re: [RFC 2/5 v4] procfs: add hidepid= and gid= mount options
Date: Mon, 20 Jun 2011 14:39:18 +0400	[thread overview]
Message-ID: <20110620103917.GA5230@albatros> (raw)
In-Reply-To: <alpine.LRH.2.00.1106201455560.6055@tundra.namei.org>

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
world.

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
do.


> > 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
http://www.openwall.com - bringing security into open computing environments

  reply	other threads:[~2011-06-20 10:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <alpine.LRH.2.00.1106192154220.7503@taiga.selinuxproject.org>
2011-06-20  5:07 ` [RFC 2/5 v4] procfs: add hidepid= and gid= mount options James Morris
2011-06-20 10:39   ` Vasiliy Kulikov [this message]
2011-06-20 10:43     ` James Morris
2011-06-20 11:23       ` KOSAKI Motohiro
2011-06-20 17:06       ` Vasiliy Kulikov
2011-06-20 19:41         ` Eric W. Biederman
2011-06-20 23:19         ` James Morris
2011-06-21 18:28       ` Vasiliy Kulikov
2011-06-20 13:58     ` Alexey Dobriyan
2011-06-20 13:31   ` Solar Designer
2011-06-15 18:51 Vasiliy Kulikov
2011-06-16  2:24 ` KOSAKI Motohiro
2011-06-16  8:47   ` Vasiliy Kulikov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110620103917.GA5230@albatros \
    --to=segoon@openwall.com \
    --cc=jmorris@namei.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).