Bug#681418: debugfs is a big security hole
Bjørn Mork wrote: 1) mode and owner is not propagated to files below the mount point: That's intentional to keep things simple. If you can control the x bit on the mount point then you can control who can reach files beneath. 2) ownership and mode seems to be shared amoung all mount points, resulting in the following unexpected behaviour: 3) ownership (but not mode?!) seems to be cached between mounts, resulting in the following unexpected behaviour: [...] These can all be considered minor glitches, but they sure confused me the first time I hit them. Me too :-) debugfs is a special beast. It's a singleton filesystem. The kernel itself mounts it at boot. When you mount it in userspace you actually only expose what the kernel already has. Modifying the mount options actually modifies the options of that single, already mounted instance. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/533a.2010...@suse.de
Bug#681418: debugfs is a big security hole
Ben Hutchings b...@decadent.org.uk writes: I would like to address this by backporting this feature: commit d6e486868cde585842d55ba3b6ec57af090fc343 Author: Ludwig Nussel ludwig.nus...@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. I like the proposal, but the feature does not seem mature yet. Played a bit with it and noticed a couple of confusing bugs which IMHO should be fixed first: 1) mode and owner is not propagated to files below the mount point: nemi:/tmp# mount /sys/kernel/debug -o uid=42,mode=0700 nemi:/tmp# ls -la /sys/kernel/debug/ total 0 drwx-- 16 42 root 0 Jul 2 00:07 . drwxr-xr-x 6 root root 0 Jul 2 00:07 .. drwxr-xr-x 2 root root 0 Jul 2 00:07 acpi drwxr-xr-x 32 root root 0 Jul 11 14:36 bdi drwxr-xr-x 2 root root 0 Jul 13 11:51 bluetooth drwxr-xr-x 4 root root 0 Jul 2 00:07 dri drwxr-xr-x 2 root root 0 Jul 2 00:07 dynamic_debug drwxr-xr-x 2 root root 0 Jul 2 00:07 extfrag -r--r--r-- 1 root root 0 Jul 2 00:07 gpio drwxr-xr-x 3 root root 0 Jul 2 00:07 ieee80211 drwxr-xr-x 2 root root 0 Jul 2 00:07 kprobes drwxr-xr-x 2 root root 0 Jul 2 00:07 kvm drwxr-xr-x 2 root root 0 Jul 2 00:07 mce drwxr-xr-x 2 root root 0 Jul 2 00:07 regmap -rw-r--r-- 1 root root 0 Jul 2 00:07 sched_features -r--r--r-- 1 root root 0 Jul 2 00:07 suspend_stats drwxr-xr-x 5 root root 0 Jul 2 00:07 tracing drwxr-xr-x 2 root root 0 Jul 2 00:07 usb -r--r--r-- 1 root root 0 Jul 2 00:07 wakeup_sources drwxr-xr-x 2 root root 0 Jul 2 00:07 x86 2) ownership and mode seems to be shared amoung all mount points, resulting in the following unexpected behaviour: nemi:/tmp# mount /sys/kernel/debug -o uid=42,mode=0700 nemi:/tmp# ls -ld /sys/kernel/debug drwx-- 16 42 root 0 Jul 2 00:07 /sys/kernel/debug nemi:/tmp# mount -t debugfs none /mnt/temp -o uid=0,mode=0755 nemi:/tmp# ls -ld /sys/kernel/debug drwxr-xr-x 16 root root 0 Jul 2 00:07 /sys/kernel/debug 3) ownership (but not mode?!) seems to be cached between mounts, resulting in the following unexpected behaviour: nemi:/tmp# mount /sys/kernel/debug -o uid=42,mode=0700 nemi:/tmp# ls -ld /sys/kernel/debug drwx-- 16 42 root 0 Jul 2 00:07 /sys/kernel/debug nemi:/tmp# umount /sys/kernel/debug nemi:/tmp# grep debugfs /proc/mounts nemi:/tmp# grep debugfs /etc/fstab debug /sys/kernel/debug debugfs defaults nemi:/tmp# mount /sys/kernel/debug nemi:/tmp# ls -ld /sys/kernel/debug drwxr-xr-x 16 42 root 0 Jul 2 00:07 /sys/kernel/debug These can all be considered minor glitches, but they sure confused me the first time I hit them. Bjørn -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87d33zgbrs@nemi.mork.no
Bug#681418: debugfs is a big security hole
On Fri, 13 Jul 2012, Ben Hutchings wrote: 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 Seconded. I know of at least three ways to hardcrash boxes through debugfs (system specific, not a kernel bug), and the unfortunate naming DOES help kernel maintainers take an even more irresponsible instance regarding security than what is already [unfortunately] normal. e.g. missing calls to capable() in debugfs handlers. It really should be called advcfgfs. Either that, or it should taint the kernel when mounted, and any production stuff would be forced to graduate to a proper peer-reviewed interface. I would like to address this by backporting this feature: commit d6e486868cde585842d55ba3b6ec57af090fc343 Author: Ludwig Nussel ludwig.nus...@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. Actually, it would be best if we could set mode, uid and gid per inode/dentry, with defaults to the ones in the mount command (or root:root 700). Just like tmpfs does. 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). Both ideas would work. Can you provide a patch for the relevant initscripts? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120713134317.gb7...@khazad-dum.debian.net
Bug#681418: debugfs is a big security hole
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.nus...@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 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120713033708.3307.93550.report...@deadeye.wl.decadent.org.uk
Bug#681418: debugfs is a big security hole
On 13.07.2012 05:37, Ben Hutchings wrote: 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. systemd might be affected too, so I'm bringing Tollef into the loop here. When having booted with systemd I get: debugfs on /sys/kernel/debug type debugfs (rw,relatime) Tollef, do you know why systemd mounts debugfs by default? Is there something that should be done in the systemd package? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#681418: debugfs is a big security hole
]] Michael Biebl Tollef, do you know why systemd mounts debugfs by default? No, I don't. Just asked upstream. Is there something that should be done in the systemd package? If it's a bad idea to mount it by default, we shouldn't, I think. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/878veojlws@xoog.err.no
