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

[Paul Moore <pmoore@redhat.com>]

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
> >>> 
> >>> <otubo@linux.vnet.ibm.com> wrote:
> >>>> Inverting the way sandbox handles arguments, making possible to have no
> >>>> argument and still have '-sandbox on' enabled.
> >>>> 
> >>>> Signed-off-by: Eduardo Otubo <otubo@linux.vnet.ibm.com>
> >>>> ---
> >>>> 
> >>>> 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 believe I've posted this information before, but just in case ...

IMHO, it is really not that hard to debug a seccomp failure; the first step is 
to look for the failure in the audit log or syslog.  If you are on a 
Fedora/RHEL based system you are most likely running audit, so finding the 
seccomp failures are quite simple with the 'ausearch' command:

 # ausearch -m SECCOMP
 ----
 time->Wed Nov 20 09:52:08 2013
 type=SECCOMP msg=audit(1384912328.482:6656): auid=0 uid=0 gid=0 ses=854
  subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 pid=12087
  comm="qemu-kvm" sig=31 syscall=62 compat=0 ip=0x7f7a1d2abc67 code=0x0

... if you are using syslog, feel free to use whatever tool you prefer, e.g. 
grep, less, etc.

Once you have the syscall number, "syscall=62", in the audit message above, 
you can use the 'scmp_sys_resolver' to resolve the number into a name:

 # scmp_sys_resolver 62
 kill

The 'scmp_sys_resolver' tool is part of the libseccomp-devel package on 
Fedora/RHEL based systems, it may be packaged differently on other 
distributions.

I'm always open to suggestions on how to improve the development/debugging 
process, so if you have any ideas please let me know.

-Paul

-- 
paul moore
security and virtualization @ redhat