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

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

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:
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++))
+    adduser --system xen-qemuuser-domid$i
+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.


[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

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='.


Xen-devel mailing list



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