Handle FreeBSD-style user-specific certificates for NFS

[chucklever]

FreeBSD's RPC-with-TLS implementation supports a security policy mechanism that enables an x.509-authenticated client to tell an NFS server to squash all requests within its TLS session to a single specific user ID. The user ID is specified within the subjectAltName field of the client's certificate. We'd like to add that support to ktls-utils and the Linux kernel's RPC client and server.

[g-v-egidy]

I think adding this would be a very good idea. Being able to differentiate access rights for example between several users homedirs is something that is currently missing in linux with TLS-NFS.

The way FreeBSD does it afaik, is you put "username@domain" into the subjectAltName with type otherName:1.3.6.1.4.1.2238.1.1.1;UTF8 of the cert and then "username" is looked up in the passwd (or other user database) and translated to the filesystem UID.

But what happens with groups and their GIDs? Would they be

• kept as the client sends them
• all squashed into the main GID of the user as it is in the passwd on the server
• the list of groups the user is member of on the server looked up and those GIDs whitelisted when sent from the client, all others squashed into the main GID?
• something else?

I'm asking because I have a bunch of directories that are used for sharing files between user groups. I have dedicated GIDs for these and use the setgid mode in the respective directories to have all files automatically regrouped to these GIDs. I would prefer if a solution for this would still allow something like that and keep strict access controls tied to certificates between the groups.

[chucklever]

I think adding this would be a very good idea. Being able to differentiate access rights for example between several users homedirs is something that is currently missing in linux with TLS-NFS.

First, you understand of course that each NFS client uses only one certificate, because certificates here identify a peer host, not a user. So one client can't, say, use multiple certificates, one for each user.

Therefore: for any one client, the server squashes all users on that client to the user identified in the client's certificate.

But what happens with groups and their GIDs?

We'll have to ask Rick how FreeBSD manages group information.

[g-v-egidy]

First, you understand of course that each NFS client uses only one certificate, because certificates here identify a peer host, not a user. So one client can't, say, use multiple certificates, one for each user.

Therefore: for any one client, the server squashes all users on that client to the user identified in the client's certificate.

Yes, I understand this and this is no issue for me.

I should probably have mentioned this in my usecase description. Each user is connected from one or more workstations, and one workstation is only ever used by one user at the same time. The client certificates are loaded into the workstation & decrypted with the pam framework when the user logs in.

But what happens with groups and their GIDs?

We'll have to ask Rick how FreeBSD manages group information.

I didn't see anything documented about GIDs in FreeBSD when skimming their docs.

[rmacklem]

The gid list is created exactly the same way as would be done if the user were to log into the server.

• gid from paaswd database entry for username
• additional gids as specified by the group database
  (More than 17 gids is supported.)

Now, what I did that I am not certain is correct is...

• I only do the identity squash for AUTH_SYS RPCs.
• RPCSEC_GSS RPCs are not squashed.
  Why?
  Well, I'm not sure what is correct for clients that use SP4_MACH_CRED.
  There is also the case where a client uses sec=krb5, but a user does not have a
  valid TGT. Some (most?) clients will fall back on AUTH_SYS for this case and I
  thought that squashing the AUTH_SYS, but not the Kerberos cred (if there is a valid one
  for the user) made sense.
  However, this makes things more confusing than just squashing all RPCs.

Squashing all RPCs should be ok for NFSv4.1/4.2 using SP4_NONE, but what about
NFSv4.0?
I think making a X.509 client cert. represent a machine credential makes sense,
but I'm not sure what has been implemented as yet?
(I'll admit I had forgotten that this was still an outstanding issue.)

[rmacklem]

I should note that I think NFSv4.0 as well as NFSv4.1/4.2 using
SP4_NONE when doing squashing, if the client uses "sec=sys".
The uid all RPCs are squashed to becomes the "machine principal".

However, when a NFSv4.1/4.2 client mixes RPCSEC_GSS and AUTH_SYS,
then it should work for SP4_NONE, but it is not obvious to me if the
RPCSEC_GSS RPCs should be squashed?
Then there is NFSv4.1/4.2 using SP4_MACH_CRED?

[chucklever]

Thanks Rick. I don't have any answers. Sounds like there needs to be some discussion on nfsv4@ietf.org. Maybe even some standards action might be helpful to resolve some of these issues so that clients and servers can interoperate securely.

[g-v-egidy]

The gid list is created exactly the same way as would be done if the user were to log into the server.

* gid from paaswd database entry for username

* additional gids as specified by the group database
  (More than 17 gids is supported.)

Thank you, this is exactly what I wandted to hear.

Squashing all RPCs should be ok for NFSv4.1/4.2 using SP4_NONE, but what about
NFSv4.0?

I'm not really familiar with the way NFS is implemented and the different RPC calls used, so take this with caution:

I'm aware that RPC-over-TLS and the underlying NFS RPCs are different layers. But nonetheless I think you can assume that there are no clients capable of RPC-over-TLS that don't also support NFS 4.2. So from a user perspective I wouldn't see an issue if there is some option in the exports file or config for tlshd on the server that restricts mounts with userid-squashing to NFS 4.2.