Description of problem: Some drivers need fxload to load firmware in the usbcontroller ram. This has always worked until I updated the selinux policy from rawhide. (Today's or yesterday's update). At the moment fxload isn't in extras at the moment but review(s) are pending. Setroubleshout gives me this information: Source Context: system_u:system_r:udev_t:SystemLow-SystemHigh Target Context: system_u:object_r:usbfs_t Target Objects: / [ dir ] Affected RPM Packages: fxload-2002_04_11-1 [application]filesystem-2.4.2-1.fc7 [target] Policy RPM: selinux-policy-2.5.8-4.fc7 Selinux Enabled: True Policy Type: targeted MLS Enabled: True Enforcing Mode: Enforcing Plugin Name: plugins.disable_trans Host Name: duvel Platform: Linux duvel 2.6.20-1.2986.fc7PAE #1 SMP Tue Mar 13 16:50:20 EDT 2007 i686 athlon Alert Count: 2 First Seen: Thu 15 Mar 2007 07:52:31 PM CET Last Seen: Thu 15 Mar 2007 07:52:32 PM CET Local ID: 01d6a314-65ac-49a5-ad52-57034223c91f Line Numbers: Raw Audit Messages : avc: denied { search } for comm="fxload" dev=usbfs egid=0 euid=0 exe="/sbin/fxload" exit=-13 fsgid=0 fsuid=0 gid=0 items=0 name="/" pid=7113 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 sgid=0 subj=system_u:system_r:udev_t:s0-s0:c0.c1023 suid=0 tclass=dir tcontext=system_u:object_r:usbfs_t:s0 tty=(none) uid=0
Fixed in selinux-policy-2.5.8-6
This error got resolved. I'm getting others now, so loading firmware still fails. I did setenforce 0 to get all errors this time: avc: denied { ioctl } for comm="fxload" dev=usbfs egid=0 euid=0 exe="/sbin/fxload" exit=1 fsgid=0 fsuid=0 gid=0 items=0 name="003" path="/proc/bus/usb/003/003" pid=2744 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 sgid=0 subj=system_u:system_r:udev_t:s0-s0:c0.c1023 suid=0 tclass=file tcontext=system_u:object_r:usbfs_t:s0 tty=(none) uid=0 avc: denied { read, write } for comm="fxload" dev=usbfs egid=0 euid=0 exe="/sbin/fxload" exit=3 fsgid=0 fsuid=0 gid=0 items=0 name="003" pid=2744 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 sgid=0 subj=system_u:system_r:udev_t:s0-s0:c0.c1023 suid=0 tclass=file tcontext=system_u:object_r:usbfs_t:s0 tty=(none) uid=0 avc: denied { ioctl } for comm="fxload" dev=usbfs egid=0 euid=0 exe="/sbin/fxload" exit=1 fsgid=0 fsuid=0 gid=0 items=0 name="005" path="/proc/bus/usb/003/005" pid=4266 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 sgid=0 subj=system_u:system_r:udev_t:s0-s0:c0.c1023 suid=0 tclass=file tcontext=system_u:object_r:usbfs_t:s0 tty=(none) uid=0 avc: denied { read, write } for comm="fxload" dev=usbfs egid=0 euid=0 exe="/sbin/fxload" exit=3 fsgid=0 fsuid=0 gid=0 items=0 name="005" pid=4266 scontext=system_u:system_r:udev_t:s0-s0:c0.c1023 sgid=0 subj=system_u:system_r:udev_t:s0-s0:c0.c1023 suid=0 tclass=file tcontext=system_u:object_r:usbfs_t:s0 tty=(none) uid=0 When the firmware get load and the actual driver is loaded, /dev/video0 is created. I get this avc then: avc: denied { getattr } for comm="setfacl" dev=tmpfs egid=0 euid=0 exe="/usr/bin/setfacl" exit=0 fsgid=0 fsuid=0 gid=0 items=0 name="video0" path="/dev/video0" pid=5211 scontext=system_u:system_r:hald_acl_t:s0 sgid=0 subj=system_u:system_r:hald_acl_t:s0 suid=0 tclass=chr_file tcontext=system_u:object_r:v4l_device_t:s0 tty=(none) uid=0 This one seems to be coming from hal, do I need to file this in an other bugreport?
I will fix the hal issue. The problem is allowing udev to rw usbfs_t seems a little extreme. I would rather write policy for fxload to confine it rather then extend udev.
Should be fixed in the current release