普通用户无法绕过内核模块加载权限检查，因内核在sys_init_module系统调用中强制校验CAP_SYS_MODULE能力；文件权限仅作为纵深防御的第一道过滤层，需配合替换modprobe、清理配置、禁用udev规则及重定向/proc/sys/kernel/modprobe等措施实现有效防护。
普通用户无法直接通过文件权限“绕过”内核模块加载的权限检查，因为内核模块加载不是靠 /sbin/modprobe 或 /usr/bin/insmod 的执行权限生效的，而是由内核在 sys_init_module 系统调用入口强制校验 CAP_SYS_MODULE 能力。也就是说，即使你把 modprobe 文件 chmod 777，普通用户运行它依然会失败，报 Operation not permitted——这不是文件权限问题，是内核能力（capability）拦截。
但文件权限控制仍有实际价值：它能阻断自动化、批量或误配置触发路径，属于纵深防御中用户态的第一道过滤层。关键不在于“禁止执行”，而在于“让调用无害化”。
直接替换 modprobe 为无操作程序
这是最常用且安全的落地方式：
- 执行
sudo ln -sf /bin/true /sbin/modprobe - 或更稳妥地：
sudo cp /bin/true /sbin/modprobe && sudo chmod 755 /sbin/modprobe - 效果：任何用户（包括 root）执行
modprobe xxx都立即返回成功码 0，但不加载模块、不写日志、不触发 udev - 验证：
modprobe dummy无输出；dmesg | tail不新增模块加载记录
清理所有可执行文件的模块加载调用链
很多脚本或服务会硬编码调用 modprobe，需统一归零其效果：
- 检查并修改
/etc/init.d/、/etc/cron.*、/etc/systemd/system/*.service中所有含modprobe的行，替换为/bin/true或删除 - 清理
/etc/modules和/etc/modprobe.d/*.conf中的install module_name /sbin/modprobe行，改为install module_name /bin/false（返回失败码，明确拒绝） - 注意：
blacklist module_name仅影响modprobe直接调用，对依赖加载无效；install ... /bin/false才真正切断所有路径
限制 udev 规则中的执行权限（非文件权限，但属用户态入口）
udev 是最常见的自动加载触发源，其规则本身不依赖文件权限，但可通过移除执行能力来封堵：
- 搜索热插拔规则：
grep -r "modprobe\|load_module" /lib/udev/rules.d/ /etc/udev/rules.d/ - 对匹配行加
#注释，或直接删掉整行（如RUN+="/sbin/modprobe ...") - 不要
chmod -xudev 规则文件——udev 不检查文件可执行位，只读取内容
禁用内核 request_module 的用户态代理（底层开关）
如果连内核主动请求都要拦截（如识别文件系统时自动加载 ext4），需改内核参数：
- 临时禁用：
echo "/bin/true" | sudo tee /proc/sys/kernel/modprobe - 效果：内核调用
request_module("ext4")时，不再 fork 并执行/sbin/modprobe ext4，而是直接失败（但insmod仍可用） - 这不是文件权限设置，但它是比
chmod更本质的“权限重定向”，且无需重启
文件权限本身不能阻止模块加载，但配合 setcap、sysctl 和配置清理，能让普通用户的任意命令调用都变成“空转”。真正的防线在内核能力检查，而用户态文件操作只是让攻击者连试探成本都变高。
