Re: [PATCH v2 6/6] RFC: tools/dm_restrict: Enable QEMU sandboxing

From: George Dunlap <george.dunlap@citrix.com>
To: Ian Jackson <ian.jackson@citrix.com>
Cc: Anthony Perard <anthony.perard@citrix.com>,
	xen-devel@lists.xenproject.org,
	Stefano Stabellini <sstabellini@kernel.org>,
	Wei Liu <wei.liu2@citrix.com>
Subject: Re: [PATCH v2 6/6] RFC: tools/dm_restrict: Enable QEMU sandboxing
Date: Mon, 24 Sep 2018 14:43:23 +0100	[thread overview]
Message-ID: <dedc9e35-984f-ef21-d508-e411ef2a4a66@citrix.com> (raw)
In-Reply-To: <23464.57587.641742.948316@mariner.uk.xensource.com>

On 09/24/2018 02:04 PM, Ian Jackson wrote:
> George Dunlap writes ("Re: [PATCH v2 6/6] RFC: tools/dm_restrict: Enable QEMU sandboxing"):
>> From qemu-depriv.md:
>>
>> `elevateprivileges` is currently required to allow `-runas` to work.
>> Removing this requirement would mean making sure that the uid change
>> happened before the seccomp2 call, perhaps by changing the uid before
>> executing QEMU.  (But this would then require other changes to create
>> the QMP socket, VNC socket, and so on).
>>
>> Should I C&P this into a comment here?
> 
> Yes.
> 
> I think the conclusion I would draw from that comment is not that the
> uid change should happen before exec'ing qemu, but that the seccomp
> call in qemu is made too early.  But fine.

Yeah, I was thinking that just after I sent this mail too; it would be
good to see if there was a reasoning behind that.

>>> In this syntax, what happens with unmentioned abilities ?
>>
>> Good question -- the -help doesn't seem to say.  Looking at the code
>> (qemu-seccomp.c:parse_sandbox()) for those who want to follow along at
>> home), it seems different options have different default values (which
>> are not mentioned) -- obsolete is default deny, but spawn,
>> elevateprivileges, and resourcsecontrol are default allow.
> 
> Erk.  I guess we could parse -help output :-/.
> 
> What about capabilities not known to the qemu source code ?

Hrm -- it looks like the sandboxing stuff is based on a blacklist,
rather than a whitelist.  Which may be inevitable, given that seccomp2
operates on system calls but qemu makes library calls (and thus doesn't
actually know which system calls are need and which are not -- see [1]).
 But it does rather undermine the usefulness of this as a security
feature -- there are literally hundreds of system calls available on
Linux, of which only 50 or so are listed here.

Luckily `-sandbox` was just one of the "sure why not" layers of extra
security, not something we rely on.

We could add a test to our testing script to parse `-help` output for
unknown-to-libxl options and throw an error, so that they get added in,
if we want.

 -George

[1] https://lwn.net/Articles/738694/

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel