On Thu, Feb 23, 2012 at 05:41:27PM -0200, Marcelo Cerri wrote: > Hi, > > I'm starting working on an improvement for libvirt to be able to > support per-guest configurable user and group IDs for QEMU > processes. Currently, libvirt uses a configurable pair of user and > group, which is defined in qemu.conf, for all qemu processes when > running in privileged mode. > > This topic was already commented in qemu mailing list (http://lists.nongnu.org/archive/html/qemu-devel/2011-10/msg00758.html) > but, as this requires changes in libvirt API, I'd like to discuss > what would be the best solution for it. > > A solution (as proposed in the link above) would be to extend the > security driver model to allow multiple drivers. In this case, an > example of the XML definition would be: > > ... > <seclabel type='dynamic' model='selinux'> > <label>system_u:system_r:svirt_t:s0:c633,c712</label> > <imagelabel>system_u:object_r:svirt_image_t:s0:c633,c712</imagelabel> > </seclabel> > <seclabel type='dynamic' model='dac'> > <label>102:102</label> > <imagelabel>102:102</imagelabel> > </seclabel> > ... > > I don't know if this is a clean solution because the usual option > would be to enclose the block above in a "<seclabels>" tag. But as > this would break the actual API, it's not viable. While it is true that we would ordinarily have an enclosing tag like <seclabels>, there's no serious problem not having it. Just having two (or more) <seclabel> elements in a row is just fine, given our backwards compatibility requirements. So I think this option is just fine. > Another option is to expose the stack security driver that already > exists internally in libvirt (maybe extending it to support more > than two security drivers): > > ... > <seclabel type='stack'> > <seclabel type='dynamic' model='selinux'> > <label>system_u:system_r:svirt_t:s0:c633,c712</label> > <imagelabel>system_u:object_r:svirt_image_t:s0:c633,c712</imagelabel> > </seclabel> > <seclabel type='dynamic' model='dac'> > <label>102:102</label> > <imagelabel>102:102</imagelabel> > </seclabel> > </seclabel> > ... > > In that case, a nested seclabel only would be allowed when type='stack'. This option has some backwards compatibility problems, because any existing app querying the SELinux data would now break the moment libvirt was upgraded, so we can't do that route. > Independently of how multiple security drivers can be expressed in > the XML, another problem would be how functions as > virDomainGetSecurityLabel should behave. > > A third option is to just not support multiple security drivers and > include a new tag for DAC: > > ... > <seclabel type='dynamic' model='selinux'> > <label>system_u:system_r:svirt_t:s0:c633,c712</label> > <imagelabel>system_u:object_r:svirt_image_t:s0:c633,c712</imagelabel> > </seclabel> > <dac process='102:102' image='102:102'/> > ... This is just <seclabel> reinvented by another name, so I don't want to see that. Regards, 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