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

[Daniel J Walsh]

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

Daniel P. Berrange wrote:
> 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.
> 
Yes and as I stated we have the ability to Drop Priv.  But dropping
privs is the less then ideal situation since it relies on the App to do
the right thing, which has not always proven to be correct in daemons.

> 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.
>
I think labeling is a better solution for file access.  Not sure about
tap devices.  Do they become device nodes that we could create and label
such that only a particular qemu could gain access?

> 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

I think labeling can be done to allow the access to directories, and
files.  So libvirt could go in an label a file/directory in such a way
that the running qemu_t:s0.c10 can read or read/write the file/directory.

Same with the ability to create save images, as long as the labeling is
correct.  The only problem I see here is the searching of the directory
path to the location of the directories.  If we want to allow users to
store files/directories anywhere, we end up having to allow qemu_t the
ability to at least search every directory on the system, and
potentially read them.   Having the ability to read a directory is
sometimes valuable, for a hacker.

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

iEYEARECAAYFAklt77cACgkQrlYvE4MpobMkeACg00dGXdT3AajN8kMQAE5utv+p
plAAni3EhyXETStxtIZA8PMhPgSrGqMG
=SMlN
-----END PGP SIGNATURE-----