Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
When /etc/libvirt is moved to another location (ie: /mnt/volume/etc/libvirt) and a symlink to the new destination is placed on /etc (ie: ln -s /mnt/volume/etc/libvirt /etc/) SELinux denies access by "virtlogd" to /etc/libvirt, preventing libvirt from running correctly.
This is true even if symlink is labeled with the correct, original virt_etc_t context. On the other hand, if symlink is marked with the more generic etc_t, "virtlogd" (and libvirtd) correctly works; it even survive restorecon.
Problem is, every libvirt-daemon updates will reset the context of the symlink to virt_etc_t, causing a failure to start libvirtd.
When "virtlogd" is blocked, the following entries are logged on /var/log/audit/audit.log:
type=SERVICE_START msg=audit(1530832860.093:278): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=virtlogd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
type=AVC msg=audit(1530832860.127:279): avc: denied { read } for pid=3965 comm="virtlogd" name="libvirt" dev="dm-0" ino=5060861 scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_etc_t:s0 tclass=lnk_file
type=SYSCALL msg=audit(1530832860.127:279): arch=c000003e syscall=21 success=no exit=-13 a0=55fdf118ec90 a1=4 a2=1 a3=3 items=0 ppid=1 pid=3965 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="virtlogd" exe="/usr/sbin/virtlogd" subj=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 key=(null)
type=PROCTITLE msg=audit(1530832860.127:279): proctitle="/usr/sbin/virtlogd"
type=AVC msg=audit(1530832860.129:280): avc: denied { read } for pid=3965 comm="virtlogd" name="libvirt" dev="dm-0" ino=5060861 scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_etc_t:s0 tclass=lnk_file
type=SYSCALL msg=audit(1530832860.129:280): arch=c000003e syscall=2 success=no exit=-13 a0=55fdf118ec90 a1=0 a2=7ffffb6d7b30 a3=1 items=0 ppid=1 pid=3965 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="virtlogd" exe="/usr/sbin/virtlogd" subj=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 key=(null)
type=PROCTITLE msg=audit(1530832860.129:280): proctitle="/usr/sbin/virtlogd"
type=SERVICE_STOP msg=audit(1530832860.145:281): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=virtlogd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'
audit2allow shows the following:
#============= virtlogd_t ==============
allow virtlogd_t virt_etc_t:lnk_file read;
Version-Release number of selected component (if applicable):
libvirt-daemon-3.9.0-14.el7_5.6.x86_64
How reproducible:
Move /etc/libvirt to another location and leave a symlink in the original location, assigning it context virt_etc_t. Then restart virtlogd while watching /var/log/audit/audit.log
Steps to Reproduce:
1. move /etc/libvirt to another location
2. ln -s <newloc> /etc/libvirtd
3. chcon -h -t virt_etc_v /etc/libvirt (or: yum reinstall libvirtd)
4. restart virtlogd
5. see the errors in audit.log
Actual results:
Virtual machine configuration is not completely loaded (ie: autostarting VMs does not work).
Expected results:
If virtlogd can read symlinks of etc_t, it should read virt_etc_t also. Please also note that virtlogd is permitted to read the real directory /etc/libvirt with virt_etc_t context.
Additional info:
OS RHEL7 x86-64
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://access.redhat.com/errata/RHBA-2018:3111
Description of problem: When /etc/libvirt is moved to another location (ie: /mnt/volume/etc/libvirt) and a symlink to the new destination is placed on /etc (ie: ln -s /mnt/volume/etc/libvirt /etc/) SELinux denies access by "virtlogd" to /etc/libvirt, preventing libvirt from running correctly. This is true even if symlink is labeled with the correct, original virt_etc_t context. On the other hand, if symlink is marked with the more generic etc_t, "virtlogd" (and libvirtd) correctly works; it even survive restorecon. Problem is, every libvirt-daemon updates will reset the context of the symlink to virt_etc_t, causing a failure to start libvirtd. When "virtlogd" is blocked, the following entries are logged on /var/log/audit/audit.log: type=SERVICE_START msg=audit(1530832860.093:278): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=virtlogd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success' type=AVC msg=audit(1530832860.127:279): avc: denied { read } for pid=3965 comm="virtlogd" name="libvirt" dev="dm-0" ino=5060861 scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_etc_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1530832860.127:279): arch=c000003e syscall=21 success=no exit=-13 a0=55fdf118ec90 a1=4 a2=1 a3=3 items=0 ppid=1 pid=3965 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="virtlogd" exe="/usr/sbin/virtlogd" subj=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 key=(null) type=PROCTITLE msg=audit(1530832860.127:279): proctitle="/usr/sbin/virtlogd" type=AVC msg=audit(1530832860.129:280): avc: denied { read } for pid=3965 comm="virtlogd" name="libvirt" dev="dm-0" ino=5060861 scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_etc_t:s0 tclass=lnk_file type=SYSCALL msg=audit(1530832860.129:280): arch=c000003e syscall=2 success=no exit=-13 a0=55fdf118ec90 a1=0 a2=7ffffb6d7b30 a3=1 items=0 ppid=1 pid=3965 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="virtlogd" exe="/usr/sbin/virtlogd" subj=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 key=(null) type=PROCTITLE msg=audit(1530832860.129:280): proctitle="/usr/sbin/virtlogd" type=SERVICE_STOP msg=audit(1530832860.145:281): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0 msg='unit=virtlogd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed' audit2allow shows the following: #============= virtlogd_t ============== allow virtlogd_t virt_etc_t:lnk_file read; Version-Release number of selected component (if applicable): libvirt-daemon-3.9.0-14.el7_5.6.x86_64 How reproducible: Move /etc/libvirt to another location and leave a symlink in the original location, assigning it context virt_etc_t. Then restart virtlogd while watching /var/log/audit/audit.log Steps to Reproduce: 1. move /etc/libvirt to another location 2. ln -s <newloc> /etc/libvirtd 3. chcon -h -t virt_etc_v /etc/libvirt (or: yum reinstall libvirtd) 4. restart virtlogd 5. see the errors in audit.log Actual results: Virtual machine configuration is not completely loaded (ie: autostarting VMs does not work). Expected results: If virtlogd can read symlinks of etc_t, it should read virt_etc_t also. Please also note that virtlogd is permitted to read the real directory /etc/libvirt with virt_etc_t context. Additional info: OS RHEL7 x86-64