1 Commits (61f739868ef33afd7586c90dfda3d0ec2feaeddb)

Author	SHA1	Message	Date
Clemens Lang	8b08b372c8	FIPS: Expose explicit indicator from fips.so ... FIPS 140-3 requires us to indicate whether an operation was using approved services or not. The FIPS 140-3 implementation guidelines provide two basic approaches to doing this: implicit indicators, and explicit indicators. Implicit indicators are basically the concept of "if the operation passes, it was approved". We were originally aiming for implicit indicators in our copy of OpenSSL. However, this proved to be a problem, because we wanted to certify a signature service, and FIPS 140-3 requires that a signature service computes the digest to be signed within the boundaries of the FIPS module. Since we were planning to certify fips.so only, this means that EVP_PKEY_sign/EVP_PKEY_verify would have to be blocked. Unfortunately, EVP_SignFinal uses EVP_PKEY_sign internally, but outside of fips.so and thus outside of the FIPS module boundary. This means that using implicit indicators in combination with certifying only fips.so would require us to block both EVP_PKEY_sign and EVP_SignFinal, which are the two APIs currently used by most users of OpenSSL for signatures. EVP_DigestSign would be acceptable, but has only been added in 3.0 and is thus not yet widely used. As a consequence, we've decided to introduce explicit indicators so that EVP_PKEY_sign and EVP_SignFinal can continue to work for now, but FIPS-aware applications can query the explicit indicator to check whether the operation was approved. To avoid affecting the ABI and public API too much, this is implemented as an exported symbol in fips.so and a private header, so applications that wish to use this will have to dlopen(3) fips.so, locate the function using dlsym(3), and then call it. These applications will have to build against the private header in order to use the returned pointer. Modify util/mkdef.pl to support exposing a symbol only for a specific provider identified by its name and path. Signed-off-by: Clemens Lang <cllang@redhat.com> Resolves: rhbz#2087147	2 years ago