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