From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56666) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VGyU8-00027Z-Ph for qemu-devel@nongnu.org; Tue, 03 Sep 2013 17:50:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VGyU2-0002n0-QG for qemu-devel@nongnu.org; Tue, 03 Sep 2013 17:50:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41809) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VGyU2-0002m5-IF for qemu-devel@nongnu.org; Tue, 03 Sep 2013 17:49:58 -0400 From: Paul Moore Date: Tue, 03 Sep 2013 17:49:52 -0400 Message-ID: <2293725.RX8ljDkuH4@sifl> In-Reply-To: <52264199.3090301@linux.vnet.ibm.com> References: <1377738272-3470-1-git-send-email-otubo@linux.vnet.ibm.com> <3584106.zoRa73cOQX@sifl> <52264199.3090301@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [Qemu-devel] [PATCH] seccomp: adding a second whitelist List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eduardo Otubo Cc: Stefan Hajnoczi , Corey Bryant , wad@chromium.org, qemu-devel@nongnu.org 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