11.2. 安全性
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 协议版本。
Bugzilla:1681178[1]
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 连接。
Bugzilla:1685470[1]
使用特定语法，scp 会清空复制到其自身的文件
scp 实用程序从安全复制协议 (SCP) 改为更安全的 SSH 文件传输协议 (SFTP)。因此，将文件从位置复制到同一位置，从而擦除文件内容。此问题会产生以下语法：
scp localhost:/myfile localhost:/myfile
要临时解决这个问题，请不要使用这个语法将文件复制到与源位置相同的目标。
这个问题已针对以下语法解决：
-
scp /myfile localhost:/myfile -
scp localhost:~/myfile ~/myfile
OSCAP Anaconda 附加组件不会在图形安装中获取定制的配置文件
OSCAP Anaconda 附加组件不提供一个选项，来在 RHEL 图形安装中选择或取消选择安全配置文件的定制。从 RHEL 8.8 开始，当从存档或 RPM 软件包安装时，附加组件不会考虑定制。因此，安装会显示以下出错信息，而不是获取 OSCAP 定制的配置文件：
There was an unexpected problem with the supplied content.
要临时解决这个问题，您必须在 Kickstart 文件的 %addon org_fedora_oscap 部分中指定路径，例如：
xccdf-path = /usr/share/xml/scap/sc_tailoring/ds-combined.xml tailoring-path = /usr/share/xml/scap/sc_tailoring/tailoring-xccdf.xml
因此，您只能将用于 SCAP 定制的配置文件的图形安装与相应的 Kickstart 规格一起使用。
Ansible 补救需要额外的集合
用 ansible-core 软件包替换 Ansible Engine 时，RHEL 订阅提供的 Ansible 模块的列表会减少。因此，运行使用包含在 scap-security-guide 软件包中的 Ansible 内容的补救需要来自 rhc-worker-playbook 软件包的集合。
对于 Ansible 补救，请执行以下步骤：
安装所需的软件包：
# dnf install -y ansible-core scap-security-guide rhc-worker-playbook
进到
/usr/share/scap-security-guide/ansible目录：# cd /usr/share/scap-security-guide/ansible
运行使用环境变量的相关 Ansible playbook，这些变量定义了到额外 Ansible 集合的路径：
# ANSIBLE_COLLECTIONS_PATH=/usr/share/rhc-worker-playbook/ansible/collections/ansible_collections/ ansible-playbook -c local -i localhost, rhel9-playbook-cis_server_l1.yml将
cis_server_l1替换为您要修复系统的配置文件的 ID。
因此，Ansible 内容会被正确处理。
对 rhc-worker-playbook 中提供的集合的支持仅限于启用 scap-security-guide 中提供的 Ansible 内容。
Keylime 不接受串联的 PEM 证书
当 Keylime 将证书链作为 PEM 格式的、串联在一个文件中的多个证书接收时，keylime-agent-rust Keylime 组件在签名验证过程中不能正确地使用所有提供的证书，导致 TLS 握手失败。因此，客户端组件(keylime_verifier 和 keylime_tenant)无法连接到 Keylime 代理。要临时解决这个问题，请只使用一个证书而不是多个证书。
Jira:RHELPLAN-157225[1]
Keylime 拒绝其摘要以反斜杠开头的运行时策略
生成运行时策略的当前脚本 create_runtime_policy.sh，使用 SHA 校验函数，如 sha256sum ，来计算文件摘要。但是，当输入的文件名包含反斜杠或 \n 时，校验和函数会在其输出中的摘要前添加一个反斜杠。在这种情况下，生成的策略文件的格式不正确。提供错误格式的策略文件时，Keylime 租户会产生以下或类似错误消息：me.tenant - ERROR - Response code 400: Runtime policy is malformat。要临时解决这个问题，请通过输入以下命令从错误格式的策略文件中手动删除反斜杠：sed -i 's/^\\//g' <malformed_file_name>。
Jira:RHEL-11867[1]
更新后，Keylime 代理拒绝来自验证器的请求
当 Keylime 代理的 API 版本号(keylime-agent-rust)已更新时，代理会拒绝使用不同版本的请求。因此，如果 Keylime 代理被添加到验证器中，然后被更新，则验证器会尝试使用旧的 API 版本联系代理。代理拒绝此请求并使认证失败。要临时解决这个问题，请在更新代理(keylime-agent-rust)前更新验证器(keylime-verifier) 。因此，当代理被更新时，verifier 会检测 API 更改，并相应地更新其存储的数据。
Jira:RHEL-1518[1]
fapolicyd 工具错误地允许执行更改的文件
在对文件进行任何更改后，文件的 IMA 哈希应该可以正确地更新，fapolicyd 应该阻止更改的文件的执行。但是，由于 IMA 策略设置和 evctml 进行哈希的文件中的区别，这不会发生。因此，IMA 哈希在更改的文件的扩展属性中不会被更新。因此，fapolicyd 错误地允许更改的文件的执行。
Jira:RHEL-520[1]
默认 SELinux 策略允许无限制的可执行文件使其堆栈可执行
SELinux 策略中的 selinuxuser_execstack 布尔值的默认状态是 on，这意味着无限制的可执行文件可以使其堆栈为可执行。可执行文件不应该使用这个选项，这通常代表开发的可执行代码的质量较差，或可能存在安全攻击的风险。但是，由于需要与其他工具、软件包和第三方产品保持兼容，红帽无法更改默认策略中的这个布尔值。如果您的环境没有此类兼容性问题，请使用 setsebool -P selinuxuser_execstack off 命令在您的本地策略中将这个布尔值设置为 off。
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 配置集中临时删除，直到开发出解决方案为止。
GnuPG 错误地允许使用 SHA-1 签名，即使通过 crypto-policies 禁止使用 SHA-1 签名
无论系统范围的加密策略中定义的设置如何，GNU Privacy Guard(GnuPG)加密软件可以创建和验证使用 SHA-1 算法的签名。因此，您可以在 DEFAULT 加密策略中将 SHA-1 用于加密目的，这与这个不安全算法的系统范围弃用没有一致的。
要临时解决这个问题，请不要使用涉及 SHA-1 的 GnuPG 选项。因此，您将使用不安全的 SHA-1 签名来防止 GnuPG 降低默认的系统安全性。
OpenSCAP 内存消耗问题
在内存有限的系统上，OpenSCAP 扫描程序可能过早停止，或者可能没有生成结果文件。要临时解决这个问题，您可以自定义扫描配置文件，以取消选择涉及递归整个 / 文件系统的规则：
-
rpm_verify_hashes -
rpm_verify_permissions -
rpm_verify_ownership -
file_permissions_unauthorized_world_writable -
no_files_unowned_by_user -
dir_perms_world_writable_system_owned -
file_permissions_unauthorized_suid -
file_permissions_unauthorized_sgid -
file_permissions_ungroupowned -
dir_perms_world_writable_sticky_bits
如需了解更多详细信息和临时解决方案，请参阅相关的 知识库文章。
在 kickstart 安装过程中修复与服务相关的规则可能会失败
在 kickstart 安装过程中，OpenSCAP 工具有时会错误地显示服务的 enable 或disable 状态补救不需要。因此，OpenSCAP 可能会将安装的系统上的服务设置为不合规的状态。作为临时解决方案，您可以在 kickstart 安装后扫描并修复该系统。这可以解决与服务相关的问题。
