Hi Ted, On Tue, Jan 11, 2022 at 4:12 AM Theodore Ts'o <tytso@xxxxxxx> wrote: > 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. I agree with you. I think enterprise distros ought to keep doing their own thing here, and there's a clear solution that does this in userspace, and also a pretty non-invasive patch from Marcelo to patch the crap into the kernel need be. I spent some time reading about FIPS certification, compliance, and the requirements of various customers. One thing in particular leapt out at me, which I think you've been saying over and over in this thread but I didn't fully understand until this morning: The goal is generally to have particular pieces of software or particular solutions FIPS certified. And to do this, they start from the top of the stack and move onward down. Most OSS software out there today isn't really FIPS ready and oftentimes a full solution needs modifications in one place or another. Other times, it's enough to plug in the right userspace crypto libraries. And I noticed in looking at things that are FIPS certified that random number generation tends to go through a userspace abstraction layer. And, it looks like these abstraction layers all have FIPS-able RNG hooks. You mentioned OpenSSL earlier, and it looks like even libgcrypt and wolfSSL have an abstraction layer for this. In other words, it's not even so clear that people who need FIPS compliance really need /dev/urandom and such to be FIPS compliant as part of that. And the ones who think they do for whatever security theater nonsense can happily load up that CUSE thing I made, apply a deliberately-downstream patch, or whatever other clever solution. So indeed it really doesn't seem like this is something the kernel needs to be doing. Jason
