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