[37715] in Kerberos

home help back first fref pref prev next nref lref last post

Re: KEYRING:persistent and ssh

daemon@ATHENA.MIT.EDU (Ken Hornstein)
Wed Sep 28 11:43:42 2016

Message-Id: <201609281543.u8SFhLoD032307@hedwig.cmf.nrl.navy.mil>
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: kerberos@mit.edu
In-Reply-To: <CAPJSo4X8wmpjq1bketqimmn-w8rnKupdTsNnf_innqKSaQX1Bg@mail.gmail.com>
MIME-Version: 1.0
Date: Wed, 28 Sep 2016 11:43:21 -0400
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu

>Storing: Simply on a ram filesystem and use ACLS to tackle it down to
>the list of users who need it. This is pretty much what KEYRING does,
>with a custom nonstandard api.

FWIW, we are going to KEYRING everywhere; the semantics for what you
want in terms of a credential cache store are almost perfect.  What you
DON'T want to do is store credentials on a filesystem (be it in RAM or
on spinning disk); been there, done that.  As for the leaking of information
across chroot/Docker containers ... I'm trying to imagine how that would
be an actual security problem in practice.  I could be proven wrong, of
course, but I'd like to see some more concrete risks here.

--Ken
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

home help back first fref pref prev next nref lref last post