[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Libguestfs] [PATCH 4/7] launch: libvirt: Allow the SELinux label to be set on qcow2 overlay files.

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]