GRUB密码仅阻止按e编辑启动项，无法防御Live USB启动、离线挂载磁盘或绕过Secure Boot等物理攻击；真正有效的防护需Secure Boot+LUKS+TPM2三者绑定。
单纯给GRUB加密码不能防止物理接触者提权——它只拦编辑菜单，不拦从Live USB启动、不拦绕过GRUB直接挂载磁盘、更不拦TPM未绑定时离线解密LUKS。
grub2-mkpasswd-pbkdf2只能锁住e键编辑，不是加密启动链
运行 grub2-mkpasswd-pbkdf2 生成的哈希，填进 /etc/grub.d/00_header 并配 superusers 和 password_pbkdf2，确实能阻止别人在GRUB菜单按 e 修改内核参数（比如加 init=/bin/bash 或 rd.break）。但以下操作完全不受影响：
- 插U盘启动任意Linux Live系统，
sudo cryptsetup luksOpen /dev/sda2 root→ 输入密码就能挂载你的根分区 - 把硬盘拆下来接到另一台机器，只要知道LUKS密码，数据全可读
- 关机后短接主板跳线清CMOS，重置BIOS设置，再禁用Secure Boot，GRUB密码配置可能被绕过
- GRUB密码本身不校验签名，攻击者可替换整个
/boot分区为恶意引导程序
真正起效的是Secure Boot + LUKS + TPM2三者联动
物理接触场景下，唯一能实质性抬高攻击门槛的是让“有硬盘” ≠ “能读数据”。这需要三环咬合：
-
Secure Boot必须启用且保持开启：确保UEFI固件只加载已签名的GRUB、内核、initramfs。用mokutil --sb-state确认输出为SecureBoot enabled -
LUKS全盘加密必须在安装时启用（或迁移时重建），且密钥不能只靠用户口令——否则Live系统下输对密码就完事 -
systemd-cryptenroll --tpm2-device=auto --tpm2-pcrs=7 /dev/sda2这条命令才是关键：它把LUKS主密钥密封进本机TPM2芯片，并绑定PCR寄存器值（如PCR 7记录Secure Boot状态）。换台机器、关掉Secure Boot、甚至重刷固件，PCR值一变，密钥就解封失败 - 确认initramfs含
tpm2-tss和cryptsetup：CentOS/RHEL系跑dracut --regenerate-all，Debian/Ubuntu系跑update-initramfs -u
/etc/inittab 或 systemd 的 sulogin 配置只是补丁，不是防线
有些资料建议在 /etc/inittab 加 sp:S:respawn:/sbin/sulogin，或在systemd里设 systemctl enable rescue.target 并配密码。这类操作只影响“已成功进入单用户模式后的第一道shell登录”，前提是攻击者已经：
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 成功绕过了GRUB密码（比如用Live USB改写
/boot/grub2/grub.cfg） - 或者禁用了Secure Boot并用自定义内核启动
- 或者LUKS没绑TPM，直接输密码解密了
此时再拦 sulogin 已无意义——数据早被读走了。它最多防个手滑误入，不是物理防护组件。
BIOS/UEFI密码和机箱开关检测是最后一道物理层提醒
GRUB和Secure Boot都依赖固件层可信。如果攻击者能进BIOS/UEFI界面，就能：
- 关闭Secure Boot
- 禁用TPM2
- 修改启动顺序优先从USB启动
- 重置管理员密码（部分厂商支持）
所以必须设BIOS/UEFI管理员密码，并启用机箱入侵检测（如有）。注意：BIOS密码本身可被跳线清除，但它能触发告警日志或停机机制，属于“威慑+留痕”手段，不是加密防线。
真正难绕过的点在于TPM2绑定的PCR策略——它不依赖用户记忆任何口令，也不依赖硬盘是否在原主机上，而取决于“启动时硬件状态是否匹配”。一旦设错PCR值（比如该用7却用了0），系统可能直接无法启动。这点极易被忽略，也最难调试。
