新手怎么通过分析Dmesg日志发现内核层身份验证模块的异常加载-安全-PHP中文网

dmesg是查看linux内核环形缓冲区日志的核心工具，用于诊断硬件、驱动、安全模块（如selinux、yama、ima）等底层问题；需结合关键词过滤（如security:、denied、capability）、启动参数（/proc/cmdline）和运行时状态（/sys/kernel/security/lsm）交叉验证模块是否加载或拦截。

新手怎么通过分析dmesg日志发现内核层身份验证模块的异常加载

直接看 dmesg 日志里有没有和“auth”“pam”“euid”“capability”“cred”“security”“smmu”“iommu”相关的报错或警告，而不是泛泛搜“error”。内核身份验证模块（比如 Yama、LoadPin、Integrity、IMA、SELinux、Smack）出问题时，往往不报“failed to load”，而是静默跳过、拒绝关键操作，或在权限检查点打印拒绝日志。

聚焦安全子系统关键词

运行这条命令快速过滤关键线索：

重点关注以下几类输出：

以 [ *.*] security: 开头的行——这是 LSM（Linux Security Module）框架的统一前缀，所有主流身份验证模块都走这里
包含 “denied”、“refused”、“not allowed”、“capability”、“no permission” 的上下文，尤其出现在 execve、fork、mmap、ptrace 等系统调用路径中
出现 “Yama: rejecting” 或 “LoadPin: rejecting” 字样——说明策略已启用但拦截了操作
有 “integrity: cannot load” 或 “IMA: disabled” ——代表模块根本没起来，不是策略问题而是加载失败

区分“没加载”和“加载了但拦住了”

先确认模块是否真的进了内核：

如果没输出，再查 dmesg 是否有加载尝试痕迹：

dmesg | grep -i "yama\|loadpin\|ima" | tail -10

典型异常信号包括：

“Yama: not enabled” —— 内核编译时没开启 CONFIG_SECURITY_YAMA，或启动参数禁用了（如 security=none）
“ima: No TPM found” 或 “integrity: unable to initialize” —— 依赖硬件/固件失败，模块注册失败
“SELinux: Disabled at boot.” —— 启动参数中有 selinux=0 或 enforcing=0，模块虽在但未激活
“security: Invalid argument” 出现在 initcall 阶段 —— 模块初始化函数返回负值，常见于策略配置错误或内存分配失败

结合启动参数和运行时状态交叉验证

很多身份验证模块行为受启动参数控制。运行：

cat /proc/cmdline

检查是否有：

security=yama 或 security=selinux —— 显式指定了默认 LSM
lsm=yama,loadpin,selinux —— 多 LSM 并行启用（需内核支持）
selinux=0、yama.disabled=1、ima_tcb=0 —— 直接关闭某模块

再看当前生效的 LSM：

cat /sys/kernel/security/lsm

如果输出是 yama,loadpin,selinux，但 dmesg 里没有 IMA 日志，就说明 IMA 没被选中启用；如果输出只有 yama，那其他模块压根没进加载队列。

模拟触发并观察实时日志

不要只看开机日志。有些策略只在特定动作发生时才报错。可以手动触发一个典型场景：

执行 sudo setcap cap_net_bind_service+ep /bin/ping，然后运行 ping -c1 127.0.0.1，观察 dmesg 是否出现 capability 相关拒绝
用 unshare -r /bin/sh 创建新 user namespace，再尝试 mount，看是否被 Yama 的 ptrace_scope 或 deny_new_privs 拦截
运行 cat /sys/kernel/security/ima/ascii_runtime_measurements，若报 “Permission denied”，且 dmesg 有 “IMA: policy required but no policy loaded”，说明 IMA 策略缺失而非模块未加载