From Newsgroup: comp.protocols.kerberos

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




--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

On Thu, 11 Apr 2024 at 16:43, Philippe de Rochambeau <phiroc@free.fr> 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 <user>

I don't think this is what is considered "impersonating" the user.
If you authenticate with kinit <user> 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

--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

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

--Ken
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

Ken Hornstein via Kerberos <kerberos@mit.edu> 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 (eagle@eyrie.org) <https://www.eyrie.org/~eagle/>
--- Synchronet 3.21d-Linux NewsLink 1.2

From Newsgroup: comp.protocols.kerberos

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 -a-auser using kinit. As someone else already noted, this isn't really -a-aimpersonating a user.
- Have access to the TGS key and generate a TGT for that user (or any user). -a-aThis is generally referred to as "ticket printing". I don't _think_ -a-athe Kerberos distributions come with a utility to do that, but I -a-abelieve there are example programs floating around that do that. I -a-ahave to say that doing so would require access to the TGS key and -a-ahaving that outside of your Kerberos database would be extremely -a-adangerous as if it was compromised your entire realm would be -a-acompromised.
- Have access to the HDFS service key and print a service ticket for that -a-auser. Again, I don't know if the Kerberos distributions have such
-a-aa utility, but this would be less dangerous (you already have to have -a-athe HDFS key on disk somewhere). I don't know how Kerberos works with -a-aHDFS, but if there are multiple service tickets for a HDFS filesystem -a-aspread 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









--- Synchronet 3.21d-Linux NewsLink 1.2