Re: [PATCH v43 01/15] Linux Random Number Generator

[Andy Lutomirski]

On Mon, Jan 10, 2022, at 2:19 PM, Jason A. Donenfeld wrote:
> On Mon, Jan 10, 2022 at 9:18 PM Theodore Ts'o <tytso@xxxxxxx> wrote:
>> In general, you need FIPS
>> certification for some specific use cases / application.  For example,
>> if you're going for PCI compliance, then you might only need FIPS
>> compliance for your OpenSSL library.  What the FIPS certification lab
>> might consider acceptable for its entropy for its DRBG is an
>> interesting question.  For some, simply having the OpenSSL library use
>> RDSEED or RDRAND might be sufficient.  Or it could talk to an actual
>> physical RNG device.
>>
>> So disabling getrandom() is probably not necessary, just so long as
>> you can demonstrate that the FIPS cryptographic module --- i.e., the
>> OpenSSL library --- is getting its entropy from an acceptable source.
>
> I don't know exactly what these people think they want, but what you
> say seems probably correct.
>
>> I suspect what's actually going on is that some enterprise customers
>> have FIPS complaince on a check-off list, and they aren't actually
>> getting a formal FIPS certification.  Or they only need something to
>> wave under the noses of their PCI certification company, and so the
>> question is what makes them happy.
>
> Right.
>
>> And this is why some FIPS certification have gotten by just *fine*
>> with a pure userspace OpenSSL library as their FIPS cryptographic
>> module.  Where you draw the line between a "blessed" entropy source
>> and one that's just hand-waving is really at the discretion of the
>> certification lab.
>
> Hah, probably correct.
>
> So, seen this way, and combined with the solution provided at [1] (or
> similar) for people who think they need something there, it seems like
> the FIPS people can likely get what they need without really needing
> to involve the kernel anyway.

Hmm, cute, but I think we can do a bit better. After all, this hack involves trusting a whole lot of code that is *not* intended for secrets to avoid having side channels.

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.

>
> Jason
>
> [1] https://lore.kernel.org/lkml/YdynXjhhuQfbYuSb@xxxxxxxxx/