Return-Path: Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) by krbdev.mit.edu (Postfix) with ESMTPS id A0D0C3E635 for ; Fri, 30 Sep 2011 14:42:58 -0400 (EDT) Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id BCBDB8498 for ; Fri, 30 Sep 2011 11:42:57 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 714918421 for ; Fri, 30 Sep 2011 11:42:57 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 59E222F4ED; Fri, 30 Sep 2011 11:42:57 -0700 (PDT) From: Russ Allbery To: rt@krbdev.mit.edu Subject: Re: [krbdev.mit.edu #6967] Kerberos weakness In-Reply-To: (Shelby@krbdev.mit.edu's message of "Fri, 30 Sep 2011 13:09:01 -0400 (EDT)") Organization: The Eyrie References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) Date: Fri, 30 Sep 2011 11:42:57 -0700 Message-ID: <87aa9lvpla.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii RT-Send-Cc: X-RT-Original-Encoding: us-ascii Content-Length: 980 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)