安全强化

来源：官方文档 原始多页入口：安全强化 内容规模：约 164,100 字符，129 个章节标题，397 个命令/代码块，63 条提示框

阅读提要

• 副标题：增强 Red Hat Enterprise Linux 10 系统的安全性
• 摘要：了解保护 Red Hat Enterprise Linux 服务器和工作站免受本地和远程入侵、利用和恶意活动的流程和实践。通过使用这些方法和工具，您可以为数据中心、工作场所和家创建更安全的计算环境。
• 主要章节：增强 Red Hat Enterprise Linux 10 系统的安全性；对红帽文档提供反馈；第 1 章 将 RHEL 切换到 FIPS 模式；第 2 章 使用系统范围的加密策略；第 3 章 通过 PKCS#11 将应用程序配置为使用加密硬件；第 4 章 使用 polkit 控制对智能卡的访问；第 5 章 扫描系统以检查配置是否合规；第 6 章 使用 Keylime 确保系统完整性；第 7 章 使用 AIDE 检查完整性；第 8 章 管理 sudo 访问；第 9 章 使用基于策略的解密配置加密卷的自动解锁；第 10 章 使用 fapolicyd 阻止和允许应用程序
• 推荐阅读顺序：先看“阅读提要”和目录，再按章节查看“关键点/命令/注意”；需要原文细节时点击来源链接。

章节笔记

概览

• 该章节主要为下一级主题的入口。

增强 Red Hat Enterprise Linux 10 系统的安全性

• 要点：摘要

对红帽文档提供反馈

• 要点：我们致力于为您提供高质量的文档，您的反馈将对我们有很大帮助。为帮助我们改进，您可以通过 Red Hat Jira 跟踪系统提交建议或报告错误。
• 要点：流程
• 列表：登录到 Jira 网站。 如果您还没有帐户，请创建一个。
• 列表：单击顶部导航栏中的 Create。
• 列表：在 Summary 字段中输入描述性标题。
• 列表：在 Description 字段中输入您对改进的建议。包括文档相关部分的链接。
• 列表：点窗口底部的 Create。

第 1 章 将 RHEL 切换到 FIPS 模式

• 要点：要启用联邦信息处理标准(FIPS) 140-3 强制的加密模块自我检查，您必须在 FIPS 模式下操作 RHEL 10。将系统切换到 FIPS 模式的唯一方法是在 RHEL 安装过程中启用它。
• 要点：Red Hat Enterprise Linux 10 不支持在安装后将系统切换到 FIPS 模式。特别是，设置 FIPS 系统范围的加密策略不足以启用 FIPS 模式，并保证遵守 FIPS 140 标准。使用 FIPS 策略启用 FIPS 模式的 fips-mode-setup 工具已从 RHEL 中删除。

1.1. 联邦信息处理标准 140 和 FIPS 模式

• 要点：Federal Information Processing Standard (FIPS) 140 是指定加密模块安全性的政府标准。FIPS 模式为合规性启用所需的自我检查。
• 要点：FIPS出版物140是由国家标准与技术研究所（NIST）制定的一系列计算机安全标准。保证了密码模块的质量。FIPS 140 标准确保加密工具正确实现其算法。运行时密码算法和完整性自测试是确保系统使用符合规定的密码的一些机制。

1.1.1. FIPS 模式下的 RHEL

• 要点：要确保 RHEL 系统只生成并使用所有带有 FIPS 批准的算法的加密密钥，您必须将 RHEL 切换到 FIPS 模式。
• 要点：要启用 FIPS 模式，请在 FIPS 模式下开始安装。这样可以避免在转换已部署的系统时加密密钥材料的再生和合规性重新评估。另外，根据 FIPS 模式来更改其算法选择的组件会选择正确的算法。例如，LUKS 磁盘加密在 FIPS 模式下安装期间使用 PBKDF2 密钥派生函数 (KDF)。否则，它会选择非 FIPS 兼容的 Argon2 KDF。因此，在安装后切换到 FIPS 模式时，带有磁盘加密的非 FIPS 安装不符合或可能无法引导。

1.1.2. FIPS 模式状态

• 要点：FIPS 模式是否启用了是由内核命令行上的 fips=1 引导选项决定的。如果没有使用 update-crypto- policies --set FIPS 命令明确设置，系统范围的加密策略会自动遵循此设置。带有 /boot 单独分区的系统还需要 boot=UUID=<uuid-of-boot-disk> 内核命令行参数。在 FIPS 模式下启动时，安装程序会执行所需的更改。
• 要点：FIPS 模式所需的限制的强制执行取决于 /proc/sys/crypto/fips_enabled 文件的内容。如果文件包含 1，RHEL 核心加密组件切换到模式，在此模式下，它们只使用 FIPS 批准的加密算法的实现。如果 /proc/sys/crypto/fips_enabled 包含 0 ，则加密组件不会启用其 FIPS 模式。

1.1.3. 加密策略中的 FIPS

• 要点：FIPS 系统范围的加密策略可帮助配置更高级别的限制。支持加密灵活性的通信协议不会在选择时宣布系统拒绝的密码。例如，ChaCha20算法未经FIPS批准。FIPS 加密策略确保 TLS 服务器和客户端不会宣布 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS 密码套件，因为任何尝试使用它都失败。
• 要点：如果您在 FIPS 模式下操作 RHEL，并使用提供其自己的与 FIPS 模式相关的配置选项的应用程序，请忽略这些选项和相应的应用程序指导。运行在 FIPS 模式下的系统，系统范围的加密策略只强制执行遵守 FIPS 的加密。例如，不支持 Node.js --enable-fips 和 --force-fips 选项。不要使用这些选项。在 RHEL 中，Node.js 遵循系统 FIPS 模式，并使用 RHEL 提供的 FIPS 认证的 OpenSSL 库。使用这些选项会导致 Node.js 以 explanatory 错误消息退出，无论系统是否以 FIPS 模式运行。

1.1.4. RHEL 10.0 OpenSSL FIPS 指标

• 要点：因为 RHEL 在 OpenSSL 上游引入 OpenSSL FIPS 指标之前引入了它，且两种设计有所不同，所以指标可能会在将来的 RHEL 10 次版本中有所变化。在可能使用上游 API 后，RHEL 10.0 指标可能会返回一个错误消息 "unsupported" ，而不是结果。详情请查看 OpenSSL FIPS Indicators GitHub 文档。
• 要点：其他资源
• 列表：FIPS - 联邦信息处理标准（红帽客户门户网站）
• 列表：产品合规性（红帽客户门户）
• 列表：RHEL 系统范围的加密策略
• 列表：NIST 计算机安全资源中心的 FIPS 出版物
• 列表：联邦信息处理标准出版物：FIPS 140-3 (NIST)
• 列表：openssl FIPS Indicators (Github)
• 注意：注意 有关 RHEL 10 加密模块根据 FIPS 140-3 要求的认证状态，请参阅产品合规性红帽客户门户页面。要求由美国国家标准与技术研究所(NIST)密码模块验证计划(CMVP)定义。查找 FIPS - 联邦信息处理标准部分。

1.2. 安装启用了 FIPS 模式的系统

• 要点：要启用联邦信息处理标准(FIPS) 140 强制的加密模块自我检查，请在 Red Hat Enterprise Linux 系统安装过程中启用 FIPS 模式。
• 要点：流程
• 列表：在系统安装开始时，当 Red Hat Enterprise Linux 引导窗口打开并显示可用的引导选项时，将 fips=1 选项添加到内核命令行中。 在 UEFI 系统上，按 e 键，将光标移至 linuxefi 内核命令行的末尾，将 fips=1 添加到此行的末尾，例如： linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=RHEL-10-0-BaseOS-x86_64 rd.live.\ check quiet fips=1 在 BIOS 系统上，按 Tab 键，将光标移至内核命令行的末尾，并将 fips=1 添加到此行的末尾，例如： > vmlinuz initrd=…
• 列表：在 UEFI 系统上，按 e 键，将光标移至 linuxefi 内核命令行的末尾，将 fips=1 添加到此行的末尾，例如： linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=RHEL-10-0-BaseOS-x86_64 rd.live.\ check quiet fips=1
• 列表：在 BIOS 系统上，按 Tab 键，将光标移至内核命令行的末尾，并将 fips=1 添加到此行的末尾，例如： > vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=RHEL-10-0-BaseOS-x86_64 rd.live.check quiet fips=1
• 列表：在软件选择阶段，请勿安装任何第三方软件。
• 列表：安装后，系统会自动以 FIPS 模式启动。
• 列表：系统启动后，检查是否启用了 FIPS 模式： $ cat /proc/sys/crypto/fips_enabled 1
• 命令/配置摘录：

linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=RHEL-10-0-BaseOS-x86_64 rd.live.\ check quiet fips=1
> vmlinuz initrd=initrd.img inst.stage2=hd:LABEL=RHEL-10-0-BaseOS-x86_64 rd.live.check quiet fips=1

• 注意：警告 完成 FIPS 模式的设置后，您无法在不将系统置于不一致状态的情况下禁用 FIPS 模式。如果您的场景需要这个变化，唯一的正确方法是完全重新安装系统。

1.3. 使用 RHEL 镜像构建器启用 FIPS 模式

• 要点：您可以创建一个自定义镜像，并引导启用了 FIPS 的 RHEL 镜像。在制作镜像前，您必须更改蓝图中 fips 指令的值。
• 要点：先决条件
• 列表：您以 root 用户身份登录，或者以是 weldr 组成员的用户身份登录。
• 列表：使用以下内容，创建一个 Tom's Obvious, Minimal Language (TOML)格式的纯文本文件： name = "system-fips-mode-enabled" description = "blueprint with FIPS enabled" version = "0.0.1" [customizations] fips = true [[customizations.user]] name = "admin" password = "admin" groups = ["users", "wheel"]
• 列表：构建自定义的 RHEL 镜像： # image-builder build image-type --blueprint blueprint-name
• 列表：使用您在蓝图中配置的用户名和密码登录到系统镜像。
• 列表：检查是否启用了 FIPS 模式： $ cat /proc/sys/crypto/fips_enabled 1
• 命令/配置摘录：

name = "system-fips-mode-enabled" description = "blueprint with FIPS enabled" version = "0.0.1" [customizations] fips = true [[customizations.user]] name = "admin" password = "admin" groups = ["users", "wheel"]
# image-builder build image-type --blueprint blueprint-name

1.4. 为启用了 FIPS 的系统创建一个可引导磁盘镜像

• 要点：您可以在执行 Anaconda 安装时创建一个磁盘镜像并启用 FIPS 模式。在引导磁盘镜像时，您必须添加 fips=1 内核参数。
• 要点：先决条件
• 列表：您已在主机机器上安装了 Podman。
• 列表：您已在主机机器上安装了 virt-install。
• 列表：您有运行 bootc-image-builder 工具的 root 访问权限，并在 --privileged 模式下运行容器，以构建镜像。
• 列表：创建一个 01-fips.toml ，来配置 FIPS 启用，例如： # Enable FIPS kargs = ["fips=1"]
• 列表：使用以下指令创建一个 Containerfile，以启用 fips=1 内核参数，并调整加密策略： FROM quay.io/<namespace>/<image>:latest # Enable fips=1 kernel argument: https://bootc-dev.github.io/bootc/building/kernel-arguments.html COPY 01-fips.toml /usr/lib/bootc/kargs.d/ # Install and enable the FIPS crypto policy RUN dnf install -y crypto-policies-scripts &&…
• 列表：在运行容器前，初始化 输出 文件夹。使用 -p 参数来确保如果目录已存在，命令不会失败： $ mkdir -p ./output
• 命令/配置摘录：

# Enable FIPS kargs = ["fips=1"]
FROM quay.io/<namespace>/<image>:latest # Enable fips=1 kernel argument: https://bootc-dev.github.io/bootc/building/kernel-arguments.html COPY 01-fips.toml /usr/lib/bootc/kargs.d/ # Install and enable the FIPS crypto policy RUN dnf install -y crypto-policies-scripts && update-crypto-policies --no-reload --set FIPS

1.5. 使用与 FIPS 140-3 不兼容的加密的 RHEL 应用程序列表

• 要点：查看使用与 FIPS 140-3 不兼容的加密的 RHEL 应用程序。要传递所有相关加密认证，如 FIPS 140-3，请使用核心加密组件集中的库。
• 要点：除了 libgcrypt 外，这些库也遵循 RHEL 系统范围加密策略。
• 列表：FIPS - 联邦信息处理标准（红帽客户门户网站）
• 列表：RHEL 核心加密组件（红帽知识库）
• 列表：对 PKCS #12 的 FIPS 140-3 更改(红帽博客)

第 2 章 使用系统范围的加密策略

• 要点：系统范围的加密策略组件配置核心加密子系统，该子系统涵盖 TLS、IPsec、SSH、DNSSEC 和 Kerberos 协议。作为管理员，您可以选择一个为您的系统提供的加密策略。

2.1. 系统范围的加密策略

• 要点：RHEL 系统范围的加密策略配置核心子系统，如 TLS 和 SSH，这样可确保应用程序默认拒绝弱算法。四个预定义的策略包括 DEFAULT、LEGACY、FUTURE 和 FIPS。
• 要点：当配置了系统范围的策略时，RHEL 中的应用程序会遵循它，并拒绝使用不符合该策略的算法和协议，除非您明确请求应用程序这样做。在运行系统提供的配置时，策略适用于应用程序的默认行为，但在需要时您可以覆盖它。如果需要，您可以覆盖它。

2.1.1. 预定义的加密策略

• 要点：RHEL 10 包含以下预定义的策略：
• 要点：更严格的前瞻性安全级别，旨在测试未来可能的策略。此策略不允许在 DNSSEC 中或作为 HMAC 使用 SHA-1。SHA2-224 和 SHA3-224 哈希被拒绝。禁用 128 位密码。CBC-mode 密码被禁用，除了 Kerberos 中。它允许 TLS 1.2 和 1.3，以及 IKEv2 和 SSH2。如果 RSA 密钥和 Diffie-Hellman 参数至少是 3072 位，则可以接受它们。如果您的系统在公共互联网上进行通信，您可能会遇到互操作性问题。
• 注意：重要 客户门户 API 上的证书使用的加密密钥不符合未来系统范围加密策略的要求。因此，红帽支持工具实用程序目前无法与此策略级别配合使用。 要临时解决这个问题，在连接到客户门户网站 API 时使用 DEFAULT 加密策略。
• 注意：注意 设置 FIPS 加密策略后，您的系统不符合 FIPS。使 RHEL 系统符合 FIPS 140 标准的唯一正确方法是在 FIPS 模式下安装它。
• 表格样本（共 13 行）：
  • LEGACY | DEFAULT | FIPS | FUTURE
  • IKEv1 | 否 | 否 | 否 | 否
  • 3DES | 否 | 否 | 否 | 否
  • RC4 | 否 | 否 | 否 | 否

2.1.2. post-quantum 加密

• 要点：RHEL 10.0 在其核心加密子系统中引入了 post-quantum 加密(PQC)。PQC 的目的是保护数字通信的机密性、完整性和真实性，并免受使用加密相关量子计算机(CRQC)的未来攻击。
• 要点：虽然 CRQC 目前无法正常工作，但量子计算的持续发展可能会导致经典的加密算法（如 RSA 和 elliptic curve 加密）进行计算破坏。PQC 算法通过提供量级等效功能来降低预计的长期安全风险。您可以通过使用 PQC 配置 RHEL，防止当前出现 "harvest, decrypt later" 攻击的风险。
• 列表：产品合规性（红帽客户门户）
• 列表：通用标准（红帽客户门户）
• 列表：在 Red Hat Enterprise Linux 10 上的 OpenSSL 中启用 SHA-1 签名（红帽知识库）
• 列表：Red Hat Enterprise Linux 10 中的 post-quantum 加密（红帽博客）
• 列表：RHEL 10 post-quantum 加密的互操作性（红帽知识库）
• 列表：红帽的 post-quantum 加密的路径（红帽博客）

2.2. 更改系统范围的加密策略

• 要点：您可以使用 update-crypto-policies 工具更改系统上的系统范围加密策略，并重启系统。使用 update-crypto-policies，您可以快速切换预定义的策略，如 DEFAULT、LEGACY 或 FUTURE。
• 要点：您系统上的 update-crypto-policies (8) 手册页提供了所有选项、相应文件和每个应用程序详情的参考。
• 列表：您在系统上具有 root 权限。
• 列表：可选：显示当前的加密策略： $ update-crypto-policies --show DEFAULT
• 列表：设置新的加密策略： # update-crypto-policies --set <POLICY> <POLICY> 将 <POLICY> 替换为您要设置的策略或子策略，例如 FUTURE、LEGACY 或 FIPS:OSPP。
• 列表：重启系统： # reboot
• 列表：显示当前加密策略： $ update-crypto-policies --show <POLICY>
• 列表：系统范围的加密策略
• 命令/配置摘录：

$ update-crypto-policies --show DEFAULT
# update-crypto-policies --set <POLICY> <POLICY>

2.3. 将系统范围的加密策略切换到与早期版本兼容的模式

• 要点：如果环境需要与 RHEL 6 或更早版本的系统兼容，则切换到 LEGACY 加密策略。此操作破坏了与不安全协议的互操作性安全性。
• 要点：先决条件
• 列表：以 # 命令提示符开头的命令需要 sudo 提供的管理特权或 root 用户访问权限。有关如何配置 sudo 访问权限的详情，请参考 使非特权用户能够运行某些命令。
• 列表：要将系统范围的加密策略切换到 LEGACY，请输入： # update-crypto-policies --set LEGACY Setting system policy to LEGACY 有关可用的加密策略的列表，请查看您系统上的 update-crypto-policies (8) 手册页。
• 列表：要使您的加密设置对已经运行的服务和应用程序有效，请重启系统： $ reboot
• 列表：重启后，验证当前策略是否设置为 LEGACY ： $ update-crypto-policies --show LEGACY
• 列表：有关定义自定义加密策略的信息，请参阅您系统上 update-crypto-policies (8) 手册页中的 自定义策略 部分，以及 crypto-policies (7) 手册页中的 加密策略定义格式 部分。
• 命令/配置摘录：

# update-crypto-policies --set LEGACY Setting system policy to LEGACY
$ reboot

• 注意：警告 切换到 LEGACY 策略会导致系统和应用程序的安全性较低。

2.4. 在 web 控制台中配置系统范围的加密策略

• 要点：您可以在 RHEL web 控制台中配置系统范围的加密策略。这为更改策略（如 DEFAULT、LEGACY 或 FUTURE）提供了一个图形界面。
• 要点：除了三个预定义的系统范围的加密策略外，您还可以通过图形界面应用 LEGACY 策略和 AD-SUPPORT 子策略的组合。LEGACY:AD-SUPPORT 策略是安全性设置较低的LEGACY 策略。这些设置提高了 Active Directory 服务的互操作性。
• 列表：您已安装了 RHEL 10 web 控制台。 具体步骤请参阅安装并启用 Web 控制台。
• 列表：以 # 命令提示符开头的命令需要 sudo 提供的管理特权或 root 用户访问权限。有关如何配置 sudo 访问权限的详情，请参考 使非特权用户能够运行某些命令。
• 列表：登录到 RHEL 10 web 控制台。
• 列表：在 Overview 页面的 Configuration 卡中，点 Crypto 策略旁的当前策略值。
• 列表：在 Change crypto policy 对话框窗口中，点您要在系统上开始使用的策略。
• 列表：点应用并重新引导按钮。

2.5. 选择不使用系统范围的加密策略的示例

• 要点：查看如何选择不使用系统范围的加密策略的示例，如 OpenSSH 和 wget。当特定应用程序需要旧的密码或协议时，请使用这些方法。
• 要点：您可以通过在应用程序中直接配置支持的密码套件和协议来自定义应用程序使用的加密设置。
• 列表：对于给定的用户，使用 ~/.ssh/config 文件中特定于用户的配置覆盖全局 ssh_config。
• 列表：对于整个系统，在拖放配置文件中指定加密策略。将文件放在 /etc/ssh/ssh_config.d/ 目录中。使用小于 50 的两位数字前缀，使其在词典上位于 50-redhat.conf 文件的前面。使用 .conf 后缀，例如 49-crypto-policy-override.conf。
• 命令/配置摘录：

$ curl <https://example.com> --ciphers '@SECLEVEL=0:DES-CBC3-SHA:RSA-DES-CBC3-SHA'
$ wget --secure-protocol=TLSv1_1 --ciphers="SECURE128" <https://example.com>

2.6. 使用子策略自定义系统范围的加密策略

• 要点：调整系统上启用的加密算法或协议集。在 RHEL 中，您可以在现有系统范围的加密策略之上应用自定义子策略，或者从头开始定义此类策略。
• 要点：有范围策略的概念为不同的后端启用不同的算法集合。您可以将每个配置指令限制到特定的协议、库或服务。
• 列表：/etc/crypto-policies/state/CURRENT.pol 文件列出了通配符扩展后当前应用了系统范围加密策略中的所有设置。
• 列表：要使您的加密策略更严格，请考虑使用 /usr/share/crypto-policies/policies/FUTURE.pol 文件中列出的值。
• 列表：您可以在 /usr/share/crypto-policies/policies/modules/ 目录中找到示例子策略。
• 列表：签出到 /etc/crypto-policies/policies/modules/ 目录： # cd /etc/crypto-policies/policies/modules/
• 列表：为您的调整创建子策略，例如： # touch <MYCRYPTO-1>.pmod # touch <SCOPES-AND-WILDCARDS>.pmod 重要 在策略模块的文件名中使用大写字母。
• 列表：在您选择的文本编辑器中打开策略模块并插入修改系统范围加密策略的选项，例如： # vi <MYCRYPTO-1>.pmod min_rsa_size = 3072 hash = SHA2-384 SHA2-512 SHA3-384 SHA3-512 # vi <SCOPES-AND-WILDCARDS>.pmod # Disable the AES-128 cipher, all modes cipher = -AES-128-* # Disable CHACHA20-POLY1305 for the TLS protocol (OpenSSL, GnuTLS, NSS, and OpenJDK) cipher@TLS = -CHA…
• 命令/配置摘录：

# cd /etc/crypto-policies/policies/modules/
# touch <MYCRYPTO-1>.pmod # touch <SCOPES-AND-WILDCARDS>.pmod

• 注意：重要 在策略模块的文件名中使用大写字母。

2.7. 创建并设置自定义系统范围的加密策略

• 要点：在现有系统范围的加密策略之上应用自定义子策略，以修改启用的加密算法或协议。通过使用这种粒度自定义，您可以确保您的系统遵循特定的安全要求。
• 要点：流程
• 列表：为自定义创建一个策略文件： # cd /etc/crypto-policies/policies/ # touch <MYPOLICY>.pol 或者，从复制四个预定义策略级别中的一个开始： # cp /usr/share/crypto-policies/policies/DEFAULT.pol /etc/crypto-policies/policies/<MYPOLICY>.pol
• 列表：在您选择的文本编辑器中编辑带有自定义加密策略的文件以满足您的要求，例如： # vi /etc/crypto-policies/policies/<MYPOLICY>.pol 有关完整的语法参考，请参阅您系统上 update-crypto-policies (8) 手册页中的 自定义策略 部分和 crypto-policies (7) 手册页中的 加密策略定义格式 部分。
• 列表：将系统范围的加密策略切换到自定义级别： # update-crypto-policies --set <MYPOLICY>
• 列表：要使您的加密设置对已经运行的服务和应用程序有效，请重启系统： # reboot
• 列表：如何在 RHEL 8.2 中自定义加密策略（红帽博客）
• 命令/配置摘录：

# cd /etc/crypto-policies/policies/ # touch <MYPOLICY>.pol
# cp /usr/share/crypto-policies/policies/DEFAULT.pol /etc/crypto-policies/policies/<MYPOLICY>.pol

2.8. 在系统范围内禁用量子算法

• 要点：从 RHEL 10.1 中，默认在所有预定义策略中都启用 post-quantum 加密(PQC)算法。您可以通过应用 NO-PQ 子策略来关闭它们。
• 要点：先决条件
• 列表：以 # 命令提示符开头的命令需要 sudo 提供的管理特权或 root 用户访问权限。有关如何配置 sudo 访问权限的详情，请参考 使非特权用户能够运行某些命令。
• 列表：在当前系统范围的加密策略之上应用 NO-PQ 加密子策略，例如： # update-crypto-policies --show DEFAULT # update-crypto-policies --set DEFAULT:NO-PQ
• 列表：要使您的加密设置对已经运行的服务和应用程序有效，请重启系统： # reboot
• 列表：检查 /etc/crypto-policies/state/CURRENT.pol 文件不包含 PQC 算法字符串 MLKEM、MLDSA 和 KEM-ECDH，例如： $ cat /etc/crypto-policies/state/CURRENT.pol | grep MLKEM 以上命令的输出必须为空。
• 命令/配置摘录：

# update-crypto-policies --show DEFAULT # update-crypto-policies --set DEFAULT:NO-PQ
# reboot

2.9. 使用 crypto_policies RHEL 系统角色增强 FUTURE 加密策略的安全性

• 要点：您可以使用 crypto_policies RHEL 系统角色在受管节点上配置 FUTURE 加密策略。
• 要点：FUTURE 策略有助于实现，例如：
• 列表：您已准备好控制节点和受管节点。
• 列表：您以可在受管主机上运行 playbook 的用户身份登录到控制节点。
• 列表：用于连接到受管节点的帐户具有这些节点的 sudo 权限。
• 列表：创建一个包含以下内容的 playbook 文件，如 ~/playbook.yml ： --- - name: Configure cryptographic policies hosts: managed-node-01.example.com tasks: - name: Configure the FUTURE cryptographic security policy on the managed node ansible.builtin.include_role: name: redhat.rhel_system_roles.crypto_policies vars: - crypto_policies_po…
• 列表：验证 playbook 语法： $ ansible-playbook --syntax-check ~/playbook.yml 请注意，这个命令只验证语法，不能防止错误的、但有效的配置。
• 列表：运行 playbook： $ ansible-playbook ~/playbook.yml
• 命令/配置摘录：

--- - name: Configure cryptographic policies  hosts: managed-node-01.example.com  tasks:  - name: Configure the FUTURE cryptographic security policy on the managed node  ansible.builtin.include_role:  name: redhat.rhel_system_roles.crypto_policies  vars:  - crypto_policies_policy: FUTURE  - crypto_policies_reboot_ok: true
$ ansible-playbook --syntax-check ~/playbook.yml

• 注意：警告 传统系统和软件不必支持 FUTURE 策略实施的更现代化且更严格的算法和协议。例如，旧的系统可能不支持 TLS 1.3 或更大的密钥大小。这可能导致互操作性问题。 另外，使用强大的算法通常会增加计算工作负载，这可能会对您的系统性能造成负面影响。

第 3 章 通过 PKCS#11 将应用程序配置为使用加密硬件

• 要点：通过一致的 PKCS modprobe API 将应用程序配置为使用加密硬件，如智能卡和 HSM。隔离硬件上的 secret 有助于提供额外的安全层。

3.1. 通过 PKCS #11 的加密硬件支持

• 要点：在 RHEL 中，您可以使用 PKCSGRESS API 标准和 p11-kit 工具访问加密令牌，如智能卡和硬件安全模块(HSM)。通过隔离这些专用设备上的密钥，您可以确保安全管理敏感数据。
• 要点：公钥加密标准(PKCS)#11为保存加密信息并执行加密功能的加密设备定义一个应用程序编程接口(API)。
• 列表：PKCSGRESS URI 方案(IETF.org)
• 列表：控制对智能卡的访问（红帽博客）
• 命令/配置摘录：

$ cat /usr/share/p11-kit/modules/opensc.module module: opensc-pkcs11.so

3.2. 通过保存在智能卡上的 SSH 密钥进行身份验证

• 要点：使用保存在智能卡中的 SSH 密钥来为您的凭证添加物理保护层。此方法增强了安全性，防止未经授权的访问。
• 要点：您可以在智能卡上创建并存储 ECDSA 和 RSA 密钥，并通过 OpenSSH 客户端上的智能卡进行身份验证。智能卡验证替换了默认密码验证。
• 列表：在客户端中安装了 opensc 软件包，pcscd 服务正在运行。
• 列表：列出所有由 OpenSC PKCS #11 模块提供的密钥，包括其 PKCS #11 URIs，并将输出保存到 key.pub 文件： $ ssh-keygen -D pkcs11: > keys.pub
• 列表：将公钥传送到远程服务器。使用ssh-copy-id 命令和上一步中创建的 keys.pub 文件： $ ssh-copy-id -f -i keys.pub <username@ssh-server-example.com>
• 列表：使用 ECDSA 密钥连接到 <ssh-server-example.com>。您可以只使用 URI 的子集，它唯一引用您的密钥，例如： $ ssh -i "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so" <ssh-server-example.com> Enter PIN for 'SSH key': [ssh-server-example.com] $ 因为 OpenSSH 使用 p11-kit-proxy 包装器，且 OpenSC PKCS #11 模块已注册到 p11-kit 工具，因此您可以简化上一个命令： $ ssh -i "pkcs11:id…
• 列表：可选：您可以在 ~/.ssh/config 文件中使用同样的 URI 字符串来使配置持久： $ cat ~/.ssh/config IdentityFile "pkcs11:id=%01?module-path=/usr/lib64/pkcs11/opensc-pkcs11.so" $ ssh <ssh-server-example.com> Enter PIN for 'SSH key': [ssh-server-example.com] $ ssh 客户端工具现在自动使用此 URI 和智能卡中的密钥。
• 命令/配置摘录：

$ ssh-keygen -D pkcs11: > keys.pub
$ ssh-copy-id -f -i keys.pub <username@ssh-server-example.com>

3.3. 使用智能卡中的证书进行身份验证的应用程序设置

• 要点：您可以配置应用程序，如 curl 以使用保存在智能卡中的证书进行身份验证。这种强大的方法可帮助您使用物理安全凭证保护您的系统。
• 要点：在应用程序中使用智能卡进行身份验证可能会提高安全性并简化自动化。您可以使用以下方法将公钥加密标准(PKCS) #11 URIs 集成到应用程序中：
• 列表：Firefox web 浏览器会自动加载 p11-kit-proxy PKCS #11 模块。这意味着系统中的每个支持的智能卡都会被自动检测到。对于使用 TLS 客户端身份验证，不需要额外的设置，在服务器请求它们时会自动使用智能卡中的密钥和证书。
• 列表：如果您的应用程序使用 GnuTLS 或 NSS 库，则它已经支持 PKCS #11 URI。另外，依赖 OpenSSL 库的应用程序可以通过 pkcs11-provider 软件包安装的 PKCS #11 提供者访问加密硬件模块，包括智能卡。
• 列表：需要使用智能卡上的私钥、不使用NSS、GnuTLS或OpenSSL的应用程序可以直接使用p11套件API。这使得他们能够使用加密硬件模块，包括智能卡，而不是使用特定PKCS #11模块的PKCS #11 API。
• 列表：使用 wget 网络下载程序，您可以指定 PKCShmac URI，而不是本地存储的私钥和证书的路径。这可能会简化为需要安全存储私钥和证书的任务创建脚本。例如： $ wget --private-key 'pkcs11:token=softhsm;id=%01;type=private?pin-value=111111' --certificate 'pkcs11:token=softhsm;id=%01;type=cert' https://example.com/
• 列表：在使用 curl 工具时，您也可以指定 PKCS #11 URI： $ curl --key 'pkcs11:token=softhsm;id=%01;type=private?pin-value=111111' --cert 'pkcs11:token=softhsm;id=%01;type=cert' https://example.com/ 注意 PIN 是一种安全措施，用于控制对存储在智能卡上的密钥的访问。因为配置文件包含纯文本形式的 PIN,所以请考虑额外的保护，以防止攻击者读取 PIN。例如，您可以使用 pin-source 属性，并提供 file: URI 来从文件读取 PIN。如需更多信息，请参阅 RFC 7512…
• 命令/配置摘录：

$ wget --private-key 'pkcs11:token=softhsm;id=%01;type=private?pin-value=111111' --certificate 'pkcs11:token=softhsm;id=%01;type=cert' https://example.com/
$ curl --key 'pkcs11:token=softhsm;id=%01;type=private?pin-value=111111' --cert 'pkcs11:token=softhsm;id=%01;type=cert' https://example.com/

• 注意：注意 PIN 是一种安全措施，用于控制对存储在智能卡上的密钥的访问。因为配置文件包含纯文本形式的 PIN,所以请考虑额外的保护，以防止攻击者读取 PIN。例如，您可以使用 pin-source 属性，并提供 file: URI 来从文件读取 PIN。如需更多信息，请参阅 RFC 7512: PKCS #11 URI 模式查询属性语义。请注意，不支持将命令路径用作 pin-source 属性的值。

3.4. 在 Apache 中使用 HSM 保护私钥

• 要点：Apache HTTP 服务器可以使用存储在硬件安全模块(HSM)上的私钥，这有助于防止密钥泄漏和中间人攻击。请注意，对于繁忙的服务器，这通常需要高性能的 HSM 。
• 要点：对于 HTTPS 协议形式的安全通信，Apache HTTP 服务器(httpd)使用 OpenSSL 库。OpenSSL 本身不支持 PKCS #11 。要使用 HSM，您必须安装 pkcs11-provider 软件包，该软件包提供对 PKCS #11 模块的访问。您可以使用 PKCS #11 URI 而不是常规文件名在 /etc/httpd/conf.d/ssl.conf 配置文件中指定服务器密钥和证书，例如：
• 命令/配置摘录：

SSLCertificateFile "pkcs11:id=%01;token=softhsm;type=cert" SSLCertificateKeyFile "pkcs11:id=%01;token=softhsm;type=private?pin-value=111111"

第 4 章 使用 polkit 控制对智能卡的访问

• 要点：在 RHEL 中配置 polkit 框架以控制对智能卡的访问。这提供了精细的控制并缓解内置机制（如 PIN、PIN pads 和 biometrics）的威胁无法防止。
• 要点：系统管理员配置 polkit 以适合特定的场景，如非特权或非本地用户或服务的智能卡访问。

4.1. 通过 polkit 的智能卡访问控制

• 要点：使用 polkit 授权管理器，您可以为保护智能卡定义精确策略。管理员可以使用此框架来控制哪些用户可以通过该卡执行特定的特权操作。
• 要点：个人计算机/智能卡(PC/SC)协议指定将智能卡及其读卡器整合成计算系统的标准。在 RHEL 中，pcc-lite 软件包提供了中间件来访问使用 PC/SC API 的智能卡。这个软件包的一部分 pcscd (PC/SC 智能卡)守护进程确保系统可以使用 PC/SC 协议访问智能卡。

4.2. 排除与 PC/SC 和 polkit 相关的问题

• 要点：您可以通过检查 Journal 日志来排除与 pcscd 守护进程和 polkit 授权框架相关的消息，从而排除智能卡身份验证失败的问题。这有助于识别策略或访问拒绝。
• 要点：在您安装 pcsc-lite 软件包并启动 pcscd 守护程序后自动实施的 Polkit 策略可能会在用户会话中要求身份验证。即使用户不直接与智能卡交互，也会发生这种情况。在 GNOME 中，您可以看到以下错误信息：
• 命令/配置摘录：

Authentication is required to access the PC/SC daemon
$ journalctl -b | grep pcsc … Process 3087 (user: 1001) is NOT authorized for action: access_pcsc …

4.3. 向 PC/SC 显示关于 polkit 授权的更多详细信息

• 要点：在默认配置中，polkit 授权框架仅将有限的信息发送到 Journal 日志。您可以通过添加新的规则来扩展与 PC/SC 协议相关的 polkit 日志条目。
• 要点：先决条件
• 列表：您已在系统上安装了 pcsc-lite 软件包。
• 列表：pcscd 守护进程正在运行。
• 列表：在 /etc/polkit-1/rules.d/ 目录中创建一个新文件： # touch /etc/polkit-1/rules.d/00-test.rules
• 列表：在您选择的编辑器中编辑该文件，例如： # vi /etc/polkit-1/rules.d/00-test.rules
• 列表：插入以下行： polkit.addRule(function(action, subject) { if (action.id == "org.debian.pcsc-lite.access_pcsc" || action.id == "org.debian.pcsc-lite.access_card") { polkit.log("action=" + action); polkit.log("subject=" + subject); } }); 保存文件并退出编辑器。
• 列表：重启 pcscd 和 polkit 服务： # systemctl restart pcscd.service pcscd.socket polkit.service
• 命令/配置摘录：

# touch /etc/polkit-1/rules.d/00-test.rules
# vi /etc/polkit-1/rules.d/00-test.rules

4.4. 其他资源

• 列表：控制对智能卡的访问（红帽博客）

第 5 章 扫描系统以检查配置是否合规

• 要点：根据合规策略中定义的特定规则扫描 RHEL 配置。使用这些清单，您可以确保您的环境遵循严格的安全要求。
• 要点：安全专家通过指定计算环境所需的设置来定义合规策略，通常是以清单的形式。

5.1. RHEL 中的配置合规工具

• 要点：RHEL 10 为自动化合规审计提供配置合规工具。这些工具基于 SCAP 标准。它们专为自动定制合规策略而设计。
• 要点：OpenSCAP 库包括 oscap 命令行工具。使用它：
• 列表：在本地系统中执行配置扫描
• 列表：验证配置合规性内容
• 列表：根据扫描和评估生成报告和指南 使用 oscap，您可以扫描系统。这对 scap-security-guide 中的安全策略进行了评估。您还可以运行自动补救。这会将系统配置为与所选策略保持一致。 重要 在使用 OpenSCAP 时可能会遇到内存消耗问题。这可以在早期停止该程序。它还可防止生成结果文件。
• 列表：红帽安全演示：创建自定义安全策略内容以自动化安全合规
• 列表：红帽安全演示：使用 RHEL 安全技术保护自己
• 列表：在 Red Hat Satellite 中管理安全合规性
• 注意：重要 在使用 OpenSCAP 时可能会遇到内存消耗问题。这可以在早期停止该程序。它还可防止生成结果文件。

5.2. 配置合规性扫描

• 要点：通过执行配置合规性扫描，验证您的红帽企业 Linux 系统是否遵守了行业标准或内部策略等安全基线。您可以使用 OpenSCAP 和 SCAP 安全指南扫描本地和远程系统、容器和容器镜像。

5.2.1. RHEL 中的配置合规性

• 要点：使用配置合规性扫描，以符合特定组织定义的基准。例如，如果您是支付处理器，您可以将您的系统与支付卡行业数据安全标准(PCI-DSS)保持一致。您还可以执行扫描来强化系统安全性。
• 要点：遵循 SCAP 安全指南包中的安全内容自动化协议 (SCAP) 内容，因为它与红帽针对受影响组件的最佳实践保持一致。
• 列表：使用 autotailor 自定义安全配置文件
• 命令/配置摘录：

Data stream  ├── xccdf  | ├── benchmark  | ├── profile  | | ├──rule reference  | | └──variable  | ├── rule  | ├── human readable data  | ├── ocil reference  ├── ocil ├── cpe reference  └── cpe └── remediation

• 注意：重要 执行配置合规性扫描不能保证系统是合规的。

5.2.2. OpenSCAP 扫描的可能结果

• 要点：了解 OpenSCAP 扫描的可能结果，如 Pass, Fail, 或 Not Applicable，可帮助您准确解释合规性报告。
• 要点：根据应用到 OpenSCAP 扫描的数据流和配置集以及系统的各种属性，每个规则都会生成特定的结果：

5.2.3. 查看配置文件是否符合配置合规

• 要点：在决定使用配置文件进行扫描或补救前，您可以使用 oscap info 子命令列出它们并检查其详细描述。
• 要点：先决条件
• 列表：openscap-scanner 和 scap-security-guide 软件包已安装。
• 列表：列出 SCAP 安全指南项目所提供的带有安全合规配置文件的所有可用文件： $ ls /usr/share/xml/scap/ssg/content/ ssg-rhel10-ds.xml
• 列表：使用 oscap info 子命令显示有关所选数据流的详细信息。包含数据流的 XML 文件由其名称中的 -ds 字符串表示。在 Profiles 部分，您可以找到可用的配置文件及其 ID 列表： $ oscap info /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml Profiles: … Title: Australian Cyber Security Centre (ACSC) ISM Official - Top Secret Id: xccdf_org.ssgproject.content_profile_ism_o_top_secret Title: PCI-D…
• 列表：从数据流文件中选择一个配置文件，并显示所选配置文件的更多详情。为此，可使用带有 --profile 选项的 oscap info ，后跟上一命令输出中显示的 ID 的最后一部分。例如，HIPPA 配置文件的 ID 是 xccdf_org.ssgproject.content_profile_hipaa，--profile 选项的值是 hipaa ： $ oscap info --profile hipaa /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml … Profile Title: Health Insurance Portability and Accountabilit…
• 列表：OpenSCAP 内存消耗问题
• 命令/配置摘录：

$ ls /usr/share/xml/scap/ssg/content/ ssg-rhel10-ds.xml
$ oscap info /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml Profiles: …  Title: Australian Cyber Security Centre (ACSC) ISM Official - Top Secret  Id: xccdf_org.ssgproject.content_profile_ism_o_top_secret  Title: PCI-DSS v4.0.1 Control Baseline for Red Hat Enterprise Linux 10  Id: xccdf_org.ssgproject.content_profile_pci-dss  Title: Red Hat STIG for Red Hat Enterprise Linux 10  Id: xccdf_org.ssgproject.content_profile_stig …

5.2.4. 评估配置是否符合特定基准

• 要点：您可以确定您的系统或远程系统是否符合特定的基准，并使用 oscap 命令行工具将结果保存到报告中。
• 要点：先决条件
• 列表：openscap-scanner 和 scap-security-guide 软件包已安装。
• 列表：您知道系统应遵守的基准中的配置文件的 ID。要查找 ID，请参阅 查看配置合规性的配置文件 部分。
• 列表：扫描本地系统是否符合所选的配置文件，并将扫描结果保存到一个文件中： $ oscap xccdf eval --report <scan_report.html> --profile <profile_ID> /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml 替换： 使用 oscap 保存扫描结果的文件名替换 <scan_report.html>。 使用系统应该遵守的配置文件 ID，例如 hipaa ，替换 <profile_ID>。
• 列表：使用 oscap 保存扫描结果的文件名替换 <scan_report.html>。
• 列表：使用系统应该遵守的配置文件 ID，例如 hipaa ，替换 <profile_ID>。
• 列表：可选：扫描远程系统以确定是否符合所选的配置文件，并将扫描结果保存到一个文件中： $ oscap-ssh <username>@<hostname> <port> xccdf eval --report <scan_report.html> --profile <profile_ID> /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml 替换： <username>@ <hostname> 带有远程系统的用户名和主机名。 使用您可以通过其访问远程系统的端口号替换 <port>。 使用 oscap 保存扫描结果的文件名替换 <scan_report.html>。 使用系统应该遵守的…
• 命令/配置摘录：

$ oscap xccdf eval --report <scan_report.html> --profile <profile_ID> /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml
$ oscap-ssh <username>@<hostname> <port> xccdf eval --report <scan_report.html> --profile <profile_ID> /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml

5.2.5. 使用特定基准评估容器或容器镜像的安全性合规

• 要点：评估容器或容器映像是否符合安全基线。支持的基线包括支付卡行业数据安全标准(PCI-DSS)和健康保险便携性和责任法案(HIPAA ) 。这也有助于识别漏洞。
• 要点：先决条件
• 列表：openscap-utils 和 scap-security-guide 软件包已安装。
• 列表：有对系统的 root 访问权限。
• 列表：查找容器或容器镜像的 ID： 查找容器的 ID： # podman ps -a 查找容器镜像的 ID： # podman images
• 列表：查找容器的 ID： # podman ps -a
• 列表：查找容器镜像的 ID： # podman images
• 列表：根据配置集评估容器或容器镜像并保存结果： # oscap-podman <ID> xccdf eval --report <scan_report.html> --profile <profile_ID> /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml 替换： 使用容器或容器镜像的 ID 替换 <ID> 使用 oscap 保存扫描结果的文件名替换 <scan_report.html> 使用系统应该遵守的配置文件 ID，例如 hipaa 或 pci-dss 替换<profile_ID>
• 命令/配置摘录：

# podman ps -a
# podman images

• 注意：注意 标记为 notapplicable 的规则仅适用于裸机和虚拟系统，不适用于容器或容器镜像。

5.3. 配置合规补救

• 要点：要自动使您的系统与特定配置集保持一致，您可以执行补救。您可以修复系统，使其与 SCAP 安全指南提供的任何配置文件保持一致。

5.3.1. 修复系统，使其与特定基准一致

• 要点：使用 oscap xccdf eval --remediate 命令修复 RHEL 系统，使其与特定的安全基准一致。这会自动修复 SCAP 安全指南中定义的配置规则。
• 要点：有关列出可用的配置文件的详情，请查看 查看配置文件的配置合规性 部分。
• 列表：openscap-scanner 和 scap-security-guide 软件包已安装。
• 列表：修复系统： # oscap xccdf eval --profile <profile_ID> --remediate /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml 使用系统应该遵守的配置文件 ID，例如 hipaa 替换 <profile_ID>。
• 列表：重启您的系统。
• 列表：使用配置文件评估系统合规性，并将扫描结果保存到一个文件中： $ oscap xccdf eval --report <scan_report.html> --profile <profile_ID> /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml 替换： 使用 oscap 保存扫描结果的文件名替换 <scan_report.html>。 使用系统应该遵守的配置文件 ID，例如 hipaa ，替换 <profile_ID>。
• 列表：使用 oscap 保存扫描结果的文件名替换 <scan_report.html>。
• 列表：使用系统应该遵守的配置文件 ID，例如 hipaa ，替换 <profile_ID>。
• 命令/配置摘录：

# oscap xccdf eval --profile <profile_ID> --remediate /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml
$ oscap xccdf eval --report <scan_report.html> --profile <profile_ID> /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml

• 注意：警告 默认配置的 RHEL 系统支持自动安全补救功能。修复安装后更改的系统可能会导致系统无法使用所需的安全配置集运行或不合规。红帽不提供任何自动的方法来恢复由安全强制补救所做的更改。 在对生产环境系统应用之前，测试补救的影响。

5.3.2. 使用 SSG Ansible Playbook 修复系统，使其与特定的基准保持一致

• 要点：使用 SCAP 安全指南项目提供的 Ansible Playbook，以针对特定的安全基准修复您的系统。这有助于确保多个系统间的一致性和自动化。
• 要点：先决条件
• 列表：scap-security-guide 软件包已安装。
• 列表：ansible-core 软件包已安装。如需更多信息，请参阅 Ansible 安装指南。
• 列表：rhc-worker-playbook 软件包已安装。
• 列表：您知道您要修复系统的配置文件的 ID。详情请参阅 查看配置文件的配置合规性。
• 列表：使用 Ansible 修复您的系统，使其与所选的配置文件保持一致： # ANSIBLE_COLLECTIONS_PATH=/usr/share/rhc-worker-playbook/ansible/collections/ansible_collections/ ansible-playbook -i "localhost," -c local /usr/share/scap-security-guide/ansible/rhel10-playbook-<profile_ID>.yml ANSIBLE_COLLECTIONS_PATH 环境变量对于运行 playbook 的命令是必需的。 将 <profile_ID> 替换为所选…
• 列表：重新启动系统。
• 命令/配置摘录：

# ANSIBLE_COLLECTIONS_PATH=/usr/share/rhc-worker-playbook/ansible/collections/ansible_collections/ ansible-playbook -i "localhost," -c local /usr/share/scap-security-guide/ansible/rhel10-playbook-<profile_ID>.yml
# oscap xccdf eval --profile <profile_ID> --report <scan_report.html> /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml

• 注意：警告 默认配置的 RHEL 系统支持自动安全补救功能。修复安装后更改的系统可能会导致系统无法使用所需的安全配置集运行或不合规。红帽不提供任何自动的方法来恢复由安全强制补救所做的更改。 在对生产环境系统应用之前，测试补救的影响。

5.3.3. 创建一个修复 Ansible Playbook，以使系统与特定的基准保持一致

• 要点：您可以创建一个 Ansible Playbook，它只包含使您的系统与特定基准保持一致所需的补救。此 playbook 更小，因为它没有涵盖已满足的要求。
• 要点：创建 playbook 不会以任何方式修改您的系统，因为您只为后续应用程序准备一个文件。
• 列表：scap-security-guide 软件包已安装。
• 列表：ansible-core 软件包已安装。如需更多信息，请参阅 Ansible 安装指南。
• 列表：rhc-worker-playbook 软件包已安装。
• 列表：您知道您要修复系统的配置文件的 ID。详情请参阅 查看配置文件的配置合规性。
• 列表：扫描系统并保存结果： # oscap xccdf eval --profile <profile_ID> --results <profile_results.xml> /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml 使用系统应遵守的配置集 ID 替换：* <profile_ ID>，例如 hipaa * & lt;profile_results.xml >，使用 oscap 保存结果的文件的路径
• 列表：在带有结果的文件中找到结果 ID 的值： # oscap info <profile_results.xml>
• 命令/配置摘录：

# oscap xccdf eval --profile <profile_ID> --results <profile_results.xml> /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml
# oscap info <profile_results.xml>

• 注意：警告 默认配置的 RHEL 系统支持自动安全补救功能。修复安装后更改的系统可能会导致系统无法使用所需的安全配置集运行或不合规。红帽不提供任何自动的方法来恢复由安全强制补救所做的更改。 在对生产环境系统应用之前，测试补救的影响。

5.4. 使用 Kickstart 执行 RHEL 的强化安装

• 要点：要使系统符合特定的安全配置文件，如 DISA STIG、CIS 或 ANSSI,您可以准备一个 Kickstart 文件，该文件定义了硬化配置。使用剪裁文件进行自定义，然后运行硬化系统的自动安装。
• 要点：先决条件
• 列表：openscap-scanner 已安装在您的系统上。
• 列表：scap-security-guide 软件包安装在您的系统中，软件包版本与您要安装的 RHEL 版本对应。因为所有支持的 RHEL 版本都使用相同的 SCAP 安全指南版本，请在生成 Kickstart 文件前更新软件包。
• 列表：从数据流文件中找到安全配置文件的 ID： $ oscap info /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml Profiles: … Title: Australian Cyber Security Centre (ACSC) Essential Eight Id: xccdf_org.ssgproject.content_profile_e8 Title: Health Insurance Portability and Accountability Act (HIPAA) Id: xccdf_org.ssgproject.content_profile_hipa…
• 列表：可选：如果要使用 XCCDF 定制文件自定义强化，您可以使用 openscap-utils 软件包提供的 autotailor 命令。如需更多信息，请参阅 使用 autotailor 自定义安全配置文件。
• 列表：从 SCAP 源数据流生成 Kickstart 文件： $ oscap xccdf generate fix --profile <profile_ID> --output <kickstart_file>.cfg --fix-type kickstart /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml 使用系统应该遵守的配置文件 ID，例如 hipaa 替换 <profile_ID>。 如果您使用定制文件，请使用 --tailoring-file tailoring.xml 选项和自定义配置文件 ID 将定制文件嵌入到生成的 Kickstart 文件中，例如： $ oscap …
• 列表：进行检查，如果需要，手动修改生成的 <kickstart_file>.cfg，以适应您的部署需求。按照文件中的注释中的说明进行操作。 注意 有些更改可能会影响 Kickstart 文件安装的系统的合规性。例如，一些安全策略需要定义的分区或特定的软件包和服务。
• 命令/配置摘录：

$ oscap info /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml Profiles: …  Title: Australian Cyber Security Centre (ACSC) Essential Eight  Id: xccdf_org.ssgproject.content_profile_e8  Title: Health Insurance Portability and Accountability Act (HIPAA)  Id: xccdf_org.ssgproject.content_profile_hipaa  Title: PCI-DSS v3.2.1 Control Baseline for Red Hat Enterprise Linux 10  Id: xccdf_org.ssgproject.content_profile_pci-dss …
$ oscap xccdf generate fix --profile <profile_ID> --output <kickstart_file>.cfg --fix-type kickstart /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml

• 注意：注意 有些更改可能会影响 Kickstart 文件安装的系统的合规性。例如，一些安全策略需要定义的分区或特定的软件包和服务。

5.5. 使用 autotailor 自定义安全配置文件

• 要点：要与内部安全标准保持一致，您可以通过选择或删除现有规则来自定义 RHEL 安全配置集。虽然您可以修改密码长度等参数，但您无法在自定义期间定义完整的新规则。
• 要点：通过使用 autotailor 工具，您可以创建一个包含原始配置文件的所有修改的 XCCDF 定制文件。然后，当您根据 SCAP 配置集扫描、修复或安装系统时，您可以将此定制文件传递给 oscap 命令行工具。
• 列表：openscap-utils 软件包已安装在您的系统上。
• 列表：您知道您要自定义的基准中的配置文件的 ID。要查找 ID，请参阅 查看配置合规性的配置文件 部分。
• 列表：使用 autotailor 命令为配置文件创建一个定制文件，例如： $ autotailor \ --select=<rule_ID_1> \ --select=<rule_ID_2> \ --unselect=<rule_ID_3> \ --var-value=<value_ID_1>=<value_1> \ --var-value=<value_ID_2>=<value_2> \ --output=<tailoring.xml> \ --tailored-profile-id=<custom_profile_ID> \ /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml <pro…
• 列表：<customization_options> 是配置文件的修改。使用以下选项之一： --select=<rule_ID> 将现有规则添加到配置文件中。 --unselect=<rule_ID> 从配置文件中删除规则。 --var-value=<value_ID>=<value> 覆盖预设置的值。例如，要将 var_sshd_max_sessions 设置为 10，请使用 --var-value=var_sshd_max_sessions=10。
• 列表：<tailoring.xml> 是 autotailor 保存定制的文件名。
• 列表：<custom_profile_ID> 是 autotailor 在其中保存自定义的配置文件 ID，如 custom_cis。
• 命令/配置摘录：

$ autotailor \ --select=<rule_ID_1> \ --select=<rule_ID_2> \ --unselect=<rule_ID_3> \ --var-value=<value_ID_1>=<value_1> \ --var-value=<value_ID_2>=<value_2> \ --output=<tailoring.xml> \ --tailored-profile-id=<custom_profile_ID> \ /usr/share/xml/scap/ssg/content/ssg-rhel10-ds.xml <profile_ID>
$ autotailor --output=<tailoring.xml> --json-tailoring=<json_tailoring.json>

• 注意：注意 对于所有配置集、规则和变量 XCCDF ID，您可以使用完整的命名空间标识符 或 自动使用命名空间前缀的简短 ID。例如，cis 等同于 xccdf_org.ssgproject.content_profile_cis。 您可以使用 --id-namespace 选项覆盖默认命名空间 org.ssgproject.content。
• 注意：注意 您可以将 --json-tailoring 与 --select, --unselect 和 --var-value 命令行自定义混在一起。在这种情况下，命令行自定义的优先级高于 JSON Tailoring。

5.6. RHEL 10 中支持的 SCAP 安全指南配置文件

• 要点：查看 RHEL 10 中支持的 SCAP 安全指南配置文件，如 HIPAA、STIG 和 CIS。要容纳使用新功能更新的强化组件，请只使用特定次版本中提供的 SCAP 内容。
• 要点：SCAP 内容更改以反映这些更新，但它并不总是与早期的版本兼容。
• 注意：注意 您可以使用 oscap info 命令获取系统上安装的 scap-security-guide RPM 版本的相关信息。如需更多信息，请参阅 查看配置文件的配置合规性。
• 表格样本（共 18 行）：
  • 配置文件名称 | 配置文件 ID | 策略版本
  • French National Agency for the Security of Information Systems (ANSSI) BP-028 Enhanced Level | xccdf_org.ssgproject.content_profile_anssi_bp28_enhanced | 2.0
  • French National Agency for the Security of Information Systems (ANSSI) BP-028 High Level | xccdf_org.ssgproject.content_profile_anssi_bp28_high | 2.0
  • French National Agency for the Security of Information Systems (ANSSI) BP-028 Intermediary Level | xccdf_org.ssgproject.content_profile_anssi_bp28_intermediary | 2.0

5.7. 其他资源

• 列表：OpenSCAP 项目页面
• 列表：SCAP 安全指南(SSG)项目页面
• 列表：使用 OpenSCAP 进行安全合规和漏洞扫描 - 一个动手实验室
• 列表：红帽安全演示：创建自定义安全策略内容以自动化安全合规
• 列表：红帽安全演示：使用 RHEL 安全技术保护自己
• 列表：美国国家标准与技术研究院(NIST) SCAP 页面

第 6 章 使用 Keylime 确保系统完整性

• 要点：借助 Keylime，您可以持续监控远程系统的完整性，并在引导时验证系统状态。您还可以将加密文件发送到被监控的系统，并指定监控系统失败时触发的自动化操作。

6.1. 远程系统完整性监控

• 要点：要快速检测未经授权的更改，并验证您的远程基础架构是否处于可信状态，请使用 Keylime 来监控系统的完整性。通过 Keylime，您可以通过将引导组件和运行时文件的测量与已知良好的基准进行比较来持续验证您的系统。

6.1.1. 用于远程系统验证的组件和机制

• 要点：要为 RHEL 中的远程测试构建可信加密基础，您需要依赖 Keylime 架构。其核心组件 verifier、registrar、tenant 和 agent，与受信任的平台模块(TPM)技术交互，以动态构建和维护信任链。
• 要点：TPM 充当这个信任的根。它是带有集成加密密钥的硬件、固件或虚拟组件。
• 注意：重要 运行在虚拟机或使用虚拟 TPM 运行的 Keylime 取决于底层主机的完整性。在依赖虚拟环境中的 Keylime 测量前，请确保信任主机环境。

6.1.2. 远程监控的 Keylime attestation model

• 要点：要为您的基础架构建立可信远程监控策略，您可以使用拉取或推送(push)模型。您可以通过任一选项实现相同的系统完整性验证目标，虽然它们使用不同的网络机制和扩展行为进行操作。
• 要点：传统的 Keylime attestation 使用拉取模型，其中 verifier 服务通过定期轮询远程系统来启动 attestation 进程。verifier 建立到 Keylime 代理的入站网络连接，以检索受信任的平台模块(TPM)引号、完整性测量架构(IMA)日志和 UEFI 事件日志。pull 模型使用 mutual TLS (mTLS)身份验证来确保 Keylime 组件之间的安全通信。verifier 在检索和评估测量时保持打开的连接。它会根据代理的在测试密钥中检查其加密签名来验证 TPM quote，它会确认报告的 PCR 值是 authentic 和 untampered。然后，它会重播每个事件日志，以重建预期的 PCR 值，并将它们与引号中报告的值进行比较。在 UEFI 事件日志评估过程中，verifier 通过针对参考状态检查每个引导组件测量来验证引导序列。在评估 IMA 日志时，它会通过将记录的文件测量与运行时策略进行比较来检测未经授权或修改的软件。如果重建的任何 PCR 值与引号不匹配，或者任何测量失败，则 attestation 会失败。
• 注意：注意 如果代理没有接收密钥和证书，它会生成一个密钥以及一个自签名证书，而无需 CA。
• 表格样本（共 8 行）：
  • 属性 | Pull model （默认） | 推送模型
  • initiator | Keylime verifier 从 Keylime 代理请求数据 | Keylime 代理将数据发送到 Keylime verifier
  • agent 软件包 | keylime-agent-rust | keylime-agent-rust-push
  • 网络方向 | 入站到 Keylime 代理（端口 9002） | 入站到 Keylime verifier (port 8881)

6.1.3. 选择正确的 Keylime attestation 模型的注意事项

• 要点：要确定最适合您的架构，从稳定的数据中心到边缘部署，您可以评估特定的网络用例和环境因素与每个 Keylime attestation 模型一致。这个选择会直接影响您配置验证器和代理的方式。
• 要点：拉取( pull)模型 最适合网络管理、稳定和透明网络的环境。
• 列表：企业数据中心：最佳用于扁平、内部网络上的服务器，其中验证器可以直接访问每个节点。
• 列表：隔离的 air-gapped 网络：对于 verifier 严格控制所有通信的高可用性环境而言。
• 列表：Secret 和脚本交付（安全有效负载）：如果验证器必须立即向代理提供敏感配置文件、密钥或脚本，则需要在成功测试时立即向代理提供敏感的配置文件、密钥或脚本。
• 列表：集中式监控架构 ：当与依赖中央服务器轮询或 ping 客户端进行状态更新的现有基础架构管理工具集成时。
• 列表：实时失败：当验证器必须立即检测到网络丢弃或代理服务故障时，使用实时失败，这对于高可用性系统至关重要。
• 列表：边缘和物联网(IoT)部署：对于远程分支或字段位置的设备，必须通过外部网关连接到验证器。
• 表格样本（共 6 行）：
  • 决策因素 | Pull model （默认） | 推送模型
  • 网络可访问性 | 需要直接从验证器到代理的网络访问。 | 在复杂的网络拓扑、NAT 和防火墙之间工作。
  • 入站防火墙要求 | 需要在每个代理节点上打开一个入站端口。 | 不需要代理节点上的开放入站端口。
  • 可扩展性 | lower (verifier 管理每个代理的轮询计时器和连接负载) | 高（测试调度被卸载为代理，这会增加系统容量）

6.2. 从软件包部署 Keylime 验证器

• 要点：从软件包部署 Keylime verifier，以建立核心完整性监控组件。verifier 充当目标系统的验证颁发机构 - 代理。
• 要点：verifier 是 Keylime 中最重要的组件。它执行系统完整性的初始和定期检查，以确保监控代理处于可信状态。在 pull 模型中，verifier 还支持使用代理引导加密密钥和安全有效负载。
• 列表：您在要安装 Keylime 组件的系统上有 root 权限和网络连接。
• 列表：您有来自您的证书颁发机构的有效密钥和证书。
• 列表：如果使用 pull model attestation: verifier 的主机对端口 9002 上所有受监控代理具有出站访问权限。 verifier 的主机可由租户在端口 8881 上访问。 verifier 具有 mTLS 的服务器和客户端证书。
• 列表：verifier 的主机对端口 9002 上所有受监控代理具有出站访问权限。
• 列表：verifier 的主机可由租户在端口 8881 上访问。
• 列表：verifier 具有 mTLS 的服务器和客户端证书。
• 命令/配置摘录：

# dnf install keylime-verifier
[verifier] ip = <verifier_IP_address>

• 注意：重要 要维护信任链，请保持运行验证器的系统的安全，并在您的控制之下。
• 注意：注意 要将配置文件保留在置入目录中，请使用具有两位数字前缀的文件名，例如 /etc/keylime/verifier.conf.d/00-verifier-ip.conf。配置处理以字典顺序读取置入目录中的文件，并对每个选项设置为它读取的最后一个值。

6.3. 将 Keylime 验证器部署为容器

• 要点：将 Keylime verifier 配置为容器而不是 RPM 方法，在主机上没有任何二进制文件或软件包。容器部署提供更好的隔离、模块化和 Keylime 组件的可重复性。
• 要点：Keylime verifier 执行系统完整性的初始和定期检查，以确保被监控的代理处于可信状态。在 pull 模型中，verifier 还支持 bootstrap 加密密钥并为代理提供安全有效负载。
• 列表：将包含配置文件的目录挂载到容器上。
• 列表：直接在容器上修改环境变量。修改环境变量会覆盖配置文件中的值。
• 列表：podman 软件包及其依赖项已安装在系统上。
• 列表：执行 podman 命令的用户对将挂载到容器中的本地配置文件和证书具有读访问权限。
• 列表：如果使用 pull model attestation: verifier 的主机对端口 9002 上所有受监控代理具有出站访问权限。 verifier 的主机可由租户在端口 8881 上访问。 verifier 具有 mTLS 的服务器和客户端证书。
• 列表：verifier 的主机对端口 9002 上所有受监控代理具有出站访问权限。
• 命令/配置摘录：

# dnf install keylime-verifier
[verifier] ip = *

• 注意：注意 使用绝对路径定义密钥和证书位置。或者，相对路径是从 tls_dir 选项中定义的目录解析的。
• 注意：注意 mode 设置会影响验证器上的所有代理。处于 push 模式的 verifier 期望代理在测试数据时提交，它不会轮询代理。单个验证器不能同时在两个模式下运行。

6.4. 从软件包部署 Keylime 注册器

• 要点：从软件包部署 Keylime registrar，以安全地存储和管理代理的身份和关键信息。保持注册商的安全有助于维护信任链。
• 要点：注册器是包含所有代理的数据库的 Keylime 组件，它托管 TPM 供应商的公钥。在注册器的 HTTPS 服务接受可信平台模块(TPM)公钥后，它提供了一个接口来获取这些公钥以进行检查配额。
• 列表：您有访问安装和运行 Keylime 验证器的系统的网络权限。如需更多信息，请参阅
• 列表：您在要安装 Keylime 组件的系统上有 root 权限和网络连接。
• 列表：您可以访问 Keylime 保存来自注册中心的数据的数据库。您可以使用以下数据库管理系统： SQLite （默认） PostgreSQL MySQL MariaDB
• 列表：SQLite （默认）
• 列表：PostgreSQL
• 列表：MySQL
• 命令/配置摘录：

# dnf install keylime-registrar
[registrar] ip = <registrar_IP_address>

• 注意：重要 要维护信任链，请保持运行注册器的系统的安全，并在您的控制之下。
• 注意：注意 要将配置文件保留在置入目录中，请使用具有两位数字前缀的文件名，例如 /etc/keylime/registrar.conf.d/00-registrar-ip.conf。配置处理以字典顺序读取置入目录中的文件，并对每个选项设置为它读取的最后一个值。

6.5. 将 Keylime 注册器部署为容器

• 要点：将 Keylime registrar 配置为容器，而不是 RPM 方法，而无需主机上的任何二进制文件或软件包。容器部署提供更好的隔离、模块化和 Keylime 组件的可重复性。
• 要点：注册器是包含一个所有代理的数据库的 Keylime 组件，它托管可信平台模块(TPM)提供商的公钥。在注册器的 HTTPS 服务接受 TPM 公钥后，它提供一个接口来获取这些公钥，以检查引用。
• 列表：将包含配置文件的目录挂载到容器上。这在所有 RHEL 9 版本中提供。
• 列表：直接在容器上修改环境变量。这在 RHEL 9.3 及更新版本中提供。修改环境变量会覆盖配置文件中的值。
• 列表：podman 软件包及其依赖项已安装在系统上。
• 列表：可选：您可以访问 Keylime 从注册器保存数据的数据库。您可以使用以下数据库管理系统： SQLite （默认） PostgreSQL MySQL MariaDB
• 列表：SQLite （默认）
• 列表：PostgreSQL
• 命令/配置摘录：

# dnf install keylime-registrar
[registrar] ip = *

• 注意：注意 使用绝对路径定义密钥和证书位置。或者，您可以在 tls_dir 选项中定义目录，并使用相对于该目录的路径。

6.6. 使用 RHEL 系统角色部署 Keylime 服务器

• 要点：您可以使用 keylime_server RHEL 系统角色配置 verifier 和 registrar，它们是 Keylime 服务器组件。keylime_server 角色在每个节点上安装和配置 verifier 和 registrar 组件。
• 要点：有关 Keylime 的更多信息，请参阅 远程系统完整性监控。
• 列表：您已准备好控制节点和受管节点。
• 列表：以可在受管主机上运行 playbook 的用户登录到控制节点。
• 列表：用于连接到受管节点的帐户具有这些节点的 sudo 权限。
• 列表：创建定义所需角色的 playbook: 创建新 YAML 文件，并在文本编辑器中打开，例如： # vi keylime-playbook.yml 插入以下内容： --- - name: Manage keylime servers hosts: all vars: keylime_server_verifier_ip: "{​{ ansible_host }​}" keylime_server_registrar_ip: "{​{ ansible_host }​}" keylime_server_verifier_tls_dir: <ver_tls_directory> keylime_server_verifier_serv…
• 列表：创建新 YAML 文件，并在文本编辑器中打开，例如： # vi keylime-playbook.yml
• 列表：插入以下内容： --- - name: Manage keylime servers hosts: all vars: keylime_server_verifier_ip: "{​{ ansible_host }​}" keylime_server_registrar_ip: "{​{ ansible_host }​}" keylime_server_verifier_tls_dir: <ver_tls_directory> keylime_server_verifier_server_cert: <ver_server_certfile> keylime_server_verifier_server_key: <ver_…
• 命令/配置摘录：

# vi keylime-playbook.yml
--- - name: Manage keylime servers  hosts: all  vars:  keylime_server_verifier_ip: "{{ ansible_host }}"  keylime_server_registrar_ip: "{{ ansible_host }}"  keylime_server_verifier_tls_dir: <ver_tls_directory>  keylime_server_verifier_server_cert: <ver_server_certfile>  keylime_server_verifier_server_key: <ver_server_key>  keylime_server_verifier_server_key_passphrase: <ver_server_key_passphrase>  keylime_server_verifier_trusted_client_ca: <ver_trusted_client_ca_list>  keylime_server_verifier_client_cert: <ver_client_certfile>  keylime_server_verifier_client_key: <ver_client_key>  keylime_server_verifier_client_key_passphrase: <ver_client_key…

6.7. keylime_server RHEL 系统角色的变量

• 要点：当使用 keylime_server RHEL 系统角色设置 Keylime 服务器时，您可以为注册器和验证器自定义以下变量。
• 要点：用于配置 Keylime 验证器的 keylime_server RHEL 系统角色变量的列表：

6.8. 从软件包部署 Keylime 租户

• 要点：Keylime 对许多功能使用 keylime_tenant 工具，包括在目标系统上置备代理。您可以在任何系统上安装 keylime_tenant，包括运行其他 Keylime 组件的系统，或者根据要求在单独的系统上安装。
• 要点：对于 keylime_tenant 工具程序的额外高级选项，请输入 keylime_tenant -h 命令。
• 列表：您在要安装 Keylime 组件的系统上有 root 权限和网络连接。
• 列表：您对配置了其他 Keylime 组件的系统有网络访问权限： 验证器 如需更多信息，请参阅 第 6.2 节 “从软件包部署 Keylime 验证器”。 注册器 如需更多信息，请参阅 第 6.4 节 “从软件包部署 Keylime 注册器”。
• 列表：安装 Keylime 租户： # dnf install keylime-tenant
• 列表：通过编辑 /etc/keylime/tenant.conf.d/00-verifier-ip.conf 文件将租户的连接定义到 Keylime 验证器的连接： [tenant] verifier_ip = <verifier_ip> 将 <verifier_ip> 替换为验证器系统的 IP 地址。 如果验证器使用与默认值 8881 不同的端口，请添加 verifier_port = <verifier_port> 设置。
• 列表：将 <verifier_ip> 替换为验证器系统的 IP 地址。
• 列表：如果验证器使用与默认值 8881 不同的端口，请添加 verifier_port = <verifier_port> 设置。
• 命令/配置摘录：

# dnf install keylime-tenant
[tenant] verifier_ip = <verifier_ip>

• 注意：注意 使用绝对路径定义密钥和证书位置。或者，您可以在 tls_dir 选项中定义目录，并使用相对于该目录的路径。

6.9. 从软件包部署 Keylime pull-model 代理

• 要点：要持续监控系统完整性，请部署 Keylime pull-model 代理。使用这个配置，目标系统在被验证器轮询时报告其安全状态。
• 要点：默认情况下，Keylime pull-model 代理将其所有数据存储在受监控系统的 /var/lib/keylime/ 目录中。
• 列表：您有对被监控系统的 root 权限。
• 列表：监控的系统有一个受信任的平台模块(TPM)。要验证，请输入 tpm2_pcrread 命令。如果输出返回多个哈希，则代表 TPM 可用。
• 列表：您对配置了其他 Keylime 组件的系统有网络访问权限： 验证器 如需更多信息，请参阅 从软件包部署 Keylime 验证器。 注册器 如需更多信息，请参阅 从软件包部署 Keylime 注册器。 租户 如需更多信息，请参阅 从软件包部署 Keylime 租户。
• 列表：在监控的系统上启用了完整性测量架构(IMA)。如需更多信息，请参阅使用内核完整性子系统 增强安全性。
• 列表：安装 Keylime pull-model 代理： # dnf install keylime-agent-rust 这个命令会安装 keylime-agent-rust 软件包。
• 列表：在配置文件中定义代理的 IP 地址和端口。在 /etc/keylime/agent.conf.d/ 目录中创建一个新的 .conf 文件，例如：/etc/keylime/agent.conf.d/00-agent-ip.conf，其内容如下： [agent] ip = '<agent_IP_address>' 注意 Keylime 代理配置使用 TOML 格式，它与用于其他组件配置的 INI 格式不同。因此，使用有效 TOML 语法输入值，例如，在带单引号的路径以及带方括号的多个路径的数组。 将 <agent_IP_address> 替换为代理的 IP 地址。或者，使用 ip = '*' 或 ip = '0.0.0.0' 将代理绑…
• 命令/配置摘录：

# dnf install keylime-agent-rust
[agent] ip = '<agent_IP_address>'

• 注意：注意 要将配置文件保留在置入目录中，请使用具有两位数字前缀的文件名，例如 /etc/keylime/agent.conf.d/00-registrar-ip.conf。配置处理以字典顺序读取置入目录中的文件，并对每个选项设置为它读取的最后一个值。
• 注意：注意 Keylime 代理配置使用 TOML 格式，它与用于其他组件配置的 INI 格式不同。因此，使用有效 TOML 语法输入值，例如，在带单引号的路径以及带方括号的多个路径的数组。

6.10. 从软件包部署 Keylime push-model 代理

• 要点：要在 verifier 缺少对代理直接网络访问的环境中监控系统完整性，请部署 Keylime push-model 代理。使用这个配置，代理会主动将测试数据提交到验证器。
• 要点：push-model 代理是独立于标准 Keylime pull-model 代理的软件包。一次只能运行一个代理类型。
• 列表：您有对被监控系统的 root 权限。
• 列表：监控的系统有一个受信任的平台模块(TPM)。要验证，请输入 tpm2_pcrread 命令。如果输出返回多个哈希，则代表 TPM 可用。
• 列表：您有从代理到配置了其他 Keylime 组件的系统的网络访问： 验证器 verifier 必须配置为 push 模式，以便它接受来自代理的入站测试连接。如需更多信息，请参阅 从软件包部署 Keylime 验证器。 注册器 如需更多信息，请参阅 从软件包部署 Keylime 注册器。 租户 如需更多信息，请参阅 从软件包部署 Keylime 租户。
• 列表：verifier 的 CA 证书在被监控的系统上可用。您可以从验证器复制它，其中通常位于 /var/lib/keylime/cv_ca/cacert.crt。
• 列表：在监控的系统上启用了完整性测量架构(IMA)。如需更多信息，请参阅使用内核完整性子系统 增强安全性。
• 列表：安装 Keylime push-model 代理： # dnf install keylime-agent-rust-push 这个命令会安装 keylime-agent-rust-push 软件包及其依赖项，包括 keylime-agent-rust-common 和 keylime-base。
• 命令/配置摘录：

# dnf install keylime-agent-rust-push
[agent] verifier_url = 'https://<verifier_IP_address>:8881'

• 注意：注意 要将配置文件保留在置入目录中，请使用带有两位数字前缀的文件名，例如 /etc/keylime/agent.conf.d/00-verifier-url.conf。配置处理以字典顺序读取置入目录中的文件，并对每个选项设置为它读取的最后一个值。
• 注意：注意 Keylime 代理配置使用 TOML 格式，它与用于其他组件配置的 INI 格式不同。因此，使用有效 TOML 语法输入值，例如，在带单引号的路径以及带方括号的多个路径的数组。

6.11. 为运行时监控配置 Keylime

• 要点：要验证受监控系统的状态是否正确，请在被监控的系统上设置 Keylime 代理。
• 要点：在置备代理时，您还可以定义 Keylime 发送到被监控系统的文件。Keylime 对发送到代理的文件进行加密，只有在代理系统符合 TPM 策略并使用 IMA allowlist 时才解密。
• 列表：您有对配置了 Keylime 组件的系统的网络访问权限： 验证器 如需更多信息，请参阅 从软件包部署 Keylime 验证器。 注册器 如需更多信息，请参阅 从软件包部署 Keylime 注册器。 租户 如需更多信息，请参阅 从软件包部署 Keylime 租户。 Agent 如果您在测试时使用拉取模型：如需更多信息，请参阅从 软件包 部署 Keylime pull-model 代理。 如果您在测试时使用推送模型：如需更多信息，请参阅从 软件包 部署 Keylime push-model 代理。
• 列表：如果您在测试时使用拉取模型：如需更多信息，请参阅从 软件包 部署 Keylime pull-model 代理。
• 列表：如果您在测试时使用推送模型：如需更多信息，请参阅从 软件包 部署 Keylime push-model 代理。
• 列表：在配置并运行了 Keylime 代理的被监控系统上，安装 python3-keylime 软件包，其包含 keylime-policy 工具： # dnf -y install python3-keylime
• 列表：从代理系统的当前状态创建一个运行时策略： # keylime-policy create runtime --ima-measurement --rootfs '/' --ramdisk-dir '/boot/' --output <policy.json> 在这个命令中， 将 <policy.json> 替换为运行时策略的文件名。 以下目录会自动从测量中排除： /sys /run /proc /lost+found /dev /media /snap /mnt /var /tmp 另外，您可以通过添加 --excludelist <excludelist.txt> 选项，从测量中排除其他具体的路径。excludelist 接受 …
• 列表：将 <policy.json> 替换为运行时策略的文件名。
• 命令/配置摘录：

# dnf -y install python3-keylime
# keylime-policy create runtime --ima-measurement --rootfs '/' --ramdisk-dir '/boot/' --output <policy.json>

• 注意：重要 运行时监控依赖于 Linux 内核完整性测量架构(IMA)在访问时测量文件。过度广泛的 IMA 策略可能会增加 I/O 操作和 CPU 用量。要最小化对您的系统的性能影响，请配置 IMA 策略来仅测量关键文件。
• 注意：重要 安全有效负载交付只能通过 pull-model attestation 提供。push 模型不支持向代理提供加密文件。不要将- cert 选项与 push-model 代理一起使用。如果您指定这个选项，系统会生成证书，但永远不会将它们传送到代理。

6.12. 为测量的引导证明配置 Keylime

• 要点：要确保您的系统引导至可信状态，请配置 Keylime，以将 UEFI 引导事件测量与已知良好的引用值进行比较。
• 要点：先决条件
• 列表：您有对配置了 Keylime 组件的系统的网络访问权限： 验证器 如需更多信息，请参阅 从软件包部署 Keylime 验证器。 注册器 如需更多信息，请参阅 从软件包部署 Keylime 注册器。 租户 如需更多信息，请参阅 从软件包部署 Keylime 租户。 Agent 如果您在测试时使用拉取模型：如需更多信息，请参阅从 软件包 部署 Keylime 代理。 如果您在测试时使用推送模型：如需更多信息，请参阅从 软件包 部署 Keylime push-model 代理。
• 列表：如果您在测试时使用拉取模型：如需更多信息，请参阅从 软件包 部署 Keylime 代理。
• 列表：如果您在测试时使用推送模型：如需更多信息，请参阅从 软件包 部署 Keylime push-model 代理。
• 列表：在代理系统上启用了统一可扩展固件接口(UEFI)。
• 列表：在配置并运行了 Keylime 代理的被监控系统上，安装 python3-keylime 软件包，其包含 keylime-policy 工具： # dnf -y install python3-keylime
• 列表：在被监控的系统上，使用 keylime-policy 工具从测量的系统的当前状态的引导日志生成一个策略： # keylime-policy create measured-boot --eventlog-file /sys/kernel/security/tpm0/binary_bios_measurements --output <measured_boot_reference_state.json> 将 <measured_boot_reference_state.json > 替换为 keylime-policy 保存生成的策略的路径。 如果您的 UEFI 系统没有启用安全引导，请传递 --without-secureboo…
• 命令/配置摘录：

# dnf -y install python3-keylime
# keylime-policy create measured-boot --eventlog-file /sys/kernel/security/tpm0/binary_bios_measurements --output <measured_boot_reference_state.json>

• 注意：重要 使用 keylime-policy 生成的策略是基于系统的当前状态，且非常严格。任何系统修改，包括内核更新和系统更新都会更改引导过程，系统就会失败。

6.13. Keylime 配置

• 要点：要安全自定义 Keylime 组件、日志记录和证书颁发机构，而无需修改默认配置文件，您可以使用置入文件或环境变量。这些方法可防止配置错误，并允许您覆盖标准和容器化部署中的设置。
• 要点：您可以在 podman run 命令中使用 a -e 选项将环境变量传递给容器。
• 列表：<SECTION> 是 Keylime 配置文件部分。
• 列表：<ENVIRONMENT_VARIABLE> 是环境变量。
• 列表：<value> 是您要设置环境变量的值。
• 命令/配置摘录：

KEYLIME_<SECTION>_<ENVIRONMENT_VARIABLE>=<value>

6.13.1. 常规验证器配置

• 要点：要自定义验证器，您可以在 /etc/keylime/verifier.conf.d/ 目录中添加配置置入文件。这些置入文件会使自定义设置与默认配置分开，以防止系统更新过程中出现错误。
• 表格样本（共 43 行）：
  • 配置选项 | 环境变量 | 默认值
  • auto_migrate_db | KEYLIME_VERIFIER_AUTO_MIGRATE_DB | True
  • client_cert | KEYLIME_VERIFIER_CLIENT_CERT | default
  • client_key_password | KEYLIME_VERIFIER_CLIENT_KEY_PASSWORD

6.13.2. push 模型的额外验证器配置

• 要点：要为推送模型自定义 verifier，您可以在 /etc/keylime/verifier.conf.d/ 目录中添加配置置入文件。这些置入文件会使自定义设置与默认配置分开，以防止系统更新过程中出现错误。
• 要点：quote_interval 选项是一个常规的 verifier 选项，供拉取和推送模型使用。在推送模型中，它用于派生代理在测试超时阈值。
• 表格样本（共 13 行）：
  • 配置选项 | 环境变量 | 默认值 | 描述
  • 模式 | KEYLIME_VERIFIER_MODE | pull | attestation 模式。设置为 push 以启用 push-model attestation。单个验证器不能同时在两个模式下运行。
  • quote_interval | KEYLIME_VERIFIER_QUOTE_INTERVAL | 2 | 测试检查之间的间隔（以秒为单位）。在 pull 模型中，这是轮询间隔。在推送模型中，代理超时作为 quote_interval * 5 派生。在此期间没有 attest 的代理被标记为失败。
  • challenge_lifetime | KEYLIME_VERIFIER_CHALLENGE_LIFETIME | 1800 | 发送到代理的 PoP 挑战的时间（以秒为单位）(30 分钟)。在此期限内未回答的挑战。

6.13.3. 注册器配置

• 要点：要自定义 registrar，您可以在 /etc/keylime/registrar.conf.d/ 目录中添加配置置入文件。这些置入文件会使自定义设置与默认配置分开，以防止系统更新过程中出现错误。
• 表格样本（共 23 行）：
  • 配置选项 | 环境变量 | 默认值
  • auto_migrate_db | KEYLIME_REGISTRAR_AUTO_MIGRATE_DB | True
  • database_pool_sz_ovfl | KEYLIME_REGISTRAR_DATABASE_POOL_SZ_OVFL | 5,10
  • database_url | KEYLIME_REGISTRAR_DATABASE_URL | SQLite

6.13.4. 租户配置

• 要点：要自定义租户，您可以在 /etc/keylime/tenant.conf.d/ 目录中添加配置置入文件。这些置入文件会使自定义设置与默认配置分开，以防止系统更新过程中出现错误。
• 表格样本（共 24 行）：
  • 配置选项 | 环境变量 | 默认值
  • accept_tpm_encryption_algs | KEYLIME_TENANT_ACCEPT_TPM_ENCRYPTION_ALGS | ecc, rsa
  • accept_tpm_hash_algs | KEYLIME_TENANT_ACCEPT_TPM_HASH_ALGS | sha512, sha384, sha256
  • accept_tpm_signing_algs | KEYLIME_TENANT_ACCEPT_TPM_SIGNING_ALGS | ecschnorr, rsassa

6.13.5. CA 配置

• 要点：要自定义证书颁发机构，您可以在 /etc/keylime/ca.conf.d/ 目录中添加配置置入文件。这些置入文件会使自定义设置与默认配置分开，以防止系统更新过程中出现错误。
• 表格样本（共 13 行）：
  • 配置选项 | 环境变量 | 默认值
  • cert_bits | KEYLIME_CA_CERT_BITS | 2048
  • cert_ca_lifetime | KEYLIME_CA_CERT_CA_LIFETIME | 3650
  • cert_ca_name | KEYLIME_CA_CERT_CA_NAME | Keylime Certificate Authority

6.13.6. 常规代理配置

• 要点：要自定义代理，您可以在 /etc/keylime/agent.conf.d/ 目录中添加配置置入文件。这些置入文件会使自定义设置与默认配置分开，以防止系统更新过程中出现错误。代理配置使用 TOML 格式。
• 表格样本（共 36 行）：
  • 配置选项 | 环境变量 | 默认值
  • contact_ip | KEYLIME_AGENT_CONTACT_IP | 127.0.0.1
  • contact_port | KEYLIME_AGENT_CONTACT_PORT | 9002
  • dec_payload_file | KEYLIME_AGENT_DEC_PAYLOAD_FILE | decrypted_payload

6.13.7. push 模型的额外代理配置

• 要点：要为推送模型自定义代理，您可以在 /etc/keylime/agent.conf.d/ 目录中添加配置置入文件。这些置入文件会使自定义设置与默认配置分开，以防止系统更新过程中出现错误。代理配置使用 TOML 格式。
• 要点：由 keylime-agent-rust-push 软件包提供的 push-model 代理共享与默认 pull-model 代理相同的配置文件。以下选项特定于 push-model 部署，或主要与 push-model 部署相关。有些选项在 push-model attestation 中有所不同。这些区别在 Description 列中记录。
• 注意：警告 禁用 TLS 验证会公开您的基础架构到中间人攻击。在生产环境中，永远不会启用绕过 TLS 检查的选项。仅在测试环境中使用这些不安全的设置来排除部署问题。
• 表格样本（共 17 行）：
  • 配置选项 | 环境变量 | 默认值 | 描述
  • verifier_url | KEYLIME_AGENT_VERIFIER_URL | https://localhost:8881 | Keylime verifier 的 URL，包括 schema、主机和端口。必须使用 HTTPS。
  • verifier_tls_ca_cert | KEYLIME_AGENT_VERIFIER_TLS_CA_CERT | default | 用于验证 verifier 的 TLS 服务器证书的 CA 证书的路径。当设置为 default 时，会使用相对于 keylime_dir 的路径 cv_ca/cacert.crt。
  • attestation_interval_seconds | KEYLIME_AGENT_ATTESTATION_INTERVAL_SECONDS | 60 | 在测试周期时推送之间的回退间隔（以秒为单位）。verifier 通过在其响应有效负载中返回 seconds_to_next_attestation 来动态覆盖此参数。代理在初始启动期间使用 attestation_interval_seconds，或者在不存在 verifier 响应时使用。这个值必须小于验证器的超时时间(quote_interval * 5)。

6.13.8. 日志记录配置

• 要点：要自定义日志记录，您可以在 /etc/keylime/logging.conf.d/ 目录中添加配置置入文件。这些置入文件会使自定义设置与默认配置分开，以防止系统更新过程中出现错误。
• 表格样本（共 2 行）：
  • 配置选项 | 环境变量 | 默认值
  • version | KEYLIME_LOGGING_VERSION | 2.0

第 7 章 使用 AIDE 检查完整性

• 要点：使用 RHEL 中的高级入侵检测环境(AIDE)实用程序来创建文件数据库并检查系统文件的完整性。这个功能有助于通过报告未经授权的更改来检测入侵。

7.1. 安装 AIDE

• 要点：要使用 AIDE 启动文件完整性检查，您必须安装相应的软件包并启动 AIDE 数据库。
• 要点：先决条件
• 列表：AppStream存储库已启用。
• 列表：安装 aide 软件包： # dnf install aide
• 列表：生成一个初始数据库： # aide --init Start timestamp: 2024-07-08 10:39:23 -0400 (AIDE 0.16) AIDE initialized database at /var/lib/aide/aide.db.new.gz Number of entries: 55856 --------------------------------------------------- The attributes of the (uncompressed) database(s): --------------------------------------------------- /v…
• 列表：可选：在默认配置中，aide --init 命令只检查 /etc/aide.conf 文件中定义的一组目录和文件。要在 AIDE 数据库中包含其他目录或文件，并更改其监视的参数，请相应地编辑 /etc/aide.conf。
• 列表：要开始使用数据库，请从初始数据库文件名中删除 .new 子字符串： # mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
• 列表：可选：要更改 AIDE 数据库的位置，请编辑 /etc/aide.conf 文件，并修改 DBDIR 值。要获得额外的安全性，请将数据库、配置和 /usr/sbin/aide 二进制文件存储在安全的位置，如只读介质。
• 命令/配置摘录：

# dnf install aide
# aide --init Start timestamp: 2024-07-08 10:39:23 -0400 (AIDE 0.16) AIDE initialized database at /var/lib/aide/aide.db.new.gz Number of entries: 55856 --------------------------------------------------- The attributes of the (uncompressed) database(s): --------------------------------------------------- /var/lib/aide/aide.db.new.gz …  SHA512 : mZaWoGzL2m6ZcyyZ/AXTIowliEXWSZqx  IFYImY4f7id4u+Bq8WeuSE2jasZur/A4  FPBFaBkoCFHdoE/FW/V94Q==

7.2. 使用 AIDE 执行完整性检查

• 要点：通过将当前文件状态与其内部数据库进行比较，使用高级入侵检测环境(AIDE)来执行文件完整性检查。此检查会生成自上次运行以来的更改的详细报告。您可以使用 crond 服务来调度 AIDE 的常规检查。
• 要点：先决条件
• 列表：AIDE 已正确安装，其数据库已初始化。请参阅 安装 AIDE
• 列表：启动手动检查： # aide --check Start timestamp: 2024-07-08 10:43:46 -0400 (AIDE 0.16) AIDE found differences between database and file system!! Summary: Total number of entries: 55856 Added entries: 0 Removed entries: 0 Changed entries: 1 --------------------------------------------------- Changed entries: ---------------…
• 列表：至少，将系统配置为每周运行 AIDE。最好每天运行 AIDE。例如，要使用 cron 命令计划在每日 04:05 a.m. 执行 AIDE，请在 /etc/crontab 文件中添加以下行： 05 4 * * * root /usr/sbin/aide --check 有关 crond 调度守护进程的详情，请查看您系统中的 cron (8) 手册页。
• 命令/配置摘录：

# aide --check Start timestamp: 2024-07-08 10:43:46 -0400 (AIDE 0.16) AIDE found differences between database and file system!! Summary:  Total number of entries: 55856  Added entries: 0  Removed entries: 0  Changed entries: 1 --------------------------------------------------- Changed entries: --------------------------------------------------- f ... ..S : /root/.viminfo --------------------------------------------------- Detailed information about changes: --------------------------------------------------- File: /root/.viminfo  SELinux : system_u:object_r:admin_home_t:s | unconfined_u:object_r:admin_home  0 | _t:s0 …
05 4 * * * root /usr/sbin/aide --check

7.3. 更新 AIDE 数据库

• 要点：在进行合法系统更改后更新 AIDE 数据库，如安装软件更新。此操作可防止后续完整性检查过程中出现假的正状态。
• 要点：先决条件
• 列表：AIDE 已正确安装，其数据库已初始化。请参阅 安装 AIDE
• 列表：更新您的基准 AIDE 数据库： # aide --update aide --update 命令创建 /var/lib/aide/aide.db.new.gz 数据库文件。
• 列表：若要开始使用更新的数据库进行完整性检查，请从文件名中删除 .new 子字符串。
• 命令/配置摘录：

# aide --update

7.4. 文件完整性工具：AIDE 和 IMA

• 要点：比较文件完整性工具、AIDE 和完整性测量架构(IMA)，以选择最适合您的场景。这有助于您决定检查和保留文件完整性的适当方法。
• 表格样本（共 6 行）：
  • 问题 | 高级入侵检测环境(AIDE) | 完整性测量架构 (IMA)
  • 什么 | AIDE 是一个在系统上创建文件和目录数据库的工具。此数据库用于检查文件完整性及检测入侵检测。 | IMA 通过检查与之前存储的扩展属性相比的文件度量（哈希值）来检查文件是否被修改了。
  • 如何 | AIDE 使用规则来比较文件和目录的完整性状态。 | IMA 使用文件哈希值来检测入侵。
  • 为什么 | 检测 - AIDE 通过验证规则来检测文件是否被修改。 | 检测和防止 - IMA 通过替换文件的扩展属性来检测和防止攻击。

7.5. 使用 aide RHEL 系统角色配置文件完整性检查

• 要点：您可以使用 aide RHEL 系统角色在多个系统中一致地配置高级入侵检测环境(AIDE)。该角色会自动将 aide 软件包安装到所有受管节点上。
• 要点：根据您的配置，ide 角色可以执行以下操作：
• 列表：初始化 AIDE 数据库，并将其保存在控制节点上
• 列表：在受管节点上运行 AIDE 完整性检查
• 列表：更新 AIDE 数据库，并将其保存在控制节点上
• 列表：您已准备好控制节点和受管节点。
• 列表：以可在受管主机上运行 playbook 的用户登录到控制节点。
• 列表：用于连接到受管节点的帐户具有这些节点的 sudo 权限。
• 命令/配置摘录：

--- - name: Configure system integrity  hosts: managed-node-01.example.com  tasks:  - name: Configure file integrity checks with AIDE  ansible.builtin.include_role:  name: rhel-system-roles.aide.aide  vars:  aide_db_fetch_dir: files  aide_init: true  aide_check: false  aide_update: false  aide_cron_check: true  aide_cron_interval: 0 12 * * *
$ ansible-playbook --syntax-check ~/playbook.yml

7.6. 其他资源

• 列表：使用内核完整性子系统提高安全性

第 8 章 管理 sudo 访问

• 要点：管理 sudo 访问权限，以允许非 root 用户在不登录 root 帐户的情况下安全地使用管理命令。正确的配置有助于控制权限和限制暴露。

8.1. sudoers 中的用户授权

• 要点：在 RHEL 中，/etc/sudoers 文件和 /etc/sudoers.d/ 目录存储 sudo 命令的用户和组授权。您可以使用这些配置来指定哪些用户可以在特定主机上输入管理命令。
• 要点：您可以将规则应用到单个用户和用户组。要简化主机组、命令和用户的配置，您可以使用别名。/etc/sudoers 文件在第一部分定义默认别名。
• 列表：<username> 是输入命令的用户，如 user1。如果该值以 % 开头，它定义一个组，例如 %group1。
• 列表：<hostname.example.com> 是应用规则的主机的名称。
• 列表：(<run_as_user>:<run_as_group>) 部分 定义以其身份执行命令的用户或组。如果省略这个部分，< username> 请以 root 用户身份使用该命令。
• 列表：<path/to/command> 是命令的完整的绝对路径。您还可以通过在命令路径后面添加这些选项，将用户限制为仅使用特定的选项和参数执行命令。如果没有指定任何选项，用户可以使用带有所有选项的命令。
• 命令/配置摘录：

## Next comes the main part: which users can run what software on ## which machines (the sudoers file can be shared between multiple ## systems).
<username> <hostname.example.com>=(<run_as_user>:<run_as_group>) <path/to/command>

• 注意：警告 使用过于宽松的规则（如 ALL=(ALL) ALL ），所有用户都可以在所有主机上以所有用户的身份运行所有命令。这带来了严重的安全风险。
• 注意：警告 避免对命令使用负规则，因为用户可以通过使用 alias 命令重命名命令来克服此类规则。

8.2. 为用户授予 sudo 访问权限

• 要点：在 RHEL 中，您可以通过授予 sudo 访问权限来允许非 root 用户进入管理命令。这样可确保用户可以安全地执行特权任务，而无需 root 用户的密码。
• 要点：当用户需要执行管理命令时，您可以在使用 sudo 命令前执行该命令。如果用户有命令的授权，则可以执行命令，就像他们是 root 一样。
• 列表：只有 /etc/sudoers 配置文件中列出的用户才能使用 sudo 命令。
• 列表：命令在用户的 shell 下执行，而不是在 root shell 下执行。但是，有一些例外情况，如向任何用户授予完整的 sudo 权限时。在这种情况下，用户可以切换到 root shell ，并在 root shell 中运行命令。例如：
• 列表：sudo -i
• 列表：sudo su -
• 列表：有对系统的 root 访问权限。
• 列表：以 root 身份，打开 /etc/sudoers 文件。 # visudo /etc/sudoers 文件定义 sudo 命令应用的策略。
• 命令/配置摘录：

# visudo
## Allows people in group wheel to run all commands %wheel ALL=(ALL) ALL

8.3. 使非特权用户运行某些命令

• 要点：作为管理员，您可以通过在 /etc/sudoers.d/ 目录中配置策略来允许非特权用户在特定工作站上输入某些命令。与授予完整的 sudo 访问权限相比，这有助于提高安全性。
• 要点：指定只允许某些命令的安全，而不是授予用户完全 sudo 访问权限，或者为某人授予 root 密码，理由如下：
• 列表：对特权操作的更精细控制。您可以允许用户对特定主机执行某些操作，而不是向他们提供完全的管理权限。
• 列表：更好的日志记录.当用户使用 sudo 执行操作时，该操作将使用其用户名进行记录，而不仅仅是 root。
• 列表：透明控制。当用户尝试使用 sudo 权限时，您可以设置电子邮件通知。
• 列表：有对系统的 root 访问权限。
• 列表：以 root 用户身份，在 /etc/ 下创建一个新的 sudoers.d/ 目录： # mkdir -p /etc/sudoers.d/
• 列表：在 /etc/sudoers.d/ 目录中创建一个新文件： # visudo -f /etc/sudoers.d/<filename> 文件会自动打开。
• 命令/配置摘录：

# mkdir -p /etc/sudoers.d/
# visudo -f /etc/sudoers.d/<filename>

8.4. 使用 RHEL 系统角色应用自定义 sudoers 配置

• 要点：您可以使用 sudo RHEL 系统角色在受管节点上应用自定义 sudoers 配置。这样，您可以定义哪些用户可以在哪些主机上运行哪些命令，从而获得更好的配置效率和更精细的控制。
• 要点：先决条件
• 列表：您已准备好控制节点和受管节点。
• 列表：以可在受管主机上运行 playbook 的用户登录到控制节点。
• 列表：用于连接到受管节点的帐户具有这些节点的 sudo 权限。
• 列表：创建一个包含以下内容的 playbook 文件，如 ~/playbook.yml ： --- - name: "Configure sudo" hosts: managed-node-01.example.com tasks: - name: "Apply custom /etc/sudoers configuration" ansible.builtin.include_role: name: redhat.rhel_system_roles.sudo vars: sudo_sudoers_files: - path: "/etc/sudoers" user_specifications: - users: …
• 列表：验证 playbook 语法： $ ansible-playbook --syntax-check ~/playbook.yml 请注意，这个命令只验证语法，不能防止错误的、但有效的配置。
• 列表：运行 playbook： $ ansible-playbook ~/playbook.yml
• 命令/配置摘录：

--- - name: "Configure sudo"  hosts: managed-node-01.example.com  tasks:  - name: "Apply custom /etc/sudoers configuration"  ansible.builtin.include_role:  name: redhat.rhel_system_roles.sudo  vars:  sudo_sudoers_files:  - path: "/etc/sudoers"  user_specifications:  - users:  - <user_name>  hosts:  - <host_name>  commands:  - <path_to_command_binary>
$ ansible-playbook --syntax-check ~/playbook.yml

第 9 章 使用基于策略的解密配置加密卷的自动解锁

• 要点：基于策略的解密(PBD)启用解锁物理和虚拟机上的加密根和辅助存储卷。PBD 使用各种解锁方法，如用户密码、受信任的平台模块(TPM)设备、PKCS installation 设备或网络服务器。
• 要点：PBD 允许将不同的解锁方法合并成一个策略，从而可以以不同的方式解锁同一个卷。Red Hat Enterprise Linux 中 PBD 的当前实现由 Clevis 框架和称为 pins 的插件组成。每个 pin 都提供单独的解锁功能。目前，可提供以下 pins ：

9.1. 网络绑定磁盘加密

• 要点：网络绑定的 Disc Encryption (NBDE)是基于策略的解密(PBD)的子类别，允许将加密卷绑定到特殊的网络服务器。NBDE 的当前实现包括 Tang 服务器的 Clevis pin 和 Tang 服务器本身。
• 要点：Clevis 和 Tang 是通用的客户端和服务器组件，提供网络绑定加密。在 RHEL 中，它们与 LUKS 一起使用，以加密和解密 root 和非 root 存储卷，从而完成网络绑定磁盘加密。

9.1.1. NBDE 组件

• 要点：在 RHEL 中，NBDE 通过以下组件和技术实现：
• 要点：图 9.1. 使用 LUKS1 加密的卷时的 NBDE 方案。luksmeta 不用于 LUKS2 卷。

9.1.2. NBDE 原则

• 要点：当您开始调配 NBDE 时，Tang 服务器的 Clevis pin 将获得 Tang 服务器发布的非对称密钥的列表。或者，由于密钥是非对称的，因此 Tang 的公钥列表可以分发到带外，以便客户端能够在不访问 Tang 服务器的情况下进行操作。此模式称为 脱机调配。
• 要点：Tang 的 Clevis pin 使用其中一个公钥来生成唯一的、加密强的加密密钥。使用此密钥加密数据后，密钥将被丢弃。Clevis 客户端应将此调配操作生成的状态存储在方便的位置。这种加密数据的过程就是 调配步骤。
• 列表：NBDE （网络绑定磁盘加密）技术（红帽知识库）
• 列表：如何配置具有多个 LUKS 设备的网络绑定磁盘加密(Clevis + Tang 解锁) （红帽知识库）
• 注意：注意 如果将 kdump 内核崩溃转储机制设置为将系统内存的内容保存到 LUKS 加密的设备中，则会在第二次内核引导时提示您输入密码。这发生在第二次内核引导期间。

9.2. 部署 Tang 服务器

• 要点：您可以使用 Tang 服务器自动解锁启用了 Clevis 的客户端上的 LUKS 加密卷。在最小的场景中，您可以通过安装其软件包并输入单个命令来部署 Tang 服务器。
• 要点：先决条件
• 列表：以 # 命令提示符开头的命令需要 sudo 提供的管理特权或 root 用户访问权限。有关如何配置 sudo 访问权限的详情，请参考 使非特权用户能够运行某些命令。
• 列表：安装 tang 软件包及其依赖项： # dnf install tang
• 列表：启动并启用 tangd 服务： # systemctl enable tangd.socket --now 由于 tangd 使用了 systemd 套接字激活机制，因此服务器会在第一次连接进来时就立即启动。在第一次启动时会自动生成一组新的加密密钥。要执行手动生成密钥等加密操作，请使用您系统上的 jose (1) 手册页中所述。
• 列表：在您的 NBDE 客户端上，使用以下命令验证您的 Tang 服务器是否正常工作。命令必须返回与您为加密和解密传递的相同的消息： # echo test | clevis encrypt tang '{"url":"<tang.server.example.com:80>"}' -y | clevis decrypt test
• 列表：有关 80 之外的端口上的部署，请参阅 部署 SELinux 处于 enforcing 模式的 Tang 服务器。
• 命令/配置摘录：

# dnf install tang
# systemctl enable tangd.socket --now

9.3. 部署 SELinux 处于 enforcing 模式的 Tang 服务器

• 要点：您服务器上的其他服务可能占用了端口 80，Tang 服务器默认使用这个端口。在这种情况下，您可以在自定义端口上部署 Tang。理想情况下，在 SELinux Enforcement 模式下作为受限服务运行。
• 要点：先决条件
• 列表：policycoreutils-python-utils 包及其依赖项已经安装。
• 列表：firewalld 服务正在运行。
• 列表：要安装 tang 软件包及其依赖项，请以 root 用户身份输入以下命令： # dnf install tang
• 列表：选择一个未被占用的端口，例如 7500/tcp，并允许 tangd 服务绑定到该端口： # semanage port -a -t tangd_port_t -p tcp 7500 请注意，一个端口一次只能被一个服务使用。
• 列表：在防火墙中打开端口： # firewall-cmd --add-port=7500/tcp # firewall-cmd --runtime-to-permanent
• 列表：启用 tangd 服务： # systemctl enable tangd.socket
• 命令/配置摘录：

# dnf install tang
# semanage port -a -t tangd_port_t -p tcp 7500

9.4. 轮转 Tang 服务器密钥并更新客户端上的绑定

• 要点：为安全起见，轮转 Tang 服务器密钥,并定期更新客户端上的现有绑定。轮转它们的确切间隔取决于您的应用程序、密钥大小以及机构策略。
• 要点：先决条件
• 列表：Tang 服务器在运行。
• 列表：clevis 和 clevis-luks 软件包已安装在您的客户端上。
• 列表：重命名 /var/db/tang 密钥数据库目录中的所有密钥，使其前面有一个 .，将它们隐藏起来，以防被看到。请注意，以下示例中的文件名与 Tang 服务器的密钥数据库目录中的独特文件名不同： # cd /var/db/tang # ls -l -rw-r--r--. 1 root root 349 Feb 7 14:55 UV6dqXSwe1bRKG3KbJmdiR020hY.jwk -rw-r--r--. 1 root root 354 Feb 7 14:55 y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk # mv UV6dqXSwe1bRKG3KbJmdiR020hY.jwk .UV6dqXSwe1bRKG…
• 列表：检查是否重命名了，是否隐藏了 Tang 服务器中的所有密钥： # ls -l total 0
• 列表：使用 /usr/libexec/tangd-keygen 命令，在Tang 服务器上的 /var/db/tang 中生成新的密钥： # /usr/libexec/tangd-keygen /var/db/tang # ls /var/db/tang 3ZWS6-cDrCG61UPJS2BMmPU4I54.jwk zyLuX6hijUy_PSeUEFDi7hi38.jwk
• 列表：检查您的 Tang 服务器是否可以显示新密钥对的签名密钥，例如： # tang-show-keys 7500 3ZWS6-cDrCG61UPJS2BMmPU4I54
• 命令/配置摘录：

# cd /var/db/tang # ls -l -rw-r--r--. 1 root root 349 Feb 7 14:55 UV6dqXSwe1bRKG3KbJmdiR020hY.jwk -rw-r--r--. 1 root root 354 Feb 7 14:55 y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk # mv UV6dqXSwe1bRKG3KbJmdiR020hY.jwk .UV6dqXSwe1bRKG3KbJmdiR020hY.jwk # mv y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk .y9hxLTQSiSB5jSEGWnjhY8fDTJU.jwk
# ls -l total 0

• 注意：警告 在客户端仍在使用旧密钥时删除旧密钥可能会导致数据丢失。如果您意外删除了这些密钥，请在客户端上使用 clevis luks regen 命令，并手动提供您的 LUKS 密码。

9.5. 在 web 控制台中使用 Tang 密钥配置自动解锁

• 要点：您可以使用 RHEL web 控制台 GUI 中的 Tang 服务器提供的密钥自动配置 LUKS 加密存储设备的自动解锁。
• 要点：先决条件
• 列表：您已安装了 RHEL 10 web 控制台。 具体步骤请参阅安装并启用 Web 控制台。
• 列表：cockpit-storaged 和 clevis-luks 软件包已安装在您的系统上。
• 列表：cockpit.socket服务运行在9090端口。
• 列表：Tang 服务器可用。详情请参阅 使用 SELinux enforcing 模式部署 Tang 服务器。
• 列表：您有 root 权限或使用 sudo 输入管理命令的权限。
• 列表：登录到 RHEL 10 web 控制台。
• 命令/配置摘录：

# tang-show-keys 7500 x100_1k6GPiDOaMlL3WbpCjHOy9ul1bSfdhI3M08wO0
# lsinitrd | grep clevis-luks lrwxrwxrwx 1 root root 48 Jan 4 02:56 etc/systemd/system/cryptsetup.target.wants/clevis-luks-askpass.path -> /usr/lib/systemd/system/clevis-luks-askpass.path …

9.6. 基本的 NBDE 和 TPM2 加密客户端操作

• 要点：您可以在包含纯文本文件的示例中了解 Clevis 提供的基本功能。您还可以使用它们来对 NBDE 或 Clevis+TPM 部署进行故障排除。
• 要点：Clevis 框架可以加密纯文本文件，并解密 JSON Web 加密(JWE)格式的加密文本和 LUKS 加密的块设备。Clevis 客户端可以使用 Tang 网络服务器、受信任的平台模块 2.0 (TPM 2.0)芯片或 PKCS modprobe 设备进行加密操作。
• 列表：要检查 Clevis 加密客户端是否绑定到 Tang 服务器，请使用 clevis encrypt tang 子命令： $ clevis encrypt tang '{"url":"http://tang.srv:port"}' < input-plain.txt > secret.jwe The advertisement contains the following signing keys: _OsIk0T-E2l6qjfdDiwVmidoZjA Do you wish to trust these keys? [ynYN] y 更改上例中的 http://tang.srv:port URL，使其与安装了 tang 的服务器…
• 列表：要解密数据，请使用 clevis decrypt 命令并提供密码文本(JWE)： $ clevis decrypt < secret.jwe > output-plain.txt
• 列表：不带任何参数的 clevis、clevis decrypt 和 clevis encrypt tang 命令会显示内置的 CLI 帮助，例如： $ clevis encrypt tang Usage: clevis encrypt tang CONFIG < PLAINTEXT > JWE …
• 列表：如需更多信息和示例，请参阅系统上的 clevis-encrypt-tang ( 1)、clevis-luks-unlockers (7) 和 clevis (1) 手册页。
• 列表：要使用 TPM 2.0 芯片进行加密，请使用 clevis encrypt tpm2 子命令以及唯一参数(JSON 配置对象的形式)： $ clevis encrypt tpm2 '{}' < input-plain.txt > secret.jwe 要选择不同的层次结构、哈希和密钥算法，请指定配置属性，例如： $ clevis encrypt tpm2 '{"hash":"sha256","key":"rsa"}' < input-plain.txt > secret.jwe
• 列表：要解密数据，请提供 JSON Web 加密(JWE)格式的密码文本： $ clevis decrypt < secret.jwe > output-plain.txt
• 命令/配置摘录：

$ clevis encrypt tang '{"url":"http://tang.srv:port"}' < input-plain.txt > secret.jwe The advertisement contains the following signing keys: _OsIk0T-E2l6qjfdDiwVmidoZjA Do you wish to trust these keys? [ynYN] y
$ curl -sfg http://tang.srv:port/adv -o adv.jws

• 注意：警告 PCR 中的哈希值可以被重写，导致您无法再解锁加密的卷。因此，添加一个强大的密码短语，可让您手动解锁加密的卷，即使 PCR 中的值发生了变化。 如果在升级 shim-x64 软件包后，系统无法自动解锁加密的卷，请按照红帽知识库解决方案 重启后，Clevis TPM2 不再解密 LUKS 设备 中的步骤操作。

9.7. 为自动解锁 LUKS 加密的卷配置 NBDE 客户端

• 要点：使用 Clevis 框架，您可以在所选的 Tang 服务器可用时配置客户端来自动解锁 LUKS 加密卷。这创建一个 NBDE （网络绑定磁盘加密）部署。
• 要点：先决条件
• 列表：Tang 服务器正在运行且可用。
• 列表：要自动解锁现有的 LUKS 加密卷，请安装 clevis-luks 子软件包： # dnf install clevis-luks
• 列表：识别 PBD 的 LUKS 加密卷。在以下示例中，块设备是指 /dev/sda2 ： # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 12G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 11G 0 part └─luks-40e20552-2ade-4954-9d56-565aa7994fb6 253:0 0 11G 0 crypt ├─rhel-root 253:0 0 9.8G 0 lvm / └─rhel-swap 253:1 0 1.2G 0 lvm [SWAP]
• 列表：使用 clevis luks bind 命令将卷绑定到 Tang 服务器： # clevis luks bind -d /dev/sda2 tang '{"url":"http://tang.srv"}' The advertisement contains the following signing keys: _OsIk0T-E2l6qjfdDiwVmidoZjA Do you wish to trust these keys? [ynYN] y You are about to initialize a LUKS device for metadata storage. Attempting to initialize it…
• 列表：使用与 LUKS 主密钥相同的无序状态测量法创建新的密钥。
• 列表：使用 Clevis 加密新密钥.
• 命令/配置摘录：

# dnf install clevis-luks
# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 12G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 11G 0 part  └─luks-40e20552-2ade-4954-9d56-565aa7994fb6 253:0 0 11G 0 crypt  ├─rhel-root 253:0 0 9.8G 0 lvm /  └─rhel-swap 253:1 0 1.2G 0 lvm [SWAP]

• 注意：注意 绑定流程假设标头至少包含一个空闲的 LUKS 密码插槽。clevis luks bind 命令占用了其中一个插槽。

9.8. 配置具有静态 IP 配置的 NBDE 客户端

• 要点：要将 NBDE 用于带有静态 IP 配置（没有 DHCP）的客户端，您必须手动将网络配置传递给 Dracut 工具。
• 要点：先决条件
• 列表：Tang 服务器正在运行且可用。
• 列表：NBDE 客户端被配置为自动解锁 Tang 服务器加密的卷。 详情请参阅 为自动解锁 LUKS 加密的卷配置 NBDE 客户端。
• 列表：您可以将静态网络配置提供为 dracut 命令中 kernel-cmdline 选项的值，例如： # dracut -fv --regenerate-all --kernel-cmdline "ip=192.0.2.10::192.0.2.1:255.255.255.0::ens3:none nameserver=192.0.2.100"
• 列表：或者，在 /etc/dracut.conf.d/ 目录中创建带有静态网络信息的 .conf 文件，然后重新生成初始 RAM 磁盘镜像： # cat /etc/dracut.conf.d/static_ip.conf kernel_cmdline="ip=192.0.2.10::192.0.2.1:255.255.255.0::ens3:none nameserver=192.0.2.100" # dracut -fv --regenerate-all
• 命令/配置摘录：

# dracut -fv --regenerate-all --kernel-cmdline "ip=192.0.2.10::192.0.2.1:255.255.255.0::ens3:none nameserver=192.0.2.100"
# cat /etc/dracut.conf.d/static_ip.conf kernel_cmdline="ip=192.0.2.10::192.0.2.1:255.255.255.0::ens3:none nameserver=192.0.2.100" # dracut -fv --regenerate-all

9.9. 使用 TPM 2.0 策略配置 LUKS 加密的卷的手动注册

• 要点：使用受信任的平台模块 2.0 (TPM 2.0)策略配置 LUKS 加密卷的解锁。
• 要点：您系统上的 clevis-encrypt-tpm2 (1) 手册页提供了可用参数的完整参考。
• 列表：一个可访问的 TPM 2.0 兼容设备。
• 列表：具有 64 位 Intel 或 64 位 AMD 架构的系统。
• 列表：安装 clevis-luks 子软件包： # dnf install clevis-luks
• 列表：识别 PBD 的 LUKS 加密卷。在以下示例中，块设备是指 /dev/sda2 ： # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 12G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 11G 0 part └─luks-40e20552-2ade-4954-9d56-565aa7994fb6 253:0 0 11G 0 crypt ├─rhel-root 253:0 0 9.8G 0 lvm / └─rhel-swap 253:1 0 1.2G 0 lvm [SWAP]
• 列表：使用 clevis luks bind 命令将卷绑定到 TPM 2.0 设备，例如： # clevis luks bind -d /dev/sda2 tpm2 '{"hash":"sha256","key":"rsa"}' … Do you wish to initialize /dev/sda2? [yn] y Enter existing LUKS password: 此命令执行四个步骤： 使用与 LUKS 主密钥相同的无序状态测量法创建新的密钥。 使用 Clevis 加密新密钥. 将 Clevis JWE 对象存储在 LUKS2 标头令牌中，或者使用 LUKSMeta（如果使用非默认的 LUKS1 标头）。 启用与 LUKS…
• 列表：使用与 LUKS 主密钥相同的无序状态测量法创建新的密钥。
• 命令/配置摘录：

# dnf install clevis-luks
# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 12G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 11G 0 part  └─luks-40e20552-2ade-4954-9d56-565aa7994fb6 253:0 0 11G 0 crypt  ├─rhel-root 253:0 0 9.8G 0 lvm /  └─rhel-swap 253:1 0 1.2G 0 lvm [SWAP]

• 注意：注意 绑定过程假定至少有一个可用的 LUKS 密码插槽。clevis luks bind 命令占用了其中一个插槽。
• 注意：重要 只有 PCR 哈希值与密封时使用的策略匹配，数据才能被解封。因为哈希可以重写，所以添加一个强密码短语，使您能够手动解锁加密卷。当PCR中的值发生变化时，这是必要的。 如果在升级 shim-x64 软件包后，系统无法自动解锁加密的卷，请按照红帽知识库解决方案 重启后，Clevis TPM2 不再解密 LUKS 设备 中的步骤操作。

9.10. 使用 PKCS #11 pin 配置 LUKS 加密卷的解锁

• 要点：您可以使用与 PKCS #11 兼容的设备（可以是智能卡或硬件安全模块(HSM)）配置 LUKS 加密卷的解锁。
• 要点：使用 Clevis Public-Key Cryptography Standards (PKCS) #11 pin 自动解锁加密卷还需要更改 /etc/crypttab 文件。这些更改将系统管理器配置为使用 AF_UNIX 套接字等待解锁卷的密钥。这样可以避免通过控制台提示用户。
• 列表：PKCS #11 设备已配置并可访问。
• 列表：clevis-pin-pkcs11 软件包已安装。
• 列表：卷至少有一个可用的 LUKS 密码插槽用于 clevis luks bind 命令。
• 列表：识别 PBD 的 LUKS 加密卷。在以下示例中，块设备是指 /dev/sda2 ： # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 12G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 11G 0 part └─luks-40e20552-2ade-4954-9d56-565aa7994fb6 253:0 0 11G 0 crypt ├─rhel-root 253:0 0 9.8G 0 lvm / └─rhel-swap 253:1 0 1.2G 0 lvm [SWAP]
• 列表：识别您要用来解锁卷的 PKCS #11 设备的 URI，例如： $ pkcs11-tool -L | grep uri uri : pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=42facd1f749ece7f;token=clevis uri : pkcs11:model=PKCS%2315%20emulated;manufacturer=OpenPGP%20project;serial=000f06080f4f;token=OpenPGP%20card%20%28User%20PIN%29
• 列表：使用 clevis luks bind 命令将卷绑定到一个 PKCS #11 设备，例如： # clevis luks bind -d /dev/sda2 pkcs11 '{"uri":"pkcs11:model=PKCS%2315%20emulated;manufacturer=OpenPGP%20project;serial=000f06080f4f;token=OpenPGP%20card%20%28User%20PIN%29;id=%03;object=Authentication%20key;type=public"}' … Do you wish to initialize /dev/sda2? [yn] y Ente…
• 命令/配置摘录：

# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 12G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 11G 0 part  └─luks-40e20552-2ade-4954-9d56-565aa7994fb6 253:0 0 11G 0 crypt  ├─rhel-root 253:0 0 9.8G 0 lvm /  └─rhel-swap 253:1 0 1.2G 0 lvm [SWAP]
$ pkcs11-tool -L | grep uri uri : pkcs11:model=PKCS%2315%20emulated;manufacturer=piv_II;serial=42facd1f749ece7f;token=clevis uri : pkcs11:model=PKCS%2315%20emulated;manufacturer=OpenPGP%20project;serial=000f06080f4f;token=OpenPGP%20card%20%28User%20PIN%29

9.11. 从 LUKS 加密卷中删除 Clevis pin

• 要点：您可以删除 clevis luks bind 命令创建的元数据，并擦除包含 Clevis 添加的密码短语的密钥插槽。
• 要点：在 RHEL 中，您可以使用单个命令删除绑定步骤创建的元数据，并擦除所选设备上的密钥插槽。如需更多信息，请参阅 clevis-luks-unbind (1) 手册页。
• 列表：具有 Clevis 绑定的 LUKS 加密卷。
• 列表：从 LUKS 加密卷中删除 Clevis pin，例如： # clevis luks unbind -d /dev/sda2 -s 1
• 列表：clevis luks list 命令的输出为空，例如： # clevis luks list -d /dev/sda2 或者，您可以检查 cryptsetup luksDump 命令的输出不包含 clevis 字符串。
• 命令/配置摘录：

# clevis luks unbind -d /dev/sda2 -s 1
# clevis luks list -d /dev/sda2

9.12. 使用 Kickstart 配置 LUKS 加密的卷的自动注册

• 要点：您可以配置一个使用 Clevis 注册 LUKS 加密卷的自动安装过程。
• 要点：您可以调整这个流程来使用 TPM 2.0 策略而不是 Tang 服务器。
• 列表：指示 Kickstart 对磁盘进行分区，以便使用除 /boot 之外的所有挂载点的临时密码启用 LUKS 加密。注册过程的这一步中的密码是临时密码。 part /boot --fstype="xfs" --ondisk=vda --size=256 part / --fstype="xfs" --ondisk=vda --grow --encrypted --passphrase=temppass 请注意，兼容 OSPP 的系统需要更复杂的配置，例如： part /boot --fstype="xfs" --ondisk=vda --size=256 part / --fstype="xfs" --ondisk=vda --si…
• 列表：通过在 %packages 部分中列出它们来安装相关的 Clevis 软件包： %packages clevis-dracut clevis-luks clevis-systemd %end
• 列表：可选：要确保您可以根据需要手动解锁加密的卷，请在删除临时密码短语前 向卷添加一个强密码短语 。
• 列表：在 %post 部分中调用 clevis luks bind 来执行绑定。之后，删除临时密码： %post clevis luks bind -y -k - -d /dev/vda2 \ tang '{"url":"http://tang.srv"}' <<< "temppass" cryptsetup luksRemoveKey /dev/vda2 <<< "temppass" dracut -fv --regenerate-all %end 如果您的配置依赖于在早期引导期间需要网络的 Tang pin,则必须修改 dracut 命令。如果您使用具有静态 IP 配置的 NBDE 客户端，您也必须对其进行修改。有关详细信息，请参阅…
• 列表：自动安装 RHEL
• 命令/配置摘录：

part /boot --fstype="xfs" --ondisk=vda --size=256 part / --fstype="xfs" --ondisk=vda --grow --encrypted --passphrase=temppass
part /boot --fstype="xfs" --ondisk=vda --size=256 part / --fstype="xfs" --ondisk=vda --size=2048 --encrypted --passphrase=temppass part /var --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass part /tmp --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass part /home --fstype="xfs" --ondisk=vda --size=2048 --grow --encrypted --passphrase=temppass part /var/log --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass part /var/log/audit --fstype="xfs" --ondisk=vda --size=1024 --encrypted --passphrase=temppass

• 注意：警告 cryptsetup luksRemoveKey 命令可防止对 LUKS2 设备进行任何进一步的管理。您只能对 LUKS1 设备使用 dmsetup 命令恢复已删除的主密钥。详情请查看您系统上的 dmsetup (8) 手册页。

9.13. 配置 LUKS 加密的可移动存储设备的自动解锁

• 要点：您可以配置 LUKS 加密的 USB 存储设备的自动解锁过程。
• 要点：您可以调整这个流程来使用 TPM 2.0 策略而不是 Tang 服务器。
• 列表：安装 clevis-udisks2 软件包： # dnf install clevis-udisks2
• 列表：重启系统，然后使用 clevis luks bind 命令执行绑定步骤，如 为自动解锁 LUKS 加密卷配置 NBDE 客户端 中所述，例如： # clevis luks bind -d /dev/sdb1 tang '{"url":"http://tang.srv"}'
• 列表：现在，可以在 GNOME 桌面会话中自动解锁 LUKS 加密的可移动设备。
• 列表：绑定到 Clevis 策略的设备也可以被 clevis luks unlock 命令解锁，例如： # clevis luks unlock -d /dev/sdb1
• 命令/配置摘录：

# dnf install clevis-udisks2
# clevis luks bind -d /dev/sdb1 tang '{"url":"http://tang.srv"}'

9.14. 部署高可用性 NBDE 系统

• 要点：Tang 提供两种方法来构建网络绑定的 Disc 加密(NBDE)的高可用性部署：客户端冗余和密钥共享。
• 要点：Shamir 的 Secret 共享(SSS)是一种加密方案，可将Secret 分成多个独特的部分。要重建 secret，需要几个部分。数字称为阈值，SSS 也被称为阈值方案。
• 命令/配置摘录：

# clevis luks bind -d /dev/sda1 sss '{"t":1,"pins":{"tang":[{"url":"http://tang1.srv"},{"url":"http://tang2.srv"}]}}'
{  "t":1,  "pins":{  "tang":[  {  "url":"http://tang1.srv"  },  {  "url":"http://tang2.srv"  }  ]  } }

9.15. NBDE 网络中虚拟机的部署

• 要点：当您为虚拟机配置网络绑定的 Disc Encryption (NBDE)时，请只在生产环境中使用安全实践。
• 要点：clevis luks bind 命令不会改变 LUKS 主密钥。这意味着，如果您创建了一个在虚拟机或云环境中使用的 LUKS 加密镜像，则所有运行此镜像的实例都会共享一个主密钥。这极其不安全，应始终避免。
• 列表：使用 Kickstart 配置 LUKS 加密的卷的自动注册

9.16. 使用 NBDE 为云环境构建可自动注册的虚拟机镜像

• 要点：在云环境中部署可自动注册的加密镜像具有独特的挑战。减少从单个镜像启动的实例数量。这可避免共享 LUKS 主密钥。
• 要点：创建自定义镜像。不要在公共存储库中共享它们。将它们用作有限数量的实例的基础。您的部署的安全策略应该定义实例的确切数量。基于您的 LUKS 主密钥攻击向量的风险容错性这个数字。
• 列表：您可以在云环境中轻松部署 Tang 服务器。但是，Tang 服务器与其他系统的数据存储共享基础架构。Tang 服务器的私钥和 Clevis 元数据可能存储在同一个物理磁盘中。如果某人访问此磁盘，就可能会破坏加密的数据。
• 列表：Tang 服务器可以在单独的基础架构上部署，在两个基础架构之间有 VPN 链接。
• 注意：重要 始终将数据存储位置与 Tang 服务器物理分开。这种分离可防止 Tang 服务器的私钥意外与 Clevis 元数据结合使用。如果云基础架构面临风险，它还提供了对 Tang 服务器的本地控制。

9.17. 将 Tang 部署为容器

• 要点：tang 容器镜像为在红帽 OpenShift Container Platform(OCP)集群中或独立的虚拟机中运行的 Clevis 客户端提供 Tang-server 解密功能。
• 要点：先决条件
• 列表：podman 软件包及其依赖项已安装在系统上。
• 列表：你可以使用 podman login registry.redhat.io 命令登录到 registry.redhat.io 容器目录。如需更多信息，请参阅 红帽容器注册表身份验证。
• 列表：Clevis 客户端安装在包含 LUKS 加密卷的系统上，您希望使用 Tang 服务器自动解锁这些卷。
• 列表：从 registry.redhat.io 注册中心中拉取 tang 容器镜像： # podman pull registry.redhat.io/rhel10/tang
• 列表：运行容器，指定其端口，并指定到 Tang 密钥的路径。以下示例运行 tang 容器，指定端口 7500，并指示到 /var/db/tang 目录的 Tang 密钥的路径： # podman run -d -p 7500:7500 -v tang-keys:/var/db/tang --name tang registry.redhat.io/rhel10/tang 请注意，Tang 默认使用端口 80，但这可能与其他服务冲突，如 Apache HTTP 服务器。
• 列表：可选：为了提高安全性，请定期轮转 Tang 密钥。您可以使用 tangd-rotate-keys 脚本，例如： # podman run --rm -v tang-keys:/var/db/tang registry.redhat.io/rhel10/tang tangd-rotate-keys -v -d /var/db/tang Rotated key 'rZAMKAseaXBe0rcKXL1hCCIq-DY.jwk' -> .'rZAMKAseaXBe0rcKXL1hCCIq-DY.jwk' Rotated key 'x1AIpc6WmnCU-CabD8_4q18vDuw.jwk' -> .'x1AIpc6WmnCU-Cab…
• 命令/配置摘录：

# podman pull registry.redhat.io/rhel10/tang
# podman run -d -p 7500:7500 -v tang-keys:/var/db/tang --name tang registry.redhat.io/rhel10/tang

9.18. 使用 Trustee attestation 服务器自动解锁加密的卷

• 要点：您可以通过信任密钥代理服务(KBS)使用远程测试来自动加密和解密 LUKS 卷。Clevis pin trustee 保护磁盘加密密钥。在发布密钥之前，您的平台必须向远程服务器证明其完整性。
• 要点：机密计算工作负载要求磁盘加密密钥永远不会公开。不要将它们公开给基础架构提供商或任何不受信任的软件。在这些环境中，只能在平台通过远程测试证明其完整性后解密 LUKS 卷。
• 列表：用于 OpenShift 的机密集群，集群节点在受信任的执行环境(TEEs)中运行。它们必须在测试后解锁加密的根卷。
• 列表：带有 KubeVirt 或 OpenShift Virtualization 的机密虚拟机，在 TEEs 内运行的客户虚拟机必须在不需要 Operator 干预的情况下解密其虚拟磁盘。
• 列表：服务器 URL
• 列表：加密密钥的资源路径
• 列表：可选参数，如 TLS 证书、重试计数和测试数据
• 列表：部署红帽构建的信任者
• 命令/配置摘录：

# clevis luks bind -d /dev/sda2 trustee '{"servers":[{"url":"https://trustee1.example.com:8080","cert":"/etc/pki/tls/certs/trustee1.pem"}, "url":"https://trustee2.example.com:8080","cert":"/etc/pki/tls/certs/trustee2.pem"}],"path":"default/mycluster/rootkey","num_retries":5,"initdata":"{\"cc_eventlog\":\"value1\"}"}'

9.19. 使用 RHEL 系统角色配置 NBDE

• 要点：您可以使用 nbde_client 和 nbde_server RHEL 系统角色，通过使用 Clevis 和 Tang 来自动部署基于策略的解密(PBD)解决方案。
• 要点：rhel-system-roles 软件包包含这些系统角色、相关示例和参考文档。

9.19.1. 使用 nbde_server RHEL 系统角色设置多个 Tang 服务器

• 要点：通过使用 nbde_server 系统角色，您可以部署和管理 Tang 服务器，来作为自动磁盘加密解决方案的一部分。
• 要点：此角色支持以下功能：
• 列表：轮转 Tang 密钥
• 列表：部署和备份 Tang 密钥
• 列表：您已准备好控制节点和受管节点。
• 列表：以可在受管主机上运行 playbook 的用户登录到控制节点。
• 列表：用于连接到受管节点的帐户具有这些节点的 sudo 权限。
• 列表：创建一个包含以下内容的 playbook 文件，如 ~/playbook.yml ： --- - name: Deploy a Tang server hosts: tang.server.example.com tasks: - name: Install and configure periodic key rotation ansible.builtin.include_role: name: redhat.rhel_system_roles.nbde_server vars: nbde_server_rotate_keys: yes nbde_server_manage_firewall: true nb…
• 命令/配置摘录：

--- - name: Deploy a Tang server  hosts: tang.server.example.com  tasks:  - name: Install and configure periodic key rotation  ansible.builtin.include_role:  name: redhat.rhel_system_roles.nbde_server  vars:  nbde_server_rotate_keys: yes  nbde_server_manage_firewall: true  nbde_server_manage_selinux: true
$ ansible-playbook --syntax-check ~/playbook.yml

9.19.2. 使用 nbde_client RHEL 系统角色设置带有 DHCP 的 Clevis 客户端

• 要点：使用 nbde_client 系统角色，您可以自动部署多个 Clevis 客户端。
• 要点：此角色支持将 LUKS 加密卷绑定到一个或多个网络绑定的(NBDE)服务器 - Tang 服务器。您可以使用密码短语保留现有卷加密或删除密码短语。删除密码短语后，您只能使用 NBDE 解锁卷。当卷最初是使用您在置备系统后删除的临时密钥或密码加密时，这非常有用。
• 列表：您已准备好控制节点和受管节点。
• 列表：以可在受管主机上运行 playbook 的用户登录到控制节点。
• 列表：用于连接到受管节点的帐户具有这些节点的 sudo 权限。
• 列表：已使用 LUKS 加密的卷。
• 列表：创建一个包含以下内容的 playbook 文件，如 ~/playbook.yml ： --- - name: Configure clients for unlocking of encrypted volumes by Tang servers hosts: managed-node-01.example.com tasks: - name: Create NBDE client bindings ansible.builtin.include_role: name: redhat.rhel_system_roles.nbde_client vars: nbde_client_bindings: - device…
• 列表：验证 playbook 语法： $ ansible-playbook --syntax-check ~/playbook.yml 请注意，这个命令只验证语法，不能防止错误的、但有效的配置。
• 命令/配置摘录：

--- - name: Configure clients for unlocking of encrypted volumes by Tang servers  hosts: managed-node-01.example.com  tasks:  - name: Create NBDE client bindings  ansible.builtin.include_role:  name: redhat.rhel_system_roles.nbde_client  vars:  nbde_client_bindings:  - device: /dev/rhel/root  encryption_key_src: /etc/luks/keyfile  nbde_client_early_boot: true  state: present  servers:  - http://server1.example.com  - http://server2.example.com  - device: /dev/rhel/swap  encryption_key_src: /etc/luks/keyfile  servers:  - http://server1.example.com  - http://server2.example.com
$ ansible-playbook --syntax-check ~/playbook.yml

• 注意：注意 nbde_client 系统角色只支持 Tang 绑定。因此，您无法将其用于 TPM2 绑定。

9.19.3. 使用 nbde_client RHEL 系统角色设置静态 IP Clevis 客户端

• 要点：nbde_client RHEL 系统角色只支持具有动态主机配置协议(DHCP)的场景。在带有静态 IP 配置的 Network-Bound Disk Encryption (NBDE)客户端中，您必须将网络配置作为内核引导参数传递。
• 要点：通常，管理员希望重复使用 playbook，且不会为 Ansible 在早期引导过程中为其分配静态 IP 地址的每个主机维护单独的 playbook。在这种情况下，您可以在 playbook 中使用变量，并在外部文件中提供设置。因此，您只需要一个 playbook 和一个带有设置的文件。
• 列表：您已准备好控制节点和受管节点。
• 列表：以可在受管主机上运行 playbook 的用户登录到控制节点。
• 列表：用于连接到受管节点的帐户具有这些节点的 sudo 权限。
• 列表：已使用 LUKS 加密的卷。
• 列表：创建一个带有主机的网络设置的文件，如 static-ip-settings-clients.yml，并添加您要动态分配给主机的值： clients: managed-node-01.example.com: ip_v4: 192.0.2.1 gateway_v4: 192.0.2.254 netmask_v4: 255.255.255.0 interface: enp1s0 managed-node-02.example.com: ip_v4: 192.0.2.2 gateway_v4: 192.0.2.254 netmask_v4: 255.255.255.0 interface: enp1s0
• 列表：创建一个包含以下内容的 playbook 文件，如 ~/playbook.yml ： - name: Configure clients for unlocking of encrypted volumes by Tang servers hosts: managed-node-01.example.com,managed-node-02.example.com vars_files: - ~/static-ip-settings-clients.yml tasks: - name: Create NBDE client bindings ansible.builtin.include_role: name: red…
• 命令/配置摘录：

clients:  managed-node-01.example.com:  ip_v4: 192.0.2.1  gateway_v4: 192.0.2.254  netmask_v4: 255.255.255.0  interface: enp1s0  managed-node-02.example.com:  ip_v4: 192.0.2.2  gateway_v4: 192.0.2.254  netmask_v4: 255.255.255.0  interface: enp1s0
- name: Configure clients for unlocking of encrypted volumes by Tang servers  hosts: managed-node-01.example.com,managed-node-02.example.com  vars_files:  - ~/static-ip-settings-clients.yml  tasks:  - name: Create NBDE client bindings  ansible.builtin.include_role:  name: redhat.rhel_system_roles.network  vars:  nbde_client_bindings:  - device: /dev/rhel/root  encryption_key_src: /etc/luks/keyfile  servers:  - http://server1.example.com  - http://server2.example.com  - device: /dev/rhel/swap  encryption_key_src: /etc/luks/keyfile  servers:  - http://server1.example.com  - http://server2.example.com  - name: Configure a Clevis client with sta…

第 10 章 使用 fapolicyd 阻止和允许应用程序

• 要点：使用 fapolicyd 框架实施应用程序允许列表解决方案，以帮助提高系统安全性。根据规则集设置和强制实施允许或拒绝应用程序执行的策略，可有效防止执行未知的和具有潜在恶意的软件。

10.1. fapolicyd 框架结构

• 要点：fapolicyd 软件框架根据用户定义的策略来控制应用程序的执行。这是防止在系统上运行不受信任的和可能具有恶意的应用程序的最有效的方法之一。
• 要点：fapolicyd 框架提供以下组件。
• 列表：fapolicyd 服务
• 列表：fapolicyd 命令行工具，如 fapolicyd-cli 命令和 fagenrules 脚本
• 列表：fapolicyd RPM 插件
• 列表：/etc/fapolicyd/fapolicyd.trust 文件包含一个可信文件的列表。您还可以在 /etc/fapolicyd/trust.d/ 目录中使用多个信任文件。
• 列表：/etc/fapolicyd/rules.d/ 目录包含有 allow 和 deny 执行规则的文件。fagenrules 脚本将这些组件规则文件合并到 /etc/fapolicyd/compiled.rules 文件中。
• 列表：fapolicyd.conf 文件包含守护进程的配置选项。此文件主要用于性能调优目的。
• 表格样本（共 11 行）：
  • 10 | 语言规则
  • 20 | 与 dracut 相关的规则
  • 21 | 更新器的规则
  • 30 | 模式

10.2. 部署 fapolicyd

• 要点：在部署 fapolicyd 应用程序允许列表框架时，您可以首先在 permissive 模式下尝试配置，或者直接在默认配置中启用服务。
• 要点：流程
• 列表：安装 fapolicyd 软件包： # dnf install fapolicyd
• 列表：设置审计子系统来记录 fapolicyd 事件： # auditctl -w /etc/fapolicyd/ -p wa -k fapolicyd_changes # service try-restart auditd
• 列表：可选：要先尝试配置，请将模式改为 permissive。 在您选择的文本编辑器中打开 /etc/fapolicyd/fapolicyd.conf 文件，例如： # vi /etc/fapolicyd/fapolicyd.conf 将 permissive 选项的值从 0 改为 1，保存文件，并退出编辑器： permissive = 1 或者，您可以在启动服务前使用 fapolicyd --debug-deny --permissive 命令调试配置。如需更多信息，请参阅 故障排除与 fapolicyd 相关的问题 部分。
• 列表：在您选择的文本编辑器中打开 /etc/fapolicyd/fapolicyd.conf 文件，例如： # vi /etc/fapolicyd/fapolicyd.conf
• 列表：将 permissive 选项的值从 0 改为 1，保存文件，并退出编辑器： permissive = 1 或者，您可以在启动服务前使用 fapolicyd --debug-deny --permissive 命令调试配置。如需更多信息，请参阅 故障排除与 fapolicyd 相关的问题 部分。
• 列表：启用并启动 fapolicyd 服务： # systemctl enable --now fapolicyd
• 命令/配置摘录：

# dnf install fapolicyd
# auditctl -w /etc/fapolicyd/ -p wa -k fapolicyd_changes # service try-restart auditd

10.3. 使用其它信任源将文件标记为可信

• 要点：fapolicyd 框架信任 RPM 数据库中包含的文件。您可以通过修改信任源将额外文件标记为可信。
• 要点：您可以直接使用文本编辑器或通过 fapolicyd-cli 命令修改 /etc/fapolicyd /fapolicyd.trust 纯文本文件或 /etc/fapolicyd/trust.d 目录中的文件。详情请查看您系统中的 fapolicyd.trust (13) 和 fapolicyd-cli (8) 手册页。
• 列表：fapolicyd 框架部署在您的系统上。
• 列表：将自定义二进制文件复制到所需的目录中，例如： $ cp /bin/ls /tmp $ /tmp/ls bash: /tmp/ls: Operation not permitted
• 列表：将自定义二进制文件标记为信任的，并将相应的条目添加到 /etc/fapolicyd/trust.d/ 中的 myapp 文件中： # fapolicyd-cli --file add /tmp/ls --trust-file myapp 如果您跳过 --trust-file 选项，则之前的命令会将相应的行添加到 /etc/fapolicyd/fapolicyd.trust。 要将目录中所有现有的文件标记为可信，请将目录路径提供为-- file 选项的参数，例如： # fapolicyd-cli --file add /tmp/my_bin_dir/ --trust-file myapp
• 列表：如果您跳过 --trust-file 选项，则之前的命令会将相应的行添加到 /etc/fapolicyd/fapolicyd.trust。
• 列表：要将目录中所有现有的文件标记为可信，请将目录路径提供为-- file 选项的参数，例如： # fapolicyd-cli --file add /tmp/my_bin_dir/ --trust-file myapp
• 列表：更新 fapolicyd 数据库： # fapolicyd-cli --update 注意 更改可信文件或目录的内容会改变其校验和，因此fapolicyd 不再认为它被信任。 要恢复新内容中的信任，请使用 fapolicyd-cli --file update 命令刷新文件信任数据库。如果没有提供任何参数，则整个数据库都会刷新。或者，您可以指定特定文件或目录的路径。然后，使用 fapolicyd-cli --update 更新数据库。
• 命令/配置摘录：

$ cp /bin/ls /tmp $ /tmp/ls bash: /tmp/ls: Operation not permitted
# fapolicyd-cli --file add /tmp/ls --trust-file myapp

• 注意：注意 出于性能考虑，使用 fapolicyd.trust 或 trust.d/ 将文件标记为信任的，而不是编写自定义 fapolicyd 规则。
• 注意：注意 更改可信文件或目录的内容会改变其校验和，因此fapolicyd 不再认为它被信任。 要恢复新内容中的信任，请使用 fapolicyd-cli --file update 命令刷新文件信任数据库。如果没有提供任何参数，则整个数据库都会刷新。或者，您可以指定特定文件或目录的路径。然后，使用 fapolicyd-cli --update 更新数据库。

10.4. 为 fapolicyd 添加自定义 allow 和 deny 规则

• 要点：默认的 fapolicyd 规则集合不会影响系统功能。对于自定义方案，请将其他文件标记为受信任或添加自定义规则。例如将二进制文件存储在非标准目录中，或者添加不带 DNF 或 RPM 的应用程序。
• 要点：先决条件
• 列表：fapolicyd 框架部署在您的系统上。
• 列表：将自定义二进制文件复制到所需的目录中，例如： $ cp /bin/ls /tmp $ /tmp/ls bash: /tmp/ls: Operation not permitted
• 列表：停止 fapolicyd 服务： # systemctl stop fapolicyd
• 列表：使用 debug 模式来识别相应的规则。因为 fapolicyd --debug 命令的输出很冗长，所以您只能按 Ctrl+C 或终止相应的进程来停止它，并将错误输出重定向到文件中。在这种情况下，您可以使用 --debug-deny 选项而不是 --debug 来限制输出只访问拒绝： # fapolicyd --debug-deny 2> fapolicy.output & [1] 51341 或者，您可以在另一个会话中运行 fapolicyd debug 模式。
• 列表：重复 fapolicyd 拒绝的命令： $ /tmp/ls bash: /tmp/ls: Operation not permitted
• 列表：通过在前台恢复并按 Ctrl+C 来停止 debug 模式： # fg fapolicyd --debug 2> fapolicy.output ^C … 或者，杀掉 fapolicyd debug 模式的进程： # kill 51341
• 命令/配置摘录：

$ cp /bin/ls /tmp $ /tmp/ls bash: /tmp/ls: Operation not permitted
# systemctl stop fapolicyd

• 注意：重要 要使规则对指定目录下的所有目录递归有效，请将斜杠添加到规则中 dir= 参数值的末尾。在前面的示例中，使用 /tmp/ 代替 /tmp。

10.5. 启用 fapolicyd 完整性检查

• 要点：默认情况下，fapolicyd 不执行完整性检查。您可以配置 fapolicyd，来通过比较文件大小或 SHA-256 哈希执行完整性检查。您还可以使用完整性度量架构(IMA)子系统来设置完整性检查。
• 要点：先决条件
• 列表：fapolicyd 框架部署在您的系统上。
• 列表：在您选择的文本编辑器中打开 /etc/fapolicyd/fapolicyd.conf 文件，例如： # vi /etc/fapolicyd/fapolicyd.conf
• 列表：将 integrity 选项的值从 none 改为 sha256，保存文件并退出编辑器： integrity = sha256
• 列表：重启 fapolicyd 服务： # systemctl restart fapolicyd
• 列表：备份用于验证的文件： # cp /bin/more /bin/more.bak
• 列表：更改 /bin/more 二进制文件的内容： # cat /bin/less > /bin/more
• 命令/配置摘录：

# vi /etc/fapolicyd/fapolicyd.conf
integrity = sha256

10.6. 故障排除与 fapolicyd 相关的问题

• 要点：fapolicyd 应用程序框架为故障排除最常见的问题提供了工具，您也可以将 rpm 命令安装的应用程序添加到信任数据库中。
• 要点：因为 fapolicyd 框架没有完全支持命名空间和容器，所以您必须在运行容器的系统中使用临时解决方案。要防止因为 fapolicyd 导致容器启动失败，请使用以下内容创建 /etc/fapolicyd/rules.d/25-runc.rules 文件：
• 列表：安装 < application>: # rpm -i <application>.rpm
• 列表：刷新数据库： # fapolicyd-cli --update 如果您跳过这一步，系统可能会被冻结，必须重启。
• 列表：使用 --list 选项检查规则的当前列表及其顺序： # fapolicyd-cli --list … 9. allow perm=execute all : trust=1 10. allow perm=open all : ftype=%languages trust=1 11. deny_audit perm=any all : ftype=%languages 12. allow perm=any all : ftype=text/x-shellscript 13. deny_audit perm=execute all : all …
• 列表：停止 fapolicyd 服务： # systemctl stop fapolicyd
• 列表：使用 debug 模式来识别相应的规则： # fapolicyd --debug 因为 fapolicyd --debug 命令的输出非常详细，所以您可以将错误输出重定向到文件中： # fapolicyd --debug 2> fapolicy.output 另外，若要在 fapolicyd 拒绝访问时仅将输出限制为条目，请使用 --debug-deny 选项： # fapolicyd --debug-deny
• 列表：在个别情况下，删除 fapolicyd 管道文件可以解决锁定问题： # rm -f /var/run/fapolicyd/fapolicyd.fifo
• 命令/配置摘录：

allow perm=any pattern=ld_so exe=/usr/bin/runc : all allow perm=any uid=0 pattern=ld_so exe=/runc : trust=1
# rpm -i <application>.rpm

• 注意：警告 不要删除 /var/lib/fapolicyd/ 目录。fapolicyd 框架只自动恢复这个目录下的数据库文件。

10.7. 使用 fapolicyd RHEL 系统角色防止用户执行不可靠的代码

• 要点：您可以使用 fapolicyd RHEL 系统角色自动化 fapolicyd 服务的安装和配置。
• 要点：使用此角色，您可以远程配置服务，以允许用户仅运行受信任的应用程序。例如，您可以将执行限制在 RPM 数据库和允许列表中列出的应用程序。另外，该服务也可以在运行允许的应用程序前执行完整性检查。
• 列表：您已准备好控制节点和受管节点。
• 列表：以可在受管主机上运行 playbook 的用户登录到控制节点。
• 列表：用于连接到受管节点的帐户具有这些节点的 sudo 权限。
• 列表：创建一个包含以下内容的 playbook 文件，如 ~/playbook.yml ： --- - name: Configuring fapolicyd hosts: managed-node-01.example.com tasks: - name: Allow only executables installed from RPM database and specific files ansible.builtin.include_role: name: redhat.rhel_system_roles.fapolicyd vars: fapolicyd_setup_permissive: false fap…
• 列表：none（默认）：禁用完整性检查。
• 列表：size ：服务仅比较允许的应用程序的文件大小。
• 命令/配置摘录：

--- - name: Configuring fapolicyd  hosts: managed-node-01.example.com  tasks:  - name: Allow only executables installed from RPM database and specific files  ansible.builtin.include_role:  name: redhat.rhel_system_roles.fapolicyd  vars:  fapolicyd_setup_permissive: false  fapolicyd_setup_integrity: sha256  fapolicyd_setup_trust: rpmdb,file  fapolicyd_add_trusted_file:  - <path_to_allowed_command>  - <path_to_allowed_service>
$ ansible-playbook ~/playbook.yml --syntax-check

第 11 章 保护系统免受入侵 USB 设备的攻击

• 要点：使用 USBGuard 保护您的 Red Hat Enterprise Linux 系统免受入侵 USB 设备。这个框架有助于防止涉及恶意软件或 trojans 被加载到 USB 驱动器中的攻击。

11.1. USBGuard 入侵防止

• 要点：使用 USBGuard 软件框架保护您的系统免受入侵 USB 设备。usbguard 使用允许和阻止的设备列表。它基于内核中 USB 设备的授权功能。
• 要点：USBGuard 框架提供以下组件：
• 列表：系统服务组件。它具有用于动态交互和策略实施的 IPC 接口。
• 列表：命令行界面。使用它来与正在运行的 usbguard 系统服务交互。
• 列表：规则语言。使用它编写 USB 设备授权策略。
• 列表：C++ API。使用它来与共享库中的系统服务组件交互。
• 注意：重要 系统服务提供 USBGuard 公共 IPC 接口。在 Red Hat Enterprise Linux 中，只有 root 用户可以默认访问这个接口。 限制访问 IPC 接口。设置这些选项之一： IPCAccessControlFiles IPCAllowedUsers 和 IPCAllowedGroups 不要使访问控制列表(ACL)未配置。未配置的 ACL 会将 IPC 接口公开给所有本地用户。然后，他们可以操作 USB 设备授权并修改 USBGuard 策略。

11.2. 安装 USBGuard

• 要点：安装 USBGuard 框架，以开始定义哪些 USB 设备可以连接到您的 Red Hat Enterprise Linux 系统的策略。这是防御物理安全漏洞的第一步。
• 要点：流程
• 列表：安装 usbguard 软件包： # dnf install usbguard
• 列表：创建初始规则集： # usbguard generate-policy > /etc/usbguard/rules.conf
• 列表：启动 usbguard 守护进程，并确保它会在引导时自动启动： # systemctl enable --now usbguard
• 列表：验证 usbguard 服务是否正在运行： # systemctl status usbguard ● usbguard.service - USBGuard daemon Loaded: loaded (/usr/lib/systemd/system/usbguard.service; enabled; vendor preset: disabled) Active: active (running) since Thu 2019-11-07 09:44:07 CET; 3min 16s ago Docs: man:usbguard-daemon(8) Main PID: 6122 (usbguard-daemon) …
• 列表：列出 USBGuard 识别的 USB 设备： # usbguard list-devices 4: allow id 1d6b:0002 serial "0000:02:00.0" name "xHCI Host Controller" hash...
• 命令/配置摘录：

# dnf install usbguard
# usbguard generate-policy > /etc/usbguard/rules.conf

11.3. 使用 CLI 阻止和授权 USB 设备

• 要点：您可以使用 usbguard 命令将 USBGuard 设置为允许、阻止或拒绝特定的 USB 设备。此设置会在 USBGuard 运行时保留。
• 要点：USBGuard 使用术语 block 和 reject，其含义如下：
• 列表：usbguard 服务已安装并运行。
• 列表：通过列出 USBGuard 认可的设备来确定 USB 设备的 ID： # usbguard list-devices 1: allow id 1d6b:0002 serial "0000:00:06.7" name "EHCI Host Controller" hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" parent-hash "4PHGcaDKWtPjKDwYpIRG722cB9SlGz9l9Iea93+Gt9c=" via-port "usb1" with-interface 09:00:00 ... 6: block id 1b1c:1ab1 serial "000…
• 列表：授权设备与系统进行交互： # usbguard allow-device <ID>
• 列表：取消授权并删除设备： # usbguard reject-device <ID>
• 列表：取消授权并保留设备： # usbguard block-device <ID>
• 命令/配置摘录：

# usbguard list-devices 1: allow id 1d6b:0002 serial "0000:00:06.7" name "EHCI Host Controller" hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" parent-hash "4PHGcaDKWtPjKDwYpIRG722cB9SlGz9l9Iea93+Gt9c=" via-port "usb1" with-interface 09:00:00 ... 6: block id 1b1c:1ab1 serial "000024937962" name "Voyager" hash "CrXgiaWIf2bZAU+5WkzOE7y0rdSO82XMzubn7HDb95Q=" parent-hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" via-port "1-3" with-interface 08:06:50
# usbguard allow-device <ID>

11.4. 永久阻止和授权 USB 设备

• 要点：您可以使用 -p 选项永久阻止和授权一个 USB 设备。这会在当前策略中添加一个特定于设备的规则，并在重启后保持不变。
• 要点：USBGuard 使用术语 block 和 reject，其含义如下：
• 列表：usbguard 服务已安装并运行。
• 列表：配置 SELinux，以允许 usbguard 守护进程编写规则。 显示与 usbguard 相关的 semanage 布尔值。 # semanage boolean -l | grep usbguard usbguard_daemon_write_conf (off , off) Allow usbguard to daemon write conf usbguard_daemon_write_rules (on , on) Allow usbguard to daemon write rules 如果 usbguard_daemon_write_rules 布尔值已关闭，请打开它。 # semanage boolean -m …
• 列表：显示与 usbguard 相关的 semanage 布尔值。 # semanage boolean -l | grep usbguard usbguard_daemon_write_conf (off , off) Allow usbguard to daemon write conf usbguard_daemon_write_rules (on , on) Allow usbguard to daemon write rules
• 列表：如果 usbguard_daemon_write_rules 布尔值已关闭，请打开它。 # semanage boolean -m --on usbguard_daemon_write_rules
• 列表：通过列出 USBGuard 认可的设备来确定 USB 设备的 ID： # usbguard list-devices 1: allow id 1d6b:0002 serial "0000:00:06.7" name "EHCI Host Controller" hash "JDOb0BiktYs2ct3mSQKopnOOV2h9MGYADwhT+oUtF2s=" parent-hash "4PHGcaDKWtPjKDwYpIRG722cB9SlGz9l9Iea93+Gt9c=" via-port "usb1" with-interface 09:00:00 ... 6: block id 1b1c:1ab1 serial "000…
• 列表：永久授权设备与系统进行交互： # usbguard allow-device <ID> -p
• 命令/配置摘录：

# semanage boolean -l | grep usbguard usbguard_daemon_write_conf (off , off) Allow usbguard to daemon write conf usbguard_daemon_write_rules (on , on) Allow usbguard to daemon write rules
# semanage boolean -m --on usbguard_daemon_write_rules

11.5. 为 USB 设备创建自定义策略

• 要点：创建自定义 USBGuard 策略，以满足您的特定安全要求。通过定义多个规则，您可以精细控制哪些 USB 设备被授权与您的系统交互。
• 要点：先决条件
• 列表：usbguard 服务已安装并运行。
• 列表：/etc/usbguard/rules.conf 文件包含了由usbguard generate-policy 命令生成的初始规则集。
• 列表：创建一个策略，其授权当前连接的 USB 设备，并将生成的规则保存到 rules.conf 文件中： # usbguard generate-policy --no-hashes > ./rules.conf --no-hashes 选项不会为设备生成哈希属性。在配置设置中避免哈希属性，因为它们可能不是永久的。
• 列表：在 rules.conf 文件中，使用文本编辑器根据需要添加、删除或编辑规则。例如，以下规则只允许带有一个大容量存储接口的设备与系统进行交互： allow with-interface equals { 08:: } 有关详细的规则语言描述和更多示例，请参阅 usbguard-rules.conf(5)手册页。
• 列表：安装更新的策略： # install -m 0600 -o root -g root rules.conf /etc/usbguard/rules.conf
• 列表：重启 usbguard 守护进程以应用您的更改： # systemctl restart usbguard
• 命令/配置摘录：

# usbguard generate-policy --no-hashes > ./rules.conf
allow with-interface equals { 08:*:* }

11.6. 为 USB 设备创建结构化自定义策略

• 要点：在 RHEL 中创建结构化的自定义 USBGuard 策略，以管理复杂的安全场景。通过将规则整理到单独的配置文件中，您可以确保更轻松地维护和全面的安全覆盖。
• 要点：您可以在 /etc/usbguard/rules.d/ 目录中的多个 .conf 文件中组织自定义 USBGuard 策略。然后 usbguard-daemon 将主 rules.conf 文件与目录中的 .conf 文件按字母顺序组合在一起。
• 列表：usbguard 服务已安装并运行。
• 列表：创建一个授权当前连接的 USB 设备的策略，并将生成的规则保存到一个新的 .conf 文件中，例如 <policy.conf>。 # usbguard generate-policy --no-hashes > ./<policy.conf> --no-hashes 选项不会为设备生成哈希属性。在配置设置中避免哈希属性，因为它们可能不是永久的。
• 列表：使用您选择的文本编辑器打开 <policy.conf> 文件，并选择具有您要记录的规则的行，例如： … allow id 04f2:0833 serial "" name "USB Keyboard" via-port "7-2" with-interface { 03:01:01 03:00:00 } with-connect-type "unknown" …
• 列表：将所选行复制到单独的 .conf 文件中。 注意 文件名开头的两位数字指定守护进程读取配置文件的顺序。 例如，要将键盘的规则复制到一个新的 .conf 文件中： # grep "USB Keyboard" ./<policy.conf> > ./<10keyboards.conf>
• 列表：将新策略安装到 /etc/usbguard/rules.d/ 目录中。 # install -m 0600 -o root -g root <10keyboards.conf> /etc/usbguard/rules.d/<10keyboards.conf>
• 列表：将其余行移到主 rules.conf 文件中。 # grep -v "USB Keyboard" ./policy.conf > ./rules.conf
• 命令/配置摘录：

# usbguard generate-policy --no-hashes > ./<policy.conf>
… allow id 04f2:0833 serial "" name "USB Keyboard" via-port "7-2" with-interface { 03:01:01 03:00:00 } with-connect-type "unknown" …

• 注意：注意 文件名开头的两位数字指定守护进程读取配置文件的顺序。

11.7. 授权用户和组使用 USBGuard IPC 接口

• 要点：授权特定用户或组使用 RHEL 中的 USBGuard 公共 IPC 接口来允许 USB 设备的非 root 管理。使用 usbguard add-user 子命令或编辑配置文件来授予访问权限，以防止未经授权的 USB 设备授权策略操作。
• 要点：先决条件
• 列表：usbguard 服务已安装并运行。
• 列表：/etc/usbguard/rules.conf 文件包含了由usbguard generate-policy 命令生成的初始规则集。
• 列表：使用您要添加的规则编辑 /etc/usbguard/usbguard-daemon.conf 文件。例如，要允许 wheel 组中的所有用户使用 IPC 接口，请添加此行： IPCAllowGroups=wheel
• 列表：您还可以使用 usbguard 命令添加用户或组。例如，以下命令使用户可以完全访问 Devices 和 Exceptions 部分，并可以列出和修改当前策略： # usbguard add-user <user_name> --devices ALL --policy modify,list --exceptions ALL 将 <user_name> 替换为应该接收这些权限的用户名。 您可以使用 usbguard remove-user <user_name> 命令删除为用户授予的权限。
• 列表：重启 usbguard 守护进程以应用您的更改： # systemctl restart usbguard
• 命令/配置摘录：

IPCAllowGroups=wheel
# usbguard add-user <user_name> --devices ALL --policy modify,list --exceptions ALL

11.8. 将 USBguard 授权事件记录到 Linux 审计日志中

• 要点：默认情况下，usbguard 守护进程将事件记录到 /var/log/usbguard/usbguard-audit.log 文件中。您可以将 USBguard 授权事件的日志集成到标准的 Linux 审计日志中。
• 要点：先决条件
• 列表：usbguard 服务已安装并运行。
• 列表：auditd 服务正在运行。
• 列表：在 /etc/usbguard/usbguard-daemon.conf 文件中，将 AuditBackend 选项从 FileAudit 改为 LinuxAudit ： AuditBackend=LinuxAudit
• 列表：重启 usbguard 守护进程以应用配置更改： # systemctl restart usbguard
• 列表：查询 USB 授权事件的 audit 守护进程日志，例如： # ausearch -ts recent -m USER_DEVICE
• 命令/配置摘录：

AuditBackend=LinuxAudit
# systemctl restart usbguard

完整目录

• 增强 Red Hat Enterprise Linux 10 系统的安全性
• 对红帽文档提供反馈
• 第 1 章 将 RHEL 切换到 FIPS 模式
  • 1.1. 联邦信息处理标准 140 和 FIPS 模式
    • 1.1.1. FIPS 模式下的 RHEL
    • 1.1.2. FIPS 模式状态
    • 1.1.3. 加密策略中的 FIPS
    • 1.1.4. RHEL 10.0 OpenSSL FIPS 指标
  • 1.2. 安装启用了 FIPS 模式的系统
  • 1.3. 使用 RHEL 镜像构建器启用 FIPS 模式
  • 1.4. 为启用了 FIPS 的系统创建一个可引导磁盘镜像
  • 1.5. 使用与 FIPS 140-3 不兼容的加密的 RHEL 应用程序列表
• 第 2 章 使用系统范围的加密策略
  • 2.1. 系统范围的加密策略
    • 2.1.1. 预定义的加密策略
    • 2.1.2. post-quantum 加密
  • 2.2. 更改系统范围的加密策略
  • 2.3. 将系统范围的加密策略切换到与早期版本兼容的模式
  • 2.4. 在 web 控制台中配置系统范围的加密策略
  • 2.5. 选择不使用系统范围的加密策略的示例
  • 2.6. 使用子策略自定义系统范围的加密策略
  • 2.7. 创建并设置自定义系统范围的加密策略
  • 2.8. 在系统范围内禁用量子算法
  • 2.9. 使用 crypto_policies RHEL 系统角色增强 FUTURE 加密策略的安全性
• 第 3 章 通过 PKCS#11 将应用程序配置为使用加密硬件
  • 3.1. 通过 PKCS #11 的加密硬件支持
  • 3.2. 通过保存在智能卡上的 SSH 密钥进行身份验证
  • 3.3. 使用智能卡中的证书进行身份验证的应用程序设置
  • 3.4. 在 Apache 中使用 HSM 保护私钥
• 第 4 章 使用 polkit 控制对智能卡的访问
  • 4.1. 通过 polkit 的智能卡访问控制
  • 4.2. 排除与 PC/SC 和 polkit 相关的问题
  • 4.3. 向 PC/SC 显示关于 polkit 授权的更多详细信息
  • 4.4. 其他资源
• 第 5 章 扫描系统以检查配置是否合规
  • 5.1. RHEL 中的配置合规工具
  • 5.2. 配置合规性扫描
    • 5.2.1. RHEL 中的配置合规性
    • 5.2.2. OpenSCAP 扫描的可能结果
    • 5.2.3. 查看配置文件是否符合配置合规
    • 5.2.4. 评估配置是否符合特定基准
    • 5.2.5. 使用特定基准评估容器或容器镜像的安全性合规
  • 5.3. 配置合规补救
    • 5.3.1. 修复系统，使其与特定基准一致
    • 5.3.2. 使用 SSG Ansible Playbook 修复系统，使其与特定的基准保持一致
    • 5.3.3. 创建一个修复 Ansible Playbook，以使系统与特定的基准保持一致
  • 5.4. 使用 Kickstart 执行 RHEL 的强化安装
  • 5.5. 使用 autotailor 自定义安全配置文件
  • 5.6. RHEL 10 中支持的 SCAP 安全指南配置文件
  • 5.7. 其他资源
• 第 6 章 使用 Keylime 确保系统完整性
  • 6.1. 远程系统完整性监控
    • 6.1.1. 用于远程系统验证的组件和机制
    • 6.1.2. 远程监控的 Keylime attestation model
    • 6.1.3. 选择正确的 Keylime attestation 模型的注意事项
  • 6.2. 从软件包部署 Keylime 验证器
  • 6.3. 将 Keylime 验证器部署为容器
  • 6.4. 从软件包部署 Keylime 注册器
  • 6.5. 将 Keylime 注册器部署为容器
  • 6.6. 使用 RHEL 系统角色部署 Keylime 服务器
  • 6.7. keylime_server RHEL 系统角色的变量
  • 6.8. 从软件包部署 Keylime 租户
  • 6.9. 从软件包部署 Keylime pull-model 代理
  • 6.10. 从软件包部署 Keylime push-model 代理
  • 6.11. 为运行时监控配置 Keylime
  • 6.12. 为测量的引导证明配置 Keylime
  • 6.13. Keylime 配置
    • 6.13.1. 常规验证器配置
    • 6.13.2. push 模型的额外验证器配置
    • 6.13.3. 注册器配置
    • 6.13.4. 租户配置
    • 6.13.5. CA 配置
    • 6.13.6. 常规代理配置
    • 6.13.7. push 模型的额外代理配置
    • 6.13.8. 日志记录配置
• 第 7 章 使用 AIDE 检查完整性
  • 7.1. 安装 AIDE
  • 7.2. 使用 AIDE 执行完整性检查
  • 7.3. 更新 AIDE 数据库
  • 7.4. 文件完整性工具：AIDE 和 IMA
  • 7.5. 使用 aide RHEL 系统角色配置文件完整性检查
  • 7.6. 其他资源
• 第 8 章 管理 sudo 访问
  • 8.1. sudoers 中的用户授权
  • 8.2. 为用户授予 sudo 访问权限
  • 8.3. 使非特权用户运行某些命令
  • 8.4. 使用 RHEL 系统角色应用自定义 sudoers 配置
• 第 9 章 使用基于策略的解密配置加密卷的自动解锁
  • 9.1. 网络绑定磁盘加密
    • 9.1.1. NBDE 组件
    • 9.1.2. NBDE 原则
  • 9.2. 部署 Tang 服务器
  • 9.3. 部署 SELinux 处于 enforcing 模式的 Tang 服务器
  • 9.4. 轮转 Tang 服务器密钥并更新客户端上的绑定
  • 9.5. 在 web 控制台中使用 Tang 密钥配置自动解锁
  • 9.6. 基本的 NBDE 和 TPM2 加密客户端操作
  • 9.7. 为自动解锁 LUKS 加密的卷配置 NBDE 客户端
  • 9.8. 配置具有静态 IP 配置的 NBDE 客户端
  • 9.9. 使用 TPM 2.0 策略配置 LUKS 加密的卷的手动注册
  • 9.10. 使用 PKCS #11 pin 配置 LUKS 加密卷的解锁
  • 9.11. 从 LUKS 加密卷中删除 Clevis pin
  • 9.12. 使用 Kickstart 配置 LUKS 加密的卷的自动注册
  • 9.13. 配置 LUKS 加密的可移动存储设备的自动解锁
  • 9.14. 部署高可用性 NBDE 系统
  • 9.15. NBDE 网络中虚拟机的部署
  • 9.16. 使用 NBDE 为云环境构建可自动注册的虚拟机镜像
  • 9.17. 将 Tang 部署为容器
  • 9.18. 使用 Trustee attestation 服务器自动解锁加密的卷
  • 9.19. 使用 RHEL 系统角色配置 NBDE
    • 9.19.1. 使用 nbde_server RHEL 系统角色设置多个 Tang 服务器
    • 9.19.2. 使用 nbde_client RHEL 系统角色设置带有 DHCP 的 Clevis 客户端
    • 9.19.3. 使用 nbde_client RHEL 系统角色设置静态 IP Clevis 客户端
• 第 10 章 使用 fapolicyd 阻止和允许应用程序
  • 10.1. fapolicyd 框架结构
  • 10.2. 部署 fapolicyd
  • 10.3. 使用其它信任源将文件标记为可信
  • 10.4. 为 fapolicyd 添加自定义 allow 和 deny 规则
  • 10.5. 启用 fapolicyd 完整性检查
  • 10.6. 故障排除与 fapolicyd 相关的问题
  • 10.7. 使用 fapolicyd RHEL 系统角色防止用户执行不可靠的代码
• 第 11 章 保护系统免受入侵 USB 设备的攻击
  • 11.1. USBGuard 入侵防止
  • 11.2. 安装 USBGuard
  • 11.3. 使用 CLI 阻止和授权 USB 设备
  • 11.4. 永久阻止和授权 USB 设备
  • 11.5. 为 USB 设备创建自定义策略
  • 11.6. 为 USB 设备创建结构化自定义策略
  • 11.7. 授权用户和组使用 USBGuard IPC 接口
  • 11.8. 将 USBguard 授权事件记录到 Linux 审计日志中