Bug 1383450
| Summary: | sebooleans get reset on image based systems / RHVH status is Non Responsive in RHVM side after upgrade from RHVH 4.0_7.2 to 4.0_7.3 | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Marcel Kolaja <mkolaja> |
| Component: | selinux-policy | Assignee: | Lukas Vrabec <lvrabec> |
| Status: | CLOSED ERRATA | QA Contact: | Milos Malik <mmalik> |
| Severity: | urgent | Docs Contact: | Mirek Jahoda <mjahoda> |
| Priority: | urgent | ||
| Version: | 7.3 | CC: | bugs, cshao, dguo, dougsland, fdeutsch, gklein, huzhao, jiawu, jneedle, leiwang, lmiksik, lvrabec, mgoldboi, mgrepl, miabbott, mjahoda, mkolaja, mmalik, msivak, nsoffer, plautrba, pvrabec, rbarry, sherold, snagar, ssekidde, weiwang, yaniwang, ybronhei, ycui, ykaul, yruseva, yzhao |
| Target Milestone: | rc | Keywords: | TestBlocker, ZStream |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | selinux-policy-3.13.1-102.el7_3.3 | Doc Type: | Bug Fix |
| Doc Text: |
In Red Hat Enterprise Linux 7.3, the SELinux user space uses the different location for some files, compared to the previous versions of Red Hat Enterprise Linux 7. Consequently, Red Hat Virtualization Host (RHVH) or Red Hat Atomic Host (RHAH) had non-responsive status, in some cases. The migrate script to perform the change from the old modules store structure to the new one is now provided.
|
Story Points: | --- |
| Clone Of: | 1381588 | Environment: | |
| Last Closed: | 2016-11-04 09:03:03 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: | |||
| Bug Depends On: | 1381588 | ||
| Bug Blocks: | |||
|
Description
Marcel Kolaja
2016-10-10 16:15:49 UTC
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. https://rhn.redhat.com/errata/RHBA-2016-2611.html I'm seeing this on CentOS (testing oVirt) even with newer selinux-policy packages (selinux-policy-targeted-3.13.1-102.el7_3.15.noarch.rpm) - when trying to use NFSv4.2, sanlock fails:
[root@lago-basic-suite-master-host0 ~]# semanage boolean -C -l
SELinux boolean State Default Description
virt_use_fusefs (on , on) Allow virt to use fusefs
sanlock_use_nfs (on , on) Allow sanlock to use nfs
sanlock_use_samba (on , on) Allow sanlock to use samba
virt_use_sanlock (on , on) Allow virt to use sanlock
virt_use_samba (on , on) Allow virt to use samba
sanlock_use_fusefs (on , on) Allow sanlock to use fusefs
virt_use_nfs (on , on) Allow virt to use nfs
^C[root@lago-basic-suite-master-host0 ~]# audit2allow -a
#============= kdump_t ==============
#!!!! WARNING: 'unlabeled_t' is a base type.
allow kdump_t unlabeled_t:file read;
#============= sanlock_t ==============
#!!!! WARNING: 'unlabeled_t' is a base type.
allow sanlock_t unlabeled_t:file { open read write };
There should be no files with an unlabeled_t context. It seems that some files are mislabeled on your machine. Could you attach the output of following command? # ausearch -m avc -i -ts today (In reply to Milos Malik from comment #12) > There should be no files with an unlabeled_t context. It seems that some > files are mislabeled on your machine. Could you attach the output of > following command? > > # ausearch -m avc -i -ts today [root@lago-basic-suite-master-host1 ~]# ausearch -m avc -i -ts today ---- type=SYSCALL msg=audit(03/13/2017 07:55:38.523:195) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x7ffefd216f5f a1=O_RDONLY a2=0x1b6 a3=0x7ffefd215610 items=0 ppid=1182 pid=10397 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=kexec exe=/usr/sbin/kexec subj=system_u:system_r:kdump_t:s0 key=(null) type=AVC msg=audit(03/13/2017 07:55:38.523:195) : avc: denied { read } for pid=10397 comm=kexec name=vmlinuz-3.10.0-514.10.2.el7.x86_64 dev="vda1" ino=167977 scontext=system_u:system_r:kdump_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file ---- type=SYSCALL msg=audit(03/13/2017 07:55:38.523:196) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x7ffefd216f5f a1=O_RDONLY a2=0x1b6 a3=0x24 items=0 ppid=1182 pid=10397 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=kexec exe=/usr/sbin/kexec subj=system_u:system_r:kdump_t:s0 key=(null) type=AVC msg=audit(03/13/2017 07:55:38.523:196) : avc: denied { read } for pid=10397 comm=kexec name=vmlinuz-3.10.0-514.10.2.el7.x86_64 dev="vda1" ino=167977 scontext=system_u:system_r:kdump_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file ---- type=SYSCALL msg=audit(03/13/2017 08:04:08.269:1597) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x7ff87c0009c8 a1=O_RDWR|O_DSYNC|O_DIRECT|__O_SYNC a2=0x0 a3=0x0 items=0 ppid=1 pid=15365 auid=unset uid=sanlock gid=sanlock euid=sanlock suid=sanlock fsuid=sanlock egid=sanlock sgid=sanlock fsgid=sanlock tty=(none) ses=unset comm=sanlock exe=/usr/sbin/sanlock subj=system_u:system_r:sanlock_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(03/13/2017 08:04:08.269:1597) : avc: denied { read write open } for pid=15365 comm=sanlock path=/rhev/data-center/mnt/192.168.201.3:_exports_nfs_share1/2cb7b5dc-d09e-424b-b66a-a7a65ba6c9b2/dom_md/ids dev="0:40" ino=67108931 scontext=system_u:system_r:sanlock_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file ---- type=SYSCALL msg=audit(03/13/2017 08:06:10.310:2170) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x7fc2a477234e a1=O_RDONLY a2=0x0 a3=0x3 items=0 ppid=1179 pid=29272 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=10 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(03/13/2017 08:06:10.310:2170) : avc: denied { read } for pid=29272 comm=sshd name=lastlog dev="dm-0" ino=9120378 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_log_t:s0 tclass=file ---- type=SYSCALL msg=audit(03/13/2017 08:06:10.551:2179) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x7f159db4a34e a1=O_RDONLY a2=0x0 a3=0x3 items=0 ppid=1179 pid=29275 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=11 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(03/13/2017 08:06:10.551:2179) : avc: denied { read } for pid=29275 comm=sshd name=lastlog dev="dm-0" ino=9120378 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_log_t:s0 tclass=file ---- type=SYSCALL msg=audit(03/13/2017 08:06:13.676:2230) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x7fb299eea34e a1=O_RDONLY a2=0x0 a3=0x3 items=0 ppid=1179 pid=29291 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=12 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(03/13/2017 08:06:13.676:2230) : avc: denied { read } for pid=29291 comm=sshd name=lastlog dev="dm-0" ino=9120378 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_log_t:s0 tclass=file ---- type=SYSCALL msg=audit(03/13/2017 08:06:13.865:2239) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x7f358984834e a1=O_RDONLY a2=0x0 a3=0x3 items=0 ppid=1179 pid=29308 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=13 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(03/13/2017 08:06:13.865:2239) : avc: denied { read } for pid=29308 comm=sshd name=lastlog dev="dm-0" ino=9120378 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_log_t:s0 tclass=file ---- type=SYSCALL msg=audit(03/13/2017 08:07:46.406:2358) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x7f1537a0234e a1=O_RDONLY a2=0x0 a3=0x3 items=0 ppid=1179 pid=29572 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=14 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(03/13/2017 08:07:46.406:2358) : avc: denied { read } for pid=29572 comm=sshd name=lastlog dev="dm-0" ino=9120378 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_log_t:s0 tclass=file ---- type=SYSCALL msg=audit(03/13/2017 08:07:46.736:2387) : arch=x86_64 syscall=open success=no exit=EACCES(Permission denied) a0=0x7f9c59cee34e a1=O_RDONLY a2=0x0 a3=0x3 items=0 ppid=1179 pid=29580 auid=root uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=15 comm=sshd exe=/usr/sbin/sshd subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(03/13/2017 08:07:46.736:2387) : avc: denied { read } for pid=29580 comm=sshd name=lastlog dev="dm-0" ino=9120378 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_log_t:s0 tclass=file A bit about this 'host' - it's a nested-virt host, that as part of its provisioning (via virt-sysprep) either does or does not (tried both) get fully updated, but also run selinux-relabeling - which I can see taking place: [ 284.0] Setting passwords [ 285.6] SELinux relabelling [ 298.9] Performing "lvm-uuids" .. So it's happening offline even. Where are the unlabeled_t files located? # find / -type f -context \*unlabeled_t\* (In reply to Milos Malik from comment #14) > Where are the unlabeled_t files located? > > # find / -type f -context \*unlabeled_t\* [root@lago-basic-suite-master-host0 ~]# find / -type f -context \*unlabeled_t\* /boot/.vmlinuz-3.10.0-514.2.2.el7.x86_64.hmac /boot/System.map-3.10.0-514.2.2.el7.x86_64 /boot/config-3.10.0-514.2.2.el7.x86_64 /boot/symvers-3.10.0-514.2.2.el7.x86_64.gz /boot/vmlinuz-3.10.0-514.2.2.el7.x86_64 /boot/initramfs-3.10.0-514.2.2.el7.x86_64.img /boot/initramfs-0-rescue-6659efcb4905440bbd62df38e20d963e.img /boot/vmlinuz-0-rescue-6659efcb4905440bbd62df38e20d963e /tmp/builder.log /rhev/data-center/mnt/192.168.201.3:_exports_nfs_share1/__DIRECT_IO_TEST__ /rhev/data-center/mnt/192.168.201.3:_exports_nfs_share1/3ec0bfc8-2c74-473e-94a1-532cd26d04b4/dom_md/xleases /rhev/data-center/mnt/192.168.201.3:_exports_nfs_share1/3ec0bfc8-2c74-473e-94a1-532cd26d04b4/dom_md/ids /rhev/data-center/mnt/192.168.201.3:_exports_nfs_share1/3ec0bfc8-2c74-473e-94a1-532cd26d04b4/dom_md/inbox /rhev/data-center/mnt/192.168.201.3:_exports_nfs_share1/3ec0bfc8-2c74-473e-94a1-532cd26d04b4/dom_md/outbox /rhev/data-center/mnt/192.168.201.3:_exports_nfs_share1/3ec0bfc8-2c74-473e-94a1-532cd26d04b4/dom_md/leases /rhev/data-center/mnt/192.168.201.3:_exports_nfs_share1/3ec0bfc8-2c74-473e-94a1-532cd26d04b4/dom_md/metadata Following command will repair SELinux contexts on all files under /boot: # restorecon -Rv /boot Before we repair contexts on /rhev/data-center/mnt/ files using the same command, I would like to know if there are any SELinux fcontext equivalences set: # matchpathcon /rhev/data-center/mnt (In reply to Milos Malik from comment #16) > Following command will repair SELinux contexts on all files under /boot: > > # restorecon -Rv /boot Thanks - I wonder why I need to run it. > > Before we repair contexts on /rhev/data-center/mnt/ files using the same > command, I would like to know if there are any SELinux fcontext equivalences > set: > > # matchpathcon /rhev/data-center/mnt [root@lago-basic-suite-master-host0 ~]# matchpathcon /rhev/data-center/mnt /rhev/data-center/mnt <<none>> Following command sets up the same label for all file-system objects under /rhev/data-center/mnt. Similar change is being introduced to RHEL-7.4 now: # semanage fcontext -a -t mnt_t '/rhev/data-center/mnt(/.*)?' Following command shows which files/directories will be relabeled, but won't do the relabeling: # restorecon -Rvn /rhev/data-center/mnt Following command will do the relabeling: # restorecon -Rv /rhev/data-center/mnt (In reply to Milos Malik from comment #18) > Following command sets up the same label for all file-system objects under > /rhev/data-center/mnt. Similar change is being introduced to RHEL-7.4 now: > # semanage fcontext -a -t mnt_t '/rhev/data-center/mnt(/.*)?' > > Following command shows which files/directories will be relabeled, but won't > do the relabeling: > # restorecon -Rvn /rhev/data-center/mnt > > Following command will do the relabeling: > # restorecon -Rv /rhev/data-center/mnt Nir - is this something we need to perform when creating /rhev/data-center ? Milo, do we need to run restorecon when creating /rhev/data-center, or we should get the correct selinux label since selinux policy has a builtin rule or this path? I always run restorecon when I find unlabeled_t object on a file-system. Such labels should not happen. |