9.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]
trustdb 中缺失的文件导致拒绝 fapolicyd
当使用 Ansible DISA STIG 配置文件安装了 fapolicyd 时，一个竞争条件导致 trustdb 数据库与 rpmdb 数据库不同步。因此，trustdb 中缺失的文件导致在系统上被拒绝。要临时解决这个问题，请重启 fapolicyd 或再次运行 Ansible DISA STIG 配置文件。
Jira:RHEL-24345[1]
fapolicyd 工具错误地允许执行更改的文件
在对文件进行任何更改后，文件的 IMA 哈希应该正确更新，fapolicyd 应该阻止更改的文件的执行。但是，这不会因为 IMA 策略设置与通过 evctml 程序哈希的文件中的差异而发生。因此，IMA 哈希没有在更改的文件的扩展属性中被更新。因此，fapolicyd 错误地允许更改的文件的执行。
Jira:RHEL-520[1]
openssl 不再创建 X.509 v1 证书
在 RHEL 9.5 中引入的 OpenSSL TLS 工具包 3.2.1 时，您无法使用 openssl CA 工具以 X.509 版本 1 格式创建证书。X.509 v1 格式不符合当前的 Web 要求。
OpenSSH 在身份验证前不再记录超时
OpenSSH 在验证 $IP 端口 $PORT 到日志前不会记录超时。这可能很重要，因为 Fail2Ban 入侵守护进程，而类似的系统在其 mdre-ddos 正则表达式中使用这些日志记录，且不再禁止尝试此类攻击的客户端 IP。目前，这个问题还没有已知的临时解决方案。
默认 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 安装后扫描并修复该系统。这可以解决与服务相关的问题。
Jira:RHELPLAN-44202[1]
FIPS:OSPP 主机的互操作性由于 CNSA 1.0 受到了影响
OSPP 子策略已与 Commercial National Security Algorithm (CNSA) 1.0 保持一致。这影响了使用 FIPS:OSPP 策略-子策略组合的主机的互操作性，以及以下主要方面：
- 最少 RSA 密钥大小强制为 3072 位。
- 算法协商不再支持 AES-128 密码、secp256r1 椭圆曲线和 FFDHE-2048 组。
Jira:RHEL-2735[1]
SELinux 策略中缺少规则阻止了对 SQL 数据库的权限
SELinux 策略中缺少规则阻止了连接到 SQL 数据库。因此，FIDO Device Onboard (FDO)服务 fdo-manufacturing-server.service、fdo-owner-onboarding-server.service 以及 fdo-rendezvous-server.service 无法与 FDO 数据库（如 PostgreSQL 和 SQLite）进行连接。因此，系统无法通过使用支持凭证和其他参数的数据库（如存储所有权凭证）来启动 FDO 。
您可以通过执行以下步骤来临时解决这个问题：
创建一个名为
local_fdo_update.cil的新文件，并输入缺少的 SELinux 策略规则：(allow fdo_t etc_t (file (write))) (allow fdo_t fdo_conf_t (file (append create rename setattr unlink write ))) (allow fdo_t fdo_var_lib_t (dir (add_name remove_name write ))) (allow fdo_t fdo_var_lib_t (file (create setattr unlink write ))) (allow fdo_t krb5_keytab_t (dir (search))) (allow fdo_t postgresql_port_t (tcp_socket (name_connect))) (allow fdo_t sssd_t (unix_stream_socket (connectto))) (allow fdo_t sssd_var_run_t (sock_file (write)))
安装策略模块软件包：
# semodule -i local_fdo_update.cil
因此，FDO 可以与 PostgreSQL 数据库连接，还修复了与 SQLite 在 /var/lib/fdo/ 上权限相关的问题，其中 SQLite 数据库文件应该位于其中。
