Re: Impersonate Kerberos user on HDFS

[Simo Sorce]

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

Re: Impersonate Kerberos user on HDFS

[Russ Allbery]

Ken Hornstein via Kerberos  writes:

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

I have in the past written a variation on these two approaches as a
service that runs directly on the KDC.  It accepted authenticated
requests, applied some sort of complex ACL, and, if the authenticated user
making the request passed that ACL, returned a printed ticket (and of
course logged that this was happening).  Since it ran on the KDC, it
already had access to the keys required to do so.  I convinced myself that
this was acceptably secure.

(The actual project was for a former employer and I don't have the source,
and there were some other weird things about that environment that meant I
was able to maintain separate keytabs for each user without worrying about
them being invalidated, so I didn't do the full ticket printing approach
based on the TGS key and just used a bunch of user keytabs since that was
a lot easier to set up without having to work too hard.)

The huge drawback of all variations on this type of approach is that you
lose the ability to distinguish between user accesses based on their own
authentication and third-party accesses via ticket printing.  That can be
a real problem if anything goes wrong and you need to figure out whether
it was really the user or some ticket-printing service, and can be hard to
explain (for good reason) in various audit situations.  So probably best
avoided if you can find a different approach.

-- 
Russ Allbery (ea...@eyrie.org) 

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Impersonate Kerberos user on HDFS

[Ken Hornstein via Kerberos]

>- impersonate the user as, say, admin, with kinit; e.g. kinit 
>- 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.

--Ken

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Impersonate Kerberos user on HDFS

[ronnie sahlberg]

On Thu, 11 Apr 2024 at 16:43, Philippe de Rochambeau  wrote:
>
> Hello,
>
> Let's say a user has the following rights on HDFS (which are constrained 
> Apache Ranger):
>
> /prd/a/b/c <- read right
> /prd/a/b/d <- read/write right
>
> I would like to get a broad picture of  his/her complete access rights.
>
> I could look at the general policies in Apache Ranger and try to figure out 
> which apply to my user, but that's complicated.
>
> I wonder if there is another way (which ideally could be automated with a 
> script) roughly:
>
> - impersonate the user as, say, admin, with kinit; e.g. kinit 

I don't think this is what is considered "impersonating" the user.
If you authenticate with kinit  you are not impersonating that
user, you ARE/BECOME that user.

> - scan all HDFS directories and try to read or write
>
> Does anyone have suggestions?
>
> PS I've asked similar questions on the Apache Ranger mailing list, but with 
> no success.
>
> Many thanks.
>
> Philippe
>
>
>
>
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Impersonate Kerberos user on HDFS

[Philippe de Rochambeau]

Hello,

Let's say a user has the following rights on HDFS (which are constrained Apache 
Ranger):

/prd/a/b/c <- read right
/prd/a/b/d <- read/write right

I would like to get a broad picture of  his/her complete access rights. 

I could look at the general policies in Apache Ranger and try to figure out 
which apply to my user, but that's complicated.

I wonder if there is another way (which ideally could be automated with a 
script) roughly:

- impersonate the user as, say, admin, with kinit; e.g. kinit 
- scan all HDFS directories and try to read or write

Does anyone have suggestions?

PS I've asked similar questions on the Apache Ranger mailing list, but with no 
success.

Many thanks.

Philippe





Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos