Detections
Analytics

MADB-10-004400 - MariaDB must use NIST FIPS 140-2 validated cryptographic modules for cryptographic operations. - version_ssl_library

Warning! Audit Deprecated

This audit has been deprecated and will be removed in a future update.

View Next Audit Version

Information

Use of weak or not validated cryptographic algorithms undermines the purposes of utilizing encryption and digital signatures to protect data. Weak algorithms can be easily broken and not validated cryptographic modules may not implement algorithms correctly. Unapproved cryptographic modules or algorithms should not be relied on for authentication, confidentiality, or integrity. Weak cryptography could allow an attacker to gain access to and modify data stored in the database as well as the administration settings of the DBMS.

Applications, including DBMSs, utilizing cryptography are required to use approved NIST FIPS 140-2 validated cryptographic modules that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

The security functions validated as part of FIPS 140-2 for cryptographic modules are described in FIPS 140-2 Annex A.

NSA Type-X (where X=1, 2, 3, 4) products are NSA-certified, hardware-based encryption modules.

Solution

If crypto.fips_enabled = 0, for Red Hat Linux, configure the operating system to implement DoD-approved encryption by following the steps below:

To enable strict FIPS compliance, the fips=1 kernel option must be added to the kernel command line during system installation so key generation is done with FIPS-approved algorithms and continuous monitoring tests in place.

Enable FIPS mode with the following command:
# sudo fips-mode-setup --enable

Modify the kernel command line of the current kernel in the 'grub.cfg' file by adding the following option to the GRUB_CMDLINE_LINUX key in the '/etc/default/grub' file and then rebuild the 'grub.cfg' file:
fips=1

Changes to '/etc/default/grub' require rebuilding the 'grub.cfg' file as follows:
On BIOS-based machines, use the following command:
# sudo grub2-mkconfig -o /boot/grub2/grub.cfg

On UEFI-based machines, use the following command:
# sudo grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg

If /boot or /boot/efi reside on separate partitions, the kernel parameter 'boot=<partition of /boot or /boot/efi>' must be added to the kernel command line. Identify a partition by running the df /boot or df /boot/efi command:
# sudo df /boot

Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 495844 53780 416464 12% /boot

To ensure the 'boot=' configuration option will work even if device naming changes occur between boots, identify the universally unique identifier (UUID) of the partition with the following command:
# sudo blkid /dev/sda1
/dev/sda1: UUID='05c000f1-a213-759e-c7a2-f11b7424c797' TYPE='ext4'

For the example above, append the following string to the kernel command line:
boot=UUID=05c000f1-a213-759e-c7a2-f11b7424c797

Reboot the system for the changes to take effect.

More information can be found here:
RedHat: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/chap-federal_standards_and_regulations
Ubuntu: https://security-certs.docs.ubuntu.com/en/fips

See Also

https://dl.dod.cyber.mil/wp-content/uploads/stigs/zip/U_MariaDB_Enterprise_10-x_V1R2_STIG.zip

Item Details

References: CAT|I, CCI|CCI-000803, Rule-ID|SV-253703r841634_rule, STIG-ID|MADB-10-004400, Vuln-ID|V-253703

Plugin: MySQLDB

Control ID: 8533ad4acfc09526152bbc71473849f0d978ed6ca66615b57dd0a4b59c8e1682