update-crypto-policies man page
update-crypto-policies — manage the policies available to the various cryptographic back-ends.
update-crypto-policies(8) is used to set the policy applicable for the various cryptographic back-ends, such as SSL/TLS libraries. That will be the default policy used by these back-ends unless the application user configures them otherwise.
The available policies are restricted to the following profiles.
- LEGACY: ensures maximum compatibility with legacy systems (64-bit security)
- DEFAULT: A reasonable default for today’s standards (80-bit security).
- FUTURE: A level that will provide security on a conservative level that is believed to withstand any near-term future attacks (112-bit security).
- EMPTY: All cryptographic algorithms are disabled (used for debugging only)
The desired system policy is selected in /etc/crypto-policies/config and this tool will generate the individual policy requirements for all back-ends that support such configuration. After this tool is called the administrator is assured that any application that utilizes the supported back-ends will follow a policy that adheres to the configured profile.
Note that the above assurance does apply to the extend that applications are configured to follow the default policy (the details vary on the back-end, see below for more information).
The generated back-end policies will be placed in /etc/crypto-policies/back-ends. Currently the supported back-ends are:
- GnuTLS library
- OpenSSL library
- NSS library
The following options are available in update-crypto-policies tool.
- --show: Shows the currently applied crypto policy
- --is-applied: Returns success if the currently configured policy is already applied.
- --no-check: By default this tool does a sanity check on whether the configured policy is accepted by the supported tools. This option disables those checks.
- --set: Sets the current policy and overwrites the config file.
Applications shipped by Fedora that provide a default configuration file that includes a cryptographic policy string will be modified gradually to support these policies.
When an application provides a configuration file, the changes needed to utilize the system-wide policy are the following.
- Applications using GnuTLS: If an application allows the configuration of cipher priotities via a string, the special priority string "@SYSTEM" should replace any other priority string. Applications which use the default library settings automatically adhere to the policy. Applications following the policy inherit the settings for cipher suite preference, TLS and DTLS protocol versions, allowed elliptic curves, and limits for cryptographic keys.
- Applications using OpenSSL: If an application allows the configuration of ciphersuite string, the special cipher string "PROFILE=SYSTEM" should replace any other cipher string. Applications which use the default library settings automatically adhere to the policy. Applications following the policy inherit the settings for cipher suite preference.
- Applications using NSS: Applications using NSS will load the crypto policies by default. They inherit the settings for cipher suite preference, TLS and DTLS protocol versions, allowed elliptic curves, and limits for cryptographic keys. Note that unlike OpenSSL and GnuTLS, the NSS policy is enforced by default; to prevent applications from adhering to the policy the NSS_IGNORE_SYSTEM_POLICY environment variable must be set to 1 prior to executing that application.
- Applications using Java: No special treatment is required. Applications using Java will load the crypto policies by default. These applications will then inherit the settings for allowed cipher suites, allowed TLS and DTLS protocol versions, allowed elliptic curves, and limits for cryptographic keys. To prevent openjdk applications from adhering to the policy the <java.home>/jre/lib/security/java.security file should be edited to contain security.useSystemPropertiesFile=false. Alternatively one can create a file containing the overridden values for jdk.tls.disabledAlgorithms, jdk.certpath.disabledAlgorithms and pass the location of that file to Java on the command line using the -Djava.security.properties=<path to file>.
- Applications using libkrb5: No special treatment is required. Applications will follow the crypto policies by default. These applications inherit the settings for the permitted encryption types for tickets as well as the cryptographic key limits for the PKINIT protocol. A system-wide opt-out is available by deleting the /etc/krb5.conf.d/crypto-policies link.
- BIND: This application inherits the set of blacklisted algorithms. To opt-out from the policy, remove the policy include directive in the named.conf file.
- OpenSSH: Both server and client application inherits the cipher preferences, the key exchange algorithms as well as the GSSAPI key exchange algorithms. To opt-out from the policy for client, override the global ssh_config with a user-specific configuration in ~/.ssh/config. See ssh_config(5) for more information. To opt-out from the policy for server, uncomment the line containing CRYPTO_POLICY= in /etc/sysconfig/sshd .
One of the supported profiles should be set in /etc/crypto-policies/config and this script should be run afterwards.
In case of a parsing error no policies will be updated.
The file contains the current system policy. It should contain a string of one of the profiles listed above (e.g., DEFAULT).
Contains the generated policies in separated files, and in a format readable by the supported back-ends.
Contains additional files to be appended to the generated policy files. The files present must adhere to $app-XXX.config file naming, where XXX is any arbitrary identifier. For example, to append a line to GnuTLS' generated policy, create a gnutls-extra-line.config file in local.d. This will be appended to the generated gnutls.config during update-crypto-policies.
Written by Nikos Mavrogiannopoulos.