9:54 a.m.
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(a)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
On 9/6/22 11:56, Matthew Richardson wrote:
>> 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
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(a)lists.nfs-ganesha.org To unsubscribe
> send an email to support-leave(a)lists.nfs-ganesha.org
_______________________________________________
Support mailing list -- support(a)lists.nfs-ganesha.org To unsubscribe send an
email to support-leave(a)lists.nfs-ganesha.org