Bug 718377 - qemu + vnc + sasl needs a unique KRB5CACHEDIR to avoid selinux issues
qemu + vnc + sasl needs a unique KRB5CACHEDIR to avoid selinux issues
Status: NEW
Product: Virtualization Tools
Classification: Community
Component: libvirt (Show other bugs)
unspecified
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Libvirt Maintainers
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-02 01:25 EDT by Anthony Messina
Modified: 2016-04-02 16:18 EDT (History)
15 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
qemu log (1.06 KB, text/plain)
2011-07-06 16:32 EDT, Anthony Messina
no flags Details
qemu xml (1.66 KB, text/plain)
2011-07-06 16:33 EDT, Anthony Messina
no flags Details

  None (edit)
Description Anthony Messina 2011-07-02 01:25:37 EDT
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.
Comment 1 Anthony Messina 2011-07-02 01:26:27 EDT
-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
Comment 2 Daniel Walsh 2011-07-05 16:27:29 EDT
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?
Comment 3 Daniel Berrange 2011-07-06 05:10:27 EDT
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
Comment 4 Anthony Messina 2011-07-06 16:32:05 EDT
/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.
Comment 5 Anthony Messina 2011-07-06 16:32:35 EDT
Created attachment 511574 [details]
qemu log
Comment 6 Anthony Messina 2011-07-06 16:33:03 EDT
Created attachment 511575 [details]
qemu xml
Comment 7 Fedora Admin XMLRPC Client 2011-09-22 13:52:49 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 8 Fedora Admin XMLRPC Client 2011-09-22 13:56:20 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 9 Anthony Messina 2011-11-26 00:59:08 EST
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
Comment 10 Fedora Admin XMLRPC Client 2011-11-30 14:32:22 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 11 Fedora Admin XMLRPC Client 2011-11-30 14:35:54 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 12 Fedora Admin XMLRPC Client 2011-11-30 14:43:04 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 13 Fedora Admin XMLRPC Client 2011-11-30 14:53:42 EST
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 14 Tim Niemueller 2012-01-05 16:20:50 EST
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.
Comment 15 Tim Niemueller 2012-01-05 16:41:02 EST
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.
Comment 16 Daniel Walsh 2012-01-11 17:08:55 EST
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?
Comment 17 Tim Niemueller 2012-02-29 15:02:02 EST
I think so. Any idea how to get this fixed properly? Currently cron is deleting the file every few minutes as a workaround...
Comment 18 James Hogarth 2012-05-14 09:16:16 EDT
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.
Comment 19 Cole Robinson 2012-06-07 15:19:38 EDT
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?
Comment 20 Daniel Berrange 2012-06-08 07:42:50 EDT
Yeah, that seems like a reasonable approach
Comment 21 Fedora End Of Life 2013-01-16 09:42:58 EST
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
Comment 22 Eric Blake 2013-01-16 10:24:44 EST
Reassigning to rawhide, as the string KRB5CACHEDIR is still not in libvirt.git.
Comment 23 Eric Blake 2013-01-23 20:27:52 EST
Proposed patch:
https://www.redhat.com/archives/libvir-list/2013-January/msg01751.html
Comment 24 Eric Blake 2013-01-24 19:22:13 EST
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.
Comment 25 Cole Robinson 2013-04-01 07:01:38 EDT
Since this has lingered for a while, and there aren't many complains, moving to the upstream tracker.
Comment 26 Anthony Messina 2016-01-30 20:52:27 EST
I no longer use libvirt and will be unable to test.  Feel free to close.

Note You need to log in before you can comment on or make changes to this bug.