Linux TCB是可信计算基（Trusted Computing Base）的核心，它决定了系统安全策略能否被强制执行，任何绕过TCB的代码都可能破坏整个信任链。
什么是Linux TCB？它包含哪些组件
TCB并非一个单独的文件或进程,而是安全上必须可信的硬件、固件和软件集合，在Linux系统中，TCB通常包括内核代码、关键内核模块、设备驱动、安全模块（如SELinux、AppArmor）、以及系统启动链中的引导加载程序，只有TCB内部的组件才能被系统信任为安全策略的执行者；TCB外部的代码，即使运行在高权限下，也被视为不可信。
![[Linux] Linux 查看硬件配置（screenfetch;lscpu;lsmem;hostnamectl;dmidecode）](https://i2.hdslb.com/bfs/archive/57c8f9cf490321781e3018a534dd90f6e65d5e45.jpg)
TCB的信任边界如何划定
行业共识认为,TCB的边界必须清晰且最小化，一个常见的误解是“只要运行Linux就自动拥有TCB”，实际上你需要主动定义哪些子系统属于TCB，典型划界方式包括：
- 内核本身：包含核心调度、内存管理、文件系统；
- 安全模块：强制访问控制策略（如SELinux策略）的代码；
- 启动固件：UEFI、BIOS、TSP（可信启动）；
- 硬件可信根：TPM（可信平台模块）芯片，用于验证TCB组件的完整性。
Linux TCB与系统安全启动的关系
安全启动（Secure Boot）是TCB的起点，它确保从UEFI固件到内核的每个阶段都有签名验证，如果安全启动被绕过，TCB的信任根就被破坏，后续所有安全机制都可能失效，配置Linux TCB时，你需要确认内核签名、模块签名、以及启动加载器（如GRUB）的签名是否完整。
如何查看Linux TCB的当前状态
很多运维人员会遇到“linux tcb检查”的需求，但不知道具体命令，以下实操步骤可以帮你快速定位当前TCB的范围和完整性。
检查内核签名与模块签名
# 查看内核是否启用模块签名 ls -l /sys/kernel/security/lockdown cat /sys/kernel/security/lockdown # 输出应为 "integrity" 或 "confidentiality" # 检查已加载模块的签名状态 tail -n 20 /var/log/messages | grep "module verification" more /proc/modules | grep -i "signature"
如果系统支持Kernel Lockdown，说明内核正处于受限制模式，TCB强制执行，否则，你可以认为TCB边界是开放的。
验证TCB组件完整性
使用TPM工具（如tpm2-tools）可以测量PCR（平台配置寄存器），从而验证TCB链条是否被篡改：
# 安装tpm2-tools（Debian/Ubuntu） sudo apt install tpm2-tools # 显示当前PCR值 tpm2_pcrread -o pcr_values.bin tpm2_pcrlist # 与已知的基准值比较（通常由安全启动过程记录） sha256sum pcr_values.bin
如果PCR值异常,说明TCB链条在某个环节被修改，需要立即排查引导加载器、内核或初始RAM磁盘（initramfs）的完整性。
使用SELinux或AppArmor确认TCB策略
强制访问控制（MAC）模块是TCB内部的关键组件，它们负责执行安全策略，查看当前生效的MAC模块：
# 检查SELinux状态（如果启用） sestatus getenforce # 应输出 Enforcing # 检查AppArmor状态（如果启用） aa-status
如果MAC模块未启用或处于宽容模式,TCB的策略执行能力被削弱，系统可能无法防御权限提升攻击。
Linux TCB在容器和虚拟化场景下的挑战
容器共享宿主内核,这意味着容器的安全性完全依赖宿主TCB的完整性，如果容器破坏了宿主机内核的TCB，它就能绕过所有隔离。在容器环境下，TCB的边界需要重新定义：
- 宿主机内核属于TCB,但容器内的进程通常不属于TCB（除非使用安全容器技术如Kata Containers）；
- 使用
--privileged标志的容器会直接暴露大量TCB组件，应严格禁止； - Linux TCB与容器安全策略的配合：通过
seccomp、AppArmor、Capabilities限制容器对TCB的访问。
为什么容器逃逸往往源于TCB漏洞
业内专家指出,绝大多数容器逃逸攻击利用了宿主机内核漏洞，这些漏洞本质上是对TCB边界的突破，避免容器逃逸的关键是：
- 保持内核和TCB组件及时更新；
- 使用用户命名空间（User Namespace）隔离特权操作；
- 限制容器对
/proc、/sys等敏感文件系统的写入权限。
虚拟化环境中的TCB差异
在KVM、Xen等虚拟化环境中，TCB包括Hypervisor和特权域（Domain 0），虚拟机（Guest）内部的TCB独立于宿主TCB，但宿主TCB的完整性依然影响所有虚拟机的安全性，如果宿主内核被篡改，攻击者可以监控甚至修改虚拟机内存。虚拟化环境下的TCB保护需要从硬件（TPM、Intel TXT）开始，一直延伸到虚拟机监视器（VMM）。
linux tcb配置方法：从基础到进阶
配置TCB不是一次性操作,而是持续维护的过程，以下步骤针对常见场景，帮助你构建一个可验证的TCB。
基础配置：启用安全启动和内核签名
- 确保UEFI安全启动已启用（BIOS中设置）；
- 使用分发版签名的内核（如Ubuntu、Fedora默认提供）；
- 配置
shim引导加载器并加载你的自签名证书（如果需要自定义内核）； - 锁定内核启动参数：
lockdown=confidentiality（在GRUB配置中加入）。
进阶配置：启用完整性测量子系统
Linux的IMA（Integrity Measurement Architecture）和EVM（Extended Verification Module）可以扩展TCB的测量范围，覆盖文件系统完整性：
# 启用IMA before 内核启动参数 ima_policy=tcb ima_appraise=fix # 设置IMA策略（仅测量关键二进制文件） echo "measure func=BPRM_CHECK fowner=0" > /sys/kernel/security/ima/policy # 查看IMA测量日志 cat /sys/kernel/security/ima/measurements
IMA与EVM配合,可以确保TCB内的可执行文件在运行前已被验证，防止rootkit篡改系统工具。
定期验证TCB完整性
建议使用自动化脚本定期检查TCB组件状态,并记录到远程日志服务器：
#!/bin/bash
# 检查内核锁定状态
if [ "$(cat /sys/kernel/security/lockdown)" != "confidentiality" ]; then
echo "TCB not locked down" | tee /var/log/tcb_monitor
fi
# 验证PCR值（示例）
tpm2_pcrlist > /tmp/pcr_current
diff /tmp/pcr_current /etc/tcb/pcr_baseline
如果PCR值与基线不匹配,应触发警报并执行取证分析。
常见问题与解答：Linux TCB核心疑问
问：linux tcb是什么？它与普通用户权限有何区别？
答：TCB是必须被信任的代码集合，它拥有执行安全策略的全部权限，普通用户进程不在TCB内，它们只能通过系统调用向TCB请求服务，如果用户进程能修改TCB组件（如内核模块），安全机制就失效了。TCB的隔离性比用户权限更关键，它决定了系统是否还能被信任。
问：在容器里运行服务，是否需要单独考虑TCB？
答：是的，容器共享宿主TCB，所以宿主的安全直接决定容器的安全，你应该假设容器内的进程不可信，并加强宿主TCB的防护（如使用seccomp限制系统调用，使用Capabilities剥离特权操作）。如果容器使用了--privileged，它就直接获得了TCB的一部分控制权，这等同于禁止了安全隔离。
问：如何验证我的Linux系统是否构建了完整的TCB？
答：首先检查安全启动是否启用，其次确认内核锁定模式（lockdown）是否为confidentiality，然后使用IMA测量关键文件，并对比TPM PCR值是否与预期一致，如果全部通过，你的TCB是完整的，如果系统不支持TPM，可以依赖安全启动连锁签名验证，但信任根会减弱。完整的TCB链条需要从硬件可信根（TPM）到应用层所有策略组件都经过验证。
Linux TCB不是一种可选的“增强”功能，而是任何安全系统的基石。 无论你运行的是普通服务器、容器平台还是虚拟化环境，定义并维护TCB的边界直接影响能否抵御提权、逃逸和固件级攻击，从安全启动开始，结合IMA测量和MAC模块，你能构建一个可审计、可验证的信任链，让系统在最坏情况下依然保持可信。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/509490.html
