On 02/23/2012 05:47 PM, Daniel P. Berrange wrote:
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.
I agree that this is a good solution, considering the XML compatibility.
But, what about virDomainGetSecurityLabel? It could access the first
security label or ignore the DAC driver (and maybe another function
could be added to access the whole list of seclabels), but it doesn't
seem to be the best solution.
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.
I agree with you, that is just a seclabel reinvented by another name.
But the idea here is to keep just a single seclabel exposed by the API
(as it's now). So, it would not require changes in
virDomainGetSecurityLabel.
Regards,
Daniel
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
