[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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.

--
Regards,
Corey Bryant


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]