KEYRING:persistent and ssh

[Simo Sorce]

On Wed, 2016-09-28 at 22:17 +0200, Cedric Blancher wrote:
> On 28 September 2016 at 19:01, Simo Sorce <simo at redhat.com> wrote:
> > 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.
> 
> That's hard to believe now that AWS and Google clouds have keyring
> support patched out of their kernels (SEL at least), too. Syscalls are
> still there but they all return not supported.

They probably do not need it in their main use cases. But in the VMs you
can run your own kernel so you can use what you like.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York