5.7.4. 安全性

可执行审核监控在符号链接上无法正常工作

由 -w 选项提供的文件监控无法直接跟踪路径。它需要解析到设备的路径以及内节点，才能与已执行程序进行比较。监控可执行符号链接的观察监控将监控设备和符号链接本身的索引节点，而不是内存中执行的程序，这些程序可从符号链接的解析中找到。即使监视解析了符号链接以获取生成的可执行程序，规则也会对从不同符号链接调用的多调用二进制文件触发。这会导致大量日志带有假的正状态。因此，可执行的审计监控符号链接无法正常工作。

/etc/selinux/config 中的SELINUX=disabled 无法正常工作

在 /etc/selinux/config 中使用 SELINUX=disabled 选项禁用 SELinux 会导致内核在启用了 SELinux 的情况下引导，并在稍后的引导过程中切换到禁用模式。这可能导致内存泄漏。

libselinux-python 只能通过其模块提供

libselinux-python 软件包只包含用于开发 SELinux 应用程序的 Python 2 绑定，它用于向后兼容。因此，通过 dnf install libselinux-python 命令，默认的 RHEL 8 软件仓库不再提供 libselinux-python。

UDICA 仅在使用 --env container=podman 启动时才会处理 UBI 8 容器

Red Hat Universal Base Image 8(UBI 8)容器将 container 环境变量设置为 oci 值，而不是 podman 值。这可以防止 udica 工具分析容器 JavaScript 对象表示法(JSON)文件。

删除 rpm-plugin-selinux 软件包会导致从系统中删除所有 selinux-policy 软件包

删除 rpm-plugin-selinux 软件包会禁用机器中的 SELinux。它还会从系统中删除所有 selinux-policy 软件包。重复安装 rpm-plugin-selinux 软件包后会安装 selinux-policy-minimum SELinux 策略，即使之前系统中存在 selinux-policy-targeted 策略。但是，重复安装不会更新 SELinux 配置文件来考虑策略的改变。因此，即使重新安装 rpm-plugin-selinux 软件包也会禁用 SELinux。

SELinux 会阻止 systemd-journal-gatewayd 在由 corosync创建的共享内存文件中调用 newfstatat（）

SELinux 策略不包含允许 systemd-journal-gatewayd 守护进程访问由 corosync 服务创建的文件的规则。因此，SELinux 拒绝 systemd-journal-gatewayd 在由 corosync 创建的共享内存文件中调用 newfstatat（） 功能。

SELinux 会阻止 auditd 停止或关闭系统

SELinux 策略不包含允许 Audit 守护进程启动 power_unit_file_t systemd 单元的规则。因此，在日志记录磁盘分区没有剩余空间的情况下，audit d 也无法停止或关闭系统。

锁定用户可以运行 sudo 命令

在使用 ALL 关键字定义 sudoers 权限的系统中，拥有 权限的 sudo 用户可以作为帐户被锁定的用户运行 sudo 命令。因此，仍然可以使用锁定的和过期的帐号来执行命令。

默认日志设置在性能上的负面影响

默认日志环境设置可能会消耗 4 GB 内存甚至更多，当 systemd-journald 使用 rsyslog 运行时，速率限制值的调整会很复杂。

使用 config.enabled的 rsyslog 输出中参数未知 错误

在 rsyslog 输出中，使用 config.enabled 指令在配置处理错误中出现意外错误。因此，在使用 config.enabled 指令时会显示 参数未知的错误，但 include（） 语句除外。

某些 rsyslog 优先级字符串无法正常工作

对允许精细控制加密的 imtcp 的 GnuTLS 优先级字符串的支持并不完整。因此，以下优先级字符串无法在 rsyslog 中正常工作：

到带有 SHA-1 签名的服务器的连接无法使用 GnuTLS

GnuTLS 安全通讯库以 insecure 形式拒绝 SHA-1 证书签名。因此，使用 GnuTLS 作为 TLS 后端的应用程序无法建立与提供此类证书的对等的 TLS 连接。这个行为与其他系统加密库不一致。要临时解决这个问题，请升级服务器以使用 SHA-256 或更强大的哈希签名的证书，或切换到 LEGACY 策略。

TLS 1.3 在 FIPS 模式中无法在 NSS 中工作

在使用 FIPS 模式的系统中不支持 TLS 1.3。因此，需要 TLS 1.3 进行的连接在以 FIPS 模式工作的系统中无法正常工作。

OpenSSL 错误处理 PKCS #11 tokens 不支持原始 RSA 或 RSA-PSS 签名

OpenSSL 库不会检测到 PKCS #11 令牌的与键相关的功能。因此，当使用不支持原始 RSA 或 RSA-PSS 签名的令牌创建签名时，建立 TLS 连接会失败。

OpenSSL 在 TLS 1.3 中的 CertificateRequest 消息中生成一个不正确的 status_request 扩展

如果启用了 status_request 扩展和基于客户端证书的身份验证，OpenSSL 服务器会在 CertificateRequest 消息中发送错误的 status_request 扩展。在这种情况下，OpenSSL 无法与 RFC 8446 协议兼容的实施互操作。因此，正确验证 CertificateRequest 消息中的扩展的客户端会中止与 OpenSSL 服务器的连接。要临时解决这个问题，在连接两侧禁用对 TLS 1.3 协议的支持，或者禁用对 OpenSSL 服务器上的 status_request 的支持。这将阻止服务器发送错误的消息。

ssh-keyscan 无法在 FIPS 模式中检索服务器的 RSA 密钥

在 FIPS 模式中的 RSA 签名禁用了 SHA-1 算法，这样可防止 ssh-keyscan 工具程序获取在那个模式下运行的服务器的 RSA 密钥。

Libreswan 在所有配置中使用 seccomp=enabled 无法正常工作

Libreswan SECCOMP 支持实施中的允许系统调用集合目前还不完整。因此，当 ipsec.conf 文件中启用 SECCOMP 时，syscall 过滤也会拒绝 pluto 守护进程正常工作所需的 syscalls；守护进程已被终止，ipsec 服务重启。

某些 SSG 中的规则组可能会失败

由于规则及其依赖项未定义，在基准中修复 SCAP 安全指南 (SSG)规则可能会失败。如果需要以特定顺序执行两个或多个规则，例如，当一条规则安装组件和另一个规则配置同一组件时，它们可按错误的顺序运行，并报告错误。要临时解决这个问题，请执行补救两次，第二次运行会修复依赖规则。

SCAP Workbench 无法从定制的配置集生成基于结果的补救方法

当尝试使用SCAP Workbench 工具从自定义配置集生成基于结果的补救角色时，会出现以下错误：

Kickstart 在 RHEL 8 中使用 org_fedora_oscap 而不是 com_redhat_oscap

Kickstart 将 Open Security Content Automation Protocol(OSCAP)Anaconda 附加组件作为 org_fedora_oscap 而不是 com_redhat_oscap 来 引用，这可能会导致混淆。这样做可以保持与 Red Hat Enterprise Linux 7 的向后兼容性。

OSCAP Anaconda Addon 不会在文本模式中安装所有软件包

如果安装以文本模式运行，则 OSCAP Anaconda Addon 插件无法修改为系统安装程序安装而选择的软件包列表。因此，当使用 Kickstart 指定安全策略配置集且安装以文本模式运行时，安全策略所需的附加软件包不会在安装过程中安装。

OSCAP Anaconda Addon 组件无法正确处理自定义配置集

OSCAP Anaconda Addon 插件无法以独立文件中自定义的方式正确处理安全配置集。因此，即使您在对应的 Kickstart 部分正确指定了自定义配置集，RHEL 图形安装中也不会提供自定义配置集。

gnutls 无法恢复使用 NSS 服务器的当前会话

当恢复 TLS（传输层安全）1.3 会话时，GnuTLS 客户端会等待 60 毫秒，加上服务器发送会话恢复数据的预计往返时间。如果服务器没有在此时间内发送恢复数据，客户端会创建一个新的会话，而不是恢复当前会话。这不会造成严重的负面影响，只会对常规会话协商的性能有小的影响。

当使用 --sudo 扫描远程系统时，oscap-ssh 工具会失败

在使用带 --sudo 选项的 oscap-ssh 工具对远程系统执行安全内容自动化协议(SCAP)扫描时，远程系统上的 oscap 工具将扫描结果文件保存并报告到一个临时目录中，以 root 用户身份将文件报告到一个临时目录中。如果远程计算机上的 umask 设置已被更改，oscap-ssh 可能无法访问这些文件。要临时解决这个问题，请修改 oscap-ssh 工具，如本解决方案 "oscap-ssh --sudo" 错误所述，检索 "scp: …​: Permission denied" 错误的结果文件。因此，oscap 会以目标用户身份保存文件，oscap-ssh 会 正常访问这些文件。

OpenSCAP 会在从 YAML 多行字符串中删除空白行时生成假的正数

当 OpenSCAP 从 datastream 中生成 Ansible 修复时，它会从 YAML 多行字符串中删除空白行。由于某些 Ansible 修复包含字面配置文件内容，因此删除空行会影响对应的修复。这会导致 openscap 实用程序无法进行相应的 Open Vulnerability 和评估语言(OVAL)检查，即使空白行没有任何作用。要临时解决这个问题，请检查规则描述并跳过因为缺少空白行而失败的扫描结果。或者，使用 Bash 修复而不是 Ansible 修复，因为 Bash 修复不会生成这些假的正结果。

基于 OSPP 的配置集与 GUI 软件包组不兼容。

服务器安装的 GUI 软件包组的GNOME 软件包需要 nfs-utils 软件包，该软件包与操作系统保护配置集(OSPP)不兼容。因此，在安装带有 OSPP 或 OSPP 配置集的系统（例如安全技术实施指南(STIG)）的过程中，选择 Server with GUI 软件包组。如果在安装后应用了基于 OSPP 的配置集，则系统将无法引导。要临时解决这个问题,请不要在使用 OSPP 配置集和基于 OSPP 的配置集时使用 Server with GUI 或者其它安装 GUI 的组。在使用 Server 或 Minimal Install 软件包组时，系统不会有任何问题并可正常工作。

无法使用 e8 配置集修复 Server with Server with GUI 软件包组的 RHEL8 系统

使用 OpenSCAP Anaconda 附加组件强化 Server with GUI 软件包组上的系统，带配置文件（从 Verify Integrity with RPM 组中选择规则）需要系统中的超大 RAM。这个问题是由 OpenSCAP 扫描程序造成的。如需更多详情，请参阅 扫描大量使用 OpenSCAP 的文件,从而导致系统运行内存不足。因此，使用 RHEL8 Essential Eight(e8)配置集强化系统将无法成功。要临时解决这个问题，请选择一个较小的软件包组，如 Server，并在安装后安装您需要的附加软件包。因此，该系统会使用较少的软件包，扫描需要较少的内存，因此可自动强化该系统。

使用 OpenSCAP 扫描大量文件会导致系统内存不足

OpenSCAP 扫描程序将所有收集的结果存储在内存中，直到扫描完成为止。因此,系统在扫描大量文件时，比如从大软件包组 Server with GUI 和 Workstation 中进行扫描时，系统可能会出现系统没有足够的问题。要临时解决这个问题，在内存较小的系统中，使用较小的软件包组，如 Server 和 Minimal Install。如果您需要使用大的软件包组，测试您的系统在虚拟或临时环境中是否有足够内存。或者，您可以将扫描配置集定制为取消选择涉及整个 / 文件系统递归的规则：