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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. 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@xxxxxxxxx";> email@xxxxxxxxx </a>