Re: [Qemu-devel] [PATCH] seccomp: adding a second whitelist

From: Paul Moore <pmoore@redhat.com>
To: Eduardo Otubo <otubo@linux.vnet.ibm.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
	Corey Bryant <coreyb@linux.vnet.ibm.com>,
	wad@chromium.org, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH] seccomp: adding a second whitelist
Date: Tue, 03 Sep 2013 17:49:52 -0400	[thread overview]
Message-ID: <2293725.RX8ljDkuH4@sifl> (raw)
In-Reply-To: <52264199.3090301@linux.vnet.ibm.com>

On Tuesday, September 03, 2013 05:07:53 PM Eduardo Otubo wrote:
> On 09/03/2013 03:21 PM, Paul Moore wrote:
> > 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, if you need any help with Qemu and/or testing, please let me know.
> I would be glad to help :) When you post your RFC to libvirt mailing
> list please add me as CC.

Of course, I appreciate all the help I can get.  We can chat a bit more once 
the patches are posted.

-- 
paul moore
security and virtualization @ redhat