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

[Jim Fehlig <jfehlig@xxxxxxxx>]

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


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