| Summary: | Wrong SELinux context of /dev/{random,null,zero} in bind chroot directory /var/named/chroot | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Petr Sklenar <psklenar> |
| Component: | bind | Assignee: | Tomáš Hozza <thozza> |
| Status: | CLOSED NOTABUG | QA Contact: | qe-baseos-daemons |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 6.8 | CC: | dwalsh, lvrabec, mgrepl, mmalik, plautrba, psklenar, pvrabec, ssekidde |
| Target Milestone: | rc | Keywords: | EasyFix, SELinux |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-08-16 11:00:59 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: | |
At least one of the random devices is mislabeled: # restorecon -v /dev/random /var/named/chroot/dev/random How is it labeled now? BIND should fix labeling. [0 root@qeos-37 dev]# ls -lZ crw-r--r--. root root unconfined_u:object_r:null_device_t:s0 null crw-r--r--. root root unconfined_u:object_r:random_device_t:s0 random crw-r--r--. root root unconfined_u:object_r:zero_device_t:s0 zero [0 root@qeos-37 dev]# restorecon -v /dev/random /var/named/chroot/dev/random [0 root@qeos-37 dev]# ls -lZ /dev/random crw-rw-rw-. root root system_u:object_r:random_device_t:s0 /dev/random I checked bind package and it restores the context on all the /dev/* files inside the /var/named/chroot/.
%posttrans chroot
if [ -x /usr/sbin/selinuxenabled ] && /usr/sbin/selinuxenabled; then
[ -x /sbin/restorecon ] && /sbin/restorecon %{chroot_prefix}/dev/* > /dev/null 2>&1 \
&& /sbin/restorecon %{chroot_prefix}/etc/localtime > /dev/null 2>&1;
fi;
It seems that restorecon is not able to reset the context without using -F (force). Miroslav, do you know what may be the issue?
I checked and the same issue is also in Fedora and RHEL-7.
This is the output from RHEL-7:
[0 root@qeos-38 test]# ls -lZ /var/named/chroot/dev/{zero,null,random}
crw-r--r--. root root unconfined_u:object_r:null_device_t:s0 /var/named/chroot/dev/null
crw-r--r--. root root unconfined_u:object_r:random_device_t:s0 /var/named/chroot/dev/random
crw-r--r--. root root unconfined_u:object_r:zero_device_t:s0 /var/named/chroot/dev/zero
[0 root@qeos-38 test]# matchpathcon /var/named/chroot/dev/{zero,null,random}
/var/named/chroot/dev/zero system_u:object_r:zero_device_t:s0
/var/named/chroot/dev/null system_u:object_r:null_device_t:s0
/var/named/chroot/dev/random system_u:object_r:random_device_t:s0
[0 root@qeos-38 test]# restorecon -v /var/named/chroot/dev/{zero,null,random}
[0 root@qeos-38 test]# restorecon -vF /var/named/chroot/dev/{zero,null,random}
restorecon reset /var/named/chroot/dev/zero context unconfined_u:object_r:zero_device_t:s0->system_u:object_r:zero_device_t:s0
restorecon reset /var/named/chroot/dev/null context unconfined_u:object_r:null_device_t:s0->system_u:object_r:null_device_t:s0
restorecon reset /var/named/chroot/dev/random context unconfined_u:object_r:random_device_t:s0->system_u:object_r:random_device_t:s0
[0 root@qeos-38 test]# ls -lZ /var/named/chroot/dev/{zero,null,random}
crw-r--r--. root root system_u:object_r:null_device_t:s0 /var/named/chroot/dev/null
crw-r--r--. root root system_u:object_r:random_device_t:s0 /var/named/chroot/dev/random
crw-r--r--. root root system_u:object_r:zero_device_t:s0 /var/named/chroot/dev/zero
Well it looks there is a correct labeling. crw-r--r--. root root unconfined_u:object_r:null_device_t:s0 /var/named/chroot/dev/null crw-r--r--. root root unconfined_u:object_r:random_device_t:s0 /var/named/chroot We care about null_device_t and random_device_t here. Petr, have you had disabled SELinux? it seems it was some wrong usage during testing, now I can see no such an issue + automation does not report any avc denial |
Description of problem: there is avc on /var/named/chroot/dev/random Version-Release number of selected component (if applicable): selinux-policy-3.7.19-287.el6.noarch bind-9.8.2-0.46.rc1.el6.x86_64 latest rhel68 How reproducible: I could see such an avc on one machine Steps to Reproduce: 0. no idea 1. I installed bind and do some testing but I am not sure what was the cause but I could see this avc on some machine logs: [0 root@qeos-17 tmp]# cat /var/log/audit/audit.log | grep avc type=AVC msg=audit(1455617346.768:268): avc: denied { getattr } for pid=2363 comm="named-sdb" path="/dev/random" dev=vda1 ino=264344 scontext=unconfined_u:system_r:named_t:s0 tcontext=unconfined_u:object_r:device_t:s0 tclass=chr_file [0 root@qeos-17 tmp]# find / -mount -inum 264344 /var/named/chroot/dev/random find: File system loop detected; `/var/named/chroot/var/named' is part of the same file system loop as `/var/named'. [0 root@qeos-17 tmp]# ls -laZ /var/named/chroot/dev/random crw-r--r--. root root unconfined_u:object_r:random_device_t:s0 /var/named/chroot/dev/ran Actual results: type=AVC msg=audit(1455617346.768:268): avc: denied { getattr } for pid=2363 comm="named-sdb" path="/dev/random" dev=vda1 ino=264344 scontext=unconfined_u:system_r:named_t:s0 tcontext=unconfined_u:object_r:device_t:s0 tclass=chr_f Expected results: no avc Additional info: