搜索

11.2. 安全性

download PDF

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

Bugzilla:2056884

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 规格一起使用。

Jira:RHEL-1824

Ansible 补救需要额外的集合

ansible-core 软件包替换 Ansible Engine 时,RHEL 订阅提供的 Ansible 模块的列表会减少。因此,运行使用包含在 scap-security-guide 软件包中的 Ansible 内容的补救需要来自 rhc-worker-playbook 软件包的集合。

对于 Ansible 补救,请执行以下步骤:

  1. 安装所需的软件包:

    # dnf install -y ansible-core scap-security-guide rhc-worker-playbook
  2. 进到 /usr/share/scap-security-guide/ansible 目录:

    # cd /usr/share/scap-security-guide/ansible
  3. 运行使用环境变量的相关 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 内容。

Jira:RHEL-1800

Keylime 不接受串联的 PEM 证书

当 Keylime 将证书链作为 PEM 格式的、串联在一个文件中的多个证书接收时,keylime-agent-rust Keylime 组件在签名验证过程中不能正确地使用所有提供的证书,导致 TLS 握手失败。因此,客户端组件(keylime_verifierkeylime_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。

Bugzilla:2064274

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 服务器时,每个规则都会配置一个选项(ClientAliveCountMaxClientAliveInterval),其行为不再像之前一样。因此,当 OpenSSH 达到这些规则配置的超时时,OpenSSH 不再断开空闲的 SSH 用户。作为临时解决方案,这些规则已从 DISA STIG for RHEL 9 和 DISA STIG with GUI for RHEL 9 配置集中临时删除,直到开发出解决方案为止。

Bugzilla:2038978

GnuPG 错误地允许使用 SHA-1 签名,即使通过 crypto-policies 禁止使用 SHA-1 签名

无论系统范围的加密策略中定义的设置如何,GNU Privacy Guard(GnuPG)加密软件可以创建和验证使用 SHA-1 算法的签名。因此,您可以在 DEFAULT 加密策略中将 SHA-1 用于加密目的,这与这个不安全算法的系统范围弃用没有一致的。

要临时解决这个问题,请不要使用涉及 SHA-1 的 GnuPG 选项。因此,您将使用不安全的 SHA-1 签名来防止 GnuPG 降低默认的系统安全性。

Bugzilla:2070722

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

如需了解更多详细信息和临时解决方案,请参阅相关的 知识库文章

Bugzilla:2161499

在 kickstart 安装过程中修复与服务相关的规则可能会失败

在 kickstart 安装过程中,OpenSCAP 工具有时会错误地显示服务的 enabledisable 状态补救不需要。因此,OpenSCAP 可能会将安装的系统上的服务设置为不合规的状态。作为临时解决方案,您可以在 kickstart 安装后扫描并修复该系统。这可以解决与服务相关的问题。

BZ#1834716

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.