nfsv4 sec=krb5p and user impersonation

[Nordgren, Bryce L -FS]

> I am unable to reproduce this.  I tried both KEYRING:persistent:myuid, and
> KEYRING:user:myusername.  In both cases, when I run klist after setting this
> variable, it says:
>
> klist: No credentials cache found while retrieving principal name
>
> However, if I export KRB5CCNAME=FILE:/tmp/krb5cc_myuid_random, then
> run klist, I get the same result as when I run klist natively (as me, i.e. step [1]
> above).

Ah. KEYRING:persistent:myuid is just where sssd on my machine puts the ccache. You're quite right to substitute the actual path to wherever yours are stored. Sorry for the confusion.

> So even though I can get klist to show my user's tickets, I still get "permission
> denied" if I try to "ls" my nfs4 sec=krb5p mounted home directory.  And, if I
> try to "kinit myusername" it prompts for my password.

Kinit will always prompt for a password. The key to impersonation is to steal the TGT that the person got after they did a kinit. :)

NFS is extra complicated because of the ID mapper. You'd also need to convince your local system to idmap "root" to the user you're trying to impersonate. That way, the NFS server sees you "mapped" as the other user and presenting the other user's credentials. It may just be mapping you as "root at localhost" which would give you permission denied.

In fact, if you "su - username", then export KRB5CCNAME={the user's Kerberos cache}, that may allow NFS to start working. In fact, this may be why it worked in your OP. Don't write this off yet. Getting this to work may just take some tinkering. NFS just has more planets which need to align, that's all.

If you have SSO set up in your domain, however, you can just ssh to some other machine as the user. The other machine should have no idea that you used to be root and should let you do "whatever" to the person's NFS-mounted files. There are many ways to skin this cat.

> Your explanation is extremely helpful.  The takeaway here is that root user
> can impersonate any Kerberos user on a machine if that user has an active
> credentials cache.

Yes, so long as it is understood that the local machine is just patient zero. Once impersonated, the scope is not limited to the machine on which the user's cache was deposited. Any machine reachable via SSO. Any kerberized website in the local domain. Any foreign domains reachable by Kerberos trust. The impersonator could be anyone, on any domain-managed-or-reachable resource, for as long as the TGT is renewable.

This was the reason to suggest host based access control rules which limit "potential destinations" reachable from systems where you don't trust root. It may also be a reason to ensure that NFS mountpoints are only shared between clients which have the same administrators, or administrators who trust one another. A little compartmentalization setup to quarantine potentially sick machines, if you will. "Project resources" make good clumps of machines run by people who should trust each other.

> However, I'd still like to understand the underlying mechanics to explain my
> original scenarios and why I can't reproduce your example above.

I would suggest repeating your original experiment, keeping in mind that the two main things which are needed are: access to a Kerberos credentials cache; and correctly mapping to an NFS ID. In your case two, in particular, do a klist before trying to list their home directory. I suspect you will find a correlation between NFS working and the user you're "su'ed" to having access to an active ccache. I'm not going to be much help past this point, I fear, as I lack detailed knowledge of NFS's inner workings.

Bryce






This electronic message contains information generated by the USDA solely for the intended recipients. Any unauthorized interception of this message or the use or disclosure of the information it contains may violate the law and subject the violator to civil or criminal penalties. If you believe you have received this message in error, please notify the sender and delete the email immediately.