Re: [Qemu-devel] [PATCH] seccomp: "-sandbox on" won't kill Qemu when option not built in

[Paul Moore <pmoore@redhat.com>]

On Monday, December 09, 2013 03:51:36 PM Eduardo Otubo wrote:
> On 12/09/2013 03:33 PM, Daniel P. Berrange wrote:
> > On Mon, Dec 09, 2013 at 03:20:52PM -0200, Eduardo Otubo wrote:
> >> This option was requested by virt-test team so they can run tests with
> >> Qemu and "-sandbox on" set without breaking whole test if host doesn't
> >> 
> >> have support for seccomp in kernel. It covers two possibilities:
> >>   1) Host kernel support does not support seccomp, but user installed
> >>   Qemu
> >>   
> >>      package with sandbox support: Libseccomp will fail -> qemu will fail
> >>      nicely and won't stop execution.
> >>   
> >>   2) Host kernel has support but Qemu package wasn't built with sandbox
> >>   
> >>      feature. Qemu will fail nicely and won't stop execution.
> >> 
> >> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com>
> >> ---
> >> 
> >>   vl.c | 10 +++-------
> >>   1 file changed, 3 insertions(+), 7 deletions(-)

{snip}

> > This change is really dubious from a security POV. If the admin requested
> > sandboxing and the host or QEMU build cannot support it, then QEMU really
> > *must* exit.
> 
> I think an admin must know what he's doing. If he requested sandbox but
> without kernel support he need to step back a little and understand what
> he's doing. This patch won't decrease the security level, IMHO.

NACK

For the reasons Daniel already mentioned.  Mistakes happen, a lot, and if the 
user explicitly requests security functionality and we can't provide it we 
need to fail in a manner that doesn't increase the user's risk.

> > IMHO the test suite should probe to see if sandbox is working or not, and
> > just not use the "-sandbox on" arg if the host doesn't support it.
> 
> But I think this could be done on virt-test as well :)

This would be ideal, but if you must have a fallback mechanism in QEMU proper, 
make it separate from '-sandbox on' so that it doesn't break with the current 
behavior and also makes it is obvious that the functionality is not 
guaranteed, e.g. '-sandbox try' or similar.

-- 
paul moore
security and virtualization @ redhat