Created attachment 423760 [details] relevant audit.log When configuring libvirtd + qemu to use kerberos/sasl selinux is preventing access to the file /var/tmp/vnc_nnn (nnn=uid of qemu user) because it's not allowed to read/write/unlink this file for another virtual machine running on the same host. Using the same setup with qemu+ssh auth works fine. I think relaxing the policy would solve the problem. howto repeat: 1. setup libvirtd + qemu to use kerberos 2. use virt-manager from a mangament machine to connect via qemu+tcp 3. start first vm, vnc output is showing fine 4. start second vm, vnc output is broken used system: - Fedora 13 with latest updates on both server and client - kernel 2.6.33.5-112.fc13.x86_64 - fedora-virt-preview repo - libvirt-0.8.1-1.fc13.x86_64 - libvirt-python-0.8.1-1.fc13.x86_64 - libvirt-client-0.8.1-1.fc13.x86_64 - virt-manager-0.8.4-2.fc13.noarch - qemu-common-0.12.3-8.fc13.x86_64 - qemu-img-0.12.3-8.fc13.x86_64 - qemu-kvm-0.12.3-8.fc13.x86_64 - gpxe-roms-qemu-1.0.0-1.fc13.noarch - qemu-system-x86-0.12.3-8.fc13.x86_64 Not using the fedora-virt-preview repo gives the same results as stated above. relevant audit log messages are attached.
Why are two virtual machines using the same tickets?
Please provide the /etc/sasl2/qemu.conf file you have on the host. > selinux is preventing access to the file /var/tmp/vnc_nnn (nnn=uid of qemu > user) because it's not allowed to read/write/unlink this file for another > virtual machine running on the same host. I think relaxing the policy would > solve the problem. I'm not convinced that allowing one guest to unlink() another guest's kerberos files will make this operate correctly. > Why are two virtual machines using the same tickets? I'm not sure what the file '/var/tmp/vnc_nnn' is for. I don't think this is the kerberos principle, because it would not try to unlink() its own kerberos principal. This sounds more like some badly named temporary / cache file to me.
Created attachment 424052 [details] /etc/sasl2/qemu.conf from kerberized KVM host
Will attach 2 versions of the contents of /var/tmp/vnc_107. Version 1 is the one that gets created when launching the graphical console for vm1 via virt-manager from my kerberized fc13 managment workstation. here is the ls -laZ output directly from KVM host after launching vm1: [root@e520 ~]# ls -laZ /var/tmp/vnc_107 -rw-------. qemu qemu system_u:object_r:svirt_tmp_t:s0:c22,c47 /var/tmp/vnc_107 Version 2 could not be created due the selinux access violation, after manually rm the file /var/tmp/vnc_107 while still have open the vm1 graphical console and launching the graphical console for vm2 everything works so far for this 2 vm's. here is the ls -laZ output directly from KVM host after launching vm2: [root@e520 ~]# ls -laZ /var/tmp/vnc_107 -rw-------. qemu qemu system_u:object_r:svirt_tmp_t:s0:c107,c846 /var/tmp/vnc_107 The files looks like some kerberos stuff, 2 different hashes in there. I'm not shure where to look further... Perhaps qemu-kvm/vnc should use different files under /var/tmp per selinux protected vm instance?
Created attachment 424056 [details] /var/tmp/vnc_107 on KVM host /var/tmp/vnc_107 on KVM host when launched vm1
Created attachment 424057 [details] /var/tmp/vnc_107 on KVM host /var/tmp/vnc_107 on KVM host when launching vm2
After reading the horrible krb5-libs source code I've discovered that this file is the 'replay cache'. There are three env variables that ought to let us control it - KRB5RCACHETYPE=none|file - KRB5RCACHENAME=$FILENAME - KRB5RCACHEDIR=$DIRNAME Unfortunately it appears the one I really want to use, KRB5RCACHENAME, is not used in this codepath, so I can't trivially give each QEMU a separate name :-( I'm going to consult Kerberos experts about the implications of disabling it by setting KRB5RCACHETYPE=none. If that would impact protocol security, we'll have to create a custom tmp directory per QEMU instance and then use KRB5RCACHEDIR.
Thank you for digging into the kerb5-libs source code... I think the cache is important. Further testing with hard rming the cache file on the kvm host and the already running vnc consoles gets stuck after a while. seems to be a replay check problem... a custom tmp directory per QEMU instance would surely solve this.
The replay cache is used to detect cases where a client attempts to repeat the authentication exchange with an already-used authenticator. In general, you want all of the processes which might accept authentication for a service with a given principal name to share the same replay cache. That... might conflict with the SELinux goal of keeping those same processes from being able to play tricks on each other.
Why not set KRB5RCACHEDIR to /var/lib/libvirt/qemu/NAME
After some further conversation with Dan, I realize that if all of the instances are already sharing a keytab, so that they can all accept authentication as the vnc service on the same host, then preventing them from sharing a replay cache doesn't really gain us anything -- someone with access to the keytab can just forge a new ticket and use it to generate a new authenticator. Given that, I'd recommend just letting them share it.
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 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 WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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 please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.