文件权限最小化原则

文件权限最小化原则，说白了就是一句话：只给必须的权限，绝不多给。很多运维事故、安全漏洞、数据泄露，追溯到最后，往往发现某个服务、某个脚本、某个用户，拿着根本用不上的写权限或执行权限在跑。这不是什么高深的理论，而是系统加固中最基础、最容易被忽视的一环。我们直接来看，在真实的生产环境中，到底怎么把这个原则落地，以及那些容易踩的坑。

很多人以为，只要不直接给 777 权限，就算最小化了。这种理解太粗糙。权限最小化不是简单的数字减法，而是一个持续的动作。它要求你回答三个问题：谁需要访问？需要读还是写？需要执行吗？这三个问题没搞清楚，权限设置一定是盲目的。比如一个 Web 应用，它只需要读取静态资源，你给了可写权限，攻击者一旦通过上传漏洞打进目录，就能直接写 Webshell。如果这个目录还给了执行权限，那连提权都省了。所以，最小化权限的本质，是把攻击面压缩到极致，即使某个组件被攻破，破坏范围也被锁死在最小单元内。

很多中小团队习惯用 root 账户跑所有服务，图省事。这是最致命的习惯。正确的做法是，为每一个独立服务创建独立的系统用户，并且把这个用户的 Shell 设置为 /sbin/nologin 或 /bin/false。这样即使服务被入侵，攻击者拿到的也只是一个无法登录的受限环境。

# 创建一个无法登录的系统用户来运行 nginx
useradd -r -s /sbin/nologin nginx

更进一步，用户的家目录权限也要收紧。默认情况下，useradd 创建的用户家目录权限通常是 755，意味着其他用户可以进入并读取文件。对于服务账户，应该直接把家目录权限设置为 750，甚至 700，只允许用户自己和所属组访问。如果服务不需要家目录，完全可以不创建，或者指向一个不存在的路径。

我们来看具体的权限分配。普通文件，默认权限绝不要出现 666 或 777。配置文件通常只需要 644 或 640，前者属主可读写，其他人只读；后者连其他人的读权限都拿掉，只允许属主和同组用户访问。如果配置文件里包含数据库密码、API 密钥，权限必须是 600，只有属主能读写。

目录的情况稍微复杂一点。目录的执行权限，代表能否进入该目录。目录的读权限，代表能否列出目录下的文件名。很多人给目录 755，觉得安全，但其实如果目录里文件不需要被列举，应该给 751 甚至 750。比如 Web 应用的上传目录，用户只需要通过程序读写文件，完全不需要直接列出目录里有什么文件。这种情况下，去掉“其他用户”的读权限，能有效防止攻击者遍历文件。

# 上传目录：属主和组可读写进入，其他人只能进入但无法列出文件
chmod 751 /var/www/app/uploads

# 配置文件：仅属主可读写
chmod 600 /var/www/app/config/database.yml

传统的 UGO（用户、组、其他）权限模型太粗放了。比如你需要让两个不同组的用户分别访问同一个目录下的不同文件，传统权限根本做不到。这时候必须上 ACL（访问控制列表）。ACL 允许你为任意用户或组设置独立权限，这是实现真正最小化权限的利器。

举个例子，Web 服务器运行在 www-data 用户下，开发人员 userA 需要能修改 Web 目录下的文件，但不希望给 userA 整个目录的所有权。可以这样设置：

# 设置目录默认 ACL，使 www-data 和 userA 都有读写执行权限
setfacl -R -m u:www-data:rwx /var/www/html
setfacl -R -m u:userA:rwx /var/www/html

# 设置默认 ACL，让新建文件也继承这些权限
setfacl -R -d -m u:www-data:rwx /var/www/html
setfacl -R -d -m u:userA:rwx /var/www/html

这样，www-data 和 userA 都能正常读写，而其他无关用户完全碰不到这些文件。注意，使用 ACL 后，ls -l 看到的权限位后面会多一个加号，表示存在扩展 ACL。排查权限问题时，别漏了这个细节。

有时候，普通用户确实需要执行一些需要 root 权限的命令，比如重启某个服务。直接给 root 密码或者把用户加入 wheel 组并赋予全部 sudo 权限，显然违背最小化原则。sudo 的规则配置可以精确到命令级别，甚至参数级别。

# 在 /etc/sudoers 中配置，仅允许 userA 以 root 身份重启 nginx
userA ALL=(root) /usr/bin/systemctl restart nginx

这样，userA 只能执行这一条命令，连修改 nginx 配置文件都做不到。如果担心用户利用 systemctl 的某些特性绕过限制，还可以进一步收紧，或者考虑使用 doas 这类更轻量的替代工具。关键是，永远不要为了方便，把完整的 root 权限授予不需要它的人。

文件权限只是静态的一面，进程运行起来后的权限同样关键。很多服务启动时需要 root 权限，仅仅是为了绑定 1024 以下的特权端口，一旦绑定完成，后续逻辑完全可以用普通用户运行。像 Nginx、Apache 这些成熟的服务器，都提供了 user 指令来降权运行 worker 进程。

# nginx.conf
user nginx;
worker_processes auto;

# 确保 nginx 用户对日志目录有写权限
# /var/log/nginx 属主为 nginx，权限 750

对于自己开发的后端服务，也应该实现类似的机制。程序启动后，立即通过 setuid 和 setgid 系统调用，把进程身份切换到低权限用户。如果服务运行在容器里，更不要用 root 用户启动容器。Dockerfile 里必须显式指定 USER 指令，切换到非 root 用户。Kubernetes 的 Pod Security Policy 或 SecurityContext 里，也要配置 runAsNonRoot 和 runAsUser，从平台层面强制阻断 root 容器。

一个常见的偏差是，开发环境权限宽松，生产环境才收紧。结果往往是，代码里写死了对某些目录的写操作，或者依赖了某个只有开发机才有的高权限文件，上线后直接报权限错误。然后运维为了快速恢复，临时 chmod 777 解决问题，这个临时方案就变成了永久方案。最小化权限必须在开发阶段就介入。本地开发环境就应该模拟生产环境的权限模型，使用同样的非 root 用户运行服务，目录权限也保持一致。CI/CD 流水线里，可以加入权限检查脚本，扫描代码仓库里是否有权限过大的文件。

# CI 中检查是否有文件权限为 777 或属主为 root
find . -type f -perm 0777 -exec echo "发现 777 权限文件: {}" \;
find . -type f -user root -exec echo "发现 root 属主文件: {}" \;

这样能把权限问题消灭在发布之前，而不是等到线上出事了再补救。

日志文件很容易被忽略。应用程序需要写日志，日志文件通常放在 /var/log 下。如果应用以普通用户运行，它必须对日志目录有写权限。很多人图方便，直接把 /var/log/app 目录权限改成 777，这又开了个口子。正确做法是，日志目录属主改为应用用户，权限 750，或者利用 syslog、systemd-journald 等系统日志服务，应用只把日志输出到标准输出和标准错误，由系统日志服务统一收集写入文件。这样应用进程完全不需要触碰日志文件的写权限，隔离性更好。

监控 agent 也是同理。监控工具往往需要读取系统状态文件，比如 /proc、/sys 下的某些接口。不要直接给监控 agent root 权限。可以把它加入特定的系统组，比如 systemd-journal 组来读取日志，或者通过 sudo 精确授权读取特定文件。每次授权前，都问自己一句：这个权限能不能再缩小一点？

权限不是设置一次就完事了。业务变更、人员流动、新功能上线，都可能引入不合理的权限。需要建立定期审计机制。系统层面，可以用工具扫描系统中所有设置了 SUID、SGID 位的文件，这些文件是提权重灾区。

# 查找系统中所有 SUID 文件
find / -perm -4000 -type f -exec ls -l {} \;

对于目录，重点检查 /tmp、/var/tmp 这些粘滞位目录，确保里面的文件权限没有被意外放大。应用层面，可以编写脚本，遍历项目目录，检查关键配置文件的权限是否符合预期。审计结果要形成报告，并且关联到工单系统，发现一处修复一处，形成闭环。

文件权限最小化原则，说到底是安全意识的具象化。它不需要你安装任何额外软件，不需要花一分钱，只需要在每次敲下 chmod、chown、useradd 命令时，多想一步。这一步的思考，往往就是系统被攻破和安然无恙之间的那一道分水岭。