On Wed, Sep 16, 2009 at 05:27:25PM +0200, Arnd Bergmann wrote: > On Wednesday 16 September 2009, Michael S. Tsirkin wrote: > > > > > > No, I think this is less important, because the bridge code > > > also doesn't do this. > > > > True, but the reason might be that it is much harder in bridge (you have > > to snoop multicast registrations). With macvlan you know which > > multicasts does each device want. > > Right. It shouldn't be hard to do, and I'll probably get to > that after the other changes. > > > One of the problems that raw packet sockets have is the requirement > > > for root permissions (e.g. through libvirt). Tap sockets and > > > macvtap both don't have this limitation, so you can use them as > > > a regular user without libvirt. > > > > I don't see a huge difference here. > > If you are happy with the user being able to bypass filters in host, > > just give her CAP_NET_RAW capability. It does not have to be root. > > Capabilities are nice in theory, but I've never seen them being used > effectively in practice, where it essentially comes down to some > SUID wrapper. Heh, for tap people seem to just give out write access to it and that's all. Not really different. > Also, I might not want to allow the user to open a > random random raw socket, but only one on a specific downstream > port of a macvlan interface, so I can filter out the data from > that respective MAC address in an external switch. I agree. Maybe we can fix that for raw sockets, want me to add it to the list? :) > That scenario is probably not so relevant for KVM, unless you > consider the guest taking over the qemu host process a valid > security threat. Defence in depth is a good thing, anyway. > Arnd <>< -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
