huschi.net

UPDATE-CRYPTO-POLI(8)                                    UPDATE-CRYPTO-POLI(8)
NAME
       update-crypto-policies - manage the policies available to the various
       cryptographic back-ends.
SYNOPSIS
       update-crypto-policies [COMMAND]
DESCRIPTION
       update-crypto-policies(8) is used to set the policy applicable for the
       various cryptographic back-ends, such as SSL/TLS libraries. The policy
       aims to control the back-end default algorithm selections unless the
       application user configures them otherwise.
       The available policies are described in the crypto-policies(7) manual
       page.
       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
       and all the affected applications are restarted, the administrator is
       assured that any application that utilizes the supported back-ends will
       follow the specified policy.
       Note that the above assurance does apply to the extent 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 (and
       directive scopes they respect) are:
       o   GnuTLS library (GnuTLS, SSL, TLS)
       o   OpenSSL library (OpenSSL, SSL, TLS)
       o   NSS library (NSS, SSL, TLS)
       o   OpenJDK (java-tls, SSL, TLS)
       o   Libkrb5 (krb5, kerberos)
       o   BIND (BIND, DNSSec)
       o   OpenSSH (OpenSSH, SSH)
       o   Libreswan (libreswan, IKE, IPSec)
       o   libssh (libssh, SSH)
       Applications and languages which rely on any of these back-ends will
       follow the system policies as well. Examples are apache httpd, nginx,
       php, and others.
       In general after changing the system crypto policies with the
       update-crypto-policies --set command it is recommended to restart the
       system for the effect to fully take place as the policy configuration
       files are loaded on application start-up. Otherwise applications
       started before the command was run need to be restarted to load the
       updated configuration.
COMMANDS
       The following commands are available in update-crypto-policies tool.
       o   --show: Shows the currently applied crypto policy
       o   --is-applied: Returns success if the currently configured policy is
           already applied.
       o   --set: Sets the current policy and overwrites the config file.
OPTIONS
       The following options are available in update-crypto-policies tool.
       o   --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.
       o   --no-reload: By default this tool causes some running applications
           to reload the configured policy. This option skips the reloading.
APPLICATION SUPPORT
       Applications in the operating system 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.
       o   Applications using GnuTLS: If an application allows the
           configuration of cipher priorities 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.
       o   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. By default the OpenSSL
           library reads a configuration file when it is initialized. If the
           application does not override loading of the configuration file,
           the policy also sets the minimum TLS protocol version and default
           cipher suite preference via this file. If the application is
           long-running such as the httpd server it has to be restarted to
           reload the configuration file after policy is changed. Otherwise
           the changed policy cannot take effect.
       o   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.
       o   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 or the system
           property java.security.disableSystemPropertiesFile be set to true.
           Note that the system property java.security.properties is loaded
           with a lower preference than the crypto policies, so you can't use
           this property to override crypto policies without also preventing
           openjdk applications from adhering to the policy.
       o   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.
       o   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.
       o   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 .
       o   Libreswan: Both servers and clients inherit the ESP and IKE
           preferences, if they are not overridden in the connection
           configuration file. Note that due to limitations of libreswan,
           crypto policies is restricted to supporting IKEv2. To opt-out from
           the policy, comment the line including
           /etc/crypto-policies/back-ends/libreswan.config from
           /etc/ipsec.conf.
       o   Applications using libssh: Both client and server applications
           using libssh will load the crypto policies by default. They inherit
           the ciphers, key exchange, message authentication, and signature
           algorithms preferences.
POLICY CONFIGURATION
       One of the supported policies 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.
CUSTOM POLICIES
       The custom policies can take two forms. First form is a full custom
       policy file which is supported by the update-crypto-policies tool in
       the same way as the policies shipped along the tool in the package.
       The second form can be called a subpolicy or policy modifier. This form
       modifies aspects of any base policy file by removing or adding
       algorithms or protocols. The subpolicies can be appended on the
       update-crypto-policies --set command line to the base policy separated
       by the : character. There can be multiple subpolicies appended. The
       resulting configuration is the same as if the policy and subpolicies
       were concatenated together.
       Let's suppose we have subpolicy NO-SHA1 that drops support for SHA1
       hash and subpolicy GOST that enables support for the various algorithms
       specified in Russian GOST standards. You can set the DEFAULT policy
       with disabled SHA1 support and enabled GOST support by running the
       following command:
       update-crypto-policies --set DEFAULT:NO-SHA1:GOST
       This command generates and applies configuration that will be
       modification of the DEFAULT policy with changes specified in the
       NO-SHA1 and GOST subpolicies.
FILES
       /etc/crypto-policies/config
           The file contains the system policy to be applied when
           update-crypto-policies is run without any arguments. It should
           contain a string of one of the policies listed in the
           crypto-policies(7) page (e.g., DEFAULT) or any custom policy name
           with subpolicies separated by the : character. The file is
           overwritten when update-crypto-policies --set is executed.
       /etc/crypto-policies/back-ends
           Contains the generated policies in separated files, and in a format
           readable by the supported back ends.
       /etc/crypto-policies/local.d
           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. Please
           note that because the mechanism just appends a line to the back-end
           configuration the effect varies among the back-ends. For some of
           the back-ends the override fully replaces the original policy and
           for other back-ends the override might not be effective at all.
       /etc/crypto-policies/state/current
           The file contains the current system policy name with eventual
           subpolicies as of the last execution of the update-crypto-policies
           command.
       /etc/crypto-policies/state/CURRENT.pol
           The file contains the current system policy definition with all the
           modifications from eventual subpolicies applied and is written when
           the update-crypto-policies command is executed.
SEE ALSO
       crypto-policies(7), fips-mode-setup(8)
AUTHOR
       Written by Nikos Mavrogiannopoulos.
update-crypto-policies            10/14/2023             UPDATE-CRYPTO-POLI(8)