Re: Per-guest configurable user/group for QEMU processes

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

 



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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]