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

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.