Bug 245702 - preventing /usr/sbin/smartd (fsdaemon_t) "read write" access to device sda
Summary: preventing /usr/sbin/smartd (fsdaemon_t) "read write" access to device sda
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 7
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-06-26 07:03 UTC by Bob Gustafson
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-06-28 12:20:21 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Bob Gustafson 2007-06-26 07:03:22 UTC
Description of problem:

Just following the instructions in the alert box

[root@hoho2 sql-ledger-progs]# /sbin/restorecon -v /dev/sda
[root@hoho2 sql-ledger-progs]# ls -lZ /dev/sda
brw-r-----  root disk system_u:object_r:fixed_disk_device_t /dev/sda
[root@hoho2 sql-ledger-progs]# 

Didn't seem to change status, so filed this bug report

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.  
2. Noticed yellow star on menu bar
3. click on yellow star - read alerts
  
Actual results:

No alerts

(Would also like to turn on strict selinux as well - one of these days.


Expected results:


Additional info:

Summary
    SELinux is preventing /usr/sbin/smartd (fsdaemon_t) "read write" access to
    device sda.

Detailed Description
    SELinux has denied the /usr/sbin/smartd (fsdaemon_t) "read write" access to
    device sda. sda 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 sda. If this device remains labeled device_t, then this is a
    bug in SELinux policy. Please file a
    http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against the selinux-policy
    package. If you look at the other similar devices labels, ls -lZ
    /dev/SIMILAR, and find a type that would work for sda, you can use chcon -t
    SIMILAR_TYPE sda, If this fixes the problem, you can make this permanent by
    executing semanage fcontext -a -t SIMILAR_TYPE sda 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
    http://bugzilla.redhat.com/bugzilla/enter_bug.cgi against this application.

Allowing Access
    Attempt restorecon -v sda or chcon -t SIMILAR_TYPE sda

Additional Information        

Source Context                system_u:system_r:fsdaemon_t
Target Context                system_u:object_r:device_t
Target Objects                sda [ blk_file ]
Affected RPM Packages         smartmontools-5.36-3.2.fc6 [application]
Policy RPM                    selinux-policy-2.4.6-17.fc6
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Permissive
Plugin Name                   plugins.device
Host Name                     hoho2.chidig.com
Platform                      Linux hoho2.chidig.com 2.6.18-1.2869.fc6 #1 SMP
                              Wed Dec 20 14:51:46 EST 2006 i686 i686
Alert Count                   21
First Seen                    Fri 12 Jan 2007 07:58:40 PM CST
Last Seen                     Tue 16 Jan 2007 02:28:40 PM CST
Local ID                      48b377dc-48b4-4fea-9433-dc4d27d5dcf5
Line Numbers                  

Raw Audit Messages            

avc: denied { read, write } for comm="smartd" dev=tmpfs egid=0 euid=0
exe="/usr/sbin/smartd" exit=3 fsgid=0 fsuid=0 gid=0 items=0 name="sda" pid=2523
scontext=system_u:system_r:fsdaemon_t:s0 sgid=0
subj=system_u:system_r:fsdaemon_t:s0 suid=0 tclass=blk_file
tcontext=system_u:object_r:device_t:s0 tty=(none) uid=0



Not so easy to find version...

[root@hoho2 sql-ledger-progs]# /sbin/restorecon --version
/sbin/restorecon: invalid option -- -
usage:  /sbin/restorecon [-iFnrRv] [-e excludedir ] [-o filename ] [-f filename
| pathname... ]
[root@hoho2 sql-ledger-progs]# /sbin/restorecon -V
/sbin/restorecon: invalid option -- V
usage:  /sbin/restorecon [-iFnrRv] [-e excludedir ] [-o filename ] [-f filename
| pathname... ]
[root@hoho2 sql-ledger-progs]# /sbin/restorecon --help
/sbin/restorecon: invalid option -- -
usage:  /sbin/restorecon [-iFnrRv] [-e excludedir ] [-o filename ] [-f filename
| pathname... ]
[root@hoho2 sql-ledger-progs]#

Comment 1 Daniel Walsh 2007-06-26 10:12:30 UTC
You reported this as an 5c7 bug but put in a fc6 bug report?  The cause of this
problem is a mislabeled /dev/sda device.  For some reason this device was not
created with the correct context.  If it was not created via udev, then what
ever is creating it did not set it correctly.  If it is created in an init
script you need to add a line restorecon /dev/sda right after the mknod.

Comment 2 Bob Gustafson 2007-06-26 13:01:55 UTC
I am running an uptodate F7 system.  I copied the info from the setroubleshooter
window. If it is wrong, then something in the se initialization gets it wrong.

My system (where I wrote the bug) is:

[root@hoho2 ThyraAccounts]# cat /proc/version
Linux version 2.6.21-1.3228.fc7 (kojibuilder.redhat.com) (gcc
version 4.1.2 20070502 (Red Hat 4.1.2-12)) #1 SMP Tue Jun 12 15:37:31 EDT 2007
[root@hoho2 ThyraAccounts]# 

----------------------------------

The sda,b devices are scsi which are hooked up as RAID 1. The installation
process (anaconda) for F7 is very unfriendly to RAID/LVM (see bug 242043 bug
241949 bug 237415 ).

Since I am using the RAID 1 implemented in FC6, maybe that is where the fc6
comes from. An open question.

All of my fixed disks have the same ls -lZ response:

brw-r-----  root  disk   system_u:object_r:fixed_disk_device_t sda
brw-r-----  root  disk   system_u:object_r:fixed_disk_device_t sda1
brw-r-----  root  disk   system_u:object_r:fixed_disk_device_t sda2
brw-r-----  root  disk   system_u:object_r:fixed_disk_device_t sda3
brw-r-----  root  disk   system_u:object_r:fixed_disk_device_t sdb
brw-r-----  root  disk   system_u:object_r:fixed_disk_device_t sdb1
brw-r-----  root  disk   system_u:object_r:fixed_disk_device_t sdb2
brw-r-----  root  disk   system_u:object_r:fixed_disk_device_t sdb3

I have a hazy idea of what selinux is trying to do, but restorecon does not seem
to have much effect on any of these disks. The partitions 1,2,3 are /boot /swap
/root (LVM).

The smartd application goes out to the disk hardware itself and queries various
registers to determine how hot it is and how many errors the disk has
accumulated since the last time it was queried. It mostly reads, but may write
to reset registers in the disk - don't know for sure.

smartd is quite helpful to me on a long term basis. I saw high temperatures and
I was able to get an extra fan and vacuum out the fuzz balls early enough to
prevent trouble...

Comment 3 Daniel Walsh 2007-06-27 15:27:54 UTC
Ok, could you update to the latest selinux-policy for fc7.  Then see if these
messages are still happening.  What is being reported was a device was created
in /dev/ named sda, this had the directory label device_t on it rather then the
fixed_disk_device_t label that udev should have put on it at the time smart
tried to use it, and was denied by SELinux.  The question was this only a
problem during the upgrade or are you continuing to see it?

Comment 4 Bob Gustafson 2007-06-28 12:18:31 UTC
Yeah, I think it is OK.

The Jan 12 date of the bug was my 'pilot error'. I looked in the setroubleshoot
browser and saw Jun 12...  Not a new problem.


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