Created attachment 439428 [details] AVC/sealert log for 'automounting /sys/kernel/debug' Description of problem: My system is running systemd-7-3.fc14.x86_64. It appears that by default, automount points are enabled for /sys/kernel/debug and /sys/kernel/security. This causes unexpected behavior (and SELinux AVCs). Not sure if this was the default for upstart, and not sure its a bug, but it is certainly unexpected.... Running "cd /sys; find . -name \*mount\* -print" appears to trigger automounting of both /sys/kernel/debug and /sys/kernel/security, along with AVCs warning about rejected attempts to write by /bin/mount in both directories. The attempted write to /sys/kernel/security triggers a "your system may be compromised" message from setroubleshootd. I attach both sealert messages below.... Version-Release number of selected component (if applicable): systemd-7-3.fc14.x86_64 How reproducible: Every time Steps to Reproduce: 1. cd /sys; find . -name \*mount\* -print 2. 3. Actual results: Expected results: Additional info:
Created attachment 439429 [details] AVC/sealert log for 'automounting /sys/kernel/security'
systemd creates a couple of autofs mounts of optional API kernel virtual file systems. This allows us to support stuff like the binfmt_misc fs without having to load the module: on first access the backing module would be automatically loaded and for the programs accessing the dir this would be invisible. This has a number of advantages: clients don't have to explicitly mount or modprobe things anymore, and can just rely that the mount point is there. On the other hand we don't have to load all modules backing these dirs right-away, thus doing less work on boot.
Well, this appears to allow quite common commands to generate the mounts and the AVCs. For example, [root@tlondon ~]# find / -inum 9310 -print find: `/home/tbl/.gvfs': Permission denied /sys/dev/char/4:40 [root@tlondon ~]# causes the same behavior as above: I get 2 AVCs complaining about attempted write access to /sys/kernel/debug and /sys/kernel/security, I get the "your systems has probably been compromised" message, and mount reports I have 2 new pseudo file systems mounted: [root@tlondon ~]# mount /dev/mapper/vg_tlondon-lv_root on / type ext4 (rw) proc on /proc type proc (rw) sysfs on /sys type sysfs (rw) devpts on /dev/pts type devpts (rw,gid=5,mode=620) tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0") /dev/sda1 on /boot type ext4 (rw) none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw) sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) fusectl on /sys/fs/fuse/connections type fusectl (rw) gvfs-fuse-daemon on /home/tbl/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=tbl) /dev/sdb1 on /media/FlashCard type vfat (rw,nosuid,nodev,uhelper=udisks,uid=500,gid=500,shortname=mixed,dmask=0077,utf8=1,flush) debugfs on /sys/kernel/debug type debugfs (rw) securityfs on /sys/kernel/security type securityfs (rw) [root@tlondon ~]# Ignoring the SELinux/AVC question for the moment, should a "find /" command cause these two mounts? I have no issue with automounting in general, but should these two mount points be enabled "all the time"? Would it make sense to disable them by default?
The change to systemd is causing strange AVC's. Why does the mount command need to write to the debugfs?
I'm not sure this is systemd related. This is actually a call to access(2) from /sbin/mount. On F13 I see something like so when I mount: 27413 mount("/sys/kerne/debug", "/sys/kernel/debug/", "debugfs", MS_MGC_VAL, NULL) = 0 27413 readlink("/sys", 0x7fff78396cc0, 4096) = -1 EINVAL (Invalid argument) 27413 readlink("/sys/kerne", 0x7fff78396cc0, 4096) = -1 ENOENT (No such file or directory) 27413 readlink("/sys", 0x7fff78396cc0, 4096) = -1 EINVAL (Invalid argument) 27413 readlink("/sys/kernel", 0x7fff78396cc0, 4096) = -1 EINVAL (Invalid argument) 27413 readlink("/sys/kernel/debug", 0x7fff78396cc0, 4096) = -1 EINVAL (Invalid argument) But on F14 I see this: 1470 mount("/sys/kernel/debug", "/sys/kernel/debug/", "debugfs", MS_MGC_VAL, NULL) = 0 1470 getuid() = 0 1470 geteuid() = 0 1470 access("/sys/kernel/debug/", W_OK) = 0 1470 readlink("/sys", 0x7fff2159cd60, 4096) = -1 EINVAL (Invalid argument) 1470 readlink("/sys/kernel", 0x7fff2159cd60, 4096) = -1 EINVAL (Invalid argument) 1470 readlink("/sys/kernel/debug", 0x7fff2159cd60, 4096) = -1 EINVAL (Invalid argument) 1470 readlink("/sys", 0x7fff2159cd60, 4096) = -1 EINVAL (Invalid argument) 1470 readlink("/sys/kernel", 0x7fff2159cd60, 4096) = -1 EINVAL (Invalid argument) 1470 readlink("/sys/kernel/debug", 0x7fff2159cd60, 4096) = -1 EINVAL (Invalid argument) So between the actual mount syscall and the readlink() checks mount added a call to getuid, geuid, and access(). No idea why.
Which looks like the mount will cause the debufs file system to be automounted then? mount must be doing access(DEBUGFS, W_OK) Ordinarily it is not mounted so we don't see this AVC. but now that systemd is automounting we are getting the AVC.
Fixed in selinux-policy-3.8.8-18.fc14
Confirmed. Fixed with selinux-policy-3.8.8-18.fc15.noarch [tbl@tlondon ~]$ cd /sys [tbl@tlondon sys]$ find . -name \*mount\* -print ./kernel/debug/tracing/events/syscalls/sys_enter_umount ./kernel/debug/tracing/events/syscalls/sys_exit_umount ./kernel/debug/tracing/events/syscalls/sys_enter_oldumount ./kernel/debug/tracing/events/syscalls/sys_exit_oldumount ./kernel/debug/tracing/events/syscalls/sys_enter_mount ./kernel/debug/tracing/events/syscalls/sys_exit_mount [tbl@tlondon sys]$ and no AVCs. Thanks!
selinux-policy-3.8.8-20.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/selinux-policy-3.8.8-20.fc14
selinux-policy-3.8.8-20.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update selinux-policy'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/selinux-policy-3.8.8-20.fc14
selinux-policy-3.8.8-20.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.