内核模块加载权限由CAP_SYS_MODULE能力控制，而非UID是否为root；即使root进程若无该能力仍被拒绝，需通过capability管理、路径限制、签名验证、规范部署及审计监控等多层加固。
内核模块加载权限不是靠“是否是 root”一刀切，而是由 CAP_SYS_MODULE 能力控制。加固的关键在于收紧该能力的授予范围，同时保留必要功能——既防未授权加载，又不破坏运维流程。
明确谁可以加载模块
内核只认 capability，不认 UID。即使 UID 是 0（root），若进程未携带 CAP_SYS_MODULE，insmod 或 modprobe 仍会返回 Operation not permitted。
- 默认情况下，root 用户启动的 shell 及其子进程拥有该能力
- 普通用户进程即使被 sudo 执行，也需确保 capability 被继承（sudo 默认保留部分 capability，但需确认配置）
- 容器环境（如 Docker、systemd-nspawn）默认剥离该能力，必须显式添加：
--cap-add=SYS_MODULE - SELinux 或 AppArmor 启用时，还需满足对应策略，例如 SELinux 的
module_load权限
禁用非必要模块加载路径
减少攻击面，从源头限制加载入口：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 禁用
insmod直接调用：可移除或重命名/sbin/insmod，仅保留modprobe作为受控入口 - 关闭模块自动加载：在内核命令行添加
module_blacklist=*（慎用），或更稳妥地通过/etc/modprobe.d/blacklist.conf屏蔽高危模块（如usb-storage、firewire-core） - 启用模块签名验证（
CONFIG_MODULE_SIG=y）并强制校验：kernel.modprobe=0+module.sig_unenforce=0，确保仅签名有效模块可加载
规范模块部署与自动加载
把模块管理纳入系统级配置，避免临时手工操作：
- 自研模块放入
/lib/modules/$(uname -r)/extra/，运行depmod -a更新依赖数据库 - 开机加载统一走
/etc/modules-load.d/*.conf，每行一个模块名（不带.ko），由systemd-modules-load.service在特权上下文中执行 - 参数配置统一写入
/etc/modprobe.d/*.conf，例如：options mydrv debug=1，避免命令行传参带来的日志泄露风险 - 对关键模块启用
install指令拦截，例如：install mydrv /bin/false，防止被modprobe非预期触发
审计与实时监控
加载行为必须可观测，便于事后追溯：
- 开启内核日志记录：确保
CONFIG_MODULE_UNLOAD和CONFIG_MODULE_FORCE_UNLOAD已设，配合dmesg -w或journalctl -k -g 'module'实时捕获 - 启用 auditd 规则：
-a always,exit -F arch=b64 -S init_module,finit_module -k kernel_modules，记录所有模块加载系统调用 - 定期检查已加载模块：
lsmod | awk '$1 !~ /^(core|builtin)$/ {print $1}'，比对白名单 - 对生产环境，建议将模块编译为 built-in（
y而非m），彻底消除动态加载环节
