[37716] in Kerberos
Re: KEYRING:persistent and ssh
daemon@ATHENA.MIT.EDU (Simo Sorce)
Wed Sep 28 13:02:11 2016
Message-ID: <1475082109.3612.79.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Ken Hornstein <kenh@cmf.nrl.navy.mil>
Date: Wed, 28 Sep 2016 13:01:49 -0400
In-Reply-To: <201609281543.u8SFhLoD032307@hedwig.cmf.nrl.navy.mil>
Mime-Version: 1.0
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Wed, 2016-09-28 at 11:43 -0400, Ken Hornstein wrote:
> >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.
It becomes a potential security issue if you run containers as root, but
nobody is doing that in production, right ? Because if you do, the
keyring issue is not the major problem here.
Besides there are various part of the kernel that depends on the keyring
now, disabling it is going to cause hard to diagnose issues or limit the
features you can use.
Simo.
--
Simo Sorce * Red Hat, Inc * New York
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
