Some things to consider: Yes, setting SecType to only allow Kerberos will then require a Kerberos ticket for any access (including NFS v3 mount). The client may use a service principle for some actions. This I believe maps to root. This must be allowed during a mount (possible exception, I'm not sure if a mount is performed by a non-root user if NFS does the mount access then using that user's credentials). This means that the Ganesha host will have to have each client's service principle in its keytab which means that isn't a way to exclude root access. The principle will allow root requests to be accepted, and then squashed. Note that adding a "RootDeny" squash option would not work since that would at least prevent an NFSv4 client from mounting a specific export (since the client will do PUTROOTFH followed by LOOKUP to traverse the pseudofs to the export, all performed as root or with the service ticket). It looks like NFSv3 mount is not so constrained (the credentials are not examined, just the fact that the security flavor is allowed). NOTE: This does mean if a user knows a directory on the server that is in the exported tree that allows world access, the user can mount that directory directly and gain access to any files in that directory that then have world access. At the least, they can list the directory. At least Ganesha does not allow mounting files (I have in the past used NFS setups where you COULD mount a single file...). If using NFS, don't ever assume that permissions in a higher level directory prevent access to directories and files below them. Each directory or file MUST have appropriate permissions set. Frank
-----Original Message----- From: Daniel Gryniewicz [mailto:dang@redhat.com] Sent: Wednesday, September 7, 2022 6:27 AM To: support@lists.nfs-ganesha.org Subject: [NFS-Ganesha-Support] Re: Restricting root's FS access
You can always change SecType to only allow krb5 authentication. Then no one can connect without a kerberos ticket.
Daniel
Yes, what is the requirement here?
The issue is really a security one. Initial connections are only 'protected' by Client config limited to host/ip ranges. If someone can 'reach' the NFS server
On 9/6/22 11:56, Matthew Richardson wrote: then they can connect as root (nobody) and potentially access anything which is world-readable. This is obviously a 'classic' issue with ip-based auth on NFS, and I was hoping that the existence of kerberos authentication helped here. Perhaps not.
Yes, definitely. Note that directory permissions are not sufficient to protect files since a client could "guess" a file handle and access any inode on an exported file system (even an inode in a portion of the file system that is outside an exported sub-tree of the file
system).
Indeed - the top-level directory has to be world-executable, which then opens
up attacks through guessing paths/filenames.
I suppose we could set some top-level ACLs to explicitly restrict the 'nobody'
user to have no access, but I was hoping that there might be a nicer way for the server to just reject all FS requests for certain users.
_______________________________________________ Support mailing list -- support@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org
Support mailing list -- support@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org