Linux Secure Boot + IMA + Kernel Lockdown 可信启动链实战 2026：sbctl 密钥管理、PCR 度量与运行时完整性完整指南

更新于：2026 年 7 月 31 日

Linux 可信启动链是指通过 UEFI Secure Boot、IMA（Integrity Measurement Architecture）与 Kernel Lockdown 三层机制，从固件加载 shim/GRUB2、到内核与 initramfs、再到运行时用户空间二进制文件，全程做加密签名校验的一整套完整性保护方案。这条信任链能拦下 Bootkit、Evil-Maid 攻击、未签名模块加载，以及运行时对内核内存的越权修改，也是 2026 年 RHEL 10、Fedora 42、Ubuntu 24.04 LTS 与 SUSE 15 SP7 生产系统默认的强化配置。本文给出从密钥托管、PCR 度量策略，到运行时策略执行的可运行完整配置。

• UEFI Secure Boot 只保证启动前签名校验，若不启用 Kernel Lockdown 与 IMA，内核加载后的完整性其实没人管，攻击面依然完整。
• 推荐用 sbctl（v0.16+）替代传统的 mokutil/efi-updatevar，一条 CLI 就完成 PK/KEK/db 密钥生成、注册与二进制签名。
• Kernel Lockdown 提供 integrity 与 confidentiality 两级模式；生产系统建议 integrity，禁止未签名 kexec、/dev/mem 与 BPF JIT 内存注入。
• IMA-appraisal 结合 EVM 会在文件被 mount 时校验 xattr 中的 HMAC 签名，可以挡住对 /usr/bin 二进制的静态篡改。
• TPM 2.0 PCR 0/1/2/4/7/9 度量可与 systemd-cryptenroll 绑定 LUKS2，形成从固件到磁盘卷的完整远程证明链。
• 在 CI 里用 sbverify、evmctl 与 tpm2_pcrread 三条命令就能对系统信任链做冒烟测试。

Linux 可信启动链是什么，为什么 Secure Boot 单独还不够？

可信启动链（Trusted Boot Chain）在 2026 年的 Linux 语境里，指的是从固件通电、到用户空间进程执行的每一环都可验证的密码学信任传递。UEFI Secure Boot 负责最底层：固件用平台内置的 db 密钥库校验 shim.efi，shim 再校验 GRUB2 或 systemd-boot，引导器最终校验 Linux 内核与其 initramfs 的签名。这一步能拦住绝大多数 Bootkit（例如 BlackLotus、MoonBounce），但它只覆盖启动前阶段。

问题是：内核一旦成功加载，攻击者仍可以通过 /dev/mem、未签名模块 insmod、kexec_load() 或 BPF 写入内核只读内存，绕过之前完成的所有签名校验。这正是 Kernel Lockdown 出场的位置，它由 David Howells 在 5.4 主线合入，2026 年的 6.11 LTS 已经相当稳定。Lockdown 关闭了内核向 root 用户开放的一切"覆盖自身"的接口，让 Secure Boot 的信任沿着内核运行时继续延伸。

而 IMA-appraisal 则把信任传递到用户空间：当 /usr/bin/bash 被 execve() 时，内核会读取该文件的 security.ima 扩展属性，用受信任的 IMA 密钥环校验其签名。三层叠加后，从 UEFI 到用户空间就形成一条不可分割的密码学信任链。如果你还没对磁盘卷做完整性保护，建议先看看 LUKS2 + TPM 2.0 + Clevis 全盘加密自动解锁实战，再回到本文补完运行时层。

用 sbctl 从零管理 UEFI Secure Boot 密钥

过去五年，管理 Secure Boot 密钥基本上就是跟 efi-updatevar、KeyTool.efi 和 UEFI Setup 界面反复搏斗。老实说，那套流程能劝退大部分人。2026 年推荐直接用 Foxboron/sbctl 项目（当前稳定版 0.16.1），它把 PK/KEK/db/dbx 的生成、注册与二进制签名统一为一条 Go 编写的 CLI。sbctl 的思路是：把厂商预置密钥全部清空，用你自己控制的 Owner Key 作为 PK，这样就完全掌握了自己机器的启动信任源。

初始化自签密钥并注册

# 1. 先把主板固件切换到 "Setup Mode"（清空既有 PK）
#    通常在 UEFI 设置 → Security → Secure Boot → Restore Factory Keys 之后立即 Clear PK

# 2. 检查当前状态：Setup Mode 应该为 Enabled，Secure Boot 为 Disabled
sudo sbctl status

# 3. 生成 PK/KEK/db 三级密钥（私钥保存在 /var/lib/sbctl，权限 0600）
sudo sbctl create-keys

# 4. 一次性注册到固件；--microsoft 保留微软 3rd-party CA，
#    以免打入的 Windows 或 Option ROM 无法启动
sudo sbctl enroll-keys --microsoft

# 5. 为当前所有需要签名的 EFI 二进制打签名
sudo sbctl sign -s /boot/EFI/BOOT/BOOTX64.EFI
sudo sbctl sign -s /boot/EFI/systemd/systemd-bootx64.efi
sudo sbctl sign -s /boot/vmlinuz-linux

与内核更新联动

Arch、Fedora 与 Ubuntu 都支持 pacman/dnf/apt 钩子在内核更新后自动重签。以 Fedora 42 为例，在 /etc/dnf/plugins/post-transaction-actions.d/sbctl.action 中加入：

kernel-core,kernel:in:/usr/bin/sbctl sign-all -g
systemd-boot-unsigned:in:/usr/bin/sbctl sign -s /boot/EFI/systemd/systemd-bootx64.efi

这一步真的很关键。跳过它，内核升级后旧签名失效，下次启动就会被固件拒绝，只能进 fallback shell。sbctl 0.16 引入的 sign-all -g 子命令会自动发现所有需要签名的二进制，并生成 hook manifest。

Kernel Lockdown 的 integrity 与 confidentiality 模式如何选

Kernel Lockdown 是通过 LSM（Linux Security Module）实现的运行时限制层，源码位于 security/lockdown/。它提供两个渐进等级：

能力	integrity 模式	confidentiality 模式
加载未签名内核模块	禁止	禁止
kexec 到未签名镜像	禁止	禁止
写入 /dev/mem、/dev/kmem、/dev/port	禁止	禁止
hibernate 到未加密 swap	禁止	禁止
读取内核内存（含 /proc/kcore、bpftool prog dump jited）	允许	禁止
调试跟踪（ftrace, kprobe events）	允许	禁止
典型场景	通用服务器、K8s Worker	处理机密数据的裸机、HSM 前端

Secure Boot 启用后，Fedora、RHEL、Ubuntu 打过补丁的内核会默认进入 integrity 模式；SUSE 与 Debian 得手动加内核参数。切换与查看方法：

# 查询当前 lockdown 状态（中括号内为激活模式）
cat /sys/kernel/security/lockdown
# 输出：none  [integrity]  confidentiality

# 永久启用 confidentiality 模式，编辑 /etc/default/grub：
GRUB_CMDLINE_LINUX="... lockdown=confidentiality"
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

只签名内核模块，避免 confidentiality 副作用

许多团队踩过的坑：切到 confidentiality 后，Prometheus node_exporter 的一些 collector（比如 diskstats）以及 eBPF 观测栈会因为无法读取 kcore 而报错。我上次在一个金融客户那儿就是被值班同事半夜投诉了这个。生产建议是停留在 integrity，同时开启模块签名强制：

# 生成 X.509 内核模块签名密钥
openssl req -new -x509 -newkey rsa:4096 -keyout module-key.pem \
  -outform DER -out module-cert.der \
  -days 3650 -nodes -subj "/CN=Ops Module Signing/"

# 用密钥签名一个外部模块（例如 zfs.ko）
/usr/src/kernels/$(uname -r)/scripts/sign-file sha256 \
  module-key.pem module-cert.der /lib/modules/$(uname -r)/extra/zfs.ko

# 把公钥注册到 MOK 列表（下次启动进入 MOK Manager 输入密码确认）
sudo mokutil --import module-cert.der

启用 module.sig_enforce=1 内核参数后，任何未签名或签名密钥不在 .builtin_trusted_keys/.secondary_trusted_keys/.machine 环中的模块都会被内核拒绝加载，也就把 modprobe 攻击面封死了。想在运行时进一步看穿模块行为，可以搭配 LKRG 内核运行时防护实战指南 做纵深防御。

配置 IMA-appraisal 与 EVM：从度量到强制执行

IMA 有两个正交能力：measurement（把文件哈希写入 TPM PCR 10）与 appraisal（在文件访问时校验签名并拒绝执行）。只开 measurement 就只是审计，不阻断攻击。真正把 IMA 变成主动防御，得让 ima_appraise=enforce 与 EVM（Extended Verification Module）一起上。

写入符合 IMA 策略语法的规则文件

# /etc/ima/ima-policy, 内核在 initramfs 阶段读取
# 度量所有 root 拥有的可执行文件
measure func=BPRM_CHECK mask=MAY_EXEC uid=0
measure func=MMAP_CHECK mask=MAY_EXEC
# 校验签名，未通过则拒绝 execve
appraise func=BPRM_CHECK appraise_type=imasig
appraise func=MODULE_CHECK appraise_type=imasig
# 允许伪文件系统豁免
dont_measure fsmagic=0x9fa0    # proc
dont_measure fsmagic=0x62656572 # sysfs
dont_appraise fsmagic=0x01021994 # tmpfs

为 /usr 里的二进制批量签名

# 用 evmctl 为每个可执行文件写入 security.ima xattr
sudo find /usr/bin /usr/sbin /usr/libexec -type f -perm -u+x \
  -exec evmctl ima_sign --key /etc/keys/ima-privkey.pem {} \;

# 同时用 EVM HMAC 保护 xattr 本身，防止攻击者篡改 security.ima
sudo evmctl hmac -a sha256 --imasig /usr/bin/ls

内核在 initramfs 中加载 EVM HMAC 密钥的常见做法是：把密钥通过 TPM Sealing 绑到 PCR 7（Secure Boot 状态），只有系统真正处于 Secure Boot 状态时才能解封，从而防止攻击者绕过 Secure Boot 后强行注入伪造的 HMAC 密钥。IMA 模板文档详细描述了度量记录字段与自定义模板方法。

TPM 2.0 PCR 策略与远程证明

TPM 2.0 的平台配置寄存器（PCR）在信任链里承担"度量结果的账本"角色。启动过程中，UEFI 会把每一段代码的哈希扩展进特定 PCR：

• PCR 0：SRTM/CRTM，固件代码本身。
• PCR 1：主板配置数据、UEFI 变量。
• PCR 2：Option ROM。
• PCR 4：MBR / bootloader 代码。
• PCR 7：Secure Boot 策略状态（PK/KEK/db 内容 + 启用位）。
• PCR 8/9：GRUB 命令行、内核与 initramfs（由 GRUB tpm 模块扩展）。
• PCR 10：IMA measurement list。

把敏感密钥（比如 LUKS2 卷解锁密钥、EVM HMAC 密钥）Sealing 到一组 PCR 上，就实现了"如果固件、bootloader、内核或 Secure Boot 策略被改动，密钥不释放"的效果。systemd-cryptenroll 与 tpm2-tools 是 2026 年推荐的工具链。

# 把 /dev/nvme0n1p3 的 LUKS 密钥封印到 PCR 0+2+7
sudo systemd-cryptenroll /dev/nvme0n1p3 \
  --tpm2-device=auto \
  --tpm2-pcrs=0+2+7 \
  --wipe-slot=tpm2

# 读取当前 PCR 值（生产系统重启后应保持稳定）
sudo tpm2_pcrread sha256:0,2,7

# 生成远程证明 quote，供集群管理器如 Keylime 校验
tpm2_quote -c 0x81010001 -l sha256:0,1,2,4,7,8,9 -m quote.msg -s quote.sig

把度量结果送到集中式远程证明服务（Keylime、HP RIM、Azure Attestation Service），可以让集群在 Pod 调度前拒绝启动到未通过完整性校验的节点。tpm2-software 官方站点提供了完整的 tpm2-tools 与 tpm2-tss 文档。这里的 PCR 策略与前面 LUKS2 + Clevis 自动解锁使用的其实是同一套底层机制，只是使用场景不同。

2026 年生产环境部署清单与常见坑

下面是我在过去 12 个月里，为若干金融与云原生团队落地信任链时提炼出来的实战清单。它不追求最激进的配置，而是要求每一步都可回滚、可审计、可热修。

1. 先做基线快照。在启用 Secure Boot 前用 chipsec_main -m common 记录固件基线，出现问题时可以比对。
2. MOK 密码托管到 Vault。别把 MOK 密码写死在 Ansible 变量里。推荐用 HashiCorp Vault 的 transit 引擎在 provision 时按需解密。
3. 先 audit 再 enforce。IMA 与 Lockdown 都至少要跑两周日志模式，观察是否遗漏第三方 agent 的白名单（Falcon、CrowdStrike 均需签名重打包）。可以配合 Falco + Tetragon 运行时威胁检测指南 做双层监控。
4. 处理签名回滚。把旧内核签名的过期时间与 dbx 同步；SBAT（Secure Boot Advanced Targeting）在 2026 已成 Fedora 默认策略，需要在 shim 元数据里维护版本号。
5. 物理机独立 PK。不要在集群内共享同一把 PK，否则一台节点被物理拆机就等于全集群破防。建议每台机器由 provisioning 服务器生成独立 PK，并把公钥推送到远程证明服务。
6. 与 systemd 服务加固对齐。Kernel Lockdown 不会阻止用户态提权后的横向移动。请参考 systemd 服务安全加固实战 为业务服务加沙箱。
7. NVIDIA/DKMS 模块预签。用 akmods（Fedora）或 dkms --sign-tool（Ubuntu）确保内核升级后驱动仍能加载，否则很容易掉图形界面。
8. 把 MAC 策略也接上。结合 SELinux 强制访问控制实战，让签名信任链和用户态策略在同一层生效。

用三条命令验证信任链是否闭合

不管你是刚完成部署，还是打算写进 CI 的 nightly smoke test，下面这三条命令是最快的信任链健康检查：

# 1. Secure Boot 与 db 密钥状态（应为 SecureBoot: Enabled，Setup Mode: Disabled）
sudo sbctl status | tee /tmp/sb.txt
sudo sbverify --list /boot/vmlinuz-linux

# 2. Kernel Lockdown 与模块签名强制
cat /sys/kernel/security/lockdown        # 期望 [integrity] 或 [confidentiality]
cat /sys/module/module/parameters/sig_enforce   # 期望 Y

# 3. IMA 度量与 TPM PCR 是否一致
sudo tail -5 /sys/kernel/security/integrity/ima/ascii_runtime_measurements
sudo tpm2_pcrread sha256:7,10

把上述三步封进一个 trust-chain-check.sh，加进 Ansible 的 handlers 或 Kubernetes 节点的 startup probe，配置漂移的那一瞬间就会让构建失败。RHEL 10 的官方 Security Hardening 指南把这三个维度纳入了默认合规评分表，可以直接对齐审计报告。

常见问题

开启 Secure Boot 是否会显著影响启动时间？

不会。UEFI 对每个 EFI 二进制的 RSA-2048 或 ECDSA-P256 签名校验只增加约 20 到 80 毫秒。真正的开销来自 IMA 全盘度量首次启动扫描，可以通过 ima_template=ima-ng 与只度量 MAY_EXEC 的策略，把稳态启动时间控制在 300 毫秒以内。

Kernel Lockdown 与 SELinux/AppArmor 有什么区别？

Kernel Lockdown 保护的是内核自身不被 root 修改；SELinux/AppArmor 则限制用户态进程之间的相互访问。两者位于不同层次，应当叠加使用而不是二选一。生产系统通常是 Secure Boot + Lockdown integrity + SELinux enforcing 三层。

虚拟机（KVM/QEMU）里能启用完整信任链吗？

可以。QEMU 8+ 支持 OVMF Secure Boot 与 swtpm 软 TPM 2.0；libvirt XML 里配置 <os firmware="efi"> 与 <tpm model="tpm-crb"><backend type="emulator"> 即可获得与裸机相同的 PCR 度量能力，非常适合在 CI 中做信任链回归测试。

忘记 MOK 密码或 Owner Key 私钥怎么办？

只能进 UEFI Setup 手动清空 PK（回到 Setup Mode），然后用 sbctl create-keys 重新生成一整套并 enroll。之前用旧密钥签名的所有 EFI 二进制都要重签，务必提前备份原始未签名镜像。

IMA-appraisal 会阻止解释型语言（如 Python/Node）执行的脚本吗？

默认策略只对 execve 的 ELF 二进制做校验，Python 脚本作为解释器的参数不会触发 BPRM_CHECK。如果要覆盖脚本，需要在策略里加入 func=MMAP_CHECK mask=MAY_EXEC 并配合 execveat 场景规则，或者在解释器内嵌入 IMA 验证。