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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list