Bug 444939 - kvm unworkable under targeted policy
Summary: kvm unworkable under targeted policy
Keywords:
Status: CLOSED DUPLICATE of bug 441619
Alias: None
Product: Fedora
Classification: Fedora
Component: virt-manager
Version: rawhide
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Daniel Berrangé
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-02 05:45 UTC by Andrew Bartlett
Modified: 2008-05-05 18:19 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2008-05-05 18:19:35 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Andrew Bartlett 2008-05-02 05:45:34 UTC
Description of problem:
SELinux prevents kvm from reading disk images stored under /home

Version-Release number of selected component (if applicable):
libvirt-0.4.2-1.fc9.x86_64
virt-manager-0.5.4-3.fc9.x86_64
selinux-policy-targeted-3.3.1-42.fc9.noarch

How reproducible:
Every time

Steps to Reproduce:
1. Use virt-manager to install a new system under KVM
2. Place the disk image on /home/ (I use /data/kvm linked to /home/data/kvm)
3. Start the VM (final step of install)
  
Actual results:
Selinux denial:
SELinux is preventing the qemu-kvm from using potentially mislabeled files
(/home/data/kvm/WinXP-5/disk.img). 

host=naomi type=AVC msg=audit(1209675230.11:139): avc: denied { getattr } for
pid=6023 comm="qemu-kvm" path="/home/data/kvm/WinXP-5/disk.img" dev=dm-1
ino=47448262 scontext=system_u:system_r:qemu_t:s0
tcontext=system_u:object_r:user_home_t:s0 tclass=file host=naomi type=SYSCALL
msg=audit(1209675230.11:139): arch=c000003e syscall=4 success=no exit=-13
a0=7fff9306b060 a1=7fff93068660 a2=7fff93068660 a3=7fff930683d0 items=0
ppid=2668 pid=6023 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="qemu-kvm" exe="/usr/bin/qemu-kvm"
subj=system_u:system_r:qemu_t:s0 key=(null) 

Expected results:
Machine should boot

Additional info:

read, write and getattr (at least) should be permitted on disk images, wherever
they are stored, or if there must be restrictions, such restrictions should be
clearly described, enforced with useful errors in libvirt and a sensible default
provided to virt-manager.

Comment 1 Daniel Walsh 2008-05-02 12:23:57 UTC
Yes we are trying to prevent system process from touching home directories.  If
you want this setup you can add custom policy to allow this.  You need to at
least label the file/directory virt_image_t

chcon -R -t virt_image_t /home/data/kvm/WinXP-5

You might also need to add custom policy to allow qemu to read users home
directories.  

grep qemu /var/log/audit/audit.log | audit2allow -M myqemu
semodule -i myqemu.pp

Will add these rules.

Another option would be to move your qemu out of /home if possible

Say /data/kvm/WinXP-5

Then you could setup the default system labeling for this directory to be
virt_image_t

# semanage fcontext -a -t virt_image_t '/data(/.*)?'
# restorecont -R -v /data

Would work.

Comment 2 Andrew Bartlett 2008-05-02 23:34:48 UTC
Then virt-manager must be similarly confined, to prevent it from allowing users
to place disk images in such directories.

Similarly, more sensible error messages much be presented to the user, telling
them that this is what the powers that be have decided.  

A new directory marked as virt_image_t needs to be created, and made the default
for virt-manager new installation. 

Comment 3 Andrew Bartlett 2008-05-02 23:36:40 UTC
As this is apparently not a selinux bug, reassigning to virt-manager.  Hopefully
we can make the user experience here sane again. 

This regression (in user visible behaviour) needs to be noted in the release notes. 

Comment 4 Daniel Walsh 2008-05-05 18:13:37 UTC
/var/lib/libvirt/images/

Has been created but it is not yet the default.

We probably should warn the user if they place it in another directory. 
Labelling the directory automatically would be dangerous, unless the default was
default_t.  But not sure we want to be that specific in the manager.

Comment 5 Daniel Berrangé 2008-05-05 18:19:35 UTC
There is already a bug to make virt-manager default to this location

See bug 441619

*** This bug has been marked as a duplicate of 441619 ***


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