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 :). -- 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
