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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel