On Fri, 2 Feb 2024 at 08:43, Willy Tarreau <w...@1wt.eu> wrote:
>
> 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.

Right, to behave exactly like /dev/urandom we need GRND_INSECURE.

GRND_INSECURE is in linux 5.6:
https://github.com/torvalds/linux/commit/75551dbf112c992bc6c99a972990b3f272247e23

defined in glibc-2.32:
https://github.com/bminor/glibc/commit/319d2a7b60cc0d06bb5c29684c23475d41a7f8b7

As such it is in RHEL 9, Ubuntu 22.04 LTS and Debian Bookworm (Stable).


There was actually an attempt at making /dev/urandom secure/blocking
in v5.18-rc1, but it didn't last for more than a few days:

https://github.com/torvalds/linux/commit/6f98a4bfee72c22f50aedb39fb761567969865fe
https://github.com/torvalds/linux/commit/0313bc278dac7cd9ce83a8d384581dc043156965
https://github.com/torvalds/linux/commit/48bff1053c172e6c7f340e506027d118147c8b7f



> Maybe we should *recommend* enabling getrandom, explaining however that
> its reliability may vary depending on the OS version and the amount of
> entropy sources.

For the record I think everything in INSTALL is a recommendation,
without any one size fits all.

WolfSSL support in HAProxy is experimental to the point that not only
does it require compiling library and application from source, it also
requires tinkering with LD paths to be able to even start the binary,
so it's not like the INSTALL instructions are "ready to roll" in
production.

I will make a V2 of the patch indicating to either enable getrandom,
mount /dev/[u]random paths into the chroot or disable chroot.


cheers,
Lukas

Reply via email to