0

I have read conflicting statements about whether shares exported via NFSv4 with sec=krb5 are cryptographically protected against a malicious client mounting the share and then spoofing the user to gain access to unauthorised files.

For example, here we have one such statement:

[In the context of Kerberos-authenticated NFS] ... NFSv4 still relies on the client to honestly report which user is accessing the files (now using the alphabetic loginID rather than the numeric UID).

And here we have a contradictory statement:

With the RPCSEC_GSS Kerberos mechanism, the server no longer depends on the client to correctly represent which user is accessing the file, as is the case with AUTH_SYS. Instead, it uses cryptography to authenticate users to the server, preventing a malicious client from impersonating a user without having that user's kerberos credentials.

What is the actual state of affairs with regard to NFSv4 file access?

Greg Askew
  • 34,339
  • 3
  • 52
  • 81
Terry Burton
  • 160
  • 1
  • 9
  • These statements are not contradictory at all. They are clear and describe the "actual state of affairs" accurately. – Michael Hampton Jun 15 '15 at 13:46
  • The first asserts that the server will deliver files to any client that provides simply a username of someone with permission to access the file. The second asserts that a cryptographic credential is required so that simply spoofing the loginID isn't enough. – Terry Burton Jun 15 '15 at 13:51
  • You appear to have ignored the context of both statements. One refers to normal NFS without Kerberos and the other refers to Kerberized NFS. – Michael Hampton Jun 15 '15 at 13:53
  • Not true. The full paragraph is as follows: "GSSAPI (Kerberos) authentication of the client host is still available, and an alternative GSSAPI mechanism called SPKM-3/LIPKEY (RFC2847) is under development, which we aren't going to use. However, NFSv4 still relies on the client to honestly report which user is accessing the files (now using the alphabetic loginID rather than the numeric UID)." (The "we aren't going to use" refers to the depricated SPKM-3/LIPKEY mechanisms.) The article goes on to demonstrate configuring NFS with sec=krb5. – Terry Burton Jun 15 '15 at 13:58
  • 1
    And RPCSEC_GSS was not even a thing eight years ago when that first item was last updated. It's a nice reference to the way things were in 2007, but it's not the way things are in 2015. – Michael Hampton Nov 16 '15 at 17:41

1 Answers1

0

sec=sys authorisation relies entirely on the uidnumber of a user on the client matching that of the file on the server. It is trivial for someone with root access to masquerade as another user.

sec=krb5 requires the user to authenticate to the kdc (not just to the client), making it harder for a local admin to impersonate a user. HOWEVER, it is not bulletproof and a client machine enrolled in the kerberos realm is considered "trusted". Say an NFSv4 share is mounted correctly by an authenticated user - the client's root then has access to the share via "su" (and possibly their tgt, which is now cached on the client).

I'm happy to be corrected ( and would like to hear from someone with a better understanding of krb NFS) - this is my observation from limited testing.

Andy
  • 1,101
  • 1
  • 7
  • 10