Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 14 Sep 2011 19:42:29 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: kernel-hardening@...ts.openwall.com
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Cyrill Gorcunov <gorcunov@...il.com>,
	Al Viro <viro@...iv.linux.org.uk>,
	Christoph Lameter <cl@...ux-foundation.org>,
	Pekka Enberg <penberg@...nel.org>, Matt Mackall <mpm@...enic.com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	Dan Rosenberg <drosenberg@...curity.com>,
	Theodore Tso <tytso@....edu>, Alan Cox <alan@...ux.intel.com>,
	Jesper Juhl <jj@...osbits.net>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: Re: [RFC PATCH 2/2] mm: restrict access to
 /proc/slabinfo

Hi Dave,

On Wed, Sep 14, 2011 at 08:18 -0700, Dave Hansen wrote:
> On Wed, 2011-09-14 at 17:16 +0400, Vasiliy Kulikov wrote:
> > > World readable slabinfo simplifies kernel developers' job of debugging
> > > kernel bugs (e.g. memleaks), but I believe it does more harm than
> > > benefits.  For most users 0444 slabinfo is an unreasonable attack vector.
> > 
> > Please tell if anybody has complains about the restriction - whether it
> > forces someone besides kernel developers to do "chmod/chgrp".  But if
> > someone want to debug the kernel, it shouldn't significantly influence
> > on common users, especially it shouldn't create security issues. 
> 
> Ubuntu ships today with a /etc/init/mounted-proc.conf that does:
> 
> 	chmod 0400 "${MOUNTPOINT}"/slabinfo
> 
> After cursing Kees's name a few times, I commented it out and it hasn't
> bothered me again.  

Another way is chgrp slabinfo to some "admin" group which are privileged
in this sense and add your user to this group.  But please, sane and
secure defaults!

> I expect that the folks that really care about this (and their distros)
> will probably have a similar mechanism.  I guess the sword cuts both
> ways in this case: it obviously _works_ to have the distros do it, but
> it was a one-time inconvenience for me to override that.
> 
> In other words, I dunno.  If we do this in the kernel, can we at least
> do something like CONFIG_INSECURE to both track these kinds of things
> and make it easy to get them out of a developer's way?

What do you think about adding your user to the slabinfo's group or
chmod it - quite the opposite Ubuntu currently does?  I think it is more
generic (e.g. you may chmod 0444 to allow all users to get debug
information or just 0440 and chgrp admin to allow only trusted users to
do it) and your local policy doesn't touch the kernel.

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.