[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110919144657.GA5928@albatros>
Date: Mon, 19 Sep 2011 18:46:58 +0400
From: Vasiliy Kulikov <segoon@...nwall.com>
To: Pekka Enberg <penberg@...helsinki.fi>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
kernel-hardening@...ts.openwall.com, Kees Cook <kees@...ntu.com>,
Cyrill Gorcunov <gorcunov@...il.com>,
Al Viro <viro@...iv.linux.org.uk>,
Christoph Lameter <cl@...ux-foundation.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
Hello Pekka,
On Mon, Sep 19, 2011 at 17:30 +0300, Pekka Enberg wrote:
> > On Wed, Sep 14, 2011 at 12:27 -0700, Kees Cook wrote:
> >> On Sat, Sep 10, 2011 at 08:41:34PM +0400, Vasiliy Kulikov wrote:
> >> > Historically /proc/slabinfo has 0444 permissions and is accessible to
> >> > the world. slabinfo contains rather private information related both to
> >> > the kernel and userspace tasks. Depending on the situation, it might
> >> > reveal either private information per se or information useful to make
> >> > another targeted attack. Some examples of what can be learned by
> >> > reading/watching for /proc/slabinfo entries:
> >> > ...
> >> > 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.
> >> >
> >> > Signed-off-by: Vasiliy Kulikov <segoon@...nwall.com>
>
> On Sun, Sep 18, 2011 at 8:05 PM, Vasiliy Kulikov <segoon@...nwall.com> wrote:
> >> Haven't had any mass complaints about the 0400 in Ubuntu (sorry Dave!), so
> >> I'm obviously for it.
> >>
> >> Reviewed-by: Kees Cook <kees@...ntu.com>
> >
> > Looks like the members of the previous slabinfo discussion don't object
> > against the patch now and it got two other Reviewed-by responses. Can
> > you merge it as-is or should I probably convince someone else?
>
> We discussed this in March (google for 'Make /proc/slabinfo 0400')
Sure, I've read it and included the link in the patch description :)
> and
> concluded that it's not worth it doesn't really protect from anything
Closing only slabinfo doesn't add any significant protection against
kernel heap exploits per se, no objections here.
But as said in the desciption, the reason for this patch is not protecting
against exploitation heap bugs. It is a source of infoleaks of kernel
and userspace activity, which should be forbidden to non-root users.
> and causes harm to developers.
One note: only to _kernel_ developers. It means it is a strictly
debugging feature, which shouldn't be enabled in the production systems.
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.
