CONFIG_MODULE_SIG_FORCE是实现内核模块白名单效果的核心机制，它强制拒绝未签名、签名无效或密钥不在信任环中的模块，配合密钥环管理、modprobe拦截和install策略才能构建完整白名单防护体系。
Linux 没有官方称为“内核白名单机制”的标准功能，但可通过组合配置实现等效的白名单效果：即只允许特定签名模块加载，拒绝一切未授权模块。这本质是通过强制签名验证 + 严格模块管理达成的主动控制，而非简单罗列允许列表。
用 CONFIG_MODULE_SIG_FORCE 实现签名级白名单
这是最接近白名单逻辑的内核级方案——它不靠“允许哪些”，而是“只接受已认证的”。启用后，内核会拒绝所有未签名、签名无效或签名密钥不在系统信任密钥环中的模块。
编译内核时启用：
CONFIG_MODULE_SIG=y（启用模块签名）CONFIG_MODULE_SIG_FORCE=y（强制验证，禁用任何绕过）CONFIG_MODULE_SIG_SHA512=y（推荐强哈希算法）-
签署你信任的模块（例如自研驱动）：
scripts/sign-file sha512 ./certs/signing_key.pem ./certs/signing_key.x509 ./your-module.ko
-
将公钥导入内核密钥环（重启后仍生效）：
sudo keyctl padd asymmetric mymodulekey @s < ./certs/signing_key.x509
此时，只有经该私钥签署、且公钥已载入密钥环的模块才能加载；其他全部被静默拒绝，dmesg 中显示 Module signature verification failed。
配合用户态策略收紧入口
签名机制防不住已签名的恶意模块，需叠加管控：
-
阻断非管理员触发路径：
sudo ln -sf /bin/true /sbin/modprobe
这让任何自动调用（如 udev、dbus）无法加载模块，仅保留
insmod/modprobe手动操作权限。 -
清空默认加载行为：
在/etc/modprobe.d/下创建策略文件，对所有非白名单模块设为失败：# /etc/modprobe.d/whitelist-only.conf install usb-storage /bin/false install bluetooth /bin/false install nvidia /bin/false # 只为你明确信任的模块留空或写 install xxx /bin/true（极少必要）
-
禁用内核自动请求（谨慎）：
echo 1 | sudo tee /proc/sys/kernel/modules_disabled
此开关一开，连
insmod都失效，适合只读安全容器场景。
验证是否生效
- 尝试加载一个未签名模块：
sudo insmod /lib/modules/$(uname -r)/kernel/drivers/usb/storage/usb-storage.ko # 应返回错误，dmesg 显示 signature verification failure 或 Operation not permitted
- 查看当前模块状态：
cat /sys/module/usb_storage/initstate # 若显示 "live"，说明已被加载——需检查 initramfs 是否含旧模块 lsmod | grep usb_storage # 应无输出
真正有效的白名单不是靠“加允许项”，而是靠切断所有非法入口 + 只开放受控出口。签名强制 + modprobe 拦截 + install 拦截三者结合，才能堵住 firmware 请求、依赖链加载、udev 规则等常见绕过路径。
