On Thu, 2018-11-01 at 04:51 +0100, Jann Horn wrote:

On Thu, Nov 1, 2018 at 3:59 AM James Bottomley
[off-list ref] wrote:

quoted

On Tue, 2018-10-16 at 11:52 +0200, Laurent Vivier wrote:

quoted

Hi,

Any comment on this last version?

Any chance to be merged?

I've got a use case for this:  I went to one of the Graphene talks
in Edinburgh and it struck me that we seem to keep reinventing the
type of sandboxing that qemu-user already does.  However if you
want to do an x86 on x86 sandbox, you can't currently use the
binfmt_misc mechanism because that has you running *every* binary
on the system emulated. Doing it per user namespace fixes this
problem and allows us to at least cut down on all the pointless
duplication.

Waaaaaait. What? qemu-user does not do "sandboxing". qemu-user makes
your code slower and *LESS* secure. As far as I know, qemu-user is
only intended for purposes like development and testing.

Sandboxing is about protecting the cloud service provider (and other
tenants) from horizontal attack by reducing calls to the shared kernel.
 I think it's pretty indisputable that full emulation is an effective
sandbox in that regard.

We can argue for about bugginess vs completeness, but technologically
qemu-user already has most of the system calls, which seems to be a
significant problem with other sandboxes.  I also can't dispute it's
slower, but that's a tradeoff for people to make.

James