[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Tue, 30 Jun 2015, Ian Campbell wrote:
> On Mon, 2015-06-29 at 18:06 +0100, Stefano Stabellini wrote:
> > On Thu, 25 Jun 2015, Ian Campbell wrote:
> > > On Mon, 2015-06-01 at 17:46 +0100, Stefano Stabellini wrote:
> > > > Try to use "xen-qemudepriv-$domname" first, then
> > > > "xen-qemudepriv-domid$domid", finally "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 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 |   34 +++++++++++++++++++++++++
> > > >  tools/libxl/libxl_dm.c         |   54 
> > > > ++++++++++++++++++++++++++++++++++++++++
> > > >  tools/libxl/libxl_internal.h   |    4 +++
> > > >  4 files changed, 99 insertions(+)
> > > >  create mode 100644 docs/misc/qemu-deprivilege.txt
> > > > 
> > > > diff --git a/INSTALL b/INSTALL
> > > > index a0f2e7b..3286a5f 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 regular user.
> > > 
> > > I'd be tempted to say something like "as a dedicated user" or something,
> > > "regular user" sounds like I should be running it as my normal login
> > > user or something.
> > 
> > OK
> > 
> > 
> > > > +
> > > > +
> > > >  History of options
> > > >  ==================
> > > >  
> > > > diff --git a/docs/misc/qemu-deprivilege.txt 
> > > > b/docs/misc/qemu-deprivilege.txt
> > > > new file mode 100644
> > > > index 0000000..db61aaf
> > > > --- /dev/null
> > > > +++ b/docs/misc/qemu-deprivilege.txt
> > > > @@ -0,0 +1,34 @@
> > > > +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-$domname"
> > > > +Where $domname is the name of the domain being created.
> > > > +To use this, you just need to create a user with the appropriate name
> > > > +for each domain. For example, if your virtual machine is named 
> > > > "windows":
> > > > +
> > > > +adduser --system xen-qemuuser-windows
> > > 
> > > I just had an annoying thought: On migration (with xl at least) the
> > > receive side appends "-incoming" to the domain name for the duration and
> > > then renames ones everything is done, which is suddenly not going to
> > > match here :-(
> > > 
> > > Since this is managed at the xl level I don't see any way libxl could
> > > cope without being told separately the domain's "real" name.
> > > 
> > > I think this reduces the utility of this option quite substantially (or
> > > at least presents an enormous caveat), perhaps to the point where we may
> > > as well not bother to offer it?
> > 
> > I think we can detect the "--incoming" and remove it. The only problem
> > is that "--incoming" is actually set by xl (xl_cmdimpl.c), not libxl.
> > Could we break the abstraction layer just this time and in libxl_dm.c
> > have something like:
> > 
> > 
> >      if ((strlen(c_info->name) > strlen("--incoming")) &&
> >          (!strcmp(c_info->name + strlen(c_info->name) - 
> > strlen("--incoming"), "--incoming"))) {
> >          name = libxl__strdup(gc, c_info->name);
> >          name[strlen(c_info->name) - strlen("--incoming")] = '\0';
> >      } else {
> >          name = c_info->name;
> >      }
> >      user = libxl__sprintf(gc, "%s-%s", LIBXL_QEMU_USER_PREFIX, name);
> > 
> > 
> > This is ugly but it was only meant to demonstrate the idea.
> 
> It's not brilliant :-(
> 
> At the risk of going off into the weeds, is there any mileage in
> exposing some sort of name suffix in the libxl API which can be used by
> e.g. xl to handle this stuff? Alternatively some sort of "realname"
> field perhaps? Neither very nice, but both better than the layering
> violation I think.

I guess I could add a constant to libxl.h and use it in both libxl and
xl?

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.