On Mon, Jan 10, 2022 at 05:44:03PM -0800, Andy Lutomirski wrote: > > So let’s solve it for real. Have a driver (in a module) that > exposes a /dev/urandom compatible interface to the CryptoAPI DRBG. > We can do a really nice job of it, and maybe it’ll be 100 lines of > code. People can do whatever they like with it in their container > manager or boot scripts. And if it has a problem (where it’s *less* > secure than the real urandom), we can say “I told you so”. > > We can go one step farther: add an LSM hook to getrandom(). Then > someone can hack up a fips_t policy for SELinux that turns off > getrandom. These are both dangerous. The first means creating a new device node which effectively is /dev/drbg-random which could be bind mounted or mknod'ed to be /dev/urandom. But if the user boots a kernel that doesn't support this new device node, it will mean opening /dev/urandom will get ENODEV. Similarly, getrandom(2) never fails. By allowing a SELinux policy to force it to fail with ENOSYS, or some other error, it means exposing userspace code to a failure path that may not be as well tested. Sure, *sane* code might fall back to opening /dev/urandom; but the whole point of getrandom(2) was that it was a dumb, stupid interface interface that could be safely used by application programmers. Not paranoid OS crypto engineers that carefully check the error returns of all system calls, with appropriate fallbacks and making sure that code always "fails safe". Right now, the enterprise distros are doing their own thing, and quite frankly, I don't see a problem with that. If it turns out DRBG is less secure (and there are some things that fill me with disquiet), then let them take the economic consequences, since they are the ones who are doing this for the economic advantages of trying to claim FIPS compliance. If we must support this in the upstream kernel, then configure it via CONFIG_RANDOM_SECURITY_THEATRE which redirects getrandom(2) and /dev/[u]random to DRBG. I'd prefer that it be possible for someone to put "random_security_theatre=0" on the boot command line which would disable redirecting the interfaces to DRBG so if it turns out that DRBG *is* less secure, we can give advice on how to turn it off without requiring a patched kernel. :-) - Ted