Description of problem: Version-Release number of selected component (if applicable): > qemu-guest-agent.x86_64 2:6.1.0-5.fc35 @anaconda How reproducible: Run this Fedora image with libvirt: > { > "subvariant": "Cloud_Base", > "variant": "Cloud", > "version": "35", > "link": "https://download.fedoraproject.org/pub/fedora/linux/releases/35/Cloud/x86_64/images/Fedora-Cloud-Base-35-1.2.x86_64.qcow2", > "sha256": "fe84502779b3477284a8d4c86731f642ca10dd3984d2b5eccdf82630a9ca2de6", > "arch": "x86_64", > "size": "376897536" > }, Query the guest-agent through libvirt/qemu. Steps to Reproduce: 1. 2. 3. Actual results: The guest agent reports nothing due to selinux issues: https://github.com/kubevirt/kubevirt/issues/6857#issuecomment-985109786 Disabling selinux makes it work again. Expected results: qemu-guest-agent should be able to report all data by default without getting denies by selinux. Additional info:
I can reproduce, with fully updated f35 cloud image. Trying to grab a file with virsh on the host talking to the guest agent will trigger AVCs: $ sudo virsh qemu-agent-command fedora35 '{"execute":"guest-file-open", "arguments":{"path": "/home/fedora/.bashrc"}}' error: internal error: unable to execute QEMU agent command 'guest-file-open': failed to open file '/home/fedora/.bashrc' (mode: 'r'): Permission denied Inside: time->Wed Jan 19 20:05:21 2022 type=AVC msg=audit(1642622721.939:223): avc: denied { dac_read_search } for pid=654 comm="qemu-ga" capability=2 scontext=system_u:system_r:virt_qemu_ga_t:s0 tcontext=system_u:system_r:virt_qemu_ga_t:s0 tclass=capability permissive=1 ---- time->Wed Jan 19 20:05:21 2022 type=AVC msg=audit(1642622721.939:224): avc: denied { read } for pid=654 comm="qemu-ga" name=".bashrc" dev="vda5" ino=260 scontext=system_u:system_r:virt_qemu_ga_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1 ---- time->Wed Jan 19 20:05:21 2022 type=AVC msg=audit(1642622721.939:225): avc: denied { open } for pid=654 comm="qemu-ga" path="/home/fedora/.bashrc" dev="vda5" ino=260 scontext=system_u:system_r:virt_qemu_ga_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=1 kubevirt is trying to inject ssh keys, and getting selinux denials. Seems like that should work out of the box. There's more example of denials in the linked github issue. Reassigning to selinux-policy
Cole, As I understand the problem, qemu-ga wants to open user's ~/.bashrc, but is not allowed to because it runs as user root. The dac_read_search and especially dac_override are too powerful capabilities so there needs to be a good justification for allowing it. Is it an option for you to run the commands as the target non-root user instead of root? Supposedly not allowing access to ~/.bashrc should not have consequences, but there are more examples in the linked issue. If this is to be addressed in selinux-policy, all relevant information should be collected, like access to which files and dirs is required, and also complete audit records gathered if they are available on the system: 0) Set the system in SELinux permissive mode: # setenforce 0 1) Open the /etc/audit/rules.d/audit.rules file in an editor. 2) Remove the following line if it exists: -a task,never 3) Add the following line to the end of the file: -w /etc/shadow -p w 4) Restart the audit daemon: # service auditd restart 5) Re-run your scenario. 6) Collect AVC denials: # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today
(In reply to Cole Robinson from comment #1) > I can reproduce, with fully updated f35 cloud image. Trying to grab a file > with virsh on the host talking to the guest agent will trigger AVCs: > > $ sudo virsh qemu-agent-command fedora35 '{"execute":"guest-file-open", > "arguments":{"path": "/home/fedora/.bashrc"}}' > error: internal error: unable to execute QEMU agent command > 'guest-file-open': failed to open file '/home/fedora/.bashrc' (mode: 'r'): > Permission denied This is totally expected to happen. The 'guest-file-open' command allows for reading/writing from/to arbitrary files on the system. Such a feature is fundamentally incompatible with a goal of restricting what files the agent can read/write with SELinux. To put it another way, for guest-file-open to work, then the agent effectively needs to be running as unconfined_t I'm actually surprised that guest-file-open command is even enabled in Fedora. That command is explicitly blocked in RHEL for the very reasons I describe above, and I thought it was blocked in Fedora too. In RHEL the qemu-ga.sysconfig ships out of the box with: BLACKLIST_RPC=guest-file-open,guest-file-close,guest-file-read,guest-file-write,guest-file-seek,guest-file-flush,guest-exec,guest-exec-status I'd consider it a bug that Fedora differs from RHEL in this respect, and we should fix Fedora to match RHEL lockdown. Libvirt doesn't expose these filtered commands in its API either, so I'm presuming KubeVirt is trying guest agent passthrough to access them. The whole scenario describe is basically an unsupported usage scenario. Now, more recently QGA did gain an explicit command for injecting SSH keys - "guest-ssh-add-authorized-keys" and that probably does need SELinux policy changes to allow it to work, but at least that's a fairly targetted change, not arbitrary file path access. (In reply to Zdenek Pytela from comment #2) > Cole, > > As I understand the problem, qemu-ga wants to open user's ~/.bashrc, but is > not allowed to because it runs as user root. The dac_read_search and > especially dac_override are too powerful capabilities so there needs to be a > good justification for allowing it. > > Is it an option for you to run the commands as the target non-root user > instead of root? > Supposedly not allowing access to ~/.bashrc should not have consequences, > but there are more examples in the linked issue. If this is to be addressed > in selinux-policy, all relevant information should be collected, like access > to which files and dirs is required, and also complete audit records > gathered if they are available on the system: I suggest that nothing needs changing in SELinux policy default rules for the QEMU guest agent - it is working as designed by blocking requests to read/write arbitrary files. At the very most,we could consider adding a boolean tunable to switch virt_qemu_ga_t to be effectively unconfined, but should not enable that tunable by default.
Okay thanks for the info. I'll follow up with kubevirt devs to get more info. I assumed from their upstream bug that this was a regression for latest Fedora but now I'm not so sure. There's already an older separate bug about the guest-ssh commands not working, I'll reassign to selinux-policy: https://bugzilla.redhat.com/show_bug.cgi?id=1917024 Let's keep this open for a bit, I'll close it if necessary when the plan is more clear
Hi, can you please run the scenario with this version of SELinux policy? Enable it and update: # dnf copr enable nknazeko/selinux-policy # dnf update selinux-policy I added boolean that switch virt_qemu_g_t to virt_qemu_ga_unconfined_t and can be enabled with: # semanage boolean -m --on virt_qemu_ga_run_unconfined Thanks Nikola
Sorry for the delay. I tried now but semanage didn't find that boolean: [root@fedora ~]# semanage boolean -m --on virt_qemu_ga_run_unconfined ValueError: Boolean virt_qemu_ga_run_unconfined is not defined [root@fedora ~]# rpm -q selinux-policy selinux-policy-37.2-1.fc36.403.noarch [root@fedora ~]# dnf info selinux-policy Last metadata expiration check: 0:03:51 ago on Mon 06 Jun 2022 02:19:06 PM UTC. Installed Packages Name : selinux-policy Version : 37.2 Release : 1.fc36.403 Architecture : noarch Size : 25 k Source : selinux-policy-37.2-1.fc36.403.src.rpm Repository : @System From repo : copr:copr.fedorainfracloud.org:nknazeko:selinux-policy Summary : SELinux policy configuration URL : https://github.com/fedora-selinux/selinux-policy License : GPLv2+ Description : SELinux core policy package. : Originally based off of reference policy, : the policy has been adjusted to provide support for Fedora
Hi Colin, sorry for late response. I have created another build, but in project named qemu-selinux: Can you please test it again? # dnf copr enable nknazeko/qemu-selinux # dnf update selinux-policy And enable boolean: # semanage boolean -m --on virt_qemu_ga_run_unconfined Thank you
(In reply to nknazeko from comment #7) > Hi Colin, > sorry for late response. > > I have created another build, but in project named qemu-selinux: > > Can you please test it again? > # dnf copr enable nknazeko/qemu-selinux > # dnf update selinux-policy > > And enable boolean: > # semanage boolean -m --on virt_qemu_ga_run_unconfined I can confirm this fixes the issue. I've tested selinux-policy-37.14-1.fc38.noarch so IIUC it's merged upstream already.
Thanks mprivozn for checking! Clearing needinfo set on me
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 35 entered end-of-life (EOL) status on 2022-12-13. Fedora Linux 35 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.
FYI: The pull request has been merged and will be a part of the next rawhide build.