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
