[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.

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

Ian.

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

 


Rackspace

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