Bug 456471
| Summary: | SELinux avoids smartd usage with AMCC/3ware IDE RAID controller (/dev/tweX) | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Robert Scheck <redhat-bugzilla> |
| Component: | smartmontools | Assignee: | Tomas Smetana <tsmetana> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | low | ||
| Version: | 5.2 | CC: | andreas, dwalsh, harald, nino, robert.scheck, tsmetana |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2009-01-20 20:52:49 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Robert Scheck
2008-07-23 21:24:19 UTC
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. 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 ;-) What does matchpatchon /dev/twe0 say? If you run restorecon on the devices do they get fixed? 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? 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. 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. (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. 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. 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. *** Bug 456859 has been marked as a duplicate of this bug. *** Tomas is there already something to test which has a chance to get into RHEL 5.3? (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/ Tomas, what will be the solution for RHEL 5.3 now? You meant, that rebasing itself won't help... (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. 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. 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. 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. 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. [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? What AVC messages did you get in /var/log/audit/audit.log? 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 #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) 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. So either a job for Daniel and/or Harald, I would guess. Who takes it? *** Bug 465639 has been marked as a duplicate of this bug. *** Policy rules added to selinux-policy-2.4.6-165 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... http://people.redhat.com/dwalsh/SELinux/RHEL5 has a preview copy. 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 |