Re: [libvirt] Per-guest configurable user/group for QEMU processes
Great. I think it is a good approach. The lack of an enclosing tag still
bothers me. But, as you said, there's no serious problem not having it
and I can live with that :)
I believe the primary driver should be defined in qemu.conf, so I would
like to replace the "security_driver" config with two new configs:
primary_security_driver and additional_security_drivers. The last one
would contain a list of security divers separated by commas, for example:
primary_security_driver = "apparmor"
additional_security_divers = "dac,another_driver"
For device seclabel's, I intend to add a "model" attribute to specify
which security driver is being overriding (if it's not given, the
primary driver is considered).
<domain ...>
...
<devices>
<disk type='file' device='disk'>
<source file='/path/to/image1'>
<seclabel relabel='no' model='dac'/>
</source>
...
</disk>
<disk type='file' device='disk'>
<source file='/path/to/image2'>
<seclabel relabel='yes' model="selinux">
<label>
system_u:object_r:shared_content_t:s0
</label>
</seclabel>
</source>
...
</disk>
...
</devices>
<seclabel type='dynamic' model='selinux'>
<baselabel>text</baselabel>
</seclabel>
<seclabel type='static' model='dac'>
<label>501:501</label>
<imagelabel>501:501</imagelabel>
</seclabel>
</domain>
What do you think?
Regards,
Marcelo
On 02/23/2012 07:34 PM, Daniel P. Berrange wrote:
On Thu, Feb 23, 2012 at 06:38:45PM -0200, Marcelo Cerri wrote:
> 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.
We can just keep virDomainGetSecurityLabel()/virNodeGetSecurityModel
as only ever handling the primary security driver.
Then add some new APIs which are more general
int virNodeGetSecurityModelCount(virConnectPtr conn);
int virNodeGetSecurityModelList(virConnectPtr conn,
virSecurityModelPtr models,
int nmodels);
int virDomainGetSecurityLabelList(virDomainptr dom,
virSecuriyLabelptr labels,
int nlabels);
Regards,
Daniel