On Thu, 2024-07-04 at 08:24 +1000, NeilBrown wrote: > > I've been pondering security questions with localio - particularly > wondering what questions I need to ask. I've found three focal points > which overlap but help me organise my thoughts: > 1- the LOCALIO RPC protocol > 2- the 'auth_domain' that nfsd uses to authorise access > 3- the credential that is used to access the file > > 1/ It occurs to me that I could find out the UUID reported by a given > local server (just ask it over the RPC connection), find out the > filehandle for some file that I don't have write access to (not too > hard), and create a private NFS server (hacking nfs-ganasha?) which > reports the same uuid and reports that I have access to a file with > that filehandle. If I then mount from that server inside a private > container on the same host that is running the local server, I would get > localio access to the target file. > > I might not be able to write to it because of credential checking, but I > think that is getting a lot closer to unauthorised access than I would > like. > > I would much prefer it if there was no credible way to subvert the > LOCALIO protocol. > > My current idea goes like this: > - NFS client tells nfs_common it is going to probe for localio > and gets back a nonce. nfs_common records that this probe is happening > - NFS client sends the nonce to the server over LOCALIO. > - server tells nfs_common "I just got this nonce - does it mean > anything?". If it does, the server gets connected with the client > through nfs_common. The server reports success over LOCALIO. > If it doesn't the server reports failure of LOCALIO. > - NFS client gets the reply and tells nfs_common that it has a reply > so the nonce is invalidated. If the reply was success and nfs_local > confirms there is a connection, then the two stay connected. > > I think that having a nonce (single-use uuid) is better than using the > same uuid for the life of the server, and I think that sending it > proactively by client rather than reactively by the server is also > safer. > I like this idea. That does sound much safer. > 2/ The localio access should use exactly the same auth_domain as the > network access uses. This ensure the credentials implied by > rootsquash and allsquash are used correctly. I think the current > code has the client guessing what IP address the server will see and > finding an auth_domain based on that. I'm not comfortable with that. > > In the new LOCALIO protocol I suggest above, the server registers > with nfs_common at the moment it receives an RPC request. At that > moment it knows the characteristics of the connection - remote IP? > krb5? tls? - and can determine an auth_domain and give it to > nfs_common and so make it available to the client. > The current localio code does this: + /* Note: we're connecting to ourself, so source addr == peer addr */ + rqstp->rq_addrlen = rpc_peeraddr(rpc_clnt, + (struct sockaddr *)&rqstp->rq_addr, + sizeof(rqstp->rq_addr)); ...which I guess means that we're setting this to the server's address? That does seem like it might allow a client in another namespace to bypass export permissions. I think your idea about associating an auth_domain should fix that. > Jeff wondered about an export option to explicitly enable LOCALIO. I > had wondered about that too. But I think that if we firmly tie the > localio auth_domain to the connection as above, that shouldn't be needed. > > 3/ The current code uses the 'struct cred' of the application to look up > the file in the server code. When a request goes over the wire the > credential is translated to uid/gid (or krb identity) and this is > mapped back to a credential on the server which might be in a > different uid name space (might it? Does that even work for nfsd?) > > I think that if rootsquash or allsquash is in effect the correct > server-side credential is used but otherwise the client-side > credential is used. That is likely correct in many cases but I'd > like to be convinced that it is correct in all case. Maybe it is > time to get a deeper understanding of uid name spaces. > I'll have to consider this #3 over some July 4th libations! -- Jeff Layton <jlayton@xxxxxxxxxx>
