On Mon, 2018-05-07 at 11:57 -0400, Sam Hartman wrote: > I'm returning from vacation and jumping into the middle of this. > > Back in the day when I wrote the code that became k5_get_os_entropy we > viewed two cases: > > * kadmind. There we're likely to sometimes be generating long-term > shared secrets, and it seemed like strong random numbers were > important. > > * krb5kdc, where we were generating session keys used for a few hours. > > It seems like the change to use the getrandom syscall or other code > changes have moved all the code to prefer strong random numbers. > That seems problematic at startup for the KDC.
There are basically three "strengths" of random numbers available now:
Weak: /dev/urandom
Medium: getrandom(flags=0)
Strong: /dev/random, getrandom(flags=GRND_RANDOM)
k5_get_os_entropy() has switched from weak/strong depending on the
"strong" flag to always medium. I think what you actually want is
medium/strong.
> Even if we do develop a target indicating that the RNG is seeded, do we
> really want to block the KDC starup on waiting for this target?
>
> I see a few issues here:
>
> 1) What's the right behavior for the KDC?
>
> 2) What's the right behavior for kadmind?
>
> 3) Do we want to provide such a service in krb5-kdc or elsewhere?
>
> 4) What do we want to do about stretch? It sounds like we need a fix
> that's small enough that we can backport it to stretch and not make the
> SRMs grumpy.
I'm going to start a discussion on debian-release, as we need to
coordinate a solution across multiple packages.
Jann Horn suggested improving systemd-random-seed.service so that it
actually credits entropy after feeding saved random bits into the RNG.
But this will require some care to ensure we never use the same random
bits twice (including on multiple systems built from the same system
image).
Ben.
--
Ben Hutchings
Life is what happens to you while you're busy making other plans.
- John Lennon
signature.asc
Description: This is a digitally signed message part
