On Thu, Mar 22, 2012 at 09:36:30AM +0530, Onkar N Mahajan wrote: > Libvirt doesn't care about security during hot add disk images. It even > accepts addition of disk images of other guest running on the host. > > Steps followed to create this scenario : > Now, try to add vm1's disk image into vm2 - this must not be allowed - > since for virtualized guest images. Only svirt_t processes with the > same MCS fields can read/write these images. i.e., for vm2 to access > vm1's disk image it's MCS label must be 's0:c660,c689'. > > Hot addition of vm1's image i.e., /var/lib/libvirt/images/vm1.img is > successful ( which must not be allowed ) sVirt does not try to stop any host administrator actions. Its goal is isolate guests from each other. There is nothing wrong with the scenario you descibe from sVirt's POV. Only one guest is able to access the disk at a time - the first VM looses access when you give the disk to the second VM, so there is no security flaw here. Responsibility for stopping administrator actions like this lies with the disk locking framework. If you enable the sanlock driver in libvirt, you would have been prevented from adding the disk to the second guest, while the host is running Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list