Return-Path: Received: from XEDGEA.nrel.gov (xedgea.nrel.gov [192.174.58.134]) by krbdev.mit.edu (Postfix) with ESMTPS id 3DBBE3E639 for ; Fri, 30 Sep 2011 14:45:41 -0400 (EDT) Received: from XHUBB.nrel.gov (10.20.4.59) by XEDGEA.nrel.gov (192.174.58.134) with Microsoft SMTP Server (TLS) id 8.2.234.1; Fri, 30 Sep 2011 12:45:38 -0600 Received: from MAILBOX2.nrel.gov ([fe80::48b0:b121:8465:5e5]) by XHUBB.nrel.gov ([::1]) with mapi; Fri, 30 Sep 2011 12:45:40 -0600 From: "Shelby, James" To: "'rt-comment@krbdev.mit.edu'" Date: Fri, 30 Sep 2011 12:45:40 -0600 Subject: RE: [krbdev.mit.edu #6967] Kerberos weakness Thread-Topic: [krbdev.mit.edu #6967] Kerberos weakness Thread-Index: Acx/oMgx9NPVCxh1RVWUTbGXHps6kgAAES0Q Message-ID: <91B33E9B9526B24BAE07189701142B5132D15F9AF4@MAILBOX2.nrel.gov> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Tnef-Correlator: Acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 RT-Send-Cc: X-RT-Original-Encoding: us-ascii Content-Length: 1401 Thanks. Ideally that would work similar to mac by using the keyring. I just need to read the documentation on removing the /tmp/krb5cc file as it exploits the entire network for the duration of the ticket life. -----Original Message----- From: Russ Allbery via RT [mailto:rt-comment@krbdev.mit.edu] Sent: Friday, September 30, 2011 12:43 PM To: Shelby, James Subject: Re: [krbdev.mit.edu #6967] Kerberos weakness Shelby@krbdev.mit.edu, James " via RT" writes: > Is there a reason that the current Kerberos allows a KRB5CCNAME file to > be created instead of being in memory? This appears to be a weak link > in the security of the Kerberos protocol as the file can be moved from > system and allow passwordless access to resources the account has access > to. It's nice to be able to share ticket caches between processes (where nice really means "mandatory" for most Kerberos use cases). On Linux, you can use the KEYRING:* ticket cache type, which uses the kernel keyring and may have more of the behavior that you're looking for, although you still have the problem that anyone with access to read the ticket cache can still copy it. Memory ticket caches are of course supported, but aren't widely used because of all the limitations involving passing tickets to subprocesses. -- Russ Allbery (rra@stanford.edu)