kernel-hardening - Re: [RFC] proc: introduce pid

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 16 Aug 2011 17:55:16 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: kernel-hardening@...ts.openwall.com,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Alexey Dobriyan <adobriyan@...il.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Al Viro <viro@...iv.linux.org.uk>,
	David Rientjes <rientjes@...gle.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Arnd Bergmann <arnd@...db.de>, "Serge E. Hallyn" <serge@...lyn.com>,
	Ingo Molnar <mingo@...e.hu>, linux-kernel@...r.kernel.org
Subject: Re: [RFC] proc: introduce pid_allowed mount option

Hi,

On Wed, Aug 10, 2011 at 20:13 +0400, Vasiliy Kulikov wrote:
> This patch adds support of pid_allowed=XX and attr_allowed=YY mount
> options for procfs.  When set, all /proc/PID/ files are restricted to
> the owner, except filenames passed via pid_allowed= argument.  E.g. with
> pid_allowed=sched sched file would be world readable and other files
> would be restricted to the task owner.  The same for /proc/PID/attr/
> files and attr_allowed=YY.
[...]
> Is the whole idea of high granularity, but static permissions worth it?
> The previous patch with relaxed/fully-restricted modes was criticized
> for being highly specific to one particular set of requirements:
> 
> http://www.openwall.com/lists/kernel-hardening/2011/06/21/3
> 
> On/off mechanism was used in server environments in times of Linux
> 2.0-2.4 as part of -ow patch and currently as part of -grsecurity patch.
> There were no complains about too limited application.  It serves a well
> defined needs (limiting processes' information to the owner, root, and a
> privileged "monitoring" group).

Any comments about the approach in general?

Different procfs patches were maintained out of tree for ~10 years,
all of them had/has the same goal - restrict processes/networking
information from unprivileged users.  All of them were not high
granularity, just on/off.

As to chmod/chown'able approach with inheritable permission across
fork() - I cannot imagine any case where it has any advantages over
static approach (which is implemented in this patch), but I see
disadvantages:

 * What to do on exec'ing setuid binary?  We have to re'chmod files to
   some sane defaults - first umask set.
 * For usermode helpers? - second umask set.
 * On privilege dropping (setuid(2))?  We can have umask
   set for all users, but it might not be convenient.  We can have umask
   set for each user.  Or we can use userspace for re-chmod'ing files
   like PAM, but what to do for apps that don't use PAM?..
 * Privilege restore? - a umask set again.


What is the goal of procfs high granularity permission model?  What
needs does it serve?  Every high granularity security model quickly
becomes hard to maintain/configure properly.  Given there were no out of
tree attempts to extend procfs in this direction (well, at least no
widespread attempts), I'm afraid such complication worth it.

I think on/off approach addresses the issue, which I've tried to
explain earlier, and it is "generic enough" for the existing needs.


Thanks,

-- 
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.