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