Hi, On Fri, Mar 17, 2017 at 12:27:44PM +0100, Guido Günther wrote: > 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.
Any chance this can get fixed? -- Guido
