I have a kerberos-enables qemu/kvm system installed. When using virt-manager and virt-viewer, I receive the following AVCs which prevent using the vnc console via Kerberos: type=AVC msg=audit(1309584085.661:943): avc: denied { read write } for pid=27470 comm="qemu-kvm" name="vnc_107" dev=dm-0 ino=3016071 scontext=system_u:system_r:svirt_t:s0:c285,c746 tcontext=system_u:object_r:svirt_tmp_t:s0:c911,c916 tclass=file type=SYSCALL msg=audit(1309584085.661:943): arch=x86_64 syscall=open success=no exit=EACCES a0=270f3d0 a1=2 a2=180 a3=0 items=0 ppid=1 pid=27470 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm=qemu-kvm exe=/usr/bin/qemu-kvm subj=system_u:system_r:svirt_t:s0:c285,c746 key=(null) Hash: qemu-kvm,svirt_t,svirt_tmp_t,file,read,write audit2allow #============= svirt_t ============== #!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow svirt_t svirt_tmp_t:file { read write }; audit2allow -R #============= svirt_t ============== #!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow svirt_t svirt_tmp_t:file { read write }; type=AVC msg=audit(1309584085.661:944): avc: denied { unlink } for pid=27470 comm="qemu-kvm" name="vnc_107" dev=dm-0 ino=3016071 scontext=system_u:system_r:svirt_t:s0:c285,c746 tcontext=system_u:object_r:svirt_tmp_t:s0:c911,c916 tclass=file type=SYSCALL msg=audit(1309584085.661:944): arch=x86_64 syscall=unlink success=no exit=EACCES a0=270f5b0 a1=ffffffff a2=0 a3=1 items=0 ppid=1 pid=27470 auid=4294967295 uid=107 gid=107 euid=107 suid=107 fsuid=107 egid=107 sgid=107 fsgid=107 tty=(none) ses=4294967295 comm=qemu-kvm exe=/usr/bin/qemu-kvm subj=system_u:system_r:svirt_t:s0:c285,c746 key=(null) Hash: qemu-kvm,svirt_t,svirt_tmp_t,file,unlink audit2allow #============= svirt_t ============== #!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow svirt_t svirt_tmp_t:file unlink; audit2allow -R #============= svirt_t ============== #!!!! This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work. #Contraint rule: allow svirt_t svirt_tmp_t:file unlink; The Kerberos/GSSAPI configuration is correct and when I switch to permissive mode, I can connect to the virtual host's VNC server using virt-viewer without issue.
-rw-------. root root system_u:object_r:virt_tmp_t:s0 libvirt_0 -rw-------. qemu qemu system_u:object_r:svirt_tmp_t:s0:c911,c916 vnc_107
Is this a libvirt bug or an selinux-policy? Who creates this file? I think it is supposed to be used to prevent kerberos replay attacks?
There's not enough information to understand what's going on here. Please provide the guest XML configuration and the /var/log/libvirt/qemu/$GUESTNAME.log logfile and your /etc/sasl2/qemu.conf file
/etc/libvirt/qemu.conf: vnc_listen = "0.0.0.0" vnc_tls = 0 vnc_sasl = 1 /etc/sasl2/qemu.conf: mech_list: gssapi keytab: /etc/qemu/krb5.tab sasldb_path: /etc/qemu/passwd.db auxprop_plugin: sasldb f15-i686.log and f15-i686.xml attached.
Created attachment 511574 [details] qemu log
Created attachment 511575 [details] qemu xml
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This continues to occur in Fedora 16: selinux-policy-targeted-3.10.0-56.fc16.noarch /var/tmp: -rw-------. root root system_u:object_r:virt_tmp_t:s0 libvirt_0 -rw-------. qemu qemu system_u:object_r:svirt_tmp_t:s0:c168,c523 vnc_107
Has someone fixed this by now? It also appears on CentOS 6.2 and therefore probably also on RHEL 6.2. It is related to #603642 where the discussion stopped in the middle. At the moment my options are either set SELinux to permissive or to remove the file manually after each connect.
What does "This avc is a constraint violation. You will need to add an attribute to either the source or target type to make it work." mean, that seems to make my typical "trump SELinux with audit2allow" fail :-/ What do I need to do, Google does not turn up any good documentation.
Basically SELinux is preventing access to this file because it was created by a different virtual machine. If you change the label to MCS Label s0, it will stop happening Is this the replay cache file?
I think so. Any idea how to get this fixed properly? Currently cron is deleting the file every few minutes as a workaround...
As per #603642 this is a replay cache - but given that all the VMs have the same access to the same keytab it doesn't really help at all.... The suggestion before the other bug for F13 was administratively closed was letting the qemu-kvm instances share the file - ie set a context that all VMs can reach... Doing a chcon system_u:object_r:svirt_tmp_t:s0 /var/tmp/vnc_XXX allows the user to view the consoles of all the VMs in virt-manager.
Hmm, even though it sounds like sharing that file is okay, I think https://bugzilla.redhat.com/show_bug.cgi?id=603642#c10 about setting KRB5CACHEDIR to /var/lib/libvirt/qemu/$VMNAME is probably the easiest fix. danpb, does that sound good to you?
Yeah, that seems like a reasonable approach
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. 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 '16'. 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 16'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 16 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, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. 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
Reassigning to rawhide, as the string KRB5CACHEDIR is still not in libvirt.git.
Proposed patch: https://www.redhat.com/archives/libvir-list/2013-January/msg01751.html
According to 'man kerberos', shouldn't the env-var be named KRB5RCACHEDIR (note the R at character 5)? Also, does the directory have to already exist, or will kerberos create it as needed? For that matter, is setting KRB5RCACHETYPE=none an appropriate alternative? Having answers to this question will make it easier to make sure the proposed patch is on the right track.
Since this has lingered for a while, and there aren't many complains, moving to the upstream tracker.
I no longer use libvirt and will be unable to test. Feel free to close.
I no longer use libvirt and will be unable to test. Closing.