11.6. 安全性
openssl 不检测 PKCS #11 令牌是否支持创建原始 RSA 或 RSA-PSS 签名
TLS 1.3 协议需要支持 RSA-PSS 签名。如果 PKCS #11 令牌不支持原始 RSA 或 RSA-PSS 签名，如果 PKCS #11 令牌持有密钥，使用 OpenSSL 库的服务器应用程序无法使用 RSA 密钥。因此，在上述场景中 TLS 通信会失败。
要临时解决这个问题，请配置服务器和客户端以使用 TLS 版本 1.2 作为可用最高 TLS 协议版本。
(BZ#1681178)
OpenSSL 错误处理 PKCS #11 tokens 不支持原始 RSA 或 RSA-PSS 签名
OpenSSL 库不会检测到 PKCS #11 令牌的与键相关的功能。因此，当使用不支持原始 RSA 或 RSA-PSS 签名的令牌创建签名时，建立 TLS 连接会失败。
要临时解决这个问题，请在 /etc/pki/tls/openssl.cnf 文件的 crypto_policy 部分的 .include 行后面添加以下行：
SignatureAlgorithms = RSA+SHA256:RSA+SHA512:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA512:ECDSA+SHA384 MaxProtocol = TLSv1.2
因此，可以在描述的场景中建立 TLS 连接。
(BZ#1685470)
当使用特定语法时，scp 会让将文件复制到自己的文件
scp 实用程序从安全复制协议 (SCP) 改为更安全的 SSH 文件传输协议 (SFTP)。因此，将文件从位置复制到同一位置，从而擦除文件内容。此问题会产生以下语法：
scp localhost:/myfile localhost:/myfile
要临时解决这个问题，请不要使用这个语法将文件复制到与源位置相同的目标。
这个问题已针对以下语法解决：
-
scp /myfile localhost:/myfile -
scp localhost:~/myfile ~/myfile
PSK 密码suites 无法用于 FUTURE 加密策略
预共享密钥(PSK)密码组合不能被识别为执行完美的转发保密(PFS)密钥交换方法。因此，ECDHE-PSK 和 DHE-PSK 加密套件无法与配置为 SECLEVEL=3 的 OpenSSL 一起工作，例如使用 FUTURE 加密策略。作为临时解决方案，您可以为使用 PSK 密码的应用程序设置限制较低的加密策略或设置较低的安全级别(SECLEVEL)。
GnuPG 错误地允许使用 SHA-1 签名，即使通过 crypto-policies 禁止使用 SHA-1 签名
无论系统范围的加密策略中定义的设置如何，GNU Privacy Guard(GnuPG)加密软件可以创建和验证使用 SHA-1 算法的签名。因此，您可以在 DEFAULT 加密策略中将 SHA-1 用于加密目的，这与这个不安全算法的系统范围弃用没有一致的。
要临时解决这个问题，请不要使用涉及 SHA-1 的 GnuPG 选项。因此，您将使用非安全 SHA-1 签名来防止 GnuPG 降低默认系统安全性。
gpg-agent 在 FIPS 模式中无法作为 SSH 代理工作
当向 ssh-agent 程序添加密钥时，gpg-agent 工具会创建 MD5 指纹，即使 FIPS 模式禁用 MD5 摘要。因此，ssh-add 工具无法将密钥添加到身份验证代理中。
要临时解决这个问题，请在不使用 gpg-agent --daemon --enable-ssh-support 命令的情况下创建 ~/.gnupg/sshcontrol 文件。例如，您可以以 <FINGERPRINT> 0 格式的 gpg --list-keys 命令的输出粘贴到 ~/.gnupg/sshcontrol。因此，gpg-agent 充当 SSH 身份验证代理。
默认 SELinux 策略允许无限制的可执行文件使其堆栈可执行
SELinux 策略中的 selinuxuser_execstack 布尔值的默认状态是 on，这意味着无限制的可执行文件可以使其堆栈为可执行。可执行文件不应该使用这个选项，这通常代表开发的可执行代码的质量较差，或可能存在安全攻击的风险。但是，由于需要与其他工具、软件包和第三方产品保持兼容，红帽无法更改默认策略中的这个布尔值。如果您的环境没有此类兼容性问题，请使用 setsebool -P selinuxuser_execstack off 命令在您的本地策略中将这个布尔值设置为 off。
在 kickstart 安装过程中修复与服务相关的规则可能会失败
在 kickstart 安装过程中，OpenSCAP 工具有时会错误地显示服务的 enable 或disable 状态补救不需要。因此，OpenSCAP 可能会将安装的系统上的服务设置为不合规的状态。作为临时解决方案，您可以在 kickstart 安装后扫描并修复该系统。这可以解决与服务相关的问题。
修正 SCAP 审计规则失败
在修复修复时，对一些与 Audit 配置相关的 SCAP 规则的 Bash 修复不会添加 Audit 密钥。这适用于以下规则：
-
audit_rules_login_events -
audit_rules_login_events_faillock -
audit_rules_login_events_lastlog -
audit_rules_login_events_tallylog -
audit_rules_usergroup_modification -
audit_rules_usergroup_modification_group -
audit_rules_usergroup_modification_gshadow -
audit_rules_usergroup_modification_opasswd -
audit_rules_usergroup_modification_passwd -
audit_rules_usergroup_modification_shadow -
audit_rules_time_watch_localtime -
audit_rules_mac_modification -
audit_rules_networkconfig_modification -
audit_rules_sysadmin_actions -
audit_rules_session_events -
audit_rules_sudoers -
audit_rules_sudoers_d
因此，如果相关的审计规则已经存在，但没有完全符合 OVAL 检查，补救会修复审计规则的功能部分，即路径和访问位，但不添加 Audit 密钥。因此，生成的审计规则可以正常工作，但 SCAP 规则会错误地报告 FAIL。要临时解决这个问题，请手动在审计规则中添加正确的密钥。
STIG 配置文件中的 SSH 超时规则配置了不正确的选项
对 OpenSSH 的更新会影响以下 Defense Information Systems Agency Security Technical Implementation Guide (DISA STIG) 配置集中的规则：
-
DISA STIG for RHEL 9 (
xccdf_org.ssgproject.content_profile_stig) -
DISA STIG with GUI for RHEL 9 (
xccdf_org.ssgproject.content_profile_stig_gui)
在每个配置集中，以下两条规则会受到影响：
Title: Set SSH Client Alive Count Max to zero CCE Identifier: CCE-90271-8 Rule ID: xccdf_org.ssgproject.content_rule_sshd_set_keepalive_0 Title: Set SSH Idle Timeout Interval CCE Identifier: CCE-90811-1 Rule ID: xccdf_org.ssgproject.content_rule_sshd_set_idle_timeout
当应用到 SSH 服务器时，每个规则都会配置一个选项（ClientAliveCountMax 和 ClientAliveInterval），其行为不再像之前一样。因此，当 OpenSSH 达到这些规则配置的超时时，OpenSSH 不再断开空闲的 SSH 用户。作为临时解决方案，这些规则已从 DISA STIG for RHEL 9 和 DISA STIG with GUI for RHEL 9 配置集中临时删除，直到开发出解决方案为止。
在测试访问多个 IMAmeasured 文件的系统时，Keylime 可能会失败
如果运行 Keylime 代理的系统会在快速成功的情况下访问由 Integrity 衡量架构 (IMA) 测量的多个文件，则 Keylime 验证程序可能会错误地处理 IMA 日志添加。因此，运行的哈希值与正确的平台配置 Register (PCR) 状态不匹配，系统会在测试时失败。目前没有临时解决方案。
Keylime 测量的引导策略生成脚本可能会导致分段错误和内核转储
在处理 tpm2_eventlog 工具的输出时，create_mb_refstate 脚本可能会错误地计算 DevicePath 字段中的数据长度，而不是在处理 tpm2_eventlog 工具的输出时使用 LengthOfDevicePath 字段的值。因此，脚本会尝试使用错误计算的长度访问无效的内存，这会导致分段错误和核心转储。Keylime 的主要功能不受此问题的影响，但您可能无法生成测量的引导策略。
要临时解决这个问题，请不要使用测量的引导策略，或使用 tpm2-tools 软件包中的 tpm2_eventlog 工具手动从获取的数据写入策略文件。
有些 TPM 证书会导致 Keylime registrar 崩溃
tenant.conf 中的 require_ek_cert 配置选项应在生产部署中启用，决定 Keylime 租户是否需要来自 Trusted Platform 模块(TPM) 的端到端密钥 (EK) 证书。当执行启用 require_ek_cert 的初始身份报价时，Kelime 会尝试验证代理上的 TPM 设备是否与 Keylime TPM 证书存储中的可信证书进行比较。但是，存储中的某些证书都是格式的 x509 证书，并导致密钥精简注册崩溃。目前，这个问题还没有简单的临时解决方案，除非将 require_ek_cert 设置为 false，并在 ek_check_script 选项中定义自定义脚本，这将执行 EK 验证。
