[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 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


 


Rackspace

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