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

[Corey Bryant]

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