From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Fehlig Subject: Re: [PATCH v6] run QEMU as non-root Date: Wed, 01 Jul 2015 15:03:03 -0600 Message-ID: <55945587.70707@suse.com> References: <1435755052-19447-1-git-send-email-stefano.stabellini@eu.citrix.com> <1435764543.25170.389.camel@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini , Dario Faggioli Cc: Ian.Jackson@eu.citrix.com, xen-devel@lists.xensource.com, wei.liu2@citrix.com, ian.campbell@citrix.com List-Id: xen-devel@lists.xenproject.org On 07/01/2015 09:34 AM, Stefano Stabellini wrote: > On Wed, 1 Jul 2015, Dario Faggioli wrote: >> On Wed, 2015-07-01 at 13:50 +0100, Stefano Stabellini wrote: >>> --- /dev/null >>> +++ b/docs/misc/qemu-deprivilege.txt >>> @@ -0,0 +1,31 @@ >>> +For security reasons, libxl tries to pass a non-root username to QEMU as >>> +argument. During initialization QEMU calls setuid and setgid with the >>> +user ID and the group ID of the user passed as argument. >>> +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 --no-create-home --system xen-qemuuser-domid$i >>> +done >>> + >>> +You might want to consider passing --group to adduser to create a new >>> +group for each new user. >>> + >> This is, IMHO, a lot of policing, for something like libxl. >> >> I'm saying this only now because, although always being always dubious >> about it, it was Jim's comment to v5 that made me realize it properly, >> and you're own reply to him in that thread, would actually be a great >> alternative! >> >> In fact, what about: >> * in libxl: >> - provide and honour (as first option) device_model_user, as you're >> doing here; >> - if the above is not provided, check the availability of the >> 'shared' user, and use it if it's there; >> - if that is not there either, use root. >> * in xl (as you said yourself in v5's review): >> - build up the per-domain username and (if available) use >> device_model_user to pass it to libxl. > That is of course possible and was my first suggestion in my reply. > > However after speaking with IanC, I was convinced that offering a good > default security mechanism in libxl is better, so that all libxl users, > including hyper for example, get good security by default without any > need to do anything (except creating some users). > > I think that libvirt is a bit of a special case here, given that it > already knows about users. I would expect most other toolstacks not to. Perhaps. But thanks for providing a way (b_info->device_model_user) for apps to override the libxl policy. Regards, Jim