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
--
|:
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 :|