Why is samba even looking there ? I'm not exporting sysfs in my smb.conf If samba has good reason to be reading this, then this should be reassigned to selinux-policy, but I'd like to understand what's going on here. node=gelk type=AVC msg=audit(1267467013.472:350): avc: denied { getattr } for pid=25660 comm="smbd" path="/sys/kernel/debug" dev=debugfs ino=1 scontext=unconfined_u:system_r:smbd_t:s0 tcontext=system_u:object_r:debugfs_t:s0 tclass=dir node=gelk type=SYSCALL msg=audit(1267467013.472:350): arch=c000003e syscall=4 success=yes exit=0 a0=7fff180d3df5 a1=7fff180d41f0 a2=7fff180d41f0 a3=3 items=0 ppid=25609 pid=25660 auid=500 uid=0 gid=0 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=4 comm="smbd" exe="/usr/sbin/smbd" subj=unconfined_u:system_r:smbd_t:s0 key=(null)
In case you care, that is a stat() syscall.
No idea why it would try to access /sys/kernel/debug, maybe some library is doing it behind our back ? What were you doing when that happened ?
Any chance abrt is doing something to make applications gather debug info. (I might be showing my ignorance here...)
Very similar to #569723
(In reply to comment #3) > Any chance abrt is doing something to make applications gather debug info. (I > might be showing my ignorance here...) Unlikely, abrt kicks in only of the app crashes and it's not linked with the app, it uses /proc/sys/kernel/core_pattern to detect/save coredumps, so there is no way how abrt could influence compiled app behaviour. Jirka
This access seems to be growing. So I guess it would be a good idea to know what is causing it. +kernel_search_debugfs(bluetooth_t) +kernel_read_debugfs(NetworkManager_t) +kernel_search_debugfs(rgmanager_t) kernel_search_debugfs(iscsid_t) kernel_mount_debugfs(insmod_t) kernel_read_debugfs(insmod_t) +kernel_search_debugfs(mount_t) +kernel_search_debugfs(ifconfig_t) Could this be something all domains need?
I'd dontaudit it rather than allow it unless it is shown to truly be needed. Can the bug reporter run this on his system: find /lib64 /usr/lib64 -type f -exec strings -f {} \; | grep /sys/kernel/debug (replace lib64 with lib if on x86_32 of course). On my system, I get one hit on libpcap, which appears to be trying to access /sys/kernel/debug/usbmon. Do all of those programs link against it?
this is a mount point, so it oculd be something which runs all mount points...
Ah, good observation. In which case dontaudit should be sufficient.
Looking at samba source code, it runs through the mount table via getmntent() and calls stat() on each mnt_dir in a couple of places. If it fails, it just skips that mount.
Ok I will add kernel_dontaudit_search_debugfs(domain) Do stop these from popping up randomly. Miroslav can you add this to F12.
Fixed in selinux-policy-3.6.32-97.fc12
selinux-policy-3.6.32-99.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/selinux-policy-3.6.32-99.fc12
selinux-policy-3.6.32-99.fc12 has been pushed to the Fedora 12 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.6.32-99.fc12
selinux-policy-3.6.32-99.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.