On Thu, 2013-02-28 at 14:41 +0000, Daniel P. Berrange wrote:
On Thu, Feb 28, 2013 at 02:31:23PM +0000, Richard W.M. Jones wrote:
On Thu, Feb 28, 2013 at 02:24:30PM +0000, Richard W.M. Jones wrote:
On Thu, Feb 28, 2013 at 02:14:42PM +0000, Matthew Booth wrote:
Relabelling the appliance could get complicated wrt multiple appliances running simultaneously.
Right -- I suspect this is buggy actually, but it's quite hard to test it since I need to run up lots of guests and run virt-df in parallel on them. Also we put <shareable/> on the appliance disk, and I'm not sure what libvirt does in that case.
I spun up a few libvirt guests and surprisingly this all seems to work. I have no idea why :-) I agree with you that it shouldn't work because the labels should get stomped on by the different connections, but it seems libvirt is being cleverer somehow.
For any disk with <sharable/> set, libvirt ignores the VM MCS level and labels the disk with a simple svirt_image_t label which allows *every* VM running on the host to have read-write access to the disk.
You can't share disks between VMs, if they have MCS levels attached, unless the VMs all have the same MCS level themselves.
Presumably, therefore, a <shareable/> disk is only guaranteed to be shareable between processes with the same SELinux context. I'm guessing that <seclabel/> defaults to svirt_t, but is configurable? If I'm right and you set it to something else, which would also require custom policy, this would fail. Presumably the behaviour of <shareable/> must also have some prior knowledge of the behaviour of the policy in order to be able to create a label which will work. How does it do this? I think the only way you can guarantee this to work is to create an appliance per user/selinux label instead of just per user. With per-VM categories this would create a lot of appliances, though. Matt