On January 15, 2023 2:43 PM D. J. Bernstein wrote: >Ethan Rahn writes: >> - Aren't you relying on filesystem permissions for /run/urandom-ready >> to correctly prevent local attackers from adding that file? > >Yes, exactly. FHS says "/run should not be writable for unprivileged users; it is a >major security problem if any user can write in this directory." > >There are non-FHS systems, but I've checked a bunch of machines and so far >haven't found any where /run---or, to be more portable, /var/run--- is writable by >non-root. > >Even if there are some systems where a regular user can create >/var/run/urandom-ready, the resulting attack would be exactly what OpenSSL >allows currently. Meanwhile this change would close the attack on other systems, >while simplifying the OpenSSL code. > >> - 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? > >No, these boot-script changes would generally be made by sysadmins running >pre-getrandom machines rather than by OS distributions. > >Meanwhile the security issue comes from OpenSSL code that's documented by >OpenSSL as waiting for /dev/random before using /dev/urandom, but that >doesn't achieve this property if an account on the same machine happens to be >running attack code. > >Tomas Mraz writes: >> 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. > >That's my impression, yes, although the mechanism selecting getrandom() isn't >particularly easy to audit. > >Meanwhile there are still many pre-getrandom Linux systems, such as >gcc22 (MIPS, kernel 3.14) in the GCC Compile Farm. My experience is that >embedded systems are split between > > * user-space updates and kernel updates working, > * user-space updates working but kernel updates not working, and > * "updates? what are those?"; > >changes in how OpenSSL treats pre-getrandom kernels will apply to many systems >in the second category. > >> 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. > >Hmmm. Is OpenSSL dropping support for pre-getrandom Linux systems? If so, >then I'd suggest > > * documenting this, > > * blanket disabling the /dev/*random code if __linux is defined, and I think the disable should be applicable to other systems, as with 50-nonstop, which does not have a secure /dev/*random. The latest x86 uses hardware randomization while older ones use PRNGD. So instead of doing this for just __linux, please allow the blanket disable to be configurable, although 50-nonstop derives from the unix template. --Randall
