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

[Vasiliy Kulikov <segoon@openwall.com>]

(I have to increase the CC list by CC'ing Greg and perf guys.  The
motivation for restricting slabinfo is here:

http://www.openwall.com/lists/kernel-hardening/2011/09/10/4)

> Anybody who thinks that debugging tools should be totally disabled on
> "production" systems probably hasn't spent enough time actually
> running production systems.

On Mon, Sep 19, 2011 at 20:55 +0100, Alan Cox wrote:
> Agreed - far better it is simply set root only.

Sorry, I've poorly worded my statement.  Of course I mean root-only
slabinfo, not totally disable it.


So, where are we now?

Linus, Alan, Kees, and Dave are about to simply restrict slabinfo (and
probably similar interfaces) to root.  Pekka is OK too.

Christoph and Valdis are about to create new CONFIG_ option to be able
to restrict the access to slabinfo/etc., but with old relaxed
permissions.


IMO having a compatibility with the old tools using slabinfo/meminfo as
non-root for good things is great, but probably a seamless upgrade
doesn't worth it in this case.  Instead, we can provide a transition
instructions to continue to use non-root monitoring tools:

    groupadd meminfo
    usermod -a -G meminfo $MONITOR_USER

And add these lines to the init scripts between mount /proc and running
monitoring daemon, for Ubuntu's upstart it should fit in mountall.conf:

    chmod g+r /proc/slabinfo /proc/meminfo
    chgrp meminfo /proc/slabinfo /proc/meminfo

Then the daemon may watch for memleaks again.  It requires some actions
from the sysadmin, but no changes to the daemons and it helps to keep
sane kernel defaults.

Are we OK with this solution?


Now about other sources of infoleaks.  Pekka has noticed that the same
information about slabs is accessible from sysfs and 'perf kmem':

http://www.openwall.com/lists/kernel-hardening/2011/09/19/23

For sysfs the solution is relatively simple - the same __ATTR(..., 0600,
...) for SLAB_ATTR() (all __ATTR* in mm/*.c?) with the same chmod in
init scripts.


For the perf the situation differs.  AFAICS (please correct me if I'm
wrong) all performance events are recorded and passed to userspace
without any security checks.  IOW, every event happened in the current
process' context is signalled to the current task if requested.  It
contains k*alloc/kfree, which are the subject of this thread, and
probably much more infoleaks which simply nobody cared about yet.
Probably it's time to develop some rules to identify what events are
safe to signal to user and what are dangerous/private to the
system/other users (probably, potentially)?  I'm not very familiar with
perf events and there might be already such mechanisms, but they're just
not used for memory things, so this is a question to the perf guys.


Other sources of similar infoleaks are fs-specific and IMO we should fix
them after these more "generic" infoleaks (slabinfo, meminfo, sysfs,
perf).


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>