[libvirt] SELinux SVirt/Qemu problems with current qemu design.

Daniel J Walsh dwalsh at redhat.com
Tue Jan 13 22:18:46 UTC 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

As I begin to work on the svirt lock down of the qemu process, I am
seeing a disturbing problem.

The qemu binaries are being used to both setup the guest image
environment and then to run the guest image.

https://bugzilla.redhat.com/show_bug.cgi?id=478901
https://bugzilla.redhat.com/show_bug.cgi?id=479614
https://bugzilla.redhat.com/show_bug.cgi?id=478734

qemu is also being used to install the images.

The problem with this is the act of installing an image or setting up
the environment an image runs within requires much more privileges then
actually running the image

If qemu program is required to be able to modify the host machines
network or to read iso images from anywhere on the host system, then
providing real security on the guest operating system process is limited.

SELinux runs best when one processes forks/execs another process this
allows us to run the two processes under different labels. Each process
with the privileges required to run.

An example environment would be the following process labels

libvirt_t->qemu_setup_t->qemu_t

Where qemu_t can only manage the files labeled with virt_image_t.
qemu_t would run the guest OS.

SELinux can allow a process to change its own label to drop priviledge
but this is considered less desirable from a security point of view.

Dan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkltE0YACgkQrlYvE4MpobOY/wCg3wNp7miY6PLy3IkFae1M4uGk
KgkAnieeGbpAUUA2/Af5oZxx9zShtZgs
=LmbV
-----END PGP SIGNATURE-----




More information about the libvir-list mailing list