Bug 456471 - SELinux avoids smartd usage with AMCC/3ware IDE RAID controller (/dev/tweX)
SELinux avoids smartd usage with AMCC/3ware IDE RAID controller (/dev/tweX)
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: smartmontools (Show other bugs)
5.2
All Linux
low Severity medium
: rc
: ---
Assigned To: Tomas Smetana
:
: 456859 465639 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-23 17:24 EDT by Robert Scheck
Modified: 2009-01-20 15:52 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-01-20 15:52:49 EST
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 Robert Scheck 2008-07-23 17:24:19 EDT
Description of problem:
SELinux avoids smartd usage with AMCC/3ware IDE RAID controller (/dev/tweX):

Jul 23 22:13:18 perimeter smartd[24203]: smartd version 5.36
[i686-redhat-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Jul 23 22:13:18 perimeter smartd[24203]: Home page is
http://smartmontools.sourceforge.net/
Jul 23 22:13:18 perimeter smartd[24203]: Opened configuration file /etc/smartd.conf
Jul 23 22:13:18 perimeter smartd[24203]: Configuration file /etc/smartd.conf parsed.
Jul 23 22:13:18 perimeter kernel: audit(1216843998.184:4): avc:  denied  {
getattr } for  pid=24203 comm="smartd" path="/dev/twe0" dev=tmpfs ino=78574 sconte
xt=root:system_r:fsdaemon_t:s0 tcontext=root:object_r:device_t:s0 tclass=chr_file
Jul 23 22:13:18 perimeter smartd[24203]: Device: /dev/twe0 [3ware_disk_00], File
exists, open() failed
Jul 23 22:13:18 perimeter smartd[24203]: Unable to register ATA device /dev/twe0
[3ware_disk_00] at line 28 of file /etc/smartd.conf
Jul 23 22:13:18 perimeter smartd[24203]: Device /dev/twe0 [3ware_disk_00] not
available
Jul 23 22:13:18 perimeter kernel: audit(1216843998.185:5): avc:  denied  {
getattr } for  pid=24203 comm="smartd" path="/dev/twe0" dev=tmpfs ino=78574 sconte
xt=root:system_r:fsdaemon_t:s0 tcontext=root:object_r:device_t:s0 tclass=chr_file
Jul 23 22:13:18 perimeter smartd[24203]: Device: /dev/twe0 [3ware_disk_01], File
exists, open() failed
Jul 23 22:13:18 perimeter smartd[24203]: Unable to register ATA device /dev/twe0
[3ware_disk_01] at line 29 of file /etc/smartd.conf
Jul 23 22:13:18 perimeter smartd[24203]: Device /dev/twe0 [3ware_disk_01] not
available
Jul 23 22:13:18 perimeter smartd[24203]: Monitoring 0 ATA and 0 SCSI devices
Jul 23 22:13:18 perimeter smartd[24205]: smartd has fork()ed into background
mode. New PID=24205.

Version-Release number of selected component (if applicable):
smartmontools-5.36-4
selinux-policy-targeted-2.4.6-137.1

How reproducible:
Everytime. Get a AMCC/3ware IDE RAID controller, configure it and try to start 
it when having SELinux enforced. After "setenforce 0" smartd works as expected.
  
Actual results:
SELinux avoids smartd usage with AMCC/3ware IDE RAID controller (/dev/tweX).

Expected results:
Working smartd even when having a AMCC/3ware IDE RAID controller (/dev/tweX).

Additional info:
--- snipp from lscpi ---
00:03.0 RAID bus controller: 3ware Inc 7xxx/8xxx-series PATA/SATA-RAID (rev 01)
        Subsystem: 3ware Inc 7xxx/8xxx-series PATA/SATA-RAID
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 32 (2250ns min), Cache Line Size: 64 bytes
        Interrupt: pin A routed to IRQ 177
        Region 0: I/O ports at ecf0 [size=16]
        Region 1: Memory at fe902000 (32-bit, non-prefetchable) [size=16]
        Region 2: Memory at fe000000 (32-bit, non-prefetchable) [size=8M]
        Expansion ROM at fe800000 [disabled] [size=64K]
        Capabilities: [40] Power Management version 1
                Flags: PMEClk- DSI- D1+ D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
--- snapp from lscpi ---

--- snipp from smartd.conf ---
/dev/twe0 -H -d 3ware,0 -m root
/dev/twe0 -H -d 3ware,1 -m root
--- snapp from smartd.conf ---
Comment 1 Daniel Walsh 2008-07-24 06:40:15 EDT
The problem here is the devices were created with the wrong context.  restorecon
/dev/tw*  should change the context to fixed_disk_device_t.  Do you know which
tool created the devices.  udev would/should have created them correctly.
Comment 2 Robert Scheck 2008-07-24 06:46:45 EDT
All I did was the following. As per that, I would say, udev created the devices.

 1. Putting the controller into the machine physically.
 2. Install the machine with Red Hat Enterprise Linux 5.2
 3. Apply all software updates and friends
 4. Reboot because of the kernel update
 5. Configure smartd via /etc/smartd.conf and restart the service
 6. Get the messages as above in the syslog and cry ;-)
Comment 3 Daniel Walsh 2008-07-24 06:59:40 EDT
What does matchpatchon /dev/twe0 say?
If you run restorecon on the devices do they get fixed?
Comment 4 Robert Scheck 2008-07-24 07:22:39 EDT
Without any relabeling/restorecon in the meantime:

[root@perimeter ~]# matchpathcon /dev/twe0
/dev/twe0       system_u:object_r:fixed_disk_device_t
[root@perimeter ~]#

[root@perimeter ~]# restorecon -v /dev/twe0
[root@perimeter ~]#

[root@perimeter ~]# matchpathcon /dev/twe0
/dev/twe0       system_u:object_r:fixed_disk_device_t
[root@perimeter ~]#

Is maybe smartd not allowed to access such devices?
Comment 5 Tomas Smetana 2008-07-24 07:38:02 EDT
This seems to have the same cause as bug #232218.  Note that smartmontools will
be rebased in 5.3 to the latest upstream version that should fix the problem.
Comment 6 Robert Scheck 2008-07-24 07:47:12 EDT
Yes, looks like a duplicate without digging really deep into it now. Can
we make somehow sure, that a fix for this will go into 5.3 (including maybe 
necessary SELinux adoptions)? I'm not marking as duplicate hereby, because
this is RHEL and not Fedora, so different trees/branches.
Comment 7 Tomas Smetana 2008-07-24 07:58:31 EDT
(In reply to comment #6)
> Can we make somehow sure, that a fix for this will go into 5.3 (including maybe 
> necessary SELinux adoptions)?

The smartmontools is on the list of approved components and the rebase request
was already acked (bug #438556) so hopefully yes.

Comment 8 RHEL Product and Program Management 2008-07-24 08:00:23 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 9 Tomas Smetana 2008-07-28 04:27:01 EDT
Hm.  I was wrong.  Rebasing itself won't help.  But the patch is ready, tested
and accepted upstream, so this shouldn't be a big problem from my point of view.
Comment 11 Daniel Walsh 2008-07-28 14:46:38 EDT
*** Bug 456859 has been marked as a duplicate of this bug. ***
Comment 12 Robert Scheck 2008-07-28 14:50:26 EDT
Tomas is there already something to test which has a chance to get into RHEL 5.3?
Comment 13 Tomas Smetana 2008-07-29 01:59:10 EDT
(In reply to comment #12)
> Tomas is there already something to test which has a chance to get into RHEL 5.3?

Yes. Here you are: http://tsmetana.fedorapeople.org/smartmontools/
Comment 15 Robert Scheck 2008-09-23 11:37:57 EDT
Tomas, what will be the solution for RHEL 5.3 now? You meant, that rebasing 
itself won't help...
Comment 16 Tomas Smetana 2008-09-24 02:20:58 EDT
(In reply to comment #15)

Of course I have not only rebased but also included the patch we have in Fedora (and upstream CVS) for the bug #232218.  I hope that would solve the problem.
Comment 17 Robert Scheck 2008-09-24 02:39:40 EDT
So http://cvs.fedoraproject.org/viewvc/devel/smartmontools/smartmontools-5.38-selinux.patch right? I will test that patch with our box the next time and let you know.
Comment 18 Robert Scheck 2008-10-09 17:45:12 EDT
Tomas, just putting the smartmontools-5.38-selinux.patch into the RHEL 5.2 
smartmontools package, rebuilding and testing brings just the same result as
without the patch.
Comment 19 Robert Scheck 2008-10-09 17:49:56 EDT
Tomas, even rebuilding smartmontools-5.38-7 for RHEL 5.2 doesn't seem to solve the problem for me. I still get:

Oct  9 23:48:45 ext-fw smartd[11284]: smartd version 5.38 [i686-redhat-linux-gnu] Copyright (C) 2002-8 Bruce Allen
Oct  9 23:48:45 ext-fw smartd[11284]: Home page is http://smartmontools.sourceforge.net/
Oct  9 23:48:45 ext-fw smartd[11284]: Opened configuration file /etc/smartd.conf
Oct  9 23:48:45 ext-fw smartd[11284]: Configuration file /etc/smartd.conf parsed.
Oct  9 23:48:45 ext-fw smartd[11284]: Device: /dev/twe0 [3ware_disk_00], Permission denied, open() failed
Oct  9 23:48:45 ext-fw smartd[11284]: Unable to register ATA device /dev/twe0 [3ware_disk_00] at line 28 of file /etc/smartd.conf
Oct  9 23:48:45 ext-fw smartd[11284]: Device /dev/twe0 [3ware_disk_00] not available
Oct  9 23:48:45 ext-fw smartd[11284]: Device: /dev/twe0 [3ware_disk_01], Permission denied, open() failed
Oct  9 23:48:45 ext-fw smartd[11284]: Unable to register ATA device /dev/twe0 [3ware_disk_01] at line 29 of file /etc/smartd.conf
Oct  9 23:48:45 ext-fw smartd[11284]: Device /dev/twe0 [3ware_disk_01] not available
Oct  9 23:48:45 ext-fw smartd[11284]: Monitoring 0 ATA and 0 SCSI devices
Oct  9 23:48:45 ext-fw smartd[11286]: smartd has fork()ed into background mode. New PID=11286.
Comment 20 Tomas Smetana 2008-10-10 03:27:24 EDT
That would be bad.  Please verify that the security labels and the permissions of the devices were correct prior to starting smartd/smartctl.

Thank you for the testing.
Comment 21 Robert Scheck 2008-10-10 04:12:54 EDT
[root@ext-fw ~]# matchpathcon /dev/twe0
/dev/twe0       system_u:object_r:fixed_disk_device_t
[root@ext-fw ~]# 

[root@ext-fw ~]# restorecon -v /dev/twe0
[root@ext-fw ~]# 

[root@ext-fw ~]# matchpathcon /dev/twe0
/dev/twe0       system_u:object_r:fixed_disk_device_t
[root@ext-fw ~]#

[root@ext-fw ~]# ls -Z /dev/twe0
crw-------  root root system_u:object_r:fixed_disk_device_t /dev/twe0
[root@ext-fw ~]#

[root@ext-fw ~]# ls -l /dev/twe0
crw------- 1 root root 253, 0 Oct  5 12:10 /dev/twe0
[root@ext-fw ~]# 

After that, I did a "service smartd restart" and still find the errors from comment #19 independent of patched smartmontools-5.36-4 or using plain/rawhide
smartmontools-5.38-7 (of course rebuilt for RHEL 5.2).

Any further suggestions?
Comment 22 Tomas Smetana 2008-10-10 04:28:56 EDT
What AVC messages did you get in /var/log/audit/audit.log?
Comment 23 Robert Scheck 2008-10-10 07:08:00 EDT
type=AVC msg=audit(1223636864.734:35226): avc:  denied  { setfscreate } for  pid=20205 comm="smartd" scontext=user_u:system_r:fsdaemon_t:s0 tcontext=user_u:system_r:fsdaemon_t:s0 tclass=process
type=SYSCALL msg=audit(1223636864.734:35226): arch=40000003 syscall=4 success=no exit=-13 a0=3 a1=0 a2=0 a3=f64a28 items=0 ppid=20204 pid=20205 auid=1005 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=5786 comm="smartd" exe="/usr/sbin/smartd" subj=user_u:system_r:fsdaemon_t:s0 key=(null)
type=AVC msg=audit(1223636864.735:35227): avc:  denied  { setfscreate } for  pid=20205 comm="smartd" scontext=user_u:system_r:fsdaemon_t:s0 tcontext=user_u:system_r:fsdaemon_t:s0 tclass=process
type=SYSCALL msg=audit(1223636864.735:35227): arch=40000003 syscall=4 success=no exit=-13 a0=3 a1=0 a2=0 a3=f64a28 items=0 ppid=20204 pid=20205 auid=1005 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=5786 comm="smartd" exe="/usr/sbin/smartd" subj=user_u:system_r:fsdaemon_t:s0 key=(null)
Comment 24 Robert Scheck 2008-10-10 07:10:15 EDT
Comment #23 is smartmontools-5.38-7 from Rawhide and rebuilt for RHEL 5.2

And when taking the selinux patch to the smartmontools 5.36-4 which is anyway
in RHEL 5.2, then:

type=AVC msg=audit(1223636909.753:35234): avc:  denied  { getattr } for  pid=20242 comm="smartd" path="/dev/twe1" dev=tmpfs ino=10231 scontext=user_u:system_r:fsdaemon_t:s0 tcontext=user_u:object_r:device_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1223636909.753:35234): arch=40000003 syscall=195 success=no exit=-13 a0=bfadfe70 a1=bfadfd20 a2=4e3ff4 a3=3 items=0 ppid=20241 pid=20242 auid=1005 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=5786 comm="smartd" exe="/usr/sbin/smartd" subj=user_u:system_r:fsdaemon_t:s0 key=(null)
type=AVC msg=audit(1223636909.754:35235): avc:  denied  { getattr } for  pid=20242 comm="smartd" path="/dev/twe1" dev=tmpfs ino=10231 scontext=user_u:system_r:fsdaemon_t:s0 tcontext=user_u:object_r:device_t:s0 tclass=chr_file
type=SYSCALL msg=audit(1223636909.754:35235): arch=40000003 syscall=195 success=no exit=-13 a0=bfadfe70 a1=bfadfd20 a2=4e3ff4 a3=3 items=0 ppid=20241 pid=20242 auid=1005 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=5786 comm="smartd" exe="/usr/sbin/smartd" subj=user_u:system_r:fsdaemon_t:s0 key=(null)
Comment 25 Tomas Smetana 2008-10-13 07:20:35 EDT
It seems that smartmontools are not even allowed to create the devices with correct context.  I don't think it can be solved in smartmontools though.  Either SELinux policy must be changed or udev should create the devices so smartmontools wouldn't have to do that.
Comment 26 Robert Scheck 2008-10-13 07:30:43 EDT
So either a job for Daniel and/or Harald, I would guess. Who takes it?
Comment 27 Michal Hlavinka 2008-10-13 09:01:58 EDT
*** Bug 465639 has been marked as a duplicate of this bug. ***
Comment 28 Daniel Walsh 2008-10-14 10:31:49 EDT
Policy rules added to selinux-policy-2.4.6-165
Comment 29 Robert Scheck 2008-10-14 11:08:09 EDT
Daniel, do you have the package somewhere around (as source RPM), so that I
can test (and use it) here at this machine? Alternatively just attach to an
e-mail...
Comment 30 Daniel Walsh 2008-10-15 14:45:18 EDT
http://people.redhat.com/dwalsh/SELinux/RHEL5

has a preview copy.
Comment 32 errata-xmlrpc 2009-01-20 15:52:49 EST
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/RHEA-2009-0089.html

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