When I start an nfs server, I see this in dmesg .. audit(1183747706.824:4): avc: denied { getattr } for pid=2320 comm="rpc.mountd" name="rtc0" dev=tmpfs ino=5317 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file audit(1183747706.824:5): avc: denied { getattr } for pid=2320 comm="rpc.mountd" name="usb2" dev=tmpfs ino=5284 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file audit(1183747706.824:6): avc: denied { getattr } for pid=2320 comm="rpc.mountd" name="usb4" dev=tmpfs ino=5110 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file audit(1183747706.824:7): avc: denied { getattr } for pid=2320 comm="rpc.mountd" name="usb3" dev=tmpfs ino=5098 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file audit(1183747706.824:8): avc: denied { getattr } for pid=2320 comm="rpc.mountd" name="usb1" dev=tmpfs ino=4994 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file audit(1183747706.824:9): avc: denied { getattr } for pid=2320 comm="rpc.mountd" name="kcore" dev=proc ino=4026531861 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:proc_kcore_t:s0 tclass=file audit(1183747706.824:10): avc: denied { getattr } for pid=2320 comm="rpc.mountd" name="rtc0" dev=tmpfs ino=5317 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file audit(1183747706.824:11): avc: denied { getattr } for pid=2320 comm="rpc.mountd" name="usb2" dev=tmpfs ino=5284 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file audit(1183747706.824:12): avc: denied { getattr } for pid=2320 comm="rpc.mountd" name="usb4" dev=tmpfs ino=5110 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file audit(1183747706.824:13): avc: denied { getattr } for pid=2320 comm="rpc.mountd" name="usb3" dev=tmpfs ino=5098 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file audit(1183747706.824:14): avc: denied { getattr } for pid=2320 comm="rpc.mountd" name="usb1" dev=tmpfs ino=4994 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file audit(1183747706.824:15): avc: denied { getattr } for pid=2320 comm="rpc.mountd" name="kcore" dev=proc ino=4026531861 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:proc_kcore_t:s0 tclass=file audit(1183747706.824:16): avc: denied { getattr } for pid=2320 comm="rpc.mountd" name="rtc0" dev=tmpfs ino=5317 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file audit(1183747706.824:17): avc: denied { getattr } for pid=2320 comm="rpc.mountd" name="usb2" dev=tmpfs ino=5284 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file audit(1183747706.824:18): avc: denied { getattr } for pid=2320 comm="rpc.mountd" name="usb4" dev=tmpfs ino=5110 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file audit(1183747706.824:19): avc: denied { getattr } for pid=2320 comm="rpc.mountd" name="usb3" dev=tmpfs ino=5098 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file audit(1183747706.824:20): avc: denied { getattr } for pid=2320 comm="rpc.mountd" name="usb1" dev=tmpfs ino=4994 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file audit(1183747706.824:21): avc: denied { getattr } for pid=2320 comm="rpc.mountd" name="kcore" dev=proc ino=4026531861 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:proc_kcore_t:s0 tclass=file rpc.mountd really shouldn't be touching any of those files afaics. (Why would it care about usb, or the rtc etc?)
Created attachment 158699 [details] strace of rpc.mountd I did an strace on the rpc.mountd process. It periodically goes nuts, trying to access a ton of files. Some of which don't exist, and never have. (/devfs ? /proc/evms ?) log attached.
I get almost exactly the same behavior on my system (Fedora 7, x86_64), usually for kcore, but occasionally for other files too: audit(1184101280.748:1553): avc: denied { getattr } for pid=2280 comm="rpc.mountd" name="kcore" dev=proc ino=4026531862 scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:object_r:proc_kcore_t:s0 tclass=file
Dave I see from your avc messages that you have some new devices that are not labeled (or labeled device_t). usb1, usb2... Are these /dev/usb1? What is /dev/rtc0?
yes, these are /dev/usb1 etc. rtc0 is the real time clock. Something that rpc should have no business looking at. Could this be a symptom of a leaked file descriptor from something run earlier ? I've no idea why rpc.mountd would care about any of this.
Looks like rpc.mound is just listing the contents of /dev and /proc looking for something, and this is triggering the AVC's. The policy currently has dontaudit;s for properly named devices, but these devices had no label, so they were improperly labeled device_t, thus the avc messages. No Block Device or Char Device should ever be labeled device_t. Should be fixes in selinux-policy-2.6.4-28.fc7
rpc.mountd still should have no business looking at those files. Whilst it won't trigger avc's any more, it'll still be doing a bunch of unnecessary work every time a client does a mount.
I get these 'setroubleshoot' alerts after starting an NFS server, despite having the selinux-policy-2.6.4-28.fc7 policy mentioned in #5. avc: denied { getattr } for comm="rpc.mountd" dev=tmpfs egid=0 euid=0 exe="/usr/sbin/rpc.mountd" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="1-9" path="/dev/1-9" pid=30242 scontext=system_u:system_r:nfsd_t:s0 sgid=0 subj=system_u:system_r:nfsd_t:s0 suid=0 tclass=chr_file tcontext=system_u:object_r:device_t:s0 tty=(none) uid=0 avc: denied { getattr } for comm="rpc.mountd" dev=tmpfs egid=0 euid=0 exe="/usr/sbin/rpc.mountd" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="2-2" path="/dev/2-2" pid=30242 scontext=system_u:system_r:nfsd_t:s0 sgid=0 subj=system_u:system_r:nfsd_t:s0 suid=0 tclass=chr_file tcontext=system_u:object_r:device_t:s0 tty=(none) uid=0 Source Context: system_u:system_r:nfsd_tTarget Context: system_u:object_r:device_t Target Objects: /dev/2-2 [ chr_file ] Affected RPM Packages: nfs-utils-1.0.12-4.fc7 [application] Policy RPM: selinux-policy-2.6.4-28.fc7 $ ls -lZ crw------- root root system_u:object_r:device_t /dev/1-9 crw------- root root system_u:object_r:device_t /dev/2-2 crw------- root root system_u:object_r:device_t /dev/2-4 $ ls -l crw------- 1 root root 189, 1 2007-07-27 06:24 /dev/1-9 crw------- 1 root root 189, 131 2007-07-27 16:50 /dev/2-2 crw------- 1 root root 189, 129 2007-07-27 06:24 /dev/2-4 also the access to kcore remains. avc: denied { getattr } for comm="rpc.mountd" dev=proc egid=0 euid=0 exe="/usr/sbin/rpc.mountd" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="kcore" path="/proc/kcore" pid=30242 scontext=system_u:system_r:nfsd_t:s0 sgid=0 subj=system_u:system_r:nfsd_t:s0 suid=0 tclass=file tcontext=system_u:object_r:proc_kcore_t:s0 tty=(none) uid=0
What are /dev/1-9?
# ls -l /dev/|grep 189 crw------- 1 root root 189, 1 2007-07-27 06:24 1-9 crw------- 1 root root 189, 131 2007-07-27 16:50 2-2 crw------- 1 root root 189, 129 2007-07-27 06:24 2-4 crw------- 1 root root 189, 0 2007-07-27 06:24 usb1 crw------- 1 root root 189, 128 2007-07-27 06:24 usb2 # lsusb Bus 002 Device 004: ID 059f:0651 LaCie, Ltd Bus 002 Device 002: ID 0ea0:2126 Ours Technology, Inc. 7-in-1 Card Reader Bus 002 Device 001: ID 0000:0000 Bus 001 Device 002: ID 045e:0040 Microsoft Corp. Wheel Mouse Optical Bus 001 Device 001: ID 0000:0000 So a usb hard drive, card reader and mouse. Where they expected to be named usb1-9 etc. ? Here are parts of /var/log/messages Jul 27 06:24:37 svart kernel: ohci_hcd 0000:00:02.0: OHCI Host Controller Jul 27 06:24:37 svart kernel: ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1 Jul 27 06:24:37 svart kernel: ohci_hcd 0000:00:02.0: irq 23, io mem 0xf8102000 Jul 27 06:24:37 svart kernel: usb usb1: configuration #1 chosen from 1 choice Jul 27 06:24:37 svart kernel: hub 1-0:1.0: USB hub found Jul 27 06:24:37 svart kernel: hub 1-0:1.0: 10 ports detected ... Jul 27 06:24:37 svart kernel: ehci_hcd 0000:00:02.1: EHCI Host Controller Jul 27 06:24:37 svart kernel: ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 2 Jul 27 06:24:37 svart kernel: ehci_hcd 0000:00:02.1: debug port 1 Jul 27 06:24:37 svart rpc.statd[2351]: Version 1.0.11 Starting Jul 27 06:24:37 svart kernel: ehci_hcd 0000:00:02.1: irq 22, io mem 0xfeb00000 Jul 27 06:24:37 svart kernel: ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 Jul 27 06:24:37 svart kernel: usb usb2: configuration #1 chosen from 1 choice Jul 27 06:24:37 svart kernel: hub 2-0:1.0: USB hub found Jul 27 06:24:37 svart kernel: hub 2-0:1.0: 10 ports detected ... Jul 27 06:24:37 svart kernel: usb 2-4: new high speed USB device using ehci_hcd and address 2 Jul 27 06:24:37 svart kernel: usb 2-4: configuration #1 chosen from 1 choice ... Jul 27 06:24:37 svart kernel: usb 1-9: new low speed USB device using ohci_hcd and address 2 Jul 27 06:24:37 svart kernel: usb 1-9: configuration #1 chosen from 1 choice Jul 27 06:24:37 svart kernel: input: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM) as /class/input/inp ut2 ... Jul 27 16:50:34 svart kernel: usb 2-2: new high speed USB device using ehci_hcd and address 4 Jul 27 16:50:34 svart kernel: usb 2-2: configuration #1 chosen from 1 choice Jul 27 16:50:34 svart kernel: scsi7 : SCSI emulation for USB Mass Storage devices
This looks like udev screwed up????
The kernel changed and introduced a new usb naming scheme. udev-113-7.fc7 is pending for fedora testing updates..
udev-113-8.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report.
udev-113-8.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.