On Mon, Sep 19, 2011 at 19:11 +0300, Pekka Enberg wrote:

quoted

quoted

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.

quoted

quoted

quoted

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.

quoted

quoted

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

--
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>