[12101] in Kerberos-V5-bugs
Re: [krbdev.mit.edu #6967] Kerberos weakness
daemon@ATHENA.MIT.EDU (Russ Allbery via RT)
Fri Sep 30 14:43:01 2011
Mail-followup-to: rt@krbdev.mit.edu
mail-copies-to: never
From: "Russ Allbery via RT" <rt-comment@krbdev.MIT.EDU>
In-Reply-To: <rt-6967@krbdev.mit.edu>
Message-ID: <rt-6967-34300.18.4893301135342@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #6967'":;"'AdminCc of krbdev.mit.edu Ticket #6967'":;@MIT.EDU
Date: Fri, 30 Sep 2011 14:42:59 -0400 (EDT)
Reply-To: rt-comment@krbdev.MIT.EDU
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
Shelby@krbdev.mit.edu, James " via RT" <rt-comment@krbdev.mit.edu> 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) <http://www.eyrie.org/~eagle/>
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
