[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:34:41 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Wed, Oct 30, 2013 at 11:04:39AM +0100, Stefan Hajnoczi wrote:
> 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/50e1f7d47a94f4c770880cd8ec0f18365dcba714
> > >
> > >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
>
> It is using the GTK UI.
IMO this seccomp approach is doomed since QEMU does not practice
privilege separation. QEMU is monolithic so it's really hard to create
a meaningful sets of system calls. To avoid breaking stuff you need to
be too liberal, defeating the purpose of seccomp.
For each QEMU command-line there may be a different set of syscalls that
should be allowed/forbidden.
The existing approach clearly doesn't support the full range of options
that users specify on the command-line. So I guess the options are:
1. Don't make it the default since it breaks stuff but use it for very
specific scenarios (e.g. libvirt use cases that have been well tested).
2. Provide a kind of syscall set for various QEMU options and apply the
union of them at launch. This still seems fragile but in theory it
could work.
Stefan
- Re: [Qemu-devel] [PATCH for-1.7] seccomp: setting "-sandbox on" by default,
Stefan Hajnoczi <=