校验 pam_unix.so 安全性需三重验证：确认实际加载路径与权限（如 /lib64/security/pam_unix.so、644 权限）、比对可信基线哈希值、验证其在 pam 栈中被真实调用且未被绕过。
直接校验 pam_unix.so 的哈希值无法证明其运行时安全性——它可能被动态劫持、被 LD_PRELOAD 覆盖，或在 PAM 栈中被后续模块绕过。真正有效的校验必须结合文件完整性 + 加载路径确认 + 运行时调用链验证。
确认 pam_unix.so 实际加载路径和权限
不同发行版存放位置不同，硬编码路径校验会失败：
- Debian/Ubuntu 通常在
/lib/security/pam_unix.so - RHEL/CentOS 8+ 多数用
/lib64/security/pam_unix.so（注意是lib64，不是lib） - 运行
ls -l $(ldconfig -p | grep pam_unix | awk '{print $NF}')可定位真实路径 - 必须检查权限：应为
-rw-r--r--（644），且属主 root:root；若为 755 或属组可写，说明已被篡改风险极高
用 sha256sum 校验文件本体，但需配合可信基线
仅比对哈希不够，攻击者可同步替换二进制与校验值。必须在可信环境生成并离线保存基线：
- 在全新安装、未联网、未运行可疑服务的同版本系统上执行：
sha256sum /lib/security/pam_unix.so > /tmp/pam_unix.sha256.baseline - 生产机上执行相同命令，输出重定向到临时文件，再用
diff对比：sha256sum /lib/security/pam_unix.so > /tmp/pam_unix.sha256.live && diff /tmp/pam_unix.sha256.baseline /tmp/pam_unix.sha256.live - 若系统无
sha256sum（极老系统），可用openssl dgst -sha256替代，但注意输出格式差异
验证 pam_unix.so 是否真正在 PAM 流程中被调用
文件没被改 ≠ 它起效了。常见静默失效场景：
- 检查对应服务（如
sshd）的 PAM 配置是否跳过了它：grep -E '^\s*auth.*pam_unix\.so' /etc/pam.d/sshd—— 若无输出，说明 SSH 根本没走pam_unix.so认证 - 确认没有被
[default=ignore]或[success=done]提前终止栈：例如某行auth [success=done] pam_permit.so在pam_unix.so之前，会导致后者永不执行 - 用
strace -e trace=openat,openat64 -f sshd -D -p 2222 2>&1 | grep pam_unix（需另开终端连接）可观察实际 open 调用，但仅限调试，不可用于生产监控
更可靠的长期监控：用 AIDE 或 aideinit 做增量校验
手动哈希易漏、难自动化。生产环境应部署文件完整性监控：
- 安装
aide（Debian:apt install aide；RHEL:yum install aide） - 初始化数据库前，先确保
/lib/security/和/lib64/security/在/etc/aide.conf的监控范围内，例如添加：/lib/security/.* p+i+n+u+g+s+b+md5+sha256 - 运行
aide --init生成基线，再mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz - 定期
aide --check，它会报告pam_unix.so的 inode、大小、权限、哈希等任一变化
最关键的遗漏点：pam_unix.so 自身不校验密码强度，它只做“比对 /etc/shadow 中的 hash”。哪怕你配了 pam_pwquality.so，只要 pam_unix.so 被绕过或降级为 sufficient，强策略就形同虚设。所以校验重点永远不是“它有没有”，而是“它有没有被真正执行”。
