1991500 – mysql: Port to OpenSSL 3.0 [FIPS]

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1991500 - mysql: Port to OpenSSL 3.0 [FIPS]

Summary: mysql: Port to OpenSSL 3.0 [FIPS]

Keywords:
Status:	CLOSED WONTFIX
Alias:	None
Product:	Red Hat Enterprise Linux 9
Classification:	Red Hat
Component:	mysql
Sub Component:
Version:	9.0
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	beta
Target Release:	---
Assignee:	Michal Schorm
QA Contact:	Jakub Heger
Docs Contact:	Lenka Špačková
URL:
Whiteboard:
Depends On:
Blocks:	1958021
TreeView+	depends on / blocked

Reported:	2021-08-09 09:53 UTC by Honza Horak
Modified:	2023-02-09 07:27 UTC (History)
CC List:	8 users (show)
Fixed In Version:
Doc Type:	Known Issue
Doc Text:	.The `--ssl-fips-mode` option in `MySQL` and `MariaDB` does not change FIPS mode The `--ssl-fips-mode` option in `MySQL` and `MariaDB` in RHEL works differently than in upstream. In RHEL 9, if you use `--ssl-fips-mode` as an argument for the `mysqld` or `mariadbd` daemon, or if you use `ssl-fips-mode` in the `MySQL` or `MariaDB` server configuration files, `--ssl-fips-mode` does not change FIPS mode for these database servers. Instead: * If you set `--ssl-fips-mode` to `ON`, the `mysqld` or `mariadbd` server daemon does not start. * If you set `--ssl-fips-mode` to `OFF` on a FIPS-enabled system, the `mysqld` or `mariadbd` server daemons still run in FIPS mode. This is expected because FIPS mode should be enabled or disabled for the whole RHEL system, not for specific components. Therefore, do not use the `--ssl-fips-mode` option in `MySQL` or `MariaDB` in RHEL. Instead, ensure FIPS mode is enabled on the whole RHEL system: * Preferably, install RHEL with FIPS mode enabled. Enabling FIPS mode during the installation ensures that the system generates all keys with FIPS-approved algorithms and continuous monitoring tests in place. For information about installing RHEL in FIPS mode, see link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/security_hardening/assembly_installing-the-system-in-fips-mode_security-hardening[Installing the system in FIPS mode]. * Alternatively, you can switch FIPS mode for the entire RHEL system by following the procedure in link:https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening#switching-the-system-to-fips-mode_using-the-system-wide-cryptographic-policies[Switching the system to FIPS mode].
Clone Of:
Environment:
Last Closed:	2023-02-09 07:27:47 UTC
Type:	Bug
Target Upstream Version:
Embargoed:
Dependent Products:
Flags:	pm-rhel: mirror+

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Issue Tracker	RHELPLAN-92864	0	None	None	None	2021-08-09 09:55:49 UTC

Description Honza Horak 2021-08-09 09:53:24 UTC

This bug was initially created as a copy of Bug #1952951

I am copying this bug because:

There are some pieces in MySQL that handle FIPS-related code, and we should make clear, that the code is fixed.

More in the original bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1952951#c11

This bug is used to track the FIPS related issues specifically.

Comment 8 Honza Horak 2022-03-30 17:02:28 UTC

The current behavior in RHEL-9, no matter whether FIPS is ON or OFF for the whole system, is this:

#> service mysqld start
Redirecting to /bin/systemctl start mysqld.service
Job for mysqld.service failed because the control process exited with error code.
See "systemctl status mysqld.service" and "journalctl -xeu mysqld.service" for details.

And /var/log/mysql/mysqld.log includes several errors like this:

2022-03-30T17:00:03.926463Z 0 [ERROR] [MY-011272] [Server] SSL fips mode error: error:00000000:lib(0)::reason(0)
2022-03-30T17:00:03.926495Z 0 [ERROR] [MY-013236] [Server] The designated data directory /var/lib/mysql/ is unusable. You can remove all files that the server added to it.
2022-03-30T17:00:03.927199Z 0 [ERROR] [MY-010119] [Server] Aborting

Comment 9 Honza Horak 2022-03-30 17:03:57 UTC

The comment above should also include the information that the behavior is seen after putting "ssl-fips-mode=ON" to the /etc/my.cnf.d/mysql-server.cnf file.

(In reply to Honza Horak from comment #8)
> The current behavior in RHEL-9, no matter whether FIPS is ON or OFF for the
> whole system, is this:
> 
> #> service mysqld start
> Redirecting to /bin/systemctl start mysqld.service
> Job for mysqld.service failed because the control process exited with error
> code.
> See "systemctl status mysqld.service" and "journalctl -xeu mysqld.service"
> for details.
> 
> And /var/log/mysql/mysqld.log includes several errors like this:
> 
> 2022-03-30T17:00:03.926463Z 0 [ERROR] [MY-011272] [Server] SSL fips mode
> error: error:00000000:lib(0)::reason(0)
> 2022-03-30T17:00:03.926495Z 0 [ERROR] [MY-013236] [Server] The designated
> data directory /var/lib/mysql/ is unusable. You can remove all files that
> the server added to it.
> 2022-03-30T17:00:03.927199Z 0 [ERROR] [MY-010119] [Server] Aborting

Comment 10 Honza Horak 2022-03-30 18:30:30 UTC

Another finding:
On FIPS enabled system, when I put "ssl-fips-mode=OFF", it allows the MySQL daemon to start. It's not clear to me whether the FIPS is enforced in that case.

Comment 11 Honza Horak 2022-03-31 06:13:30 UTC

(In reply to Honza Horak from comment #10)
> Another finding:
> On FIPS enabled system, when I put "ssl-fips-mode=OFF", it allows the MySQL
> daemon to start. It's not clear to me whether the FIPS is enforced in that
> case.

Confirmed that the FIPS is still enabled even if "ssl-fips-mode=OFF" is explicitly put into the config file (OFF is actually a default, so putting it explicitly to the config file does not change the configuration value actually):

On FIPS-enabled machine:

[root@kvm-01-guest26 ~]# echo "SHOW SESSION STATUS LIKE 'Ssl_cipher_list';"|mysql -u root -h 127.0.0.1 
Variable_name	Value
Ssl_cipher_list	TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA:AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA

While on non-FIPS machine I get a larger cipher list (not sure how else I could verify that the mysqld daemon is in the FIPS mode or not):

[root@s390x-kvm-063 newcerts]# echo "SHOW SESSION STATUS LIKE 'Ssl_cipher_list';"|mysql -u root -h 127.0.0.1 
Variable_name	Value
Ssl_cipher_list	TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES128-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES256-SHA:CAMELLIA256-SHA:CAMELLIA128-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA

Comment 15 Honza Horak 2022-07-18 15:06:25 UTC

I've put some short text into the Doc Text, but rather inclusing more verbose description that might be needed:

The option --ssl-fips-mode is not encouraged to use in RHEL. FIPS mode is enabled on the whole system and the MySQL and MariaDB database services follow that setting.

However, when the server is started with --ssl-fips-mode option set, the daemon does not behave as documented in the upstream documentation for this configuration option.

When --ssl-fips-mode is used as an argument for mysqld or used in the MySQL or MariaDB server configuration and set to ON, the daemon does not start.

When --ssl-fips-mode is used as an argument for mysqld or used in the MySQL or MariaDB server configuration on a machine with FIPS mode endabled and this configuration option is set to OFF, the daemon does not turn off the FIPS mode for the daemon. Instead, the daemon still runs in the FIPS mode.

Comment 23 RHEL Program Management 2023-02-09 07:27:47 UTC

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.

Note You need to log in before you can comment on or make changes to this bug.