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

["Daniel P. Berrange" <berrange@redhat.com>]

On Tue, Mar 14, 2017 at 02:05:32PM +0100, Paolo Bonzini wrote:
> 
> 
> 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.

That we don't whitelist setuid is a bug in the current impl vs the intended
semantics of '-sandbox on', where we are denying valid features. 

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

It isn't totally useless - it is blocking access to a number of system
calls that QEMU should never use. eg things like reboot, load_module,
etc. In the absence of other security protections it is useless, but
if you combine with other mechanisms like DAC or LSM, then the default
seccomp rules offer some extra protection. Admittedly not alot, but
it is non-zero. The extra opt-in protecton flags then increase the
value at cost of killing some features.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://entangle-photo.org       -o-    http://search.cpan.org/~danberr/ :|