|
From: | Corey Bryant |
Subject: | Re: [Qemu-devel] [PATCH] seccomp: adding a second whitelist |
Date: | Tue, 03 Sep 2013 14:02:35 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8 |
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".
By the way, are any test buckets running regularly with -sandbox on? -- Regards, Corey Bryant
Stefan
[Prev in Thread] | Current Thread | [Next in Thread] |