[libvirt] None seclabel question

[Daniel P. Berrange]

On Tue, Sep 04, 2012 at 01:43:43PM +0200, Jiri Denemark wrote:
> On Tue, Sep 04, 2012 at 11:14:35 +0100, Daniel P. Berrange wrote:
> > On Tue, Sep 04, 2012 at 12:00:33PM +0200, Jiri Denemark wrote:
> > 
> > I don't think that description of existing behaviour is accurate. With old
> > libvirt you have one <seclabel> (for SELinux/AppArmour), but secretly there
> > are 2 security drivers (SELinux/AppArmour + DAC). Setting type=none for
> > the seclabel only meant that the SELinux/AppArmour drivers ran the guest
> > unconfined. The second (DAC) driver would still be applied to the guest
> > making it run unprivileged/confined.
> 
> Isn't DAC still applied in the same way?
> 
> > What actual problem have you seen with upgrades ?
> 
> I don't see any actual problem, I'm just trying to think about them :-) Let's
> say there's a domain running with <seclabel type='none'/> while libvirtd is
> upgraded and reconfigured to enable more seclabels by default (a very
> theoretical example could be [ "selinux", "apparmor" ]. I think neither
> selinux nor apparmor labeling should be applied for that domain. Or am I
> wrong?

When I think of upgrade issues, i consider the scenario where the new
libvirt is configured in the same way as the old livirt, and we need
to make sure the guest behaviour remains the same. This scenario you
describe obviously doesn't fall under that, since you're enabling new
behaviour that was not previously possible. I so don't think that is
an upgrade problem, but rather just a case of defining what the new
behaviour should be.

IMHO, the behaviour is thus

 - A single <seclabel> with no model=XXX attribute, refers to the first
   security driver
 - Multiple <seclabel> with explicit model=XXX attributes refer to the
   corresponding driver
 - Multiple <seclabel> with no model=XX -> forbidden config

If you want to set behaviour for the secondary, or tertiary security
drivers then you are required to provide multiple <seclabel> elements
with explicit model=XXXX attributes. We shouldn't try to abuse a single
<seclabel> element to set properties against multiple security drivers.

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