qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for-1.7] seccomp: setting "-sandbox on" by defau


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH for-1.7] seccomp: setting "-sandbox on" by default
Date: Fri, 22 Nov 2013 11:39:31 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Nov 21, 2013 at 10:48:58AM -0500, Paul Moore wrote:
> On Thursday, November 21, 2013 04:14:11 PM Paolo Bonzini wrote:
> > Il 30/10/2013 11:04, Stefan Hajnoczi ha scritto:
> > > On Wed, Oct 23, 2013 at 12:42:34PM -0200, Eduardo Otubo wrote:
> > >> On 10/22/2013 11:00 AM, Anthony Liguori wrote:
> > >>> On Tue, Oct 22, 2013 at 12:21 PM, Eduardo Otubo
> > >>> 
> > >>> <address@hidden> wrote:
> > >>>> Inverting the way sandbox handles arguments, making possible to have no
> > >>>> argument and still have '-sandbox on' enabled.
> > >>>> 
> > >>>> Signed-off-by: Eduardo Otubo <address@hidden>
> > >>>> ---
> > >>>> 
> > >>>> The option '-sandbox on' is now used by default by virt-test[0] -- it
> > >>>> has been merged into the 'next' branch and will be available in the
> > >>>> next release, meaning we have a back support for regression tests if
> > >>>> anything breaks because of some missing system call not listed in the
> > >>>> whitelist.
> > >>>> 
> > >>>> This being said, I think it makes sense to have this option set to 'on'
> > >>>> by
> > >>>> default in the next Qemu version. It's been a while since no missing
> > >>>> syscall is reported and at this point the whitelist seems to be pretty
> > >>>> mature.
> > >>>> 
> > >>>> [0] -
> > >>>> https://github.com/autotest/virt-test/commit/50e1f7d47a94f4c770880cd8e
> > >>>> c0f18365dcba714>>> 
> > >>> This breaks hot_add of a network device that uses a script= argument,
> > >>> correct?
> > >>> 
> > >>> If so, this cannot be made default.
> > >> 
> > >> Anthony, I believe you're talking about the blacklist feature. This
> > >> is the old whitelist that is already upstream and it does not block
> > >> any network device to be hot plugged.
> > > 
> > > The following fails to start here (the shell hangs and ps shows QEMU is
> > > a <defunct> process):
> > > 
> > > qemu-system-x86_64 -sandbox on -enable-kvm -m 1024 -cpu host \
> > > 
> > >                    -drive if=virtio,cache=none,file=test.img
> > 
> > Easier-to-debug failures are another prerequisite for enabling the
> > sandbox by default, I think.
[...]
> I'm always open to suggestions on how to improve the development/debugging 
> process, so if you have any ideas please let me know.

The failure mode is terrible:
  "The following fails to start here (the shell hangs and ps shows QEMU
  is a <defunct> process)"

When a process dies the shell prints a warning.  That alerts the user
and prompts them to take further steps.

Hanging the shell is a really bad way to fail.  We can't expect users to
begin searching logs for audit failures.  They probably don't even know
about audit or seccomp.

Is it possible to produce output when a seccomp violation takes place?

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]