[36446] in Kerberos
Re: nfsv4 sec=krb5p and user impersonation
daemon@ATHENA.MIT.EDU (Matt Garman)
Thu Sep 11 13:56:51 2014
MIME-Version: 1.0
In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E7236F4@001FSN2MPN1-044.001f.mgd2.msft.net>
Date: Thu, 11 Sep 2014 12:56:39 -0500
Message-ID: <CAJvUf-A8uLrsRAEHC1-_sqMq=riFJKQ0SL6xMEzyGz63FHpwzA@mail.gmail.com>
From: Matt Garman <matthew.garman@gmail.com>
To: "Nordgren, Bryce L -FS" <bnordgren@fs.fed.us>
Cc: "<kerberos@mit.edu>" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
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@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
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
