Re: [PATCH nfs-utils v3 00/14] add NFS over AF_VSOCK support

["J. Bruce Fields" <bfields@fieldses.org>]

On Tue, Sep 26, 2017 at 12:08:07PM +1000, NeilBrown wrote:
> On Fri, Sep 22 2017, Daniel P. Berrange wrote:
> > This just isn't practical in the general case. Even on a single Linux OS
> > distro there are multiple ways to manage firewalls (Fedora as a static
> > init script, or firewalld, and many users invent their own personal way
> > of doing it). There are countless other OS, many closed source with 3rd
> > party firewall products in use. And then there are the firewall policies
> > defined by organization's IT departments that mandate particular ways of
> > doing things with layers of approval to go through to get changes made.
> >
> > IOW, while improving firewall configuraiton is a worthy goal, it isn't
> > a substitute for host<->guest file system sharing over a non-network
> > based transport. 
> 
> I don't find this argument at all convincing.
> 
> The main selling point for VSOCK seems to be that it bypassed all
> firewalls.  i.e. traffic through a VSOCK is immune to any netfilter
> settings.
> 
> If "traffic immune to any netfilter settings" is a useful thing (and I'm
> quite willing to believe that it is), then let's focus on that goal.  It
> might be useful well beyond NFS and VMs.
> 
> How about a flag for a network interface which says "disable netfilter"??

Sounds like network configuration tools in general are a problem, so
it'd probably need to disable more than just netfilter.

But if iptable configuration and other operations start failing or
behaving strangely on one special interface, I'd worry that stuff will
break.

So I think you'd really want the interface completely hidden.

Except that you still want to configure the interface yourself using the
usual interfaces.  So:

> 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!

--b.