[Secure-testing-team] Bug#681418: debugfs is a big security hole

Ben Hutchings ben at decadent.org.uk
Fri Jul 13 03:37:08 UTC 2012


Package: src:linux
Version: 3.2.21-3
Severity: important
Tags: security

As discussed here
<http://lists.linux-foundation.org/pipermail/ksummit-2012-discuss/2012-July/000891.html>.

I certainly consider mounting of debugfs to be significant security
liability.  I'm not at all happy that people use it as the basis for
end-user applications that quietly mount debugfs if they find it isn't
yet mounted.  Even if their corner of debugfs is robust, all the other
stuff exposed by random drivers may not be.

Debian has at least one such application package (blktrace) which
mounts debugfs from its init script.

I would like to address this by backporting this feature:

commit d6e486868cde585842d55ba3b6ec57af090fc343
Author: Ludwig Nussel <ludwig.nussel at suse.de>
Date:   Wed Jan 25 11:52:28 2012 +0100

    debugfs: add mode, uid and gid options

and then changing the default mode (mask) to be 0700.  This should
leave debugfs functional (most such applications will require root
anyway) and allow users to relax permissions if they really don't
care about the security problems.

However, currently there is not a single place for the user options.
I think that either (1) debugfs should be mounted by default in a
similar way to other pseudo-filesystems, or (2) debugfs should have a
noauto entry in /etc/fstab where users can set options, and packages
may use 'mount /sys/kernel/debug' to mount debugfs with those options
(not 'mount -t debugfs debugfs /sys/kernel/debug', as now).

Ben.

-- System Information:
Debian Release: wheezy/sid
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: i386 (x86_64)
Foreign Architectures: amd64

Kernel: Linux 3.2.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash





More information about the Secure-testing-team mailing list