Re: [PATCH v6] run QEMU as non-root

[Jim Fehlig <jfehlig@suse.com>]

On 07/01/2015 09:34 AM, Stefano Stabellini wrote:
> On Wed, 1 Jul 2015, Dario Faggioli wrote:
>> On Wed, 2015-07-01 at 13:50 +0100, Stefano Stabellini wrote:
>>> --- /dev/null
>>> +++ b/docs/misc/qemu-deprivilege.txt
>>> @@ -0,0 +1,31 @@
>>> +For security reasons, libxl tries to pass a non-root username to QEMU as
>>> +argument. During initialization QEMU calls setuid and setgid with the
>>> +user ID and the group ID of the user passed as argument.
>>> +Libxl looks for the following users in this order:
>>> +
>>> +1) a user named "xen-qemuuser-domid$domid",
>>> +Where $domid is the domid of the domain being created.
>>> +This requires the reservation of 65535 uids from xen-qemuuser-domid1
>>> +to xen-qemuuser-domid65535. To use this mechanism, you might want to
>>> +create a large number of users at installation time. For example:
>>> +
>>> +for ((i=1; i<65536; i++))
>>> +do
>>> +    adduser --no-create-home --system xen-qemuuser-domid$i
>>> +done
>>> +
>>> +You might want to consider passing --group to adduser to create a new
>>> +group for each new user.
>>> +
>> This is, IMHO, a lot of policing, for something like libxl.
>>
>> I'm saying this only now because, although always being always dubious
>> about it, it was Jim's comment to v5 that made me realize it properly,
>> and you're own reply to him in that thread, would actually be a great
>> alternative!
>>
>> In fact, what about:
>>   * in libxl:
>>      - provide and honour (as first option) device_model_user, as you're
>>        doing here;
>>      - if the above is not provided, check the availability of the
>>        'shared' user, and use it if it's there;
>>      - if that is not there either, use root.
>>   * in xl (as you said yourself in v5's review):
>>      - build up the per-domain username and (if available) use
>>        device_model_user to pass it to libxl.
> That is of course possible and was my first suggestion in my reply.
>
> However after speaking with IanC, I was convinced that offering a good
> default security mechanism in libxl is better, so that all libxl users,
> including hyper for example, get good security by default without any
> need to do anything (except creating some users).
>
> I think that libvirt is a bit of a special case here, given that it
> already knows about users. I would expect most other toolstacks not to.

Perhaps.  But thanks for providing a way (b_info->device_model_user) for apps to 
override the libxl policy.

Regards,
Jim