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 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list