[libvirt] [Qemu-devel] [PATCH v4 0/5] Per-guest configurable user/group for QEMU processes

[Corey Bryant]

On 09/14/2012 09:51 AM, Daniel P. Berrange wrote:
> On Fri, Sep 14, 2012 at 09:31:26AM -0400, Corey Bryant wrote:
>>
>>
>> On 09/14/2012 04:40 AM, Daniel P. Berrange wrote:
>>> On Tue, Sep 11, 2012 at 02:13:38PM -0400, Corey Bryant wrote:
>>>> Are there any other requirements that need to be taken care of to
>>>> enable execution of QEMU guests under separate unprivileged user IDs
>>>> (ie. DAC isolation)?
>>>>
>>>> At this point, this patch series (Per-guest configurable user/group
>>>> for QEMU processes) is upstream, allowing libvirt to execute guests
>>>> under separate unprivileged user IDs.  Additionally, the QEMU bridge
>>>> helper series is upstream, allowing QEMU to allocate a tap device
>>>> and attach it to a bridge when run under an unprivileged user ID (http://www.redhat.com/archives/libvir-list/2012-August/msg00277.html).
>>>>
>>>> Is there any other feature in QEMU that requires QEMU to be run as root?
>>>
>>> Well those features you mention are for two separate issues. When
>>> running libvirt privileged (qemu:///system), QEMU was already run
>>> as non-root (qemu:qemu). The per-guest user/group was just making
>>> sure that QEMU VMs were  isolated from each other using user IDs.
>>> Since libvirtd is running privileged, it can either set permissions
>>> or open things on QEMU's behalf. All this side of things really
>>> works already.
>>
>> Ok good. This is really what I was getting at and you answered my
>> question.  So we now have DAC isolation of QEMU guests when running
>> with the qemu:///system URI and there shouldn't be any issues
>> running unprivileged guests from a privileged libvirt.
>>
>>>
>>> The TAP device bridge helper is something that's needed when running
>>> libvirtd itself unprivileged (eg the per user qemu:///session libvirtd).
>>> In this case libvirtd can't access privileged resources at all, hence
>>> the setuid TAP helper was required.
>>>
>>
>> Ah, that's right, the bridge helper is really only benefiting
>> libvirt when running with the qemu:///session URI.
>>
>> Is there a desire to get to a point where libvirt can do everything
>> under a session URI that it can do today under a system URI?  Then
>> libvirt and guests could all run unprivileged.  I'm sure it's a lot
>> of work.. I'm just asking. :)
>
> Well if you want to give a VM a raw block device someone/thing needs to
> be running privileged to set an ACL on the device to le the unprivileged
> VM use it. Similarly for PCI device passthrough. Traditionally in the
> qemu:///system case, libvirt can deal with this. In a qemu:///session
> case the sysadmin would have had to setup ACLs/permissions on the
> devices / files ahead of time.

Perhaps these are things that could eventually be taken care of by a 
setuid root helper with reduced capabilities, allowing libvirt to run 
unprivileged.

-- 
Regards,
Corey Bryant