[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [libvirt] selinux



On Tue, Mar 03, 2009 at 09:04:19PM +0100, Michael Kress wrote:
> Hi! What do I have to do to get qemu-kvm to run with selinux running
> with enforcing policy?

[snip]
 
> I've tried to set the type:
> chcon -t virt_image_t a01.img
> but all I got was:
> chcon: failed to change context of `a01.img' to
> `system_u:object_r:virt_image_t:s0': Invalid argument
> The host is a debian 5.0 machine.

I'm not sure how it works in Debian, but I'll outline the way it does
in Fedora. I believe all our SELinux policy bits for virt are in the
upstream SELinux reference policy, so available to Debian too.

First if you run libvirtd or qemu directly, it won't be confined at all,
so you have to start from the init script.

The /etc/init.d/libvirtd script is labelled with:

  system_u:object_r:virtd_script_exec_t:s0

With the policy transition rules, this means that when you start
libvirtd via the '/etc/init.d/libvirtd start, it'll transition
to  unconfined_u:system_r:virtd_t:s0

$ ps -axuwfZ | grep libvirtd
unconfined_u:system_r:virtd_t:s0 root     6249  0.0  0.0  65960   660 ?        Sl   Feb23   0:15 libvirtd --daemon


Now that has libvirtd running in virtd_t domain.

Next, the /usr/bin/qemu, /usr/bin/qemu-kvm and /usr/bin/qemu-system-*
binaries must all be labelled system_u:object_r:qemu_exec_t:s0


When a qemu binary is launched by a program running in virtd_t, it
will thus transition to system_u:system_r:qemu_t:s0

Thus QEMU is now confined.

Finally, when confined, QEMU needs to access its disks, so these must
all be labelled system_u:object_r:virt_image_t:s0

# ls -lZ /var/lib/libvirt/images/
-rwxr-xr-x. root root system_u:object_r:virt_image_t:s0 demo2.img

This basically protects the host OS from guest VMs.


With the sVirt support that was committed to libvirt yesterday, we can
also now protect guest VMs from each other.

What happens is that each VM runs with a dynamically generated MCS (?) 
level, and is thus isolated from VMs with different levels

On my F11 system, you'll thus see VMs running with contexts like

  system_u:system_r:qemu_t:s0:c25,c100
  system_u:system_r:qemu_t:s0:c231,c352
  system_u:system_r:qemu_t:s0:c502,c523
  system_u:system_r:qemu_t:s0:c94,c156

With disks images automatically labelled to match

  system_u:object_r:virt_image_t:s0:c25,c100
  system_u:object_r:virt_image_t:s0:c231,c352
  system_u:object_r:virt_image_t:s0:c502,c523
  system_u:object_r:virt_image_t:s0:c94,c156


Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]