Bug 603642 - selinux prevents using qemu-kvm with kerberos via sasl
selinux prevents using qemu-kvm with kerberos via sasl
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
13
All Linux
low Severity medium
: ---
: ---
Assigned To: Miroslav Grepl
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-14 04:56 EDT by René Scholz
Modified: 2011-06-27 14:10 EDT (History)
4 users (show)

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


Attachments (Terms of Use)
relevant audit.log (1.47 KB, text/plain)
2010-06-14 04:56 EDT, René Scholz
no flags Details
/etc/sasl2/qemu.conf from kerberized KVM host (1.26 KB, text/plain)
2010-06-15 02:54 EDT, René Scholz
no flags Details
/var/tmp/vnc_107 on KVM host (181 bytes, application/octet-stream)
2010-06-15 03:25 EDT, René Scholz
no flags Details
/var/tmp/vnc_107 on KVM host (181 bytes, application/octet-stream)
2010-06-15 03:26 EDT, René Scholz
no flags Details

  None (edit)
Description René Scholz 2010-06-14 04:56:25 EDT
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.
Comment 1 Daniel Walsh 2010-06-14 18:49:34 EDT
Why are two virtual machines using the same tickets?
Comment 2 Daniel Berrange 2010-06-15 02:31:34 EDT
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.
Comment 3 René Scholz 2010-06-15 02:54:39 EDT
Created attachment 424052 [details]
/etc/sasl2/qemu.conf from kerberized KVM host
Comment 4 René Scholz 2010-06-15 03:09:36 EDT
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?
Comment 5 René Scholz 2010-06-15 03:25:52 EDT
Created attachment 424056 [details]
/var/tmp/vnc_107 on KVM host

/var/tmp/vnc_107 on KVM host when launched vm1
Comment 6 René Scholz 2010-06-15 03:26:55 EDT
Created attachment 424057 [details]
/var/tmp/vnc_107 on KVM host

/var/tmp/vnc_107 on KVM host when launching vm2
Comment 7 Daniel Berrange 2010-06-15 05:07:04 EDT
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.
Comment 8 René Scholz 2010-06-15 11:39:06 EDT
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.
Comment 9 Nalin Dahyabhai 2010-06-15 15:31:50 EDT
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.
Comment 10 Daniel Walsh 2010-06-15 15:52:34 EDT
Why not set KRB5RCACHEDIR to /var/lib/libvirt/qemu/NAME
Comment 11 Nalin Dahyabhai 2010-06-15 16:26:20 EDT
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.
Comment 12 Bug Zapper 2011-06-02 06:58:02 EDT
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
Comment 13 Bug Zapper 2011-06-27 14:10:40 EDT
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.

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