| Summary: | incorrect selinux policy prevents smartd from accessing LSI Megaraid connected drives | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Gerrit Slomma <gerrit.slomma> |
| Component: | selinux-policy | Assignee: | Lukas Vrabec <lvrabec> |
| Status: | CLOSED ERRATA | QA Contact: | Milos Malik <mmalik> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.4 | CC: | dwalsh, eparis, gerrit.slomma, kschneid, lvrabec, mgrepl, mmalik, paulds |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | selinux-policy-3.7.19-238.el6 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-10-14 07:58:18 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Gerrit Slomma
2013-11-27 15:55:10 UTC
This request was not resolved in time for the current release. Red Hat invites you to ask your support representative to propose this request, if still desired, for consideration in the next release of Red Hat Enterprise Linux. Could you attach AVC msg which you are getting? How to obtain those, please advise... Can't see any avc-messages in /var/log/message except for those where i dis- or enabled selinux via setenforce-command. You can check /var/log/audit/audit.log. # ausearch -m avc Okay.
I did a /etc/init.d/smartd restart which yielded following result (only last entry of ausearch posted):
time->Tue Dec 10 15:48:35 2013
type=SYSCALL msg=audit(1386686915.503:16074): arch=c000003e syscall=2 success=yes exit=4 a0=7f988bebca95 a1=2 a2=7f988b06bed8 a3=16 items=0 ppid=16154 pid=16155 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=2371 comm="smartd" exe="/usr/sbin/smartd" subj=unconfined_u:system_r:fsdaemon_t:s0 key=(null)
type=AVC msg=audit(1386686915.503:16074): avc: denied { open } for pid=16155 comm="smartd" name="megaraid_sas_ioctl_node" dev=devtmpfs ino=2780174 scontext=unconfined_u:system_r:fsdaemon_t:s0 tcontext=unconfined_u:object_r:device_t:s0 tclass=chr_file
type=AVC msg=audit(1386686915.503:16074): avc: denied { read write } for pid=16155 comm="smartd" name="megaraid_sas_ioctl_node" dev=devtmpfs ino=2780174 scontext=unconfined_u:system_r:fsdaemon_t:s0 tcontext=unconfined_u:object_r:device_t:s0 tclass=chr_file
How is /dev/sg1 labeled now? # ls -Z /dev/sg1 # ls -Z /dev/sg1 crw-rw----. root disk system_u:object_r:scsi_generic_device_t:s0 /dev/sg1 There is a race condition. If you run /etc/init.d/smartd restart you get it again, right? What do i get again? I you refer to the selinux-error-messages: yes, i do get them everytime i (re)start the smartd-daemon via /etc/init.d/smartd. Does the smartd script recreated the sgi device? The /dev/sg1-device seems to be persistent: [root@D0164531 ~]# ps -ef|grep smartd root 10194 10135 0 08:50 pts/1 00:00:00 grep smartd root 16157 1 0 2013 ? 00:00:03 /usr/sbin/smartd -q never [root@D0164531 ~]# ls -Z /dev/sg1; ls -l /dev/sg1 crw-rw----. root disk system_u:object_r:scsi_generic_device_t:s0 /dev/sg1 crw-rw----. 1 root disk 21, 1 26. Nov 15:25 /dev/sg1 [root@D0164531 ~]# /etc/init.d/smartd restart smartd beenden: [ OK ] smartd starten: [ OK ] [root@D0164531 ~]# ls -Z /dev/sg1; ls -l /dev/sg1 crw-rw----. root disk system_u:object_r:scsi_generic_device_t:s0 /dev/sg1 crw-rw----. 1 root disk 21, 1 26. Nov 15:25 /dev/sg1 [root@D0164531 ~]# /etc/init.d/smartd stop smartd beenden: [ OK ] [root@D0164531 ~]# ps -ef|grep smartd root 12556 10135 0 08:52 pts/1 00:00:00 grep smartd [root@D0164531 ~]# ls -Z /dev/sg1; ls -l /dev/sg1 crw-rw----. root disk system_u:object_r:scsi_generic_device_t:s0 /dev/sg1 crw-rw----. 1 root disk 21, 1 26. Nov 15:25 /dev/sg1 Or is there any other clue to track if the character-device is recreated? Furthermore i can't see any device-links created in /etc/init.d/smartd or via /etc/smartd.conf.
Miroslav why are we looking at sd1 rather then "megaraid_sas_ioctl_node
type=AVC msg=audit(1386686915.503:16074): avc: denied { open } for pid=16155 comm="smartd" name="megaraid_sas_ioctl_node" dev=devtmpfs ino=2780174 scontext=unconfined_u:system_r:fsdaemon_t:s0 tcontext=unconfined_u:object_r:device_t:s0 tclass=chr_file
The problem is this char file is mislabeled.
I am getting this problem as well on several RHEV 6 systems. # ls -lZ /dev/megaraid_sas_ioctl_node c---------. root root system_u:object_r:device_t:s0 /dev/megaraid_sas_ioctl_node # restorecon -v /dev/megaraid_sas_ioctl_node restorecon reset /dev/megaraid_sas_ioctl_node context system_u:object_r:device_t:s0->system_u:object_r:fixed_disk_device_t:s0 # ls -lZ /dev/megaraid_sas_ioctl_node c---------. root root system_u:object_r:fixed_disk_device_t:s0 /dev/megaraid_sas_ioctl_node And then restarting smartd shows no further errors. I haven't confirmed this, but anecdotally it looks like the problem may reoccur following a system reboot. Am I correct in thinking that this means the selinux-policy is already correct, since restorecon knows what type it ought to be, but whatever is (re)creating the device file (smartd? udev?) is for whatever reason creating it with the wrong type? Ie, perhaps the bug component ought to be changed? The device is being created by something other then udev, which would label it correctly. When udev realizes their is a mislabeled file it fixes the label. We have a fix for this in RHEL7. In RHEL6 we should probably allow fsdaemon_t to manage device_t char_file. It can already manage fixed disk, so it is pretty much unconfined. Added rule dev_rw_generic_chr_files(fsdaemon_t). Patch sent to Mirek. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2014-1568.html |