Bug 1966842
Summary: | SELinux is preventing virtlogd from 'read, append' accesses on the file system.token | |||
---|---|---|---|---|
Product: | Red Hat Enterprise Linux 8 | Reporter: | Fangge Jin <fjin> | |
Component: | selinux-policy | Assignee: | Zdenek Pytela <zpytela> | |
Status: | CLOSED ERRATA | QA Contact: | Milos Malik <mmalik> | |
Severity: | urgent | Docs Contact: | ||
Priority: | high | |||
Version: | 8.5 | CC: | berrange, dwalsh, dzheng, extras-qa, grepl.miroslav, hhan, jen, jsuchane, klaas, lcheng, lizhu, lmen, lvrabec, meili, mmalik, mprivozn, mxie, nknazeko, nsoffer, omosnace, peljasz, pezhang, plautrba, rjones, sbonazzo, smitterl, ssekidde, tstaudt, virt-maint, vmojzis, weizhan, xinma, yafu, yanqzhan, yidliu, yoguo, zpytela | |
Target Milestone: | beta | Keywords: | Automation, Regression, TestBlocker, Triaged | |
Target Release: | 8.5 | |||
Hardware: | Unspecified | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | selinux-policy-3.14.3-71.el8 | Doc Type: | No Doc Update | |
Doc Text: | Story Points: | --- | ||
Clone Of: | 1964317 | |||
: | 1969209 (view as bug list) | Environment: | ||
Last Closed: | 2021-11-09 19:43:05 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: | ||||
Bug Depends On: | 1964317 | |||
Bug Blocks: | 1969209 |
Description
Fangge Jin
2021-06-02 02:33:31 UTC
type=AVC msg=audit(1622599792.544:1738): avc: denied { read append } for pid=16525 comm="virtlogd" name="system.token" dev="tmpfs" ino=129891 scontext=system_u:system_r:virtlogd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:virt_var_run_t:s0 tclass=file permissive=0 Additional info: 1. Can't be reproduced with libvirt-7.3.0 2. I have confirmed that libvirtd and virtlogd are running 3. After the first failure, try to start vm again, it failed as first time, but there is NO new avc denied info produced in audit.log 4. Restart virtlogd, then try to start vm again, it failed as before, and there is new avc denied info produced in audit.log 5. "setenforce 0" won't work around this issue One workaround is: set stdio_handler = "file" in /etc/libvirt/qemu.conf, and restart libvirtd @fjin should this be filed against selinux-policy instead of libvirt (just like the fedora bug)? Another workaround: Start libvirtd and virtlogd by shell command: 1) # systemctl stop libvirtd; systesmctl stop virtlogd; systemctl stop libvirtd.socket; systemctl stop virtlogd.socket 2) # libvirtd -d; virtlogd -d (In reply to Fangge Jin from comment #2) > Additional info: > 1. Can't be reproduced with libvirt-7.3.0 > > 2. I have confirmed that libvirtd and virtlogd are running > > 3. After the first failure, try to start vm again, it failed as first time, > but there is NO new avc denied info produced in audit.log > > 4. Restart virtlogd, then try to start vm again, it failed as before, and > there is new avc denied info produced in audit.log > > 5. "setenforce 0" won't work around this issue 'setenforce 0' should work, but the error message is cached by libvirtd as it is hit in a one-time initializer. So after making selinux permissive, you need to also restart libvirtd I believe. There's no need to restart virtlogd. Hi Daniel I just tried, it seems that restart virtlogd after 'setenforce 0' can work around the issue. 1. Start a vm, it failed [root@fjin-8-5-1 ~]# virsh start avocado-vt-vm1 error: Failed to start domain 'avocado-vt-vm1' error: can't connect to virtlogd: Unable to open system token /run/libvirt/common/system.token: Permission denied 2. Set enforce to 0, restart libvirtd, then try to start vm, still failed [root@fjin-8-5-1 ~]# setenforce 0 [root@fjin-8-5-1 ~]# systemctl restart libvirtd [root@fjin-8-5-1 ~]# virsh start avocado-vt-vm1 error: Failed to start domain 'avocado-vt-vm1' error: can't connect to virtlogd: Unable to open system token /run/libvirt/common/system.token: Permission denied 3. Restart virtlogd, then try to start vm, can succeed [root@fjin-8-5-1 ~]# systemctl restart virtlogd [root@fjin-8-5-1 ~]# virsh start avocado-vt-vm1 Domain 'avocado-vt-vm1' started [root@fjin-8-5-1 ~]# virsh destroy avocado-vt-vm1 Domain 'avocado-vt-vm1' destroyed 4. Now, set enforce to 1, try to start vm, can succeed [root@fjin-8-5-1 ~]# setenforce 1 [root@fjin-8-5-1 ~]# virsh start avocado-vt-vm1 Domain 'avocado-vt-vm1' started [root@fjin-8-5-1 ~]# virsh destroy !$ virsh destroy avocado-vt-vm1 5. Then restart virtlogd, and try to start vm, it failed. [root@fjin-8-5-1 ~]# systemctl restart virtlogd [root@fjin-8-5-1 ~]# virsh start avocado-vt-vm1 error: Failed to start domain 'avocado-vt-vm1' error: can't connect to virtlogd: Unable to open system token /run/libvirt/common/system.token: Permission denied Hi Fangge, do you have any other AVC messages after reproducing this with setenforce 0? (In reply to nknazeko from comment #10) > Hi Fangge, do you have any other AVC messages after reproducing this with > setenforce 0? There is no new AVC denied info after setenfore 0. And if restart virtlogd after setenforce 0, it can't be reproduced. Could you run the following commands on a machine where the problems appears? # ls -lZ /run/libvirt/common/system.token # matchpathcon /run/libvirt/common/system.token Thank you. [root@fjin-8-5-1 ~]# ll /run/libvirt/common/system.token -Z -rw-------. 1 root root system_u:object_r:virt_var_run_t:s0 32 Jun 2 02:08 /run/libvirt/common/system.token [root@fjin-8-5-1 ~]# matchpathcon /run/libvirt/common/system.token /run/libvirt/common/system.token system_u:object_r:virt_var_run_t:s0 This breaks oVirt users using Cantos Stream. Hello, There is a selinux-policy PR available, I verified the token file is created with expected label, but I cannot verify the fix is complete and sufficient to back the libvirt feature. Should there be somebody able to test it out, please either use the PR builds for Fedora 34 and 35: https://github.com/fedora-selinux/selinux-policy/pull/777 Show all checks -> build-rpm -> Details -> Artifacts -> rpms or apply the following steps on any system: 1. Install devel package dnf install setools-console selinux-policy-devel -y 2. Create a local selinux policy module # cat local_virt.fc /var/run/libvirt/common(/.*)? gen_context(system_u:object_r:virt_common_var_run_t,s0) # cat local_virt.te policy_module(local_virt, 1.0) gen_require(` type virt_var_run_t; type virtd_t; type virtlogd_t; ') type virt_common_var_run_t; files_pid_file(virt_common_var_run_t) allow virtd_t virt_common_var_run_t:file { append_file_perms read_file_perms }; manage_dirs_pattern(virtd_t, virt_common_var_run_t, virt_common_var_run_t) manage_files_pattern(virtd_t, virt_common_var_run_t, virt_common_var_run_t) filetrans_pattern(virtd_t, virt_var_run_t, virt_common_var_run_t, dir, "common") allow virtlogd_t virt_common_var_run_t:file { append_file_perms read_file_perms }; manage_files_pattern(virtlogd_t, virt_common_var_run_t, virt_common_var_run_t) # make -f /usr/share/selinux/devel/Makefile local_virt.pp # semodule -i local_virt.pp 3. Reproduce the scenario 4. Look for avc denials ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts recent (In reply to Zdenek Pytela from comment #20) > Hello, > > There is a selinux-policy PR available, I verified the token file is created > with expected label, but I cannot verify the fix is complete and sufficient > to back the libvirt feature. Should there be somebody able to test it out, > please either use the PR builds for Fedora 34 and 35: > https://github.com/fedora-selinux/selinux-policy/pull/777 > Show all checks -> build-rpm -> Details -> Artifacts -> rpms I tested libvirt on a Fedora 34 host with this build of the policy and it solved the problems I first hit. (In reply to Daniel Berrangé from comment #21) > I tested libvirt on a Fedora 34 host with this build of the policy and it > solved the problems I first hit. Thank you, merging the PR to move it to further testing then. What's more, an dependency of bug-fixed selinux-policy should be added for the libvirt>=7.4(the version with /run/libvirt/common). Otherwise, when the user update libvirt only to the latest. They will encounter the bug, either. The bug is even there unless they update selinux-policy and then cleanup /run/libvirt/common and restart libvirtd+virtlogd: https://bugzilla.redhat.com/show_bug.cgi?id=1964317#c16 What's your idea? (In reply to Han Han from comment #24) > What's more, an dependency of bug-fixed selinux-policy should be added for > the libvirt>=7.4(the version with /run/libvirt/common). > > Otherwise, when the user update libvirt only to the latest. They will > encounter the bug, either. The bug is even there unless they update > selinux-policy and then cleanup /run/libvirt/common and restart > libvirtd+virtlogd: https://bugzilla.redhat.com/show_bug.cgi?id=1964317#c16 A part of selinux-policy rpm scriptlets is relabeling of files were the label changed, but it does not apply to filesystems like /run. So if the update order is 1. selinux-policy 2. libvirtd, the service restart with cleanup would help. In the inverse order the labels are kept in the previous state until libvirtd restart, but I suppose this part was not working anyway before. (In reply to Zdenek Pytela from comment #25) > (In reply to Han Han from comment #24) > > What's more, an dependency of bug-fixed selinux-policy should be added for > > the libvirt>=7.4(the version with /run/libvirt/common). > > > > Otherwise, when the user update libvirt only to the latest. They will > > encounter the bug, either. The bug is even there unless they update > > selinux-policy and then cleanup /run/libvirt/common and restart > > libvirtd+virtlogd: https://bugzilla.redhat.com/show_bug.cgi?id=1964317#c16 > A part of selinux-policy rpm scriptlets is relabeling of files were the > label changed, but it does not apply to filesystems like /run. > > So if the update order is 1. selinux-policy 2. libvirtd, the service restart > with cleanup would help. > In the inverse order the labels are kept in the previous state until > libvirtd restart, but I suppose this part was not working anyway before. Yes. From the customer perspective, a user may update 2 first and 1 then. We should make sure there is always the 1->2 order. Hi team, The selinux-policy-3.14.3-71.el8 build is now available with support for the /run/libvirt/common/system.token feature. Please remove the local policy and use this package to test if everything works as expected. Any idea on the comment24 to coment26? Do we need to file a bug against libvirt? *** Bug 1969861 has been marked as a duplicate of this bug. *** (In reply to Han Han from comment #32) > Any idea on the comment24 to coment26? Do we need to file a bug against > libvirt? I assume selinux-policy and libvirt will be updated together when customer upgrade from RHEL8.4 to RHEL8.5, but I'm not so sure about this. And considering if customer deploy libvirtd and virtlogd by shell command "libvirtd -d; virtlogd -d", the issue in this bug won't happen. Is it suitable to add dependency on selinux-policy in this condition? (In reply to Fangge Jin from comment #34) > (In reply to Han Han from comment #32) > > Any idea on the comment24 to coment26? Do we need to file a bug against > > libvirt? > > I assume selinux-policy and libvirt will be updated together when customer > upgrade from RHEL8.4 to RHEL8.5, but I'm not so sure about this. From the former z-stream bug https://bugzilla.redhat.com/show_bug.cgi?id=1679569 , this assumption is not correct. > > And considering if customer deploy libvirtd and virtlogd by shell command > "libvirtd -d; virtlogd -d", the issue in this bug won't happen. Is it > suitable to add dependency on selinux-policy in this condition? New a libvirt bug on the dependency: https://bugzilla.redhat.com/show_bug.cgi?id=1973510 *** Bug 1983957 has been marked as a duplicate of this bug. *** 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 (selinux-policy bug fix and enhancement update), 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-2021:4420 |