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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list