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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.