Re: arc4random - are you sure we want these?

["Theodore Ts'o" <tytso@mit.edu>]

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.  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!

Similarly the LTS kernels have gotten backports of Jason's latest
enhancements to the /dev/random driver.  Someone who is using an
out-of-date LTS kernel is similarly likely to be exposed to any number
of zero-day vulnerabilities.  Hence, the primary path that glibc
should be concerned about, IMHO, should assume that getrandom(2) is
(a) secure, and (b) fast.

The other thing to note here is this really is an over-constrained
problem.  Some people will insist, strongly, that they need
cryptographically secure random numbers, above all else.  Others will
insist that the interface for getting secure random numbers must never
block.  Still others will insist that they be able to use the
crappiest CPU's, on systems with absolutely no entropy that can be
harvested from I/O devices, and that they be able to generate mission-
or -life critical cryptgraphic keys milliseconds after the user
removes the consumer grade IOT device from the box, and plugs it into
wall for the first time.

It is ***impossible*** to satisfy all of these constraints.  We do the
best that we can in the kernel, but it's an order of magnitude harder
to do it in userspace.  So unless you want to cop-out by saying,
"arcrandom isn't really secure, so when 10% of all devices reachable
on the internet can breached, don't blame us", I strongly recommend
that you leave things to the kernel.

      		       	  	  - Ted
---
"Remember, the 'S' in IOT stands for security."