[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |