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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 James Morris wrote:

On Wed, 14 Jan 2009, Daniel J Walsh wrote:

...

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.

I thought the virt-manager etc. tools were moving toward using standardized directories and not allowing users to put VM images just anywhere.

This is more the iso images used to install virt images can be anywhere. So a user copies a iso image to his home directory and then installs the iso using virt-manager. Currently qemu_t would need to read user_home_t to make this work. If virt-manager/libvirt were to relabel the iso file to virt_image_t then qemu_t would be able to read it, iff it could search all of the parent directories. Daniel, has brought up the fact that additional files/directories could be added to the image via virt_manager, He is suggesting that virt-manager/libvirt would label images something like virt_image_t or virt_image_ro_t. With Svirt, these would also need the categories added. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkluVPcACgkQrlYvE4MpobPSSACg6eaZhuA+9teDqVN7ebRQkVV2 LTUAn0vKMh9TdHDvJOuT0iIeT3krHeP/ =Q/VZ -----END PGP SIGNATURE-----

On Thu, Jan 15, 2009 at 07:32:25AM +1100, James Morris wrote:

On Wed, 14 Jan 2009, Daniel J Walsh wrote:

...

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.

I thought the virt-manager etc. tools were moving toward using standardized directories and not allowing users to put VM images just anywhere.

Yes, in the next release we intend to remove the generic file browser dialog, and do all file picking via the managed storage pool APIs in libvirt. This means we know exactly what directories are expected to hold disk / iso images and can ensure they are labelled suitably 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 :|

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Itamar Heim wrote:

...

From: libvir-list-bounces@redhat.com [mailto:libvir-list- bounces@redhat.com] On Behalf Of Daniel J Walsh 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. [IH] I don't see us avoiding per-vm policy. The policy has to be dynamic - customized before launching qemu, and able to change during process life-cycle for events like hot-plug and migration. I don't see the need for the qemu process to change its permissions, since the managing libvirt can change the policy during process life (I assume selinux policy can change while a process is already running). The reason the policy has to be created just before process launch is that the VM can be run on different hosts, and I don't think it makes sense to synchronize the policy of all possible guests on all hosts all the time (and the policy is enforced at host level, not storage level for example). Also, we need to cover the SAN use case, where each image is probably an LV in LVM. SELinux has to levels of flexibility here device/file labeling and booleans. Having virt-manager modifying the policy on the fly would be quite a bit more complicated.

lvm should be handled just by setting the labels on the /dev/mapper/VolGroup00-LogVol00 For example. If this is labeled virt_image_t then qemu_t can read/write it. If it is default labeled to fixed_disk_device_t, then it will not be allowed. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkluVyMACgkQrlYvE4MpobPu2QCg5HB5U1DsFa3gTnb+T78dj2iT hPoAn21jAg46ohyybQhwoJrjihR6puU5 =Ew2C -----END PGP SIGNATURE-----