From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: [PATCH v5] run QEMU as non-root Date: Wed, 01 Jul 2015 14:42:23 -0600 Message-ID: <559450AF.1010806@suse.com> References: <1435672550-4788-1-git-send-email-stefano.stabellini@eu.citrix.com> <55932EA7.1080708@suse.com> <5593A365.90209@m2r.biz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5593A365.90209@m2r.biz> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Fabio Fantoni , Stefano Stabellini , xen-devel@lists.xensource.com Cc: wei.liu2@citrix.com, Ian.Jackson@eu.citrix.com, ian.campbell@citrix.com List-Id: xen-devel@lists.xenproject.org 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 >>> >>> --- >>> 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