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

[Stefan Hajnoczi <stefanha@redhat.com>]

On Thu, Sep 28, 2017 at 08:21:48AM +1000, NeilBrown wrote:
> On Wed, Sep 27 2017, Stefan Hajnoczi wrote:
> 
> > On Wed, Sep 27, 2017 at 10:45:17AM +1000, NeilBrown wrote:
> >> On Tue, Sep 26 2017, 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.
> >> 
> >> Did I miss something.... the whole premise of this work seems to be that
> >> programs (nfs in particular) cannot rely on host<->guest networking
> >> because some rogue firewall might interfere with it, but now you say
> >> that some programs might rely on it....
> >
> > Programs rely on IPC (e.g. UNIX domain sockets) and that's affected by
> > network namespace isolation.  This is what I was interested in.
> >
> > But I've checked that UNIX domain socket connect(2) works across network
> > namespaces for pathname sockets.  The path to the socket file just needs
> > to be accessible via the file system.
> >
> >> However I think you missed the important point - maybe I didn't explain
> >> it clearly.
> >> 
> >> My idea is that the "root" network namespace is only available in early
> >> boot.  An NFS mount happens then (and possibly a daemon hangs around in
> >> this network namespace to refresh the NFS mount).  A new network
> >> namespace is created and *everthing*else* runs in that subordinate
> >> namespace.
> >> 
> >> If you want host<->guest networking in this subordinate namespace you
> >> are quite welcome to configure that - maybe a vethX interface which
> >> bridges out to the host interface.
> >> But the important point is that any iptables rules configured in the
> >> subordinate namespace will not affect the primary namespace and so will
> >> not hurt the NFS mount. They will be entirely local.
> >
> > Using the "root" (initial) network namespace is invasive.  Hotplugged
> > NICs appear in the initial network netspace and interfaces move there if
> > a subordinate namespace is destroyed.  Were you thinking of this
> > approach because it could share a single NIC (you mentioned bridging)?
> 
> I was thinking of this approach because you appear to want isolation to
> protect the NFS mount from random firewalls, and the general approach of
> namespaces is to place the thing you want to contain (the firewall etc)
> in a subordinate namespace.
> 
> However, if a different arrangement works better then a different
> arrangement should be pursued.  I knew nothing about network namespaces
> until a couple of days ago, so I'm largely guessing.

Me neither.

> The problem I assumed you would have with putting NFS in a subordinate
> namespace is that the root namespace could still get in and mess it up,
> whereas once you are in a subordinate namespace, I assume you cannot
> get out (I assume that is part of the point).  But maybe you can stop
> processes from the root namespace getting in, or maybe you can choose
> that that is not part of the threat scenario.

Good point, I didn't think about enforcing isolation.  I was assuming
that anything running in the initial namespace will not mess with the
host<->guest namespace accidentally.  That's probably a mistake :).