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

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