> 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@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.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
