[39411] in Kerberos
Re: Impersonate Kerberos user on HDFS
daemon@ATHENA.MIT.EDU (Simo Sorce)
Thu Apr 11 15:43:38 2024
Message-ID: <df90fa76175d10283acb659b62a9512f54a8dd8e.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>,
Philippe de Rochambeau
<phiroc@free.fr>
Cc: kerberos@mit.edu
Date: Thu, 11 Apr 2024 15:41:57 -0400
In-Reply-To: <202404111224.43BCOTL9014923@hedwig.cmf.nrl.navy.mil>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On Thu, 2024-04-11 at 08:24 -0400, Ken Hornstein via Kerberos wrote:
> > - impersonate the user as, say, admin, with kinit; e.g. kinit <user>
> > - scan all HDFS directories and try to read or write
> >
> > Does anyone have suggestions?
>
> In general, your options are:
>
> - Have access to to user's key/password and generate a ticket for that
> user using kinit. As someone else already noted, this isn't really
> impersonating a user.
> - Have access to the TGS key and generate a TGT for that user (or any user).
> This is generally referred to as "ticket printing". I don't _think_
> the Kerberos distributions come with a utility to do that, but I
> believe there are example programs floating around that do that. I
> have to say that doing so would require access to the TGS key and
> having that outside of your Kerberos database would be extremely
> dangerous as if it was compromised your entire realm would be
> compromised.
> - Have access to the HDFS service key and print a service ticket for that
> user. Again, I don't know if the Kerberos distributions have such
> a utility, but this would be less dangerous (you already have to have
> the HDFS key on disk somewhere). I don't know how Kerberos works with
> HDFS, but if there are multiple service tickets for a HDFS filesystem
> spread across multiple servers that might be complicated.
Modern kerberos implementation additionally allow to impersonate users
via s4u2self and s4u2proxy services (implementations like AD and
FreeIPA provide this but standard MIT db does not) without having to
obtain any secret credential out of services.
That said, trying to read/write files can have unwanted side effects on
a large shared file system.
Posix ACLS are not that hard to interpret but group memberships can get
tricky to resolve w/o access to how the HDFS serve resolves them (or
the KDC resolves them in case AD is used the the MS-PAC is used by
Hadoop to infer group membership of a user by its authentication
ticket).
Philippe,
this is not a trivial problem, may make sense to consider what brought
you to this point and if there is any better way to handle the problem
at hand.
Simo.
--
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
