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

[Daniel P. Berrange]

On Tue, Jan 13, 2009 at 05:18:46PM -0500, Daniel J Walsh wrote:
> -----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.

With 'setup' vs 'run' terminology, my understanding is that by 'setup'
you are refering to the initial stage which QEMU opens the disk device
backing files, possibly creates TAP devices (or uses existing TAP fds)
creates Pseudo TTYs, etc ?

In other words, this distinction is similar to the traditional idea of
a daemon starting as root, opening all its resources, and then dropping
its privs user 'nobody' or equiv ?

> 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.

Trying to make a distinction between install vs post-install is inventing
something that doesn't really exist The concept of 'install' does not have
any real meaning in the host - it is entirely a guest OS concept. All the 
host knows / cares about is that it is booting a guest with zero or more
disks. One of these may happen to be a CDROM device, which may happen to 
have a OS install image on it. It could just as easily be a live CD image.
Or it could just be a CDROM given to a running installed guest. Or there
may be no CDROM device, the guest PXE boot installing. In all the scenarios 
the host setup / guest boot works the same way - QEMU is given  an emulated
CDROM device, backed by the real host CDROM device, or an ISO  image. Or 
there may be no. This is no different to setup of virtual harddisks,

The key here is that whatever file/device is backing the virtual CDROM,
it needs to be correctly labelled to allow QEMU to either read from it,
or read+write from it (we allow RO disks, which CDROM typically are).
This is the same labelling problem as for virtual harddisks, although
its probably more common for users to have ISOs in unexpected places.
The installation app should really deal with this problem, perhaps by
saying there shall always be a '$HOME/ISO Images' directory which we could
just add to the SELinux policy to allow read-only access for QEMU. Then
virt-manager would only allow use of ISOs from that directory, or offer
to move the ISO there & re-label

> 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.

The complication comes in when you want to hot-plug devices (ie adding
extra network cards, harddisks disks, change CDROM media, attach PCI
or USB devices from the host). If we have a setup phase and a runtime
phase, this basically prevents all hotplug capabilities.

There is a tradeoff between functionality we allow qemu_t to have vs
security restrictions. eg, we could write policy to prevent QEMU creating
TAP devices / changing bridging itself, because 95% of the time libvirt
will take care of that, and pass an open FD to QEMU. Depends if we're
happy to exclude those other 5% of users.

Hotplug could potentially be made to work if we made use of UNIX domain
sockets, and their file descriptor passing, to pass an open FD of a tap
device to a running QEMU instance.

Perhaps you could do a similar trick with disks, passing a pre-opened
FD for the backing file of the disk, so you could avoid giving QEMU the
privileges to open / create files - merely read/write existing file 
handles

Save/migration is another potential complication where the running VM
needs more privileges, ie to create the save image in a suitable directory
but prevent it touching another VM's save image. 

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 :|