Message-ID:

I can't drive 55. I'm looking forward to not being able to drive 65, either.

devel / comp.protocols.kerberos / Re: Impersonate Kerberos user on HDFS

Re: Impersonate Kerberos user on HDFS

<mailman.83.1712847297.2322.kerberos@mit.edu>

https://www.rocksolidbbs.com/devel/article-flat.php?id=535&group=comp.protocols.kerberos#535

copy link Newsgroups: comp.protocols.kerberos

Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!tncsrv06.tnetconsulting.net!.POSTED.mailman.mit.edu!not-for-mail
From: eagle@eyrie.org (Russ Allbery)
Newsgroups: comp.protocols.kerberos
Subject: Re: Impersonate Kerberos user on HDFS
Date: Thu, 11 Apr 2024 07:54:39 -0700
Organization: The Eyrie
Lines: 39
Message-ID: <mailman.83.1712847297.2322.kerberos@mit.edu>
References: <4FD44739-01B9-4D7A-B383-D3B7B4BFF047@free.fr>
<202404111224.43BCOTL9014923@hedwig.cmf.nrl.navy.mil>
<87zfu00x1s.fsf@hope.eyrie.org>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: tncsrv06.tnetconsulting.net; posting-host="mailman.mit.edu:18.7.21.50";
logging-data="21025"; mail-complaints-to="newsmaster@tnetconsulting.net"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cc: Philippe de Rochambeau <phiroc@free.fr>, Ken Hornstein
<kenh@cmf.nrl.navy.mil>
To: Ken Hornstein via Kerberos <kerberos@mit.edu>
DKIM-Filter: OpenDKIM Filter v2.11.0 unknown-host (unknown-jobid)
Authentication-Results: mailman.mit.edu; dkim=pass (1024-bit key,
unprotected) header.d=mitprod.onmicrosoft.com
header.i=@mitprod.onmicrosoft.com header.a=rsa-sha256
header.s=selector2-mitprod-onmicrosoft-com header.b=rMHnvjq/
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=gF/kHJh6XtJarjqopd6UHydTMas5H1gpAa5g/tua1lwohpLS7Q+p/JY+NfYTMSQedFr+X4tYOAO0IfZ2RPjISop0miiYxn4IwM+Ke3XfAcwnSGC2xfxocmKlVnJ/gTc7C8YZlo7Ug11cAnR8ylnWf0xdokb+cNUQJSOufWGoE2CQcKKQlUV7DRM75jK29YRXDlYCeaUXVn6PzKZ7wnb4cO9jnZNcfmrmV2dNxXYK2cUq4+RT29CU+DoigONMWgr0UwqK2hdjIAHT007lCxGQRByAeoaBy4JS8wvXCUrgEHh//Hdh9iamDMxdhRdOxUgifiVeHXCZydaaX75eHG/TaA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=biuhsn2sA83jcGlMMisrfdM2dytQnXxHxDGhmj02xXA=;
b=ZnaflnPGfKb0n2ExYH3o6F9E4eCtl/5nC9djY2kbsvw/9pDAhUloiB3D5jM8ONnhOJrdHUf/HVznh8OwU2lFpSzcqUQUiyYAHtT3SQRqN/h5SYkpOHz7N2zZVtnthLJA/3vGGnSkRnIMMLPhYbsQipt6W+gEy8riVKJ0kEdt/nC6bxziWS1Tx0/2eVnrJr7adI4hWoqm5Dvd4DARgcEb6FUwB7X/lttttUNNtpjRtP/t6nj/jAr+zjuTV4szBmeHf9viqfW8iIqn/oNDspsSgmUS4vyIEYxaVgkH7gi0ulmMvXsdsK+h7cdy1Hum3DACdVhG5X5d/ixK6ajbA82UTA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
166.84.7.159) smtp.rcpttodomain=mit.edu smtp.mailfrom=eyrie.org;
dmarc=bestguesspass action=none header.from=eyrie.org; dkim=none (message not
signed); arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=mitprod.onmicrosoft.com; s=selector2-mitprod-onmicrosoft-com;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=biuhsn2sA83jcGlMMisrfdM2dytQnXxHxDGhmj02xXA=;
b=rMHnvjq/rQzE8/Kbk0jbAA9giDc9ltz1Xc3VDvmDJ+yY+Z30/6KI0Nj7tZ07ARAy9RGQR8T4iupH2+cJVHdTf719Qe8najefrx89hLCC+QH9kJLPkbG2ES+A0OWDx2ymI8bOeI6x2SP8844kJIUSuuWvo9YhH7aGHtAecHh7OYI=
Authentication-Results: spf=pass (sender IP is 166.84.7.159)
smtp.mailfrom=eyrie.org; dkim=none (message not signed)
header.d=none;dmarc=bestguesspass action=none header.from=eyrie.org;
Received-SPF: Pass (protection.outlook.com: domain of eyrie.org designates
166.84.7.159 as permitted sender) receiver=protection.outlook.com;
client-ip=166.84.7.159; helo=haven.eyrie.org; pr=C
In-Reply-To: <202404111224.43BCOTL9014923@hedwig.cmf.nrl.navy.mil> (Ken
Hornstein via Kerberos's message of "Thu, 11 Apr 2024 08:24:29 -0400")
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b:0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: MN1PEPF0000ECDB:EE_|BN0PR01MB7085:EE_
X-MS-Office365-Filtering-Correlation-Id: 9b6342fb-15b0-449b-3f13-08dc5a375842
X-LD-Processed: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b,ExtAddr
X-MS-Exchange-AtpMessageProperties: SA
X-MS-Exchange-SenderADCheck: 0
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: Cg4RRh35Na4u4yxJPqJSq5UuteKGczLjioiP4RRTzewaDfbTuR/LpA1rxNwRUv6rcTpoGuo5p8oLOb/3pyF+vyO3fI8lwkj1g2Qf230/YYdXLSaz3qidl/ioE2Z3kByCXO0KXTUU8GWtdtHHPh8TYd1iT2s7mjLjbNEkEsvMwpI3LkC1Ol6xRWTgTzMLS5SdyAKXsR2FGJJa3iZTzac/4dQaj3WwZzEgjji1YGB8Mim50/YqxXzAJZcWqdrwz5YjWEQpbznWIiWawTkgfF72pkpOsWcSWGOp1ZXV2qdvV6RP2bm0cJM6C0iprcgPN8z/aFFFUI+aFFZmOPCMXMS5J/UKdjZzr/pP02O9BfQhBJFRVUZ4pDLSYvIDJKG6uO0lo4xkuUV5cBhc513aJBvicjId/xkA89QUc4Jn7mVglwtSSkt8hxJzs9Gp04gYaaChToDl7/iaVS08pOGvfxg78KWhYxjBlMYm3GoylyywxOb0gYXx4nF8HP7c+vTMYSGhboaXN2kcYIaGtahpZ2JvSBUEMX9R/FDLQG/P5CFs5KGk9lRk1KFmOqzQIotce9k+hN5A40BHXIgdRK/GgmkPewdvdL568C81OcGZY+tveLQC7F3avjHgBZopTiOZiAge0YHuhTH8wVoJNYIWc4Iuyg77MGk2enwkgrEaLrcMBl72zEiBdw/QNnbz7jfaTew6
X-Forefront-Antispam-Report: CIP:166.84.7.159; CTRY:US; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:haven.eyrie.org; PTR:haven.eyrie.org; CAT:NONE;
SFS:(13230031)(376005)(48200799009)(61400799018); DIR:OUT; SFP:1102;
X-ExternalRecipientOutboundConnectors: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-Auto-Response-Suppress: DR, OOF, AutoReply
X-OriginatorOrg: mitprod.onmicrosoft.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Apr 2024 14:54:52.9580 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 9b6342fb-15b0-449b-3f13-08dc5a375842
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-AuthSource: MN1PEPF0000ECDB.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0PR01MB7085
X-BeenThere: kerberos@mit.edu
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: The Kerberos Authentication System Mailing List <kerberos.mit.edu>
List-Unsubscribe: <https://mailman.mit.edu/mailman/options/kerberos>,
<mailto:kerberos-request@mit.edu?subject=unsubscribe>
List-Archive: <http://mailman.mit.edu/pipermail/kerberos/>
List-Post: <mailto:kerberos@mit.edu>
List-Help: <mailto:kerberos-request@mit.edu?subject=help>
List-Subscribe: <https://mailman.mit.edu/mailman/listinfo/kerberos>,
<mailto:kerberos-request@mit.edu?subject=subscribe>
X-Mailman-Original-Message-ID: <87zfu00x1s.fsf@hope.eyrie.org>
X-Mailman-Original-References: <4FD44739-01B9-4D7A-B383-D3B7B4BFF047@free.fr>
<202404111224.43BCOTL9014923@hedwig.cmf.nrl.navy.mil>

by: Russ Allbery - Thu, 11 Apr 2024 14:54 UTC

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

Subject	Author
Re: Impersonate Kerberos user on HDFS	Russ Allbery