URL:
https://github.com/SSSD/sssd/pull/838
Title: #838: FIPS140 compliant usage of PRNG
alexey-tikhonov commented:
"""
In the FIPS case, you need to fail if RAND_bytes() fails; otherwise
you're noncompliant.
That's correct, but only for random numbers used in security relevant functionality.
This is exactly the case with `sss_generate_csprng_buffer()` function, which might be used
in security relevant functionality, thus it fails if `RAND_bytes()` fails.
But `sss_rand()` is not used in security relevant functionality. Hence, I just do not see
a reason to fail instead of fallback to `rand()`.
The reasons to introduce this wrapper are:
(1) it simplifies code as there is no need to call `srand()` explicitly
(2) it reduces amount of covscan complains
(3) usage of better quality PRNG won't hurt even if doesn't make much sense
But I agree it might be good idea to put comments regarding usage restriction in the
header.
And may be I could add `int sss_cs_rand` that would fail instead of fallback. But I am not
eager to do so since it would not be used currently.
If you want to use that in non-FIPS as well, I don't know why
you'd bother with fallback at all - just fail if RAND_bytes() fails.
1) We definitely do not want to check in run time if system is in FIPS mode or not. That
would complicate stuff for no good reason.
2) And what is the reason to fail instead of fallback, if caller doesn't actually need
crypto strong random number? (Be it because of functionality context or because of
"in non-FIPS"). Again, that would complicate function usage for no reason (need
to check return code and handle it appropriately).
getrandom(). Do you actually support any platforms which wouldn't
have it?
IMO, there is just absolutely no sense to prefer `getrandom()` over available
`RAND_bytes()` in our case.
Keep in mind that el7 does support the getrandom syscall(), which is
what we do in krb5 for this reason.
Yes, I have [
this](https://mivehind.net/2017/05/14/please-remove-your-prng/) read.
"""
See the full comment at
https://github.com/SSSD/sssd/pull/838#issuecomment-506759590