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

[Jim Fehlig <jfehlig@xxxxxxxx>]

On 07/01/2015 04:42 AM, Stefano Stabellini wrote:
> On Tue, 30 Jun 2015, Jim Fehlig wrote:
> > On 06/30/2015 07:55 AM, Stefano Stabellini wrote:
[...]
> > > 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
> >
> > [0] http://lists.xenproject.org/archives/html/xen-devel/2015-05/msg02139.html
> Are you suggesting to expose a per-domain user:group setting that can be
> passed down by libvirt? Maybe something under
> libxl_domain_build_info.u.hvm?
Yes. But should it be restricted to .hvm? Maybe it will be useful now (or in the 
future) for pv too. E.g. older pv bootloaders that run in dom0 could be executed 
as the user:group.
> Then I could move the code below to xl_cmdimpl.c, making it xl specific
> (rather than libxl).
Right. Which means adding 'user=' and 'group=' to xl.cfg, correct? If so, 
perhaps xl.conf should provide "xl-wide" defaults, applicable to all domains 
created with xl that don't contain explicit 'user=' and 'group='.
Regards,
Jim


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