Bug 1308897
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: | |
Embargoed: |
Description
Petr Sklenar
2016-02-16 11:58:13 UTC
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 |