Hi Lukas!
On Thu, Feb 01, 2024 at 02:52:10PM +0000, Lukas Tribus wrote:
> On Thu, 1 Feb 2024 at 12:08, William Lallemand <wlallem...@haproxy.com> wrote:
> >
> > That's interesting, however I'm surprised the init does not work before the
> > chroot,
> > we are doing a RAND_bytes() with OpenSSL before the chroot to achieve this.
>
> This approach can actually hide chroot issues leading to nasty
> operational issues like "Haproxy 1.8 with OpenSSL 1.1.1-pre4 stops
> working after 1 hour" (see [1] and [2]). It's also not unrealistic to
> cause issue with process management, like FD leaks [3].
>
> Stable OpenSSL on stable OS release branches today use getrandom() and
> not /dev/urandom.
>
> I think using the filesystems for CRNG is a footgun. At least let us
> fail fast and immediately if there is an issue with CRNG seeding from
> chroot.
>
> I consider getrandom() a modern and simple solution to all those problems.
It's not that black and white actually. I pretty well remember that we
had to patch some code (I think it was openssl) in the past to force
to switch back from getrandom() to /dev/urandom, precisely because it
could block (particularly during early boot), while /dev/urandom would
never. It's a bit old, it was around kernel 4.4 I think, and since then
there has been endless discussions on the usual topics of "should a
program work but be less safe or should it fail to protect users against
themselves" and "how to generate a random MAC address on a headless
system when the only entropy source is the network", leading to a debate
around the addition of a GRND_INSECURE flag, but I don't know what the
status is nowadays, especially in LTS distros. I just found an abstract
of this thread here:
https://lwn.net/Articles/800509/
It might be one reason why it's not enabled by default, though I can't
say, really.
Maybe we should *recommend* enabling getrandom, explaining however that
its reliability may vary depending on the OS version and the amount of
entropy sources.
Willy
