Hi, I'm currently working to set up ganesha with kerberos. Everything seems to work as expected, except that I can't find a way to limit the access that root on the client has to the mounted filesystem. At the moment I'm squashing root to 'nobody' - however that obviously still allows access to world-readable files/dirs. Is there a way to block all FS access from root/nobody, or always require a valid kerberos ticket? Thanks, Matthew
Why should root have less access than any other user? Daniel On 9/5/22 05:36, Matthew Richardson wrote:
Hi,
I'm currently working to set up ganesha with kerberos. Everything seems to work as expected, except that I can't find a way to limit the access that root on the client has to the mounted filesystem.
At the moment I'm squashing root to 'nobody' - however that obviously still allows access to world-readable files/dirs. Is there a way to block all FS access from root/nobody, or always require a valid kerberos ticket?
Thanks,
Matthew _______________________________________________ Support mailing list -- support@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org
On Tue, Sep 6, 2022 at 8:51 AM Daniel Gryniewicz <dang@redhat.com> wrote:
Why should root have less access than any other user?
Daniel
On 9/5/22 05:36, Matthew Richardson wrote:
Hi,
I'm currently working to set up ganesha with kerberos. Everything seems to work as expected, except that I can't find a way to limit the access that root on the client has to the mounted filesystem.
At the moment I'm squashing root to 'nobody' - however that obviously still allows access to world-readable files/dirs. Is there a way to block all FS access from root/nobody, or always require a valid kerberos ticket?
If you want to restrict root's access to a file system, and root is squashed/mapped to "nobody", you need to restrict "nobody's" access to the filesystem. This is just the way it works. Essentially, if you have the "other" permissions (or ACLs) on a file set to allow access, then anyone can get access - this is how POSIX permissions work. If you don't want everyone - including a remote "root" user - to have access, restrict the permissions accordingly. -Nick
On Tue, Sep 6, 2022 at 8:51 AM Daniel Gryniewicz <dang@redhat.com> wrote:
Why should root have less access than any other user?
Yes, what is the requirement here?
Hi,
I'm currently working to set up ganesha with kerberos. Everything seems to work as expected, except that I can't find a way to limit the access that root on
On 9/5/22 05:36, Matthew Richardson wrote: the client has to the mounted filesystem.
At the moment I'm squashing root to 'nobody' - however that obviously still
allows access to world-readable files/dirs. Is there a way to block all FS access from root/nobody, or always require a valid kerberos ticket?
Does root have a valid Kerberos ticket?
If you want to restrict root's access to a file system, and root is squashed/mapped to "nobody", you need to restrict "nobody's" access to the filesystem. This is just the way it works. Essentially, if you have the "other" permissions (or ACLs) on a file set to allow access, then anyone can get access - this is how POSIX permissions work. If you don't want everyone - including a remote "root" user - to have access, restrict the permissions accordingly.
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). Frank
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.
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@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org
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
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.
Many thanks - this post got me digging deeper into the debug logs and what exactly was happening at mount versus ls on the client, and my previous assumptions on how things were working was incorrect. It turns out that the mount is using the client's krb5 'host' principal to authenticate the mount. Moving the keytab sideways and restarting rpc-gssd means the client is forbidden from mounting. So from a security perspective an untrusted machine without a host principal can't mount at all, which is exactly what I was hoping for. Any account on the client that doesn't then have it's own krb5 ticket will result in idmapd on the server squashing them to 'nobody'. Obviously it would be nice if we could enforce that both the host and the user must have a valid ticket to get any fs access, but your explanation of why this wouldn't work for root means this isn't likely to happen. (Though this is really only thinking of untrusted users on trusted machines, which is a whole different issue security-wise!) Thanks once again for helping clarify everything! Matthew
You're welcome. I hope these explanations help you achieve the security you are hoping for. Frank
-----Original Message----- From: Matthew Richardson [mailto:m.richardson@ed.ac.uk] Sent: Wednesday, September 7, 2022 9:28 AM To: support@lists.nfs-ganesha.org Subject: [NFS-Ganesha-Support] Re: Restricting root's FS access
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.
Many thanks - this post got me digging deeper into the debug logs and what exactly was happening at mount versus ls on the client, and my previous assumptions on how things were working was incorrect.
It turns out that the mount is using the client's krb5 'host' principal to authenticate the mount. Moving the keytab sideways and restarting rpc-gssd means the client is forbidden from mounting.
So from a security perspective an untrusted machine without a host principal can't mount at all, which is exactly what I was hoping for.
Any account on the client that doesn't then have it's own krb5 ticket will result in idmapd on the server squashing them to 'nobody'.
Obviously it would be nice if we could enforce that both the host and the user must have a valid ticket to get any fs access, but your explanation of why this wouldn't work for root means this isn't likely to happen. (Though this is really only thinking of untrusted users on trusted machines, which is a whole different issue security-wise!)
Thanks once again for helping clarify everything!
Matthew _______________________________________________ Support mailing list -- support@lists.nfs-ganesha.org To unsubscribe send an email to support-leave@lists.nfs-ganesha.org
You can always change SecType to only allow krb5 authentication. Then no one can connect without a kerberos ticket.
I have the following config at the moment (the SecType in EXPORT is probably redundant, but is there just to make sure it was being used): EXPORT { Export_ID=100; Protocols = 4; Transports = TCP; Path = /; Pseudo = /nfs; Access_Type = None; SecType = krb5; Squash = root; CLIENT { Clients = *; Access_Type = RW; SecType = krb5; } } It doesn't appear that kerberos is used at all in order for root to mount the export. It just means that kerberos/idmap is used to identify the user (with root being squashed to nobody). Unless I'm missing something?
participants (4)
-
Daniel Gryniewicz -
Frank Filz -
Matthew Richardson -
Nick Couchman