Bug 232491 - Fxload
Summary: Fxload
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Ben Levenson
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-03-15 19:02 UTC by Bart Vanbrabant
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

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


Attachments (Terms of Use)

Description Bart Vanbrabant 2007-03-15 19:02:16 UTC
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-16 03:48:15 UTC
Fixed in selinux-policy-2.5.8-6

Comment 2 Bart Vanbrabant 2007-03-18 20:04:05 UTC
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 18:41:09 UTC
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 14:15:46 UTC
Should be fixed in the current release



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