Date: Mon, 19 Sep 2011 20:18:37 +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 On Mon, Sep 19, 2011 at 19:11 +0300, Pekka Enberg wrote: > >> What's different about the patch now? > > > > The exploitation you're talking about is an exploitation of kernel heap > > bugs. Dan's previous "make slabinfo 0400" patch tried to complicate > > attacker's life by hiding information about how many free object are > > left in the slab. With this information an attacker may compute how he > > should spray the slab to position slab object to increase his chances of > > overwriting specific memory areas - pointers, etc. > > > > I don't speak about how much/whether closing slabinfo complicates this > > task, though. My idea is orthogonal to the Dan's idea. I claim that > > with 0444 slabinfo any user may get information about in-system activity > > that he shouldn't learn. In short, one may learn precisely when other > > user reads directory contents, opens files, how much files there are in > > the specific _private_ directory, how much files _private_ ecryptfs or > > fuse mount point contains, etc. This breaks user's assumption that > > the number of files in a private directory is a private information. > > There are a bit more thoughts in the patch description. > > Yes, I read your patch description and I think it's convincing enough > to warrant a config option but not changing the default. > > However, if the encryptfs and infoleaks really are serious enough to > hide /proc/slabinfo, I think you should consider switching over to > kmalloc() instead of kmem_cache_alloc() to make sure nobody can > gain access to the information. kmalloc() is still visible in slabinfo as kmalloc-128 or so. > >> > One note: only to _kernel_ developers. It means it is a strictly > >> > debugging feature, which shouldn't be enabled in the production systems. > >> > >> It's pretty much _the_ interface for debugging kernel memory leaks in > >> production systems and we ask users for it along with /proc/meminfo > >> when debugging many memory management related issues. When we > >> temporarily dropped /proc/slabinfo with the introduction of SLUB, people > >> complained pretty loudly. > > > > Could you point to the discussion, please? I cannot find the patch for > > 0400 slabinfo even in the linux-history repository. > > We dropped the whole file for SLUB: > > http://lwn.net/Articles/263337/ Ah, I've misunderstood you. > [ I didn't find the original discussion that motivated the above > patch but it should be somewhere in LKML archives around > that time. ] > > Making it root-only will have pretty much the same kind of > out-of-the-box behavior. > > >> I'd be willing to consider this patch if it's a config option that's not enabled > >> by default; otherwise you need to find someone else to merge the patch. > >> You can add some nasty warnings to the Kconfig text to scare the users > >> into enabling it. ;-) > > > > How do you see this CONFIG_ option? CONFIG_PROCFS_COMPAT_MODES (or _PERMS), > > defaults to Y? If we find more procfs files with dangerous permissions, > > we may move it under "ifndef CONFIG_PROCFS_COMPAT_PERMS". > > I guess CONFIG_RESTRICT_PROCFS type of thing makes most sense > since the problem is not only about SLAB. If you want to make it slab-only > config option, I'm fine with that too. OK, then I'll prepare a patch with a configure option, if no other objections. > Please note that you need to restrict sysfs files for SLUB as well. Sure. Thank you for the comments! -- 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.