Thread (34 messages) 34 messages, 8 authors, 2011-09-19

Re: [kernel-hardening] Re: [RFC PATCH 2/2] mm: restrict access to /proc/slabinfo

From: Christoph Lameter <cl@gentwo.org>
Date: 2011-09-19 17:57:57
Also in: lkml

Possibly related (same subject, not in this thread)

On Mon, 19 Sep 2011, Vasiliy Kulikov wrote:
quoted
quoted
kmalloc() is still visible in slabinfo as kmalloc-128 or so.
Yes, but there's no way for users to know where the allocations came from
if you mix them up with other kmalloc-128 call-sites. That way the number
of private files will stay private to the user, no? Doesn't that give you even
better protection against the infoleak?
No, what it gives us is an obscurity, not a protection.  I'm sure it
highly depends on the specific situation whether an attacker is able to
identify whether the call is from e.g. ecryptfs or from VFS.  Also the
correlation between the number in slabinfo and the real private actions
still exists.
IMHO a restriction of access to slab statistics is reasonable in a
hardened environment. Make it dependent on CONFIG_SECURITY or some such
thing?



--
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>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help