On Tue, Sep 26, 2017 at 11:56:26AM +0100, Stefan Hajnoczi wrote: > On Mon, Sep 25, 2017 at 11:40:26PM -0400, J. Bruce Fields wrote: > > On Tue, Sep 26, 2017 at 12:08:07PM +1000, NeilBrown wrote: > > > On Fri, Sep 22 2017, Daniel P. Berrange wrote: > > > Rather than a flag, it might work to use network namespaces. > > > Very early in the init sequence the filesystem gets mounted using the > > > IPv6 link-local address on a client->host interface, and then a new > > > network namespace is created which does not include that interface, and > > > which everything else including firewall code runs in. Maybe. > > > > That seems closer, since it allows you to hide the interface from most > > of the guest while letting some special software--qemu guest agent?-- > > still work with it. That agent would also need to be the one to do the > > mount, and would need to be able to make that mount usable to the rest > > of the guest. > > > > Sounds doable to me? > > > > There's still the problem of the paranoid security bureaucracy. > > > > It should be pretty easy to demonstrate that the host only allows > > point-to-point traffic on these interfaces. I'd hope that that, plus > > the appeal of the feature, would be enough to win out in the end. This > > is not a class of problem that I have experience dealing with, though! > > Programs wishing to use host<->guest networking might still need the > main network namespace for UNIX domain sockets and other communication. > > For example, the QEMU guest agent has a command to report the IP > addresses of the guest. It must access the main network namespace to > collect this information while using a host<->guest socket to > communicate with the hypervisor. > > I think this can be achieved as follows: > 1. open /proc/self/ns/net (stash the file descriptor) > 2. open /var/run/netns/hvnet & call setns(2) to switch namespaces > 3. socket(AF_INET6, SOCK_STREAM, 0) to create host<->guest socket > 4. call setns(2) to switch back to main namespace > > In other words, the program stays mostly in the main network namespace > and only enters the host<->guest namespace to create sockets. > > setns(2) with a network namespace requires CAP_SYS_ADMIN so it's not > very practical. This is also a Linux only solution - it doesn't do anything to help us with supporting the feature on *BSD, Windows, and such changes are harder to backport to existing Linux guest OS. Having to play all these games to design the applications using this "just work" does not compare favourably with AF_VSOCK which is on a par with UNIX domain sockets in terms of simplicitly of use. There's also still the complexity on the host side where we have to setup firewalling to both ensure that these extra NICs can't be used to access to the LAN, as well as providing rules to ensure we don't get fooled by guest doing IP address spoofing. Again VSOCK is preferrable here since by design the data channel source address is trustworthy without needing any special protection. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
