Re: [Qemu-devel] [PATCH 3/5] seccomp: add elevateprivileges argument to command line

[Paolo Bonzini]

On 14/03/2017 14:02, Daniel P. Berrange wrote:
>>> Can you give an example of such a list?
>> 
>> Well, anything that makes "-sandbox on" more than security theater...  I
>> would consider it a necessary evil, not a good thing to have such a list.
>> 
>> Due to NO_NEW_PRIVS, I think non-migration fork/exec should be on the
>> list, but hopefully nothing else.
>
> The current semantics of '-sandbox on' are that it is documented to not
> break any valid QEMU features. By blocking fork/exec, we make a semantic
> change to the existing behaviour of '-sandbox on'.

I don't propose to block fork/exec.  I propose not to whitelist setuid,
as is the case now too.  It wouldn't be backwards-incompatible.

> So any application
> which has been using '-sandbox on' historically, is at risk of being
> broken when upgrading to QEMU 2.10. It would force the application to
> generate a different CLI for new QEMU - ie to avoid being broken they
> would have to now  add elevateprivs=allow, spawn=allow. I think we have
> to maintain semantic compat with existing usage, which means that
> '-sandbox on' has to remain security theatre.
> 
> So if we want a default config to be more restrictive, then I think you
> realistically have to turn the default parameter into a tri-state
> instead of bool, ie allow '-sandbox default' as an alternative to
> '-sandbox on' that was slightly stronger by blocking fork/exec.

Or just print a warning that "-sandbox on" is useless.  I guess that
would be okay too if we want to be "stronger" than backwards-compatible.

Paolo