RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1383450 - 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
Summary: sebooleans get reset on image based systems / RHVH status is Non Responsive i...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy
Version: 7.3
Hardware: All
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Lukas Vrabec
QA Contact: Milos Malik
Mirek Jahoda
URL:
Whiteboard:
Depends On: 1381588
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-10-10 16:15 UTC by Marcel Kolaja
Modified: 2017-03-30 10:28 UTC (History)
33 users (show)

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.
Clone Of: 1381588
Environment:
Last Closed: 2016-11-04 09:03:03 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2611 0 normal SHIPPED_LIVE selinux-policy bug fix update 2016-11-03 16:24:17 UTC
oVirt gerrit 65066 0 None None None 2016-10-10 16:16:10 UTC

Description Marcel Kolaja 2016-10-10 16:15:49 UTC 
This bug has been copied from bug #1381588 and has been proposed
to be backported to 7.3 z-stream (EUS).
Comment 10 errata-xmlrpc 2016-11-04 09:03:03 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
Comment 11 Yaniv Kaul 2017-03-13 11:41:58 UTC 
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 };
Comment 12 Milos Malik 2017-03-13 11:46:30 UTC 
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
Comment 13 Yaniv Kaul 2017-03-13 12:13:01 UTC 
(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.
Comment 14 Milos Malik 2017-03-15 07:45:15 UTC 
Where are the unlabeled_t files located?

# find / -type f -context \*unlabeled_t\*
Comment 15 Yaniv Kaul 2017-03-15 09:05:31 UTC 
(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
Comment 16 Milos Malik 2017-03-15 09:18:18 UTC 
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
Comment 17 Yaniv Kaul 2017-03-15 09:41:09 UTC 
(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>>
Comment 18 Milos Malik 2017-03-15 10:48:51 UTC 
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
Comment 19 Yaniv Kaul 2017-03-15 10:58:09 UTC 
(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 ?
Comment 20 Nir Soffer 2017-03-15 12:06:42 UTC 
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?
Comment 21 Milos Malik 2017-03-30 10:28:52 UTC 
I always run restorecon when I find unlabeled_t object on a file-system. Such labels should not happen.
Note You need to log in before you can comment on or make changes to this bug.