From: Vasiliy Kulikov <segoon@openwall.com>
To: Pekka Enberg <penberg@cs.helsinki.fi>
Cc: Andrew Morton <akpm@linux-foundation.org>,
kernel-hardening@lists.openwall.com, Kees Cook <kees@ubuntu.com>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Al Viro <viro@zeniv.linux.org.uk>,
Christoph Lameter <cl@linux-foundation.org>,
Matt Mackall <mpm@selenic.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Dan Rosenberg <drosenberg@vsecurity.com>,
Theodore Tso <tytso@mit.edu>, Alan Cox <alan@linux.intel.com>,
Jesper Juhl <jj@chaosbits.net>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [kernel-hardening] Re: [RFC PATCH 2/2] mm: restrict access to /proc/slabinfo
Date: Mon, 19 Sep 2011 18:46:58 +0400 [thread overview]
Message-ID: <20110919144657.GA5928@albatros> (raw)
In-Reply-To: <CAOJsxLF8DBEC9o9pSwa6c6pMg8ByFBdsDnzg22P3ucQcP98uzA@mail.gmail.com>
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@openwall.com>
>
> On Sun, Sep 18, 2011 at 8:05 PM, Vasiliy Kulikov <segoon@openwall.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@ubuntu.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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2011-09-19 14:47 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20110910164001.GA2342@albatros>
2011-09-10 16:41 ` [RFC PATCH 2/2] mm: restrict access to /proc/slabinfo Vasiliy Kulikov
2011-09-12 15:06 ` Cyrill Gorcunov
2011-09-13 6:28 ` Vasiliy Kulikov
2011-09-14 13:16 ` Vasiliy Kulikov
2011-09-14 15:18 ` Dave Hansen
2011-09-14 15:42 ` [kernel-hardening] " Vasiliy Kulikov
2011-09-14 15:48 ` Vasiliy Kulikov
2011-09-14 18:24 ` Dave Hansen
2011-09-14 18:41 ` Dave Hansen
2011-09-14 19:14 ` Vasiliy Kulikov
2011-09-14 19:27 ` Kees Cook
2011-09-18 17:05 ` [kernel-hardening] " Vasiliy Kulikov
2011-09-19 13:42 ` Christoph Lameter
2011-09-19 14:30 ` Pekka Enberg
2011-09-19 14:46 ` Vasiliy Kulikov [this message]
2011-09-19 15:13 ` Pekka Enberg
2011-09-19 15:57 ` Vasiliy Kulikov
2011-09-19 16:11 ` Pekka Enberg
2011-09-19 16:18 ` Vasiliy Kulikov
2011-09-19 17:31 ` Pekka Enberg
2011-09-19 17:35 ` Vasiliy Kulikov
2011-09-19 17:51 ` Christoph Lameter
2011-09-19 19:59 ` Valdis.Kletnieks
2011-09-19 20:02 ` Christoph Lameter
2011-09-19 20:36 ` Valdis.Kletnieks
2011-09-19 17:51 ` Pekka Enberg
2011-09-19 17:58 ` Vasiliy Kulikov
2011-09-19 18:46 ` Pekka Enberg
2011-09-19 18:55 ` Vasiliy Kulikov
2011-09-19 19:20 ` Pekka Enberg
2011-09-19 19:33 ` Pekka Enberg
2011-09-19 18:55 ` Linus Torvalds
2011-09-19 19:18 ` Pekka Enberg
2011-09-19 19:45 ` Pekka Enberg
2011-09-19 20:59 ` David Rientjes
2011-09-19 18:03 ` Dave Hansen
2011-09-19 18:21 ` Pekka Enberg
2011-09-19 19:45 ` Valdis.Kletnieks
2011-09-19 19:55 ` Alan Cox
2011-09-21 17:05 ` Vasiliy Kulikov
2011-09-22 2:20 ` Valdis.Kletnieks
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=20110919144657.GA5928@albatros \
--to=segoon@openwall.com \
--cc=akpm@linux-foundation.org \
--cc=alan@linux.intel.com \
--cc=cl@linux-foundation.org \
--cc=drosenberg@vsecurity.com \
--cc=gorcunov@gmail.com \
--cc=jj@chaosbits.net \
--cc=kees@ubuntu.com \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mpm@selenic.com \
--cc=penberg@cs.helsinki.fi \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/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).