签名校验是执行前的强制门禁系统，通过密码学校验确保关键二进制来自可信源且未被篡改；Linux用IMA+eBPF+TPM构建双层校验链，Windows通过WDAC+Secure Boot+双重签名实现拦截，嵌入式则需BootROM级安全启动。
核心思路：签名校验不是附加动作，而是执行前的强制门禁
系统关键二进制（如 /usr/bin/sudo、/bin/mount、/sbin/init）一旦被恶意替换或注入，攻击者就能绕过权限控制、提权甚至持久驻留。签名校验的本质，是让操作系统在加载执行前确认：“这个文件确实来自可信源，且一字未改”。它不依赖文件路径或权限位，而是基于密码学绑定内容与签名者身份。
Linux 系统级实战：用内核模块 + 用户态工具构建双层校验链
仅靠用户手动校验 SHA256 不够——它无法阻止运行时被替换。真正落地需结合内核可信机制与启动链管控：
-
启用 IMA（Integrity Measurement Architecture）：在内核启动参数中加入
ima_policy=tcb，使内核对所有 execve 调用的二进制自动计算哈希并比对预设策略库；配合ima_appraise=fix可自动拒绝未签名或签名失效的程序执行 -
将关键二进制签名写入 eBPF 验证器：使用
bpf_load加载自定义校验程序，在进程创建（tracepoint:syscalls:sys_enter_execve）时实时检查/proc/[pid]/exe的签名有效性，非法则直接返回 -EACCES -
签名密钥必须离线存储于 TPM 或 Secure Boot keyring：避免私钥泄露导致整个签名体系崩塌；公钥通过
keyctl padd注入内核 keyring，并设置KEYCTL_SET_PERM限制仅内核可读
Windows 系统级实战：强制启用 Authenticode + 启动时验证
Windows 原生支持二进制签名验证，但默认不拦截未签名程序。要实现“越权篡改即阻断”，需激活以下三层：
-
启用 Device Guard（现为 WDAC）策略：通过
Set-RuleOption -FilePathPolicy创建仅允许已签名且发布者受信的二进制运行的代码完整性策略（.cip），并以强制模式部署（Enable-WDAC） -
锁定启动时的签名验证开关：使用
bcdedit /set {current} testsigning off关闭测试签名模式；同时确保 Secure Boot 处于On状态，防止绕过 UEFI 层签名检查 -
对关键服务二进制做双重签名：例如
svchost.exe不仅需 Microsoft 签名，还应在企业内部 CA 下追加组织级签名；WDAC 策略配置为“任一有效签名即放行”，兼顾兼容性与可控性
嵌入式/固件场景：把签名校验下沉到 BootROM 层
在无完整 OS 的设备（如 IoT 网关、工控 PLC）中，攻击者常直接刷写 Flash 替换 boot.bin 或 app.elf。此时必须让验证发生在第一条指令执行前：
-
利用 SoC 原生安全启动（Secure Boot）流程：以 ESP32-C3 为例，烧录前用
esptool.py --keyfile my_signing_key.pem sign_data对固件签名；BootROM 会自动加载内置公钥，验证签名后才跳转执行 -
签名必须覆盖全部可执行段，不含调试符号与注释区：否则攻击者可删减非关键节后重签名绕过；建议使用
objcopy --strip-all清理后再签名 - 签名密钥严禁硬编码在构建脚本中：应由 CI/CD 流水线从 HashiCorp Vault 动态拉取，且每次签名后立即轮换密钥对，降低长期泄露风险
