search

ComplianceAsCode / content

Security automation content in SCAP, Bash, Ansible, and other formats
https://complianceascode.readthedocs.io/en/latest/
Other
2.21k stars 697 forks source link

Rule configure_gnutls_tls_crypto_policy doesn't work with the new gnutls.config file format #9385

Open jan-cerny opened 2 years ago

jan-cerny commented 2 years ago

Description of problem:

Rule configure_gnutls_tls_crypto_policy expects the old format for /etc/crypto-policies/back-ends/gnutls.config that was present in RHEL 8.

On RHEL 8, it looks like this:

[root@ci-vm-10-0-138-135 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux release 8.6 (Ootpa)
[root@ci-vm-10-0-138-135 ~]# rpm -q crypto-policies
crypto-policies-20211116-1.gitae470d6.el8.noarch
[root@ci-vm-10-0-138-135 ~]# cat /etc/crypto-policies/back-ends/gnutls.config
SYSTEM=NONE:+MAC-ALL:-MD5:+GROUP-ALL:+SIGN-ALL:-SIGN-RSA-MD5:-SIGN-DSA-SHA1:-SIGN-DSA-SHA224:-SIGN-DSA-SHA256:-SIGN-DSA-SHA384:-SIGN-DSA-SHA512:+SIGN-RSA-SHA1:%VERIFY_ALLOW_SIGN_WITH_SHA1:+CIPHER-ALL:-CAMELLIA-256-GCM:-CAMELLIA-128-GCM:-CAMELLIA-256-CBC:-CAMELLIA-128-CBC:-3DES-CBC:-ARCFOUR-128:+ECDHE-RSA:+ECDHE-ECDSA:+RSA:+DHE-RSA:+VERS-ALL:-VERS-DTLS0.9:-VERS-TLS1.1:-VERS-TLS1.0:-VERS-SSL3.0:-VERS-DTLS1.0:+COMP-NULL:%PROFILE_MEDIUM

However, on RHEL 9, it looks like this:

[root@ci-vm-10-0-139-157 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux release 9.0 (Plow)
[root@ci-vm-10-0-139-157 ~]# rpm -q crypto-policies
crypto-policies-20220223-1.git5203b41.el9_0.1.noarch
[root@ci-vm-10-0-139-157 ~]# cat /etc/crypto-policies/back-ends/gnutls.config
[global]
override-mode = allowlist

[overrides]
secure-hash = SHA256
secure-hash = SHA384
secure-hash = SHA512
secure-hash = SHA3-256
secure-hash = SHA3-384
secure-hash = SHA3-512
secure-hash = SHA224
secure-hash = SHA3-224
secure-hash = SHAKE-256
tls-enabled-mac = AEAD
tls-enabled-mac = SHA1
tls-enabled-mac = SHA512
tls-enabled-group = GROUP-X25519
tls-enabled-group = GROUP-X448
tls-enabled-group = GROUP-SECP256R1
tls-enabled-group = GROUP-SECP384R1
tls-enabled-group = GROUP-SECP521R1
tls-enabled-group = GROUP-FFDHE2048
tls-enabled-group = GROUP-FFDHE3072
tls-enabled-group = GROUP-FFDHE4096
tls-enabled-group = GROUP-FFDHE6144
tls-enabled-group = GROUP-FFDHE8192
secure-sig = ECDSA-SHA3-256
secure-sig = ECDSA-SHA256
secure-sig = ECDSA-SECP256R1-SHA256
secure-sig = ECDSA-SHA3-384
secure-sig = ECDSA-SHA384
secure-sig = ECDSA-SECP384R1-SHA384
secure-sig = ECDSA-SHA3-512
secure-sig = ECDSA-SHA512
secure-sig = ECDSA-SECP521R1-SHA512
secure-sig = EdDSA-Ed25519
secure-sig = EdDSA-Ed448
secure-sig = RSA-PSS-SHA256
secure-sig = RSA-PSS-SHA384
secure-sig = RSA-PSS-SHA512
secure-sig = RSA-PSS-RSAE-SHA256
secure-sig = RSA-PSS-RSAE-SHA384
secure-sig = RSA-PSS-RSAE-SHA512
secure-sig = RSA-SHA3-256
secure-sig = RSA-SHA256
secure-sig = RSA-SHA3-384
secure-sig = RSA-SHA384
secure-sig = RSA-SHA3-512
secure-sig = RSA-SHA512
secure-sig = ECDSA-SHA224
secure-sig = RSA-SHA224
secure-sig = ECDSA-SHA3-224
secure-sig = RSA-SHA3-224
secure-sig-for-cert = ECDSA-SHA3-256
secure-sig-for-cert = ECDSA-SHA256
secure-sig-for-cert = ECDSA-SECP256R1-SHA256
secure-sig-for-cert = ECDSA-SHA3-384
secure-sig-for-cert = ECDSA-SHA384
secure-sig-for-cert = ECDSA-SECP384R1-SHA384
secure-sig-for-cert = ECDSA-SHA3-512
secure-sig-for-cert = ECDSA-SHA512
secure-sig-for-cert = ECDSA-SECP521R1-SHA512
secure-sig-for-cert = EdDSA-Ed25519
secure-sig-for-cert = EdDSA-Ed448
secure-sig-for-cert = RSA-PSS-SHA256
secure-sig-for-cert = RSA-PSS-SHA384
secure-sig-for-cert = RSA-PSS-SHA512
secure-sig-for-cert = RSA-PSS-RSAE-SHA256
secure-sig-for-cert = RSA-PSS-RSAE-SHA384
secure-sig-for-cert = RSA-PSS-RSAE-SHA512
secure-sig-for-cert = RSA-SHA3-256
secure-sig-for-cert = RSA-SHA256
secure-sig-for-cert = RSA-SHA3-384
secure-sig-for-cert = RSA-SHA384
secure-sig-for-cert = RSA-SHA3-512
secure-sig-for-cert = RSA-SHA512
secure-sig-for-cert = ECDSA-SHA224
secure-sig-for-cert = RSA-SHA224
secure-sig-for-cert = ECDSA-SHA3-224
secure-sig-for-cert = RSA-SHA3-224
enabled-curve = X25519
enabled-curve = X448
enabled-curve = SECP256R1
enabled-curve = SECP384R1
enabled-curve = SECP521R1
enabled-curve = Ed25519
enabled-curve = Ed448
tls-enabled-cipher = AES-256-GCM
tls-enabled-cipher = AES-256-CCM
tls-enabled-cipher = CHACHA20-POLY1305
tls-enabled-cipher = AES-256-CBC
tls-enabled-cipher = AES-128-GCM
tls-enabled-cipher = AES-128-CCM
tls-enabled-cipher = AES-128-CBC
tls-enabled-kx = ECDHE-RSA
tls-enabled-kx = ECDHE-ECDSA
tls-enabled-kx = RSA
tls-enabled-kx = DHE-RSA
enabled-version = TLS1.3
enabled-version = TLS1.2
enabled-version = DTLS1.2
min-verification-profile = medium

[priorities]
SYSTEM=NONE
[root@ci-vm-10-0-139-157 ~]#

The rule expects the RHEL8 related format, it says:

Crypto Policies provide a centralized control over crypto algorithms usage of many packages. GnuTLS is supported by system crypto policy, but the GnuTLS configuration may be set up to ignore it. To check that Crypto Policies settings are configured correctly, ensure that /etc/crypto-policies/back-ends/gnutls.config contains the following line and is not commented out: +VERS-ALL:-VERS-DTLS0.9:-VERS-SSL3.0:-VERS-TLS1.0:-VERS-TLS1.1:-VERS-DTLS1.0

During a remediation of a STIG profile, this causes that the /etc/crypto-policies/back-ends/gnutls.config is remediated to the old version and then the rule rpm_verify_hashes fails because a file owned by the crypto-policies rpm package changed.

We can see this problem very often in the testing farm CI jobs executed on CS 9 that are triggered by our PRs, for example: https://artifacts.dev.testing-farm.io/ff0ddbe2-cba3-4b6b-806e-5a8dcc176fcc/

SCAP Security Guide Version:

current upstream head as of 2022-08-03 as of HEAD cedbd31ab378a0024e055656d81df2a00c2be117

Operating System Version:

9

Steps to Reproduce:

  1. open rule linux_os/guide/system/software/integrity/crypto/configure_gnutls_tls_crypto_policy/rule.yml and review its OVAL and remediations
  2. compare that with /etc/crypto-policies/back-ends/gnutls.config on RHEL 9

Actual Results:

rule uses the old gnutls.config format and remediates the system to use the old gnutls.config format

Expected Results:

rule uses the new gnutls.config format and doesn't conflict with rule rpm_verify_permissions

Additional Information/Debugging Steps:

https://github.com/ComplianceAsCode/content/issues/7279

ggbecker commented 2 years ago

I think that the problem with the rpm_verify_hashes happens because the file /etc/crypto-policies/back-ends/gnutls.config will point to the crypto policy defined in the system. In the following case the DEFAULT crypto policy is being used.

# update-crypto-policies --show
DEFAULT

# ls -la /etc/crypto-policies/back-ends/gnutls.config
lrwxrwxrwx. 1 root root 45 Sep  6 09:22 /etc/crypto-policies/back-ends/gnutls.config -> /usr/share/crypto-policies/DEFAULT/gnutls.txt

The only way I see avoiding this problem is to copy the file from the desired crypto policy first and then modifying it.

jan-cerny commented 2 years ago

so basically we have 2 different problems here:

  1. new format
  2. modification of a package-owned file