linux权限审计核心是闭环管理：识别现状→分析风险→调整配置→验证生效→持续监控，需关注主体真实身份、权限变更实效性及策略固化。

Linux权限审计不是单纯看ls -l输出，而是理解“谁在什么场景下能对什么做哪些操作”，并验证它是否符合最小权限原则和实际业务需求。核心在于闭环：识别权限现状 → 分析风险点 → 调整配置 → 验证生效 → 持续监控。

看清三类主体的真实身份：User、Group、Others不是静态标签

User不单指文件属主，还包括执行进程的用户（如www-data运行Nginx时访问日志）、sudo提权后的临时身份、甚至通过SSH密钥登录的非交互用户。Group也不只是附加组，要特别注意primary group对新建文件默认权限的影响（受umask和setgid目录共同作用）。Others则常被低估——比如一个world-writable的/tmp子目录，可能让任意本地用户劫持脚本执行流。

建议：

• 用id -a查当前会话完整身份，含UID、GID、所有附属组
• 对关键服务，用ps -eo pid,user,group,args --forest | grep 服务名确认其真实运行身份
• 检查/etc/passwd中UID

盯紧四类高危权限模式与隐性继承

SUID/SGID位、sticky bit、world-writable目录、以及ACL中的mask误配，是绕过基础rwx的常见入口。例如/usr/bin/passwd的SUID允许普通用户临时以root身份修改shadow，但若某自研运维工具也被误设SUID且存在命令注入漏洞，就直接升级为root shell。

建议：

• 批量扫描：用find / -perm -4000 -o -perm -2000 2>/dev/null找SUID/SGID文件，人工核查必要性
• 检查/tmp、/var/tmp及其子目录是否过度开放：find /tmp -type d -perm -002 2>/dev/null
• 对启用了ACL的目录，用getfacl确认mask是否无意放大了group或others权限

验证权限变更是否真正生效，而非仅改表面数字

修改chown或chmod后，需模拟真实访问路径验证。例如将数据库备份目录属主改为backup用户，还需确认backup用户的crontab脚本能否读取私钥、能否写入目标路径、SELinux上下文是否允许（ls -Z查看，ausearch -m avc -ts recent查拒绝日志）。

建议：

• 用目标用户身份测试：sudo -u backup bash -c "cp /src/file /dest/ 2>&1"
• 检查systemd服务单元的SupplementaryGroups=和UMask=设置，它们会影响服务内进程的实际权限
• 对网络服务，用ss -tulpn确认监听地址绑定（0.0.0.0 vs 127.0.0.1）比文件权限更早暴露攻击面

把审计变成可持续动作：从一次性检查到策略固化

手工跑一遍find命令只是起点。真正的闭环在于把判断逻辑编码化：用Ansible playbook定义“web根目录禁止world-writable”策略，配合定期CIS基准扫描（如Lynis），并将关键指标（如SUID文件数量、异常登录组成员）接入监控告警。

建议：

• 用auditctl -w /etc/shadow -p wa -k shadow_access追踪敏感文件访问，日志进/var/log/audit/audit.log
• 在/etc/sudoers.d/下按功能拆分权限，禁用NOPASSWD滥用，每季度review注释说明的变更原因
• 对容器环境，额外检查镜像Dockerfile中的USER指令、挂载卷的uid/gid映射、以及seccomp/profile限制是否覆盖宿主机权限逃逸路径

权限审计不是追求零警告，而是确保每个非常规权限都有明确责任人、可追溯的审批记录、和对应的补偿控制措施。每次变更后多走一步验证，就能避免90%的误配置引发的生产事故。