Hi,
On Tue, May 19, 2015 at 04:12:18PM +0200, Raphael Hertzog wrote:
> Hi,
>
> On Sun, 19 Oct 2014, Michael Tokarev wrote:
> > This configuration is unsupported, until proper security model is
> > implemented
> > upstream.
>
> From what I have read elsewhere, it looks like that you need to whitelist
> the bridges on which qemu-system-helper can attach new devices (via
> /etc/qemu/bridge.conf).
>
> This seems like a reasonable balance if the whitelist is empty by default?
>
> Or if the whitelist only includes the "virbr0" that libvirt setups
> for basic NAT networking in VM...
>
> Note that GNOME Boxes for example needs this helper to work in order
> to provide a sane networking setup where the host can access the VM:
> https://bugzilla.gnome.org/show_bug.cgi?id=677688
>
> At the very least, you could document how users can opt to re-enable
> permanently the setuid bit with "dpkg-statoverride" (and ensure that
> the package doesn't mess with this).
>
> Please reconsider your position on this topic.
Having the binary only executable by group kvm (which is needed for
sensible virt performance) and doing a
setcap cap_net_admin+ep /usr/lib/qemu/qemu-bridge-helper
and not a full u+s would further limit the attack surface. Having
gnome-boxes work out of the box in Stretch would be great.
Cheers,
-- Guido
