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
