nfsv4 sec=krb5p and user impersonation

[Matt Garman]

Hi Bryce, thanks for your help.  I am unable to duplicate your scenario...

On Tue, Sep 9, 2014 at 6:44 PM, Nordgren, Bryce L -FS
<bnordgren at fs.fed.us> wrote:
> 1] I sftp'ed to my fileserver (CentOS 7 + sssd + kerberos5 to active directory). This involved an AS exchange and the creation of a ticket cache.

Instead of this, I ssh in to my server as myself.  This results in me
having a credentials cache that I can see with klist, and also I have
a /tmp/krb5cc_myuid_random file.


> 2] I ssh'ed to my fileserver as root.
>
> 3] As root on fileserver: export KRB5CCNAME=KEYRING:persistent:10001  (my uid number)
>
> 4] klist now shows my credentials.


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).

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.


> Note that root never had to know my password. So to summarize, All I have to do is look at who is actively using my fileserver, "getent passwd <them>", and set my KRB5CCNAME to their uid. Then I can ssh to whatever other machine I'd like, as them. Or visit kerberized websites, or mount kerberized NFS shares, etc.
> ...


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.

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

Thanks again,
Matt