Re: arc4random - are you sure we want these?

[Rich Felker <dalias@libc.org>]

On Wed, Jul 27, 2022 at 08:34:17AM -0300, Adhemerval Zanella Netto via Libc-alpha wrote:
> 
> 
> On 26/07/22 22:54, Theodore Ts'o via Libc-alpha wrote:
> > On Mon, Jul 25, 2022 at 02:49:30PM -0400, Rich Felker wrote:
> >>
> >> You can at least try the sysctl and possibly also /dev approaches and
> >> only treat this as fatal as a last resort. If you can inspect
> >> entropy_avail or poll /dev/random to determine that the pool is
> >> initialized this is very safe, I think. And some research on distro
> >> practices might uncover whether this should be believed to be
> >> complete.
> > 
> > I think people are *way* too worried about what happens if /dev/random
> > is symlinked to /dev/urandom, and/or other bits of insanitry.
> 
> On glibc, my view is have settled to have the /dev/urandom fallback,
> mainly to give ancient kernel that we still nominally support a way
> to call arc4random without aborting the process (which seemed to be
> a 'featured' frown upon when someone try to standardize posix_random
> with Austin Group) and to give a fallback if the environment for whatever
> reason filter getrandom.
> 
> But to be realistic newer glibc are usually deployed with newer kernels
> and running on an environment without getrandom support will be highly
> unlikely.  The only scenario that it might happen if someone tries to
> run some container on older kernel (that one reason that prevented us
> to raised minimum supported kernel for x86_64 some years ago), but it
> will most likely have the same issues you described (unless the vendor
> spent an herculean amount of time on backporting).
> 
> The only thing I am kinda worried is we will need to be judicious if
> we aim to use arc4random internally for hardening, since on some pattern

If failure to support the functionality nukes the process, it's not
suitable for internal hardening. Also if it hangs forever in early
boot it's not suitable for internal hardening. AT_RANDOM is the
functionality for internal hardening, which glibc already uses and
should continue to use, extending it with chacha if more bytes are
needed.

Rich