Bug 2068458
| Summary: | Allow libkrad to process TCP/IP requests on localhost in FIPS mode [rhel-9.1] | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 9 | Reporter: | Filip Dvorak <fdvorak> | |
| Component: | krb5 | Assignee: | Julien Rische <jrische> | |
| Status: | CLOSED ERRATA | QA Contact: | Filip Dvorak <fdvorak> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | medium | |||
| Version: | 9.0 | CC: | abokovoy, amore, antorres, fdvorak, frenaud, rcritten, ssorce, tscherf | |
| Target Milestone: | rc | Keywords: | Triaged | |
| Target Release: | --- | Flags: | pm-rhel:
mirror+
|
|
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | krb5-1.19.1-20.el9 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 2082189 (view as bug list) | Environment: | ||
| Last Closed: | 2022-11-15 11:11:42 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: | ||||
| Bug Depends On: | 2083699 | |||
| Bug Blocks: | 2082189 | |||
|
Description
Filip Dvorak
2022-03-25 11:28:46 UTC
The problem seems to not be coming from krb5, but from ipa-otpd: tuser: request received tuser: user query start tuser: user query end: uid=tuser,cn=users,cn=accounts,dc=test,dc=ipa tuser: radius query start: cn=tproxy,cn=radiusproxy,dc=test,dc=ipa tuser: radius query end: 127.0.0.1 tuser: forward start: tuser / 127.0.0.1 tuser: forward end: Socket type not supported tuser: response sent: Access-Reject The LDAP queries that ipa-otpd sends to 389ds are completed successfully and present in the logs. The issue probably is the "Socket type not supported" error against FreeRadius. radisud is running but does not receive any request (no logs, even with the -X debugging option). FIPS does not care what the transport is, as long as you are not sending secrets in the clear over the network. 127.* is the same as a Unix socket in this regard, assuming some form of authentication to avoid interception by an untrusted process trying to squat on the receiver end. The OS guarantees in terms of restricting which process can intercept a third party process communications on the same OS are fine, just like for Unix Sockets. Thank you, Simo. So, we would treat localhost-based FreeRADIUS the same as UNIX domain socket in FIPS mode. I prepared a fix[1] for allowing TCP/IP connections, and another one[2] for an issue related to MD5. However, the same issue is happening on the FreeRadius side: The current MD4/5 code[3] for FreeRadius is relying on the "EVP_MD_CTX_FLAG_NON_FIPS_ALLOW" flag to bypass FIPS limitations, but it doesn't work any more[4]. A standalone OpenSSL context loading the "legacy" provider for MD4 and the "default" one for MD5 is now the only way to use MD4/5 on a FIPS-enabled system. [1] https://gitlab.com/jrisc/centos_rpms_krb5/-/commit/b948596f5e7bb722da6abe167e2b29af252d79d5 [2] https://gitlab.com/jrisc/centos_rpms_krb5/-/commit/fd651c1cb210d62740f192e2f74f8e75ba562cee [3] https://gitlab.com/redhat/centos-stream/rpms/freeradius/-/blob/c9s/freeradius-Backport-OpenSSL3-fixes.patch#L483 [4] https://github.com/openssl/openssl/blob/cac250755efd0c40cc6127a0e4baceb8d226c7e3/include/openssl/evp.h#L208 The fix on FreeRadius side has been merged by Antonio[1], we can proceed on our side. [1] https://gitlab.com/redhat/centos-stream/rpms/freeradius/-/merge_requests/22 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 (krb5 bug fix and enhancement update), 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:8271 |