[libvirt] [PATCH 5/5] qemu: launch bridge helper from libvirtd

[Daniel P. Berrange]

On Fri, Apr 19, 2013 at 10:05:33AM -0400, Corey Bryant wrote:
> 
> 
> On 04/19/2013 09:51 AM, Daniel P. Berrange wrote:
> >On Fri, Apr 19, 2013 at 09:47:05AM -0400, Corey Bryant wrote:
> >>
> >>[snip]
> >>>
> >>>I still don't like using qemu-bridge-helper, but this is better than the
> >>>alternative of having qemu call it (although, due to the way that
> >>>process capabilities works, we are unable to prevent a rogue qemu
> >>>started by unprivileged libvirtd from calling it :-(
> >>
> >>Maybe we can introduce a tighter seccomp sandbox environment that
> >>doesn't allow the QEMU process to call exec(), open(), socket() (and
> >>anything else?) on top of the syscalls that are already not included
> >>in the -sandbox whitelist.  This would require fd's to be passed
> >>from libvirt.  Eduardo's going to work on adding functionality in
> >>this area in case you have any suggestions.
> >
> >I'd certainly like to see us have a profile that prevents execve() in
> >the near future. Already today there's no reason why a QEMU managed by
> >libvirt should need to exec anything. Eventually we'll get to the place
> >where we can consider blocking open/socket too, but I fear that's still
> >quite a way off in the distance.
> >
> >Daniel
> >
> 
> Thanks for the input.  The problem we run into next is that QEMU
> already calls execve() so I assume we'd need to support 2 seccomp
> syscall whitelists, the existing whitelist that allows execve() and
> another that doesn't.  Perhaps we can have a -sandbox,strict that
> ends up being a much more locked down environment than the current
> default.  Or perhaps we can allow libvirt to define and pass a
> whitelist to QEMU.

I think it is inevitable that we will need to have multiple seccomp
whitelist profiles, because we can't assume that everyone who wants
to use seccomp with QEMU, will also be using libvirt. Minimising the
number of profiles we need to maintain though is key, perhaps to just
2 or 3 profiles. One that is fairly permissive to allow all QEMU
features to 'just work', and one+ that is strict requiring apps to
avoid certain features in favour of FD passing.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|