Re: arc4random - are you sure we want these?

[Rich Felker <dalias@libc.org>]

On Tue, Jul 26, 2022 at 09:54:30PM -0400, 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.
> 
> The getrandom(3) system call has been around since v3.17.  That's
> 2014.

Last year I helped someone get musl up and running with EABI userspace
(all we support) on a pre-EABI kernel (2.6.18 or so?) on embedded
hardware in use in the field that could not be upgraded for hardware
support reasons. Assuming post-2014 kernel may be okay for
desktop/server distros but from my perspective it's pretty
unthinkable.

> Even an ancient, obsolete enterprise distro like RHEL 7
> backported the getrandom system call in 2017 --- a full 5 years ago.
> If someone is still using a pre-2017, or $DEITY help them, pre-2014
> kernel, that kernel will be so riddled with zero-day vulnerabilities
> that some fallback to a /dev/urandom at boot time will be the
> ***least*** of their worries from a security perspective.  And that's
> assuming someone who is so hide-bound as to be using a badly obsolete
> kernel would be interested in going to a bleeding edge libc in the
> first place!

There's a huge difference in zero-day vulnerabilities which might
exist nowhere but on a box that's not exposed to the outside world,
and possibly creating compromised key material from said boxes. And
weird embedded stuff that can't be upgraded is *also* the same setting
where you have a complete lack of early boot entropy.

I'm fine with folks who need this stuff coming to musl instead of
glibc, but I think folks on the glibc side are doing right to at least
*consider* whether/how it matters rather than writing anything older
than a few years off as irrelevant.

Rich