[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] seccomp: adding a second whitelist
From: |
Paul Moore |
Subject: |
Re: [Qemu-devel] [PATCH] seccomp: adding a second whitelist |
Date: |
Tue, 03 Sep 2013 14:21:02 -0400 |
User-agent: |
KMail/4.11 (Linux/3.10.6-gentoo; KDE/4.11.0; x86_64; ; ) |
On Tuesday, September 03, 2013 02:08:28 PM Corey Bryant wrote:
> On 09/03/2013 02:02 PM, Corey Bryant wrote:
> > On 08/30/2013 10:21 AM, Eduardo Otubo wrote:
> >> On 08/29/2013 05:34 AM, Stefan Hajnoczi wrote:
> >>> On Wed, Aug 28, 2013 at 10:04:32PM -0300, Eduardo Otubo wrote:
> >>>> Now there's a second whitelist, right before the vcpu starts. The
> >>>> second
> >>>> whitelist is the same as the first one, except for exec() and select().
> >>>
> >>> -netdev tap,downscript=/path/to/script requires exec() in the QEMU
> >>> shutdown code path. Will this work with seccomp?
> >>
> >> I actually don't know, but I'll test that as well. Can you run a test
> >> with this patch and -netdev? I mean, if you're pointing that out you
> >> might have a scenario already setup, right?
> >>
> >> Thanks!
> >
> > This uses exec() in net/tap.c.
> >
> > I think if we're going to introduce a sandbox environment that restricts
> > existing QEMU behavior, then we have to introduce a new argument to the
> > -sandbox option. So for example, "-sandbox on" would continue to use
> > the whitelist that allows everything in QEMU to work (or at least it
> > should :). And something like "-sandbox on,strict=on" would use the
> > whitelist + blacklist.
> >
> > If this is acceptable though, then I wonder how we could go about adding
> > new syscalls to the blacklist in future QEMU releases without regressing
> > "-sandbox on,strict=on".
>
> Maybe a better approach is to provide support that allows libvirt to
> define the blacklist and pass it to QEMU?
FYI: I didn't want to mention this until I had some patches ready to post, but
I'm currently working on adding syscall filtering, via libseccomp, to libvirt.
I hope to get an initial RFC-quality patch out "soon".
--
paul moore
security and virtualization @ redhat