On any recent (even not so recent) Linux kernels which have getrandom syscall, it will be used, and the SHM workaround/hack won't be applicable. IMO that SHM workaround was never meant to be perfect and I do not see a reason to further complicate it when it does not apply to contemporary Linux distributions anyway. Tomas Mraz, OpenSSL On Sat, 2023-01-14 at 16:31 -0800, Ethan Rahn wrote: > Dr. Bernstein, > > A couple questions: > > - Aren't you relying on filesystem permissions for /run/urandom-ready > to correctly prevent local attackers from adding that file? > - I'm under the impression that boot scripts for Linux systems are > the responsibility of the distro maintainers to package. Wouldn't > they be the better audience for this request, as well as able to > assess if /run/ would have it's filesystem permissions set properly? > > Cheers, > > Ethan > > On Sat, Jan 14, 2023 at 10:21 AM D. J. Bernstein > <posting-openssl-users@xxxxxxxxxxxx> wrote: > > There are well-known security risks for applications using > > /dev/urandom > > on pre-getrandom Linux systems. OpenSSL addressed this in 1.1.1d > > (after > > preliminary work in 1.1.1c) as follows: > > > > Early start up entropy quality from the DEVRANDOM seed source > > has > > been improved for older Linux systems. The RAND subsystem will > > wait > > for /dev/random to be producing output before seeding from > > /dev/urandom. The seeded state is stored for future library > > initialisations using a system global shared memory segment. > > > > But what happens if an attacker has the ability to run code on the > > same > > machine, under whichever unprivileged account? > > > > I've looked briefly at rand_unix.c and don't see any protection > > against > > the attacker creating shared-memory segment 114. It then doesn't > > seem > > true that the RAND subsystem "will wait for /dev/random to be > > producing > > output": OpenSSL under other accounts will use guessable > > /dev/urandom > > output, for example to create long-term keys. Am I missing > > something? > > > > Of course, one can always _hope_ that attackers can't run code > > locally, > > especially in the early boot stages where /dev/urandom on these > > systems > > is maximally vulnerable. But I'd think that it's safer to have > > OpenSSL > > poll /dev/random if, say, /run/urandom-ready doesn't exist, and to > > recommend adding something like > > > > dd count=1 bs=64 if=/dev/random of=/dev/urandom status=none \ > > && findmnt -t tmpfs -T /run >/dev/null && touch /run/urandom- > > ready > > > > to the boot scripts for Linux systems. > > > > ---D. J. Bernstein -- Tomáš Mráz, OpenSSL
