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

[Jim Fehlig <jfehlig@suse.com>]

On 07/01/2015 02:23 AM, Fabio Fantoni wrote:
> Il 01/07/2015 02:04, Jim Fehlig ha scritto:
>> On 06/30/2015 07:55 AM, Stefano Stabellini wrote:
>>> Try to use "xen-qemudepriv-domid$domid" first, then
>>> "xen-qemudepriv-shared" and root if everything else fails.
>>>
>>> The uids need to be manually created by the user or, more likely, by the
>>> xen package maintainer.
>>>
>>> To actually secure QEMU when running in Dom0, we need at least to
>>> deprivilege the privcmd and xenstore interfaces, this is just the first
>>> step in that direction.
>>>
>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>
>>> ---
>>> Changes in v5:
>>> - improve wording in doc
>>> - fix wording in warning message
>>> - fix example in doc
>>> - drop xen-qemudepriv-$domname
>>>
>>> Changes in v4:
>>> - rename qemu-deprivilege to qemu-deprivilege.txt
>>> - add a note about qemu-deprivilege.txt to INSTALL
>>> - instead of xen-qemudepriv-base + $domid, try xen-qemudepriv-domid$domid
>>> - introduce libxl__dm_runas_helper to make the code nicer
>>>
>>> Changes in v3:
>>> - clarify doc
>>> - handle errno == ERANGE
>>> ---
>>>   INSTALL                        |    7 ++++++
>>>   docs/misc/qemu-deprivilege.txt |   26 +++++++++++++++++++++
>>>   tools/libxl/libxl_dm.c         |   50 
>>> ++++++++++++++++++++++++++++++++++++++++
>>>   tools/libxl/libxl_internal.h   |    4 ++++
>>>   4 files changed, 87 insertions(+)
>>>   create mode 100644 docs/misc/qemu-deprivilege.txt
>>>
>>> diff --git a/INSTALL b/INSTALL
>>> index a0f2e7b..fe83c20 100644
>>> --- a/INSTALL
>>> +++ b/INSTALL
>>> @@ -297,6 +297,13 @@ systemctl enable xendomains.service
>>>   systemctl enable xen-watchdog.service
>>>     +QEMU Deprivilege
>>> +================
>>> +It is recommended to run QEMU as non-root.
>>> +See docs/misc/qemu-deprivilege.txt for an explanation on what you need
>>> +to do at installation time to run QEMU as a dedicated user.
>>> +
>>> +
>>>   History of options
>>>   ==================
>>>   diff --git a/docs/misc/qemu-deprivilege.txt b/docs/misc/qemu-deprivilege.txt
>>> new file mode 100644
>>> index 0000000..783874b
>>> --- /dev/null
>>> +++ b/docs/misc/qemu-deprivilege.txt
>>> @@ -0,0 +1,26 @@
>>> +For security reasons, libxl tries to create QEMU as non-root.
>>> +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 --system xen-qemuuser-domid$i
>>> +done
>>> +
>>> +
>>> +2) a user named "xen-qemuuser-shared"
>>> +As a fall back if both 1) and 2) fail, libxl will use a single user for
>>> +all QEMU instances. The user is named xen-qemuuser-shared. This is
>>> +less secure but still better than running QEMU as root. Using this is as
>>> +simple as creating just one more user on your host:
>>> +
>>> +adduser --system xen-qemuuser-shared
>>> +
>>> +
>>> +3) root
>>> +As a last resort, libxl will start QEMU as root.
>>
>> The more I think about it, the more I feel libxl is the wrong place for this 
>> policy. As mentioned earlier [0], libvirt allows apps to control the 
>> user:group policy. It is already supported by the qemu driver. It could be 
>> used by the libxl driver to inform libxl that the emulator (and other 
>> binaries?) it spawns should be in the context of the specified user:group.
>>
>> Regards,
>> Jim
>
> In the patch I saw this:
>> +        if (user) {
>> +            flexarray_append(dm_args, "-runas");
>> +            flexarray_append(dm_args, user);
>> +        }
> So seems that already use qemu parameter for it.
>
> What you mean is to add also the possibility to specify user for use it from 
> libvirt and similar instead doing a different thing to support the xen 
> specific one?

Yes.

> If yes I also think can be a good idea. In that case can you explain a better 
> way to do it? Probably Stabellini didn't done it because don't know other 
> similar implementation already present in other systems that use qemu and how 
> are good and used.

I replied to Stefano's mail with some additional thoughts and ideas, but I think 
he understands.

Regards,
Jim