[libvirt] Per-guest configurable user/group for QEMU processes

Marcelo Cerri mhcerri at linux.vnet.ibm.com
Mon Feb 27 15:48:55 UTC 2012


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




More information about the libvir-list mailing list