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

[Corey Bryant <coreyb@linux.vnet.ibm.com>]

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?

>
> By the way, are any test buckets running regularly with -sandbox on?
>

-- 
Regards,
Corey Bryant