Bug 634650 - SELinux is preventing /sbin/usbhid-ups "read write" access to device 104.
SELinux is preventing /sbin/usbhid-ups "read write" access to device 104.
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: udev (Show other bugs)
13
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Fedora Extras Quality Assurance
setroubleshoot_trace_hash:546a446ac58...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-09-16 11:52 EDT by Laurent Rineau
Modified: 2010-10-05 06:44 EDT (History)
5 users (show)

See Also:
Fixed In Version: udev-153-4.fc13
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-09-26 00:37:24 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)
open fds of /sbin/usbhid-ups with contexts: result of sudo sh -c 'ls -lZ /proc/`pidof usbhid-ups`/fd' (4.94 KB, text/plain)
2010-09-16 11:58 EDT, Laurent Rineau
no flags Details

  None (edit)
Description Laurent Rineau 2010-09-16 11:52:22 EDT
Summary:

SELinux is preventing /sbin/usbhid-ups "read write" access to device 104.

Detailed Description:

[usbhid-ups has a permissive type (nut_upsdrvctl_t). This access was not
denied.]

SELinux has denied usbhid-ups "read write" access to device 104. 104 is
mislabeled, this device has the default label of the /dev directory, which
should not happen. All Character and/or Block Devices should have a label. You
can attempt to change the label of the file using restorecon -v '104'. If this
device remains labeled device_t, then this is a bug in SELinux policy. Please
file a bg report. If you look at the other similar devices labels, ls -lZ
/dev/SIMILAR, and find a type that would work for 104, you can use chcon -t
SIMILAR_TYPE '104', If this fixes the problem, you can make this permanent by
executing semanage fcontext -a -t SIMILAR_TYPE '104' If the restorecon changes
the context, this indicates that the application that created the device,
created it without using SELinux APIs. If you can figure out which application
created the device, please file a bug report against this application.

Allowing Access:

Attempt restorecon -v '104' or chcon -t SIMILAR_TYPE '104'

Additional Information:

Source Context                system_u:system_r:nut_upsdrvctl_t:s0
Target Context                system_u:object_r:device_t:s0
Target Objects                104 [ chr_file ]
Source                        usbhid-ups
Source Path                   /sbin/usbhid-ups
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           nut-2.4.3-5.fc13
Target RPM Packages           
Policy RPM                    selinux-policy-3.7.19-54.fc13
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Plugin Name                   device
Host Name                     (removed)
Platform                      Linux (removed) 2.6.34.6-54.fc13.x86_64
                              #1 SMP Sun Sep 5 17:16:27 UTC 2010 x86_64 x86_64
Alert Count                   6
First Seen                    Mon 13 Sep 2010 12:12:54 AM CEST
Last Seen                     Thu 16 Sep 2010 01:27:23 PM CEST
Local ID                      963c0789-7b6f-49a1-a7d6-c50a4cac2b29
Line Numbers                  

Raw Audit Messages            

node=(removed) type=AVC msg=audit(1284636443.904:2566): avc:  denied  { read write } for  pid=1973 comm="usbhid-ups" name="104" dev=devtmpfs ino=15173387 scontext=system_u:system_r:nut_upsdrvctl_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file

node=(removed) type=AVC msg=audit(1284636443.904:2566): avc:  denied  { open } for  pid=1973 comm="usbhid-ups" name="104" dev=devtmpfs ino=15173387 scontext=system_u:system_r:nut_upsdrvctl_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file

node=(removed) type=SYSCALL msg=audit(1284636443.904:2566): arch=c000003e syscall=2 success=yes exit=54 a0=7fffe3e9c350 a1=2 a2=7fffe3e9c364 a3=fffffffd items=0 ppid=1 pid=1973 auid=4294967295 uid=57 gid=57 euid=57 suid=57 fsuid=57 egid=57 sgid=57 fsgid=57 tty=(none) ses=4294967295 comm="usbhid-ups" exe="/sbin/usbhid-ups" subj=system_u:system_r:nut_upsdrvctl_t:s0 key=(null)



Hash String generated from  device,usbhid-ups,nut_upsdrvctl_t,device_t,chr_file,read,write
audit2allow suggests:

#============= nut_upsdrvctl_t ==============
#!!!! The source type 'nut_upsdrvctl_t' can write to a 'chr_file' of the following types:
# devtty_t, usb_device_t, initrc_devpts_t, tty_device_t, null_device_t, zero_device_t

allow nut_upsdrvctl_t device_t:chr_file { read write open };
Comment 1 Laurent Rineau 2010-09-16 11:58:42 EDT
Created attachment 447779 [details]
open fds of /sbin/usbhid-ups with contexts: result of sudo sh -c 'ls -lZ /proc/`pidof usbhid-ups`/fd'

It seems to be a sort of race-condition between udev and /sbin/usbhid-ups

I attach the result of sudo sh -c 'ls -lZ /proc/`pidof usbhid-ups`/fd' that displays selinux contexts of devices opened by usbhid-ups
Comment 2 Laurent Rineau 2010-09-16 12:01:22 EDT
Comment on attachment 447779 [details]
open fds of /sbin/usbhid-ups with contexts: result of sudo sh -c 'ls -lZ /proc/`pidof usbhid-ups`/fd'

Ooops. The context in /proc/$PID/fd are those of the symbolic links.

Here is the context of the real device:
$ ls -lZ /dev/bus/usb/004/104
crw-rw-r--. root dialout system_u:object_r:usb_device_t:s0 /dev/bus/usb/004/104
Comment 3 Laurent Rineau 2010-09-16 12:06:14 EDT
udev has a rule for my UPS device, in this file:
  /lib/udev/rules.d/62-nut-usbups.rules
Here is the relevant line:
ATTR{idVendor}=="0463", ATTR{idProduct}=="ffff", MODE="664", GROUP="dialout"

Should there be here something about the SELinux context of the newly created device inode?
Comment 4 Fedora Update System 2010-09-22 08:10:01 EDT
udev-153-4.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/udev-153-4.fc13
Comment 5 Fedora Update System 2010-09-23 00:58:52 EDT
udev-153-4.fc13 has been pushed to the Fedora 13 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 udev'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/udev-153-4.fc13
Comment 6 Fedora Update System 2010-09-26 00:36:57 EDT
udev-153-4.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 7 Laurent Rineau 2010-10-05 06:44:29 EDT
I use udev-153-4.fc13.x86_64 but still have the AVCs.

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