LSM是内核级强制访问控制框架，不替代PAM或SSH密钥，而是在系统调用执行前插入安全检查，确保高权限进程无法绕过策略访问认证相关资源，如sshd进程、/etc/shadow、auth.log等，其钩子位于DAC检查之后、内核操作之前，支持SELinux、AppArmor、eBPF-LSM等多模块共存与动态加固。
核心服务器的认证加固不能只靠PAM或SSH密钥，必须下沉到内核层——LSM正是实现这一目标的关键机制。它不替代传统认证，而是在系统调用执行前插入强制检查，确保即使高权限进程也无法绕过策略访问敏感资源。
明确LSM在认证加固中的定位
LSM本身不是认证模块，而是为认证逻辑提供内核级执行环境。例如：SELinux可定义“仅允许systemd-journald以特定标签读取/var/log/auth.log”，AppArmor可限制sshd进程只能访问指定配置路径和密钥文件。这种控制发生在open()、execve()等系统调用内部，比用户态守护进程拦截更早、更可靠。
- LSM钩子位于DAC（UID/GID）检查之后、内核对象操作之前，既尊重传统权限，又叠加强制策略
- 多个LSM可共存（如SELinux + Yama），但策略决策按初始化顺序串联，需注意优先级冲突
- 内核5.7+支持eBPF LSM，允许热加载策略代码，无需重启或编译模块，适合生产环境动态加固
选择并启用适合核心服务器的LSM
生产环境首选已深度集成的主流LSM，避免自行打补丁。RHEL/CentOS系默认启用SELinux，Ubuntu/Debian系默认启用AppArmor，二者均经过长期验证。
- 确认当前启用状态：
cat /sys/kernel/security/lsm显示已激活模块列表 - 启用SELinux（RHEL系）：
sed -i 's/SELINUX=disabled/SELINUX=enforcing/' /etc/selinux/config，重启后运行sestatus验证 - 启用AppArmor（Ubuntu系）：
sudo systemctl enable apparmor && sudo systemctl start apparmor，用aa-status查看策略加载情况 - 禁用冲突模块：若同时启用多个LSM，需在内核启动参数中显式指定，例如
lsm=selinux,lockdown,yama
围绕认证流程定制LSM策略
认证加固重点保护三类对象：认证服务进程（sshd、login）、凭证存储（/etc/shadow、SSH私钥）、日志输出（auth.log、journal）。LSM策略需覆盖其全生命周期。
- 对sshd进程：用SELinux type enforcement限制其仅能读取/etc/ssh/sshd_config、/etc/passwd，禁止访问其他用户家目录
- 对私钥文件：用AppArmor路径规则限定
/usr/sbin/sshd PUx,且/etc/ssh/ssh_host_*_key r,，拒绝写和执行权限 - 对日志写入：通过Yama模块启用
kernel.yama.ptrace_scope=2，防止非特权进程dump认证进程内存 - 利用eBPF LSM实时拦截异常行为：编写BPF程序监控
security_bprm_check钩子，对未签名的PAM模块加载直接拒绝
验证与持续运维要点
LSM策略生效后必须验证是否真正阻断绕过路径，而非仅依赖日志告警。
- 模拟绕过测试：用
unshare -r /bin/sh创建新user namespace，尝试读取/etc/shadow，确认返回-EPERM - 审计关键事件：启用
auditctl -a always,exit -F arch=b64 -S openat -F path=/etc/shadow，结合LSM拒绝日志交叉分析 - 策略更新不中断服务：SELinux用
semodule -i policy.pp热加载，AppArmor用sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.sshd - 备份原始策略：
semanage export > baseline.sepol，便于故障回滚
