Description of problem: In FIPS mode (FIPS mode is crucial in this case), I sometimes see the following AVCs related to /usr/lib64/ossl-modules/fips.so (openssl FIPS provider) on RHEL-9.2 on either s390x or ppc64le. I don't see it on other architectures. rhsmcertd-worker ================ time->Tue Jan 24 09:35:30 2023 type=PROCTITLE msg=audit(1674570930.172:3140): proctitle=2F7573722F62696E2F707974686F6E33002F7573722F6C6962657865632F7268736D63657274642D776F726B6572 type=MMAP msg=audit(1674570930.172:3140): fd=4 flags=0x802 type=SYSCALL msg=audit(1674570930.172:3140): arch=80000016 syscall=90 success=no exit=-13 a0=3ffed56bbf0 a1=cced8 a2=5 a3=802 items=0 ppid=950 pid=518291 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="rhsmcertd-worke" exe="/usr/bin/python3.9" subj=system_u:system_r:rhsmcertd_t:s0 key=(null) type=AVC msg=audit(1674570930.172:3140): avc: denied { map } for pid=518291 comm="rhsmcertd-worke" path="/usr/lib64/ossl-modules/fips.so" dev="dm-0" ino=704333 scontext=system_u:system_r:rhsmcertd_t:s0 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file permissive=0 sshd ==== time->Tue Jan 24 10:22:12 2023 type=PROCTITLE msg=audit(1674573732.153:3204): proctitle=2F7573722F7362696E2F73736864002D44002D52 type=MMAP msg=audit(1674573732.153:3204): fd=3 flags=0x802 type=SYSCALL msg=audit(1674573732.153:3204): arch=c0000015 syscall=90 success=no exit=-13 a0=0 a1=171110 a2=5 a3=802 items=0 ppid=451883 pid=526064 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1674573732.153:3204): avc: denied { map } for pid=526064 comm="sshd" path="/usr/lib64/ossl-modules/fips.so" dev="sda3" ino=1074972814 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:tmp_t:s0 tclass=file permissive=0 Version-Release number of selected component (if applicable): selinux-policy-38.1.4-1.el9 How reproducible: Steps to Reproduce: The following tests seem to be reproducing the problem in FIPS mode: * TC#602893 - /CoreOS/gnutls/Sanity/rngtest * TC#613619 - /CoreOS/openssl/Regression/bz2081378-... $ wow --case 602893 --case 613619 --distro RHEL-9.2.0-20230115.7 --fips --arch s390x --arch ppc64le Actual results: Both tests work fine but there are AVCs (described above). Expected results: No AVC.
What these two denial have in common is that /usr/lib64/ossl-modules/fips.so seems to have the tmp_t type: can you confirm it is a result of enabling fips, or is there any other service/command which handles libraries in this directory? I cannot reproduce it (on an x86 architecture systems) with just # fips-mode-setup --enable
Yes, /usr/lib64/ossl-modules/fips.so is openssl FIPS provider used _only_ in FIPS mode. I cannot reliably reproduce it either but I have a testplan during which these AVCs are triggered with almost 100% probability (but it takes hours to finish). Most likely you would see the AVCs also while using the system in FIPS mode for longer time period. It seems that some application needs to work with this openssl FIPS provider and selinux prevents that. However, I cannot exactly tell what application and why it needs it. Perhaps FIPS folks might shed some more light on it? (adding Dima, Clemens and Hubert to CC)
FIPS provider is automatically activated on OpenSSL initialization when the system is in FIPS mode. So every OpenSSL-based application will try to use it.
tmp_t type sounds incorrect, they should be treated exactly the same as libcrypto.so and libssl.so (same should be the case for legacy.so in the same directory as fips.so)
(In reply to Hubert Kario from comment #7) > tmp_t type sounds incorrect, they should be treated exactly the same as > libcrypto.so and libssl.so > > (same should be the case for legacy.so in the same directory as fips.so) Exactly. Such incorrect labels typically happen when a file is created in /tmp and then moved/copied with preserving attributes. I cannot reproduce it though so I wonder what else is needed, and, since you can see it only on s390x and ppc64le, what makes the difference to e. g. x86_64.
I've just set up a ppc64le system, enabled fips mode and rebooted: # uname -a Linux ibm-p9z-23-lp7.virt.pnr.lab.eng.rdu2.redhat.com 5.14.0-268.kpq0.el9.ppc64le #1 SMP Tue Feb 14 14:50:16 EST 2023 ppc64le ppc64le ppc64le GNU/Linux # fips-mode-setup --check FIPS mode is enabled. # ls -lZa /usr/lib64/ossl-modules/ total 1640 drwxr-xr-x. 2 root root system_u:object_r:lib_t:s0 38 Feb 15 06:59 . dr-xr-xr-x. 64 root root system_u:object_r:lib_t:s0 45056 Feb 15 07:10 .. -rwxr-xr-x. 1 root root system_u:object_r:lib_t:s0 1462456 Feb 8 13:00 fips.so -rwxr-xr-x. 1 root root system_u:object_r:lib_t:s0 135696 Feb 8 13:00 legacy.so # rpm -q selinux-policy selinux-policy-38.1.6-1.el9.noarch It makes me believe it's one of the tests which makes such changes.
If the test makes such changes, it cannot actually modify the fips.so object, though – if it did, the FIPS self-test would fail and OpenSSL would refuse to work. Maybe the test actually tests that, and creates a copy of fips.so in /tmp to do so? Maybe some tool does this implicitly (e.g. objcopy(1)) and then moves the copy over the original file?
Right, I'll try to isolate the bad egg better (by bisecting test plan) and I'll let you know, hopefully. If a test is causing it then it will be NOTABUG. However, I am not convinced about that yet.
Hi, I am closing this bug, feel free to open it, if you have more information.