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

[Jim Fehlig <jfehlig@xxxxxxxx>]

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@xxxxxxxxxxxxx>
> > >
> > > ---
> > > 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


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