Bug 232491 - Fxload
Fxload
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-15 15:02 EDT by Bart Vanbrabant
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: Current
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-22 10:15:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bart Vanbrabant 2007-03-15 15:02:16 EDT
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
Comment 1 Daniel Walsh 2007-03-15 23:48:15 EDT
Fixed in selinux-policy-2.5.8-6
Comment 2 Bart Vanbrabant 2007-03-18 16:04:05 EDT
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?
Comment 3 Daniel Walsh 2007-03-19 14:41:09 EDT
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.
Comment 4 Daniel Walsh 2007-08-22 10:15:46 EDT
Should be fixed in the current release

Note You need to log in before you can comment on or make changes to this bug.