真正有效的敏感文件访问控制需结合chmod/chown、ACL与SELinux：先用chown root:root和chmod 640限定基础权限，再通过ACL授权特定用户，最后用SELinux实现进程级强制拦截。
直接限制特定用户对敏感文件的读写权限
标准 chmod 和 chown 只能按“所有者/组/其他”三级控制，无法单独禁用某个用户。真要拦住某人访问 /etc/shadow 或自定义配置文件，必须叠加 ACL 或 SELinux。
常见错误是只改 chmod 600 /etc/shadow 就以为安全了——但只要该用户属于 root 组或被加进 shadow 组，依然能读。真正生效的组合是：
- 先用
sudo chown root:root /path/to/file固定属主和属组 - 再用
sudo chmod 640 /path/to/file关闭“其他用户”权限 - 确认目标用户不在该文件所属组内：
groups username - 若仍需授权个别非组成员，才启用 ACL：
sudo setfacl -m u:alice:r /path/to/file
启用并验证文件系统 ACL 支持
很多发行版默认挂载时没开 acl 选项，setfacl 看似成功，实际不生效。别跳过这步验证。
执行 mount | grep "$(df . | tail -1 | awk '{print $1}')" | grep acl，输出为空就说明没启用。此时：
- 编辑
/etc/fstab，在对应分区行末尾加,acl（如defaults,acl） - 运行
sudo mount -o remount /（替换/为实际挂载点） - 重试
setfacl后，用getfacl /path/to/file检查输出里是否出现user:username:r--这类条目 - 注意：ext4 默认支持，但 XFS 需额外确认
xfs_info输出含attr2和inode64
用 SELinux 实现进程级强制拦截
ACL 和传统权限管的是“用户能否访问文件”，SELinux 管的是“某个进程能否以某种方式访问该文件”——即使用户有 shell 权限，只要其域（domain）没被策略允许，cat /etc/shadow 也会被内核拒绝。
典型误操作是只打标签不加载策略：
- 先确认 SELinux 是
enforcing模式：sestatus -v | grep "Current mode" - 给文件打类型标签：
sudo semanage fcontext -a -t shadow_t "/path/to/sensitive_file" - 立即生效：
sudo restorecon -v /path/to/sensitive_file - 禁止某用户域读取：
sudo audit2allow -M deny_user_read -l -i /var/log/audit/audit.log（需先触发一次拒绝日志） - 加载规则：
sudo semodule -i deny_user_read.pp
没生成拒绝日志就跑 audit2allow，结果模块为空，等于白配。
sudoers 仅放行最小必要命令
别用 ALL=(ALL) ALL 授权，那是把钥匙交给别人让他自己配锁。真正安全的做法是锁定具体路径和参数。
例如允许运维查看但不能编辑 /etc/ssh/sshd_config：
- 用
sudo visudo编辑，添加一行：deployer ALL=(root) /bin/cat /etc/ssh/sshd_config - 禁止带通配符或 shell 字符：
deployer ALL=(root) !/bin/sh, !/usr/bin/less * - 测试是否生效：
sudo -u deployer cat /etc/ssh/sshd_config应成功；sudo -u deployer vim /etc/ssh/sshd_config应被拒绝 - 注意：路径必须绝对且精确，
/usr/bin/cat和/bin/cat是两个不同条目
ACL 和 sudoers 解决的是“谁能在什么条件下访问”，SELinux 解决的是“即使条件满足，内核是否允许”。三者不是替代关系，而是层层补位——漏掉任意一层，都可能被绕过。
