Bug 2034320
| Summary: | various services trigger { execmem } denials in FIPS mode | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Alicja Kario <hkario> |
| Component: | openssl | Assignee: | Dmitry Belyavskiy <dbelyavs> |
| Status: | CLOSED ERRATA | QA Contact: | Alicja Kario <hkario> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9.0 | CC: | dbelyavs, fweimer, lvrabec, mmalik, sahana, ssekidde, ssorce |
| Target Milestone: | rc | Keywords: | Triaged |
| Target Release: | 9.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | openssl-3.0.1-4.el9 | Doc Type: | No Doc Update |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-05-17 15:36:34 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Looks like it is non-x86_64 specific. I.e. fails on s390x, aarch64, ppc64le. SELinux Memory Protection Tests: * https://akkadia.org/drepper/selinux-mem.html The execmem permission is nothing that SELinux policy allows without asking, because it is a dangerous operation. annocheck actually falgs this: Hardened: /usr/lib64/ossl-modules/fips.so: FAIL: rwx-seg test because segment has Read, Write and eXecute flags set The build log unfortunately does not show the linker flags. The only unusual thing I can see is the objcopy call. Could you check if the RWE LOAD segment is present even before the objcopy call? Testing can proceed with selinux in permissive mode, so this is not an immediate blocker. However we'd like to find the cause asap so we know how difficult it will be to address it. Without machines to experiment with, my guess is this:
Due to the const volatile specifier, the section is created as:
.section .rodata1,"aw"
That is, it is allocated and writable. This means that the entire segment needs to be writable. On non-x86 targets, -z noseparate-code is the default, so .rodata1 overlaps with .text, and you end up with a RWE load segment. On x86-64, you still lose some security hardening because more data becomes writable.
If that's true, the objcopy doesn't matter: fips.so should be in a bad state before that.
Presumably you added the volatile as a compiler barrier. I suggest to use this instead (completely untested):
extern unsigned char __attribute__ ((visiblity ("hidden"))) fips_hmac_container[32];
__asm(".hidden fips_hmac_container\n\t"
".type fips_hmac_container, %object\n\t"
".size fips_hmac_container, 32\n\t"
".section .rodata.fips_hmac_container,\"a\"\n\t"
".balign 16\n"
"fips_hmac_container:\n\t"
".zero 32\n\t"
".previous");
And switch to .rodata.fips_hmac_container in the objcopy call. This way, you avoid corrupting fips.so in case the toolchain uses .rodata1 for some reason.
This is a part of my downstream patch. I had to use volatile because otherwise there were some problems with moving it to the correct section. I'll try your solution and let you know if I succeed. Unfortnately, I don't get any .rodata.fips_hmac_container in the binary I build. Replacing it back with .rodata1 helps, the necessary section is seen via objdump -t I removed the `volatile` attribute for embedded hmac value. Currently the section attribute is preserved so hopefully the issue will go away. (In reply to Dmitry Belyavskiy from comment #25) > I removed the `volatile` attribute for embedded hmac value. Currently the > section attribute is preserved so hopefully the issue will go away. The volatile was presumably added to avoid constant propagation because the intent is to change the constant under the covers. Yes. Without volatile the variable didn't fit into a requested section, so we couldn't embed the value. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (new packages: openssl), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2022:3900 |
Description of problem: When system is configured to execute in FIPS mode SELinux reports AVC denials for execmem for applications using openssl like sshd, NetworkManager or gssproxy. Version-Release number of selected component (if applicable): selinux-policy-34.1.19-1.el9.noarch openssl-3.0.0-5.el9.x86_64 NetworkManager-1.36.0-0.2.el9.x86_64 How reproducible: always Steps to Reproduce: 1. Install system 2. switch to FIPS mode 3. inspect SELinux logs Actual results: time->Mon Dec 20 11:23:05 2021 type=PROCTITLE msg=audit(1640017385.295:23): proctitle=2F7573722F7362696E2F67737370726F7879002D44 type=SYSCALL msg=audit(1640017385.295:23): arch=80000016 syscall=90 success=no exit=-13 a0=3ffd5b7bbf8 a1=fc1b8 a2=7 a3=802 items=0 ppid=1 pid=1103 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="gssproxy" exe="/usr/sbin/gssproxy" subj=system_u:system_r:gssproxy_t:s0 key=(null) type=AVC msg=audit(1640017385.295:23): avc: denied { execmem } for pid=1103 comm="gssproxy" scontext=system_u:system_r:gssproxy_t:s0 tcontext=system_u:system_r:gssproxy_t:s0 tclass=process permissive=0 ---- time->Mon Dec 20 11:23:05 2021 type=PROCTITLE msg=audit(1640017385.445:29): proctitle=2F7573722F7362696E2F73736864002D44 type=SYSCALL msg=audit(1640017385.445:29): arch=80000016 syscall=90 success=no exit=-13 a0=3ffc077d028 a1=fc1b8 a2=7 a3=802 items=0 ppid=1 pid=1108 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(1640017385.445:29): avc: denied { execmem } for pid=1108 comm="sshd" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tclass=process permissive=0 ---- time->Mon Dec 20 11:23:05 2021 type=PROCTITLE msg=audit(1640017385.565:42): proctitle=2F7573722F7362696E2F4E6574776F726B4D616E61676572002D2D6E6F2D6461656D6F6E type=SYSCALL msg=audit(1640017385.565:42): arch=80000016 syscall=90 success=no exit=-13 a0=3fffbafcb18 a1=fc1b8 a2=7 a3=802 items=0 ppid=1 pid=1067 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="NetworkManager" exe="/usr/sbin/NetworkManager" subj=system_u:system_r:NetworkManager_t:s0 key=(null) type=AVC msg=audit(1640017385.565:42): avc: denied { execmem } for pid=1067 comm="NetworkManager" scontext=system_u:system_r:NetworkManager_t:s0 tcontext=system_u:system_r:NetworkManager_t:s0 tclass=process permissive=0 Expected results: No denials Additional info: This is likely caused because OpenSSL loads and executes the /usr/lib64/ossl-modules/fips.so file that is the FIPS module.