Bug 2262587
| Summary: | Error when starting a domain: Unable to open system token /run/libvirt/common/system.token: Permission denied | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Han Han <hhan> |
| Component: | selinux-policy | Assignee: | Zdenek Pytela <zpytela> |
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | rawhide | CC: | berrange, dowdle, dwalsh, georgmueller, lvrabec, mail, mmalik, motoskov, nknazeko, omosnacek, pkoncity, tripledes, vmojzis, zpytela |
| Target Milestone: | --- | Keywords: | Regression |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2024-04-26 10:40:28 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: | |||
|
Description
Han Han
2024-02-04 03:50:39 UTC
Hi. I also have this bug after upgrading from Fedora 39 to Fedora 40: Unable to open system token /run/libvirt/common/system.token: Permission denied It might be related to https://access.redhat.com/errata/RHBA-2021:4420 , because errata is showing the same error message, but for RHEL8. My journal logs: Feb 18 12:48:15 mckenna.ping.local setroubleshoot[1714]: SELinux is preventing daemon-init from relabelfrom access on the directory 5-maria1.ping.local. For complete SELinux messages run: sealert -l 9d377782-1046-46c4-8e87-fb8ba348d053 Feb 18 12:48:15 mckenna.ping.local setroubleshoot[1714]: SELinux is preventing daemon-init from relabelfrom access on the directory 5-maria1.ping.local. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that daemon-init should be allowed relabelfrom access on the 5-maria1.ping.local directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'daemon-init' --raw | audit2allow -M my-daemoninit # semodule -X 300 -i my-daemoninit.pp Sedismod of this policy: # sedismod my-daemoninit.mod Reading policy... libsepol.policydb_index_others: security: 0 users, 1 roles, 4 types, 0 bools libsepol.policydb_index_others: security: 0 sens, 0 cats libsepol.policydb_index_others: security: 3 classes, 0 rules, 0 cond rules libsepol.policydb_index_others: security: 0 users, 1 roles, 4 types, 0 bools libsepol.policydb_index_others: security: 0 sens, 0 cats libsepol.policydb_index_others: security: 3 classes, 0 rules, 0 cond rules Binary policy module file loaded. Module name: my-daemoninit Module version: 1.0 Policy version: 21 Select a command: 1) display unconditional AVTAB 2) display conditional AVTAB 3) display users 4) display bools 5) display roles 6) display types, attributes, and aliases 7) display role transitions 8) display role allows 9) Display policycon 0) Display initial SIDs a) Display avrule requirements b) Display avrule declarations c) Display policy capabilities l) Link in a module u) Display the unknown handling setting F) Display filename_trans rules v) display the version of policy and/or module f) set output file m) display menu q) quit Command ('m' for menu): 1 unconditional avtab: --- begin avrule block --- decl 1: allow [virtqemud_t] [device_t] : [filesystem] { unmount }; allow [virtqemud_t] [urandom_device_t] : [chr_file] { setattr }; allow [virtqemud_t] [virt_var_run_t] : [dir] { relabelfrom }; Command ('m' for menu): 2 conditional avtab: --- begin avrule block --- decl 1: Command ('m' for menu): 3 Command ('m' for menu): 4 Command ('m' for menu): 5 role: object_r types: Command ('m' for menu): 6 [device_t] [3]: type flags:0 [urandom_device_t] [1]: type flags:0 [virt_var_run_t] [2]: type flags:0 [virtqemud_t] [4]: type flags:0 Command ('m' for menu): 7 role transitions: --- begin avrule block --- decl 1: Command ('m' for menu): 8 role allows: --- begin avrule block --- decl 1: Command ('m' for menu): 9 Sorry, not implemented Command ('m' for menu): 0 Initial SIDs: Command ('m' for menu): a avrule block requirements: --- begin avrule block --- decl 1: commons: <empty> classes: dir { relabelfrom } filesystem { unmount } chr_file { setattr } roles : <empty> types : urandom_device_t virt_var_run_t device_t virtqemud_t users : <empty> bools : <empty> levels : <empty> cats : <empty> Command ('m' for menu): b avrule block declarations: --- begin avrule block --- decl 1: commons: <empty> classes: <empty> roles : <empty> types : <empty> users : <empty> bools : <empty> levels : <empty> cats : <empty> Command ('m' for menu): c policy capabilities: Command ('m' for menu): l Can only link if initial file was a base policy. Command ('m' for menu): u Deny unknown classes and perms Command ('m' for menu): F filename_trans rules: --- begin avrule block --- decl 1: filename transition Command ('m' for menu): v Binary policy module file loaded. Module name: my-daemoninit Module version: 1.0 Policy version: 21 ---------------------------------------------- "restorecon -Rv /var/lib/libvirt" did relabel files, but VM's are still not able to start: # virsh start --domain maria1.ping.local error: Failed to start domain 'maria1.ping.local' error: can't connect to virtlogd: Unable to open system token /run/libvirt/common/system.token: Permission denied ---------------------------------------------- After switching selinux to permissive mode all VM's are running fine. # virsh list --all Id Name State ----------------------------------- 1 psqlb.ping.local running 2 awx.ping.local running 3 maria1.ping.local running 4 psqla.ping.local running There are multiple denials in the journal, some of them not related. Can you 1. update to selinux-policy-40.10-1.fc40.noarch or the one from https://dashboard.packit.dev/results/copr-builds/1349099 2. Gather Avc denial, preferably with full auditing enabled? https://fedoraproject.org/wiki/SELinux/Debugging#Enable_full_auditing (In reply to Łukasz Posadowski from comment #1) > I also have this bug after upgrading from Fedora 39 to Fedora 40: > Unable to open system token /run/libvirt/common/system.token: Permission > denied > > It might be related to https://access.redhat.com/errata/RHBA-2021:4420 , > because errata is showing the same error message, but for RHEL8. Can you write down specific AVC denials? The fix for the https://bugzilla.redhat.com/show_bug.cgi?id=1966842 bug referred to from the advisory is in Fedora since 3 years ago. (In reply to Zdenek Pytela from comment #2) > There are multiple denials in the journal, some of them not related. Can you > 1. update to selinux-policy-40.10-1.fc40.noarch or the one from > https://dashboard.packit.dev/results/copr-builds/1349099 > > 2. Gather Avc denial, preferably with full auditing enabled? > https://fedoraproject.org/wiki/SELinux/Debugging#Enable_full_auditing Thank You. I will have some time on Monday, or Tuesday and attach more audit logs. It (In reply to Zdenek Pytela from comment #2) > There are multiple denials in the journal, some of them not related. Can you > 1. update to selinux-policy-40.10-1.fc40.noarch or the one from > https://dashboard.packit.dev/results/copr-builds/1349099 > > 2. Gather Avc denial, preferably with full auditing enabled? > https://fedoraproject.org/wiki/SELinux/Debugging#Enable_full_auditing It works for me on: selinux-policy-40.13-1.fc40.noarch libvirt-10.0.0-4.fc41.x86_64 virt-install-4.1.0-5.fc40.noarch qemu-kvm-8.2.0-9.fc41.x86_64 I think it is OK to close this bug. Confirmed. After adding copr repo https://dashboard.packit.dev/results/copr-builds/1349099 , I have those selinux packages: # rpm -qa | grep 'selinux' libselinux-3.6-4.fc40.x86_64 libselinux-utils-3.6-4.fc40.x86_64 python3-libselinux-3.6-4.fc40.x86_64 smartmontools-selinux-7.4-3.fc40.noarch swtpm-selinux-0.8.1-5.fc40.noarch rpm-plugin-selinux-4.19.1.1-1.fc40.x86_64 passt-selinux-0^20240220.g1e6f92b-1.fc40.noarch nbdkit-selinux-1.37.9-1.fc40.noarch selinux-policy-40.13-1.20240219143814232296.pr2041.11.g7f2deebb0.fc40.noarch selinux-policy-targeted-40.13-1.20240219143814232296.pr2041.11.g7f2deebb0.fc40.noarch # virsh list --all Id Name State ----------------------------------- 1 psqlb.ping.local running 2 awx.ping.local running 3 maria1.ping.local running 4 psqla.ping.local running # sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 33 Thanks. (In reply to Łukasz Posadowski from comment #6) > Confirmed. After adding copr repo > https://dashboard.packit.dev/results/copr-builds/1349099 , I have those > selinux packages: Spoken too soon. As werid as it sounds, it works sometimes. (-: I still can't find why. My journal for today is on https://wiki.baszarek.pl/magazyn/journal-2262587.gz . Hitting this problem also... on an F40 pre-release upgraded from F39. Having the same on f40:
SELinux is preventing virtlogd from 'read, append' accesses on the file system.token.
Additional Information:
Source Context system_u:system_r:virtlogd_t:s0-s0:c0.c1023
Target Context system_u:object_r:virt_var_run_t:s0
Target Objects system.token [ file ]
Source virtlogd
Source Path virtlogd
Port <Unknown>
Host (removed)
Source RPM Packages
Target RPM Packages
SELinux Policy RPM selinux-policy-targeted-40.15-1.fc40.noarch
Local Policy RPM selinux-policy-targeted-40.15-1.fc40.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name (removed)
Platform Linux (removed) 6.8.1-300.fc40.x86_64
#1 SMP PREEMPT_DYNAMIC Wed Mar 20 04:39:30 UTC
2024 x86_64
Alert Count 12
First Seen 2024-02-26 15:30:15 IST
Last Seen 2024-03-27 10:11:21 IST
Local ID f17b3391-e730-4eda-a575-bd891fb6c51e
Raw Audit Messages
type=AVC msg=audit(1711527081.142:970): avc: denied { read append } for pid=122194 comm="virtlogd" name="system.token" dev="tmpfs" ino=2506 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
Hash: virtlogd,virtlogd_t,virt_var_run_t,file,read,append
Has anyone hit this on a /fresh/ install of Fedora 40, as opposed to an 39->40 upgrade ? I've just deployed a brand new F40 VM, and installed libvirt inside it, rebooted and was able to successfully run a nested VM inside. As was pointed out earlier, long ago this was an SELinux policy bug, but it shouldn't have been a problem for many Fedora releases now. I'm gonig to struggle to diagnose it unless someone can identify a sequence of steps that reliably reproduces the problem I had the same issue, fixed it as described in https://bugzilla.redhat.com/show_bug.cgi?id=2272971#c1 (In reply to Daniel Berrangé from comment #10) > Has anyone hit this on a /fresh/ install of Fedora 40, as opposed to an > 39->40 upgrade ? I swapped disks and do a fresh Fedora 40 install. I can reproduce the problem. I have: --------------------------------------------------------------- Apr 08 20:09:13 ftest40virsh.ping.local setroubleshoot[1460]: SELinux is preventing rpc-virtqemud from relabelfrom access on the directory 1-nolife.ping.local. For complete SELinux messages run: sealert -l 05fbadfc-1367-4a1c-89e6-342b8f71292a Apr 08 20:09:13 ftest40virsh.ping.local setroubleshoot[1460]: SELinux is preventing rpc-virtqemud from relabelfrom access on the directory 1-nolife.ping.local. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that rpc-virtqemud should be allowed relabelfrom access on the 1-nolife.ping.local directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'rpc-virtqemud' --raw | audit2allow -M my-rpcvirtqemud # semodule -X 300 -i my-rpcvirtqemud.pp Apr 08 20:09:13 ftest40virsh.ping.local setroubleshoot[1460]: SELinux is preventing virtlogd from 'read, append' accesses on the file system.token. For complete SELinux messages run: sealert -l 460c13c2-4944-4e53-b877-8e506c7bb9b9 Apr 08 20:09:13 ftest40virsh.ping.local setroubleshoot[1460]: SELinux is preventing virtlogd from 'read, append' accesses on the file system.token. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that virtlogd should be allowed read append access on the system.token file by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'virtlogd' --raw | audit2allow -M my-virtlogd # semodule -X 300 -i my-virtlogd.pp --------------------------------------------------------------- in journal. My VM is sometimes off after host reboot: root@ftest40virsh:~# virsh list --all Id Name State ------------------------------------ - nolife.ping.local shut off This happens when I am trying to run it: root@ftest40virsh:~# virsh start --domain nolife.ping.local error: Failed to start domain 'nolife.ping.local' error: can't connect to virtlogd: Unable to open system token /run/libvirt/common/system.token: Permission denied with Apr 08 20:14:02 ftest40virsh.ping.local setroubleshoot[1783]: SELinux is preventing rpc-virtqemud from relabelfrom access on the directory 2-nolife.ping.local. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that rpc-virtqemud should be allowed relabelfrom access on the 2-nolife.ping.local directory by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'rpc-virtqemud' --raw | audit2allow -M my-rpcvirtqemud # semodule -X 300 -i my-rpcvirtqemud.pp in journal. The problem went away for me on F40 pre-release. On my F40, which was upgraded from F39, I am still having issues with SeLinux enforcing
Apr 21 12:46:37 mckenna.ping.local audit[1361]: VIRT_CONTROL pid=1361 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:virtqemud_t:s0 msg='virt=kvm op=start reason=booted vm="awx.ping.local" uuid=3e661383-2190-4641-8ffe-b96c7465de75 vm-pid=0 exe="/usr/sbin/virtqemud" hostname=? addr=? terminal=? res=failed'
Apr 21 12:46:37 mckenna.ping.local virtqemud[1361]: internal error: Failed to autostart VM 'awx.ping.local': can't connect to virtlogd: Unable to open system token /run/libvirt/common/system.token: Permission denied
Apr 21 12:46:38 mckenna.ping.local systemd[1]: Starting setroubleshootd.service - SETroubleshoot daemon for processing new SELinux denial logs...
Apr 21 12:46:41 mckenna.ping.local systemd[1]: Started setroubleshootd.service - SETroubleshoot daemon for processing new SELinux denial logs.
Apr 21 12:46:50 mckenna.ping.local setroubleshoot[1565]: SELinux is preventing daemon-init from relabelfrom access on the file master-key.aes. For complete SELinux messages run: sealert -l ebdc9c9a-21b8-4e0f-883b-21445700dcbd
Apr 21 12:46:50 mckenna.ping.local setroubleshoot[1565]: SELinux is preventing daemon-init from relabelfrom access on the file master-key.aes.
Apr 21 12:46:50 mckenna.ping.local setroubleshoot[1565]: SELinux is preventing virtlogd from 'read, append' accesses on the file system.token. For complete SELinux messages run: sealert -l 84a89654-338e-422d-a302-5ff21501dac4
Apr 21 12:46:51 mckenna.ping.local setroubleshoot[1565]: SELinux is preventing virtlogd from 'read, append' accesses on the file system.token.
If you believe that virtlogd should be allowed read append access on the system.token file by default.
I will leave this system intentionally in that state and just disable selinux when not testing for this thread. Maybe some policy upgrade will fix this and we'll know which one did it.
*** Bug 2276834 has been marked as a duplicate of this bug. *** I am going to close this bz originally created for the system.token file. There is an ongoing effort to resolve the other bzs, e.g. https://bugzilla.redhat.com/show_bug.cgi?id=2272971 https://bugzilla.redhat.com/show_bug.cgi?id=2273960 https://bugzilla.redhat.com/show_bug.cgi?id=2245233 It will probably require more than one iteration of builds. |