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

[Daniel P. Berrange]

On Tue, Mar 14, 2017 at 01:48:59PM +0100, Paolo Bonzini wrote:
> 
> 
> On 14/03/2017 13:32, Eduardo Otubo wrote:
> > On Tue, Mar 14, 2017 at 01=13=15PM +0100, Paolo Bonzini wrote:
> >>
> >>
> >> On 14/03/2017 12:52, Daniel P. Berrange wrote:
> >>>>>  DEF("sandbox", HAS_ARG, QEMU_OPTION_sandbox, \
> >>>>> -    "-sandbox on[,obsolete=allow]  Enable seccomp mode 2 system call 
> >>>>> filter (default 'off').\n" \
> >>>>> -    "                              obsolete: Allow obsolete system 
> >>>>> calls",
> >>>>> +    "-sandbox on[,obsolete=allow][,elevateprivileges=deny]\n" \
> >>>>> +    "                               Enable seccomp mode 2 system call 
> >>>>> filter (default 'off').\n" \
> >>>>> +    "                               obsolete: Allow obsolete system 
> >>>>> calls\n" \
> >>>>> +    "                               elevateprivileges: avoids Qemu 
> >>>>> process to elevate its privileges by blacklisting all set*uid|gid 
> >>>>> system calls",
> >>>> Why allow these by default?
> >>> The goal is that '-sandbox on' should not break *any* QEMU feature. It
> >>> needs to be a safe thing that people can unconditionally turn on without
> >>> thinking about it.
> >>
> >> Sure, but what advantages would it provide if the default blacklist does
> >> not block anything meaningful?  At the very least, spawn=deny should
> >> default elevateprivileges to deny too.
> >>
> >> I think there should be a list (as small as possible) of features that
> >> are sacrificed by "-sandbox on".
> > 
> > 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'. 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.


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/ :|