Bug 547387 - SELinux denies smartd access to /dev/sg*
Summary: SELinux denies smartd access to /dev/sg*
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: selinux-policy
Version: 5.4
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Miroslav Grepl
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 582145
TreeView+ depends on / blocked
 
Reported: 2009-12-14 15:05 UTC by Hannes Schulz
Modified: 2012-10-15 14:38 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 582145 (view as bug list)
Environment:
Last Closed: 2010-03-30 07:50:43 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2010:0182 0 normal SHIPPED_LIVE selinux-policy bug fix update 2010-03-29 12:19:53 UTC

Description Hannes Schulz 2009-12-14 15:05:12 UTC
Description of problem:
SELinux denies smartd access to /dev/sg*

Version-Release number of selected component (if applicable):
smartmontools-5.38-2.el5
selinux-policy-2.4.6-255.el5_4.1

How reproducible:
The disks of my system are exposed as /dev/sg[123] by the Adaptec RAID Controller (aacraid). 


Steps to Reproduce:
1. Find a system using an Adaptec aacraid Controller
2. Add a line such as this in "/etc/smartd.conf":
/dev/sg1 -H -o on -S on -s (S/../.././12|L/../../5/08) -l error -l selftest -f -p -u -W 5,40,50 -m root
3. "service smartd start"
  
Actual results:

[root@saur ~]# sealert -l 2b2200cb-5933-4587-904f-66a5d2d43cdd

Summary:

SELinux is preventing smartd (fsdaemon_t) "read write" to sg1
(scsi_generic_device_t).

Detailed Description:

[SELinux is in permissive mode, the operation would have been denied but was
permitted due to permissive mode.]

SELinux denied access requested by smartd. It is not expected that this access
is required by smartd and this access may signal an intrusion attempt. It is
also possible that the specific version or configuration of the application is
causing it to require additional access.

Allowing Access:

Sometimes labeling problems can cause SELinux denials. You could try to restore
the default system file context for sg1,

restorecon -v 'sg1'

If this does not work, there is currently no automatic way to allow this access.
Instead, you can generate a local policy module to allow this access - see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can disable
SELinux protection altogether. Disabling SELinux protection is not recommended.
Please file a bug report (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.

Additional Information:

Source Context                system_u:system_r:fsdaemon_t
Target Context                system_u:object_r:scsi_generic_device_t
Target Objects                sg1 [ chr_file ]
Source                        smartd
Source Path                   /usr/sbin/smartd
Port                          <Unknown>
Host                          saur.wien-ticket.at
Source RPM Packages           smartmontools-5.38-2.el5
Target RPM Packages           
Policy RPM                    selinux-policy-2.4.6-255.el5_4.1
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Permissive
Plugin Name                   catchall_file
Host Name                     saur.wien-ticket.at
Platform                      Linux saur.wien-ticket.at 2.6.18-164.6.1.el5xen #1
                              SMP Tue Oct 27 11:45:55 EDT 2009 x86_64 x86_64
Alert Count                   58
First Seen                    Sun Dec  6 18:42:20 2009
Last Seen                     Mon Dec 14 15:44:15 2009
Local ID                      2b2200cb-5933-4587-904f-66a5d2d43cdd
Line Numbers                  

Raw Audit Messages            

host=saur.wien-ticket.at type=AVC msg=audit(1260801855.468:22586): avc:  denied  { read write } for  pid=3735 comm="smartd" name="sg1" dev=tmpfs ino=7406 scontext=system_u:system_r:fsdaemon_t:s0 tcontext=system_u:object_r:scsi_generic_device_t:s0 tclass=chr_file

host=saur.wien-ticket.at type=SYSCALL msg=audit(1260801855.468:22586): arch=c000003e syscall=2 success=yes exit=3 a0=2b1c801b8810 a1=802 a2=0 a3=8 items=0 ppid=1 pid=3735 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="smartd" exe="/usr/sbin/smartd" subj=system_u:system_r:fsdaemon_t:s0 key=(null)




Expected results:
No such error message


Additional info:

Comment 1 Michal Hlavinka 2009-12-14 15:33:27 UTC
this seems like job for selinux, re-assigning

Comment 2 Daniel Walsh 2009-12-15 13:25:35 UTC
Miroslav add

storage_read_scsi_generic(fsdaemon_t)
storage_write_scsi_generic(fsdaemon_t)

Comment 3 Miroslav Grepl 2009-12-21 11:28:57 UTC
Fixed in selinux-policy-2.4.6-267.el5.noarch

Comment 7 errata-xmlrpc 2010-03-30 07:50:43 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0182.html


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