最小权限设计要求用户、进程和服务仅拥有必要权限。禁用root登录，用sudo分级管控；配置文件遵循“三不原则”，严格设权；服务以非特权用户运行并限制能力；自动化脚本需静态校验权限。
在Linux生产环境中，权限误操作是导致服务中断、数据泄露甚至系统瘫痪的常见原因。最小权限设计不是“尽量少给权限”，而是通过系统性策略，让每个用户、进程和服务只拥有完成其职责所必需的最低限度权限——多一分风险，少一分冗余。
用户账户：禁用root登录，强制使用sudo分级管控
直接使用root账户操作等于放弃所有操作审计与权限隔离基础。生产环境必须禁用SSH root登录，并为运维人员分配独立账号，通过sudoers精细控制命令白名单。
- 执行sudo sed -i 's/^PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config并重启sshd
- 为不同角色创建专用用户组（如deploy、backup、dbadmin），再用visudo按组配置命令权限，例如：
%deploy ALL=(www-data) NOPASSWD: /usr/bin/systemctl restart nginx, /usr/bin/rsync - 禁用shell交互式登录的系统账户（如mysql、nginx）：将其shell设为/usr/sbin/nologin
文件与目录：遵循“三不原则”——不裸放、不宽放、不混放
敏感配置文件（如/etc/nginx/conf.d/*.conf、/var/www/app/.env）、私钥（~/.ssh/id_rsa）、数据库凭证等，绝不能放在Web根目录或全局可读位置；权限设置需严格匹配运行主体身份。
- 配置文件统一归集到/etc/myapp/，属主设为root:myapp，权限640（组可读，其他无权）
- 应用运行用户（如www-data）仅对其所需日志路径（/var/log/myapp/）和临时上传目录有写权限，其余路径一律chmod 755或更低
- 使用find /opt/myapp -type f -perm /o+w定期扫描世界可写文件，立即修复
服务进程：以非特权用户运行，禁用能力继承
90%以上的网络服务无需root权限启动后持续运行。应通过systemd的User=、Group=及NoNewPrivileges=yes限制进程提权能力，避免漏洞利用后横向升级。
- 编辑服务单元文件（如/etc/systemd/system/myapp.service），明确指定：
User=myapp
Group=myapp
NoNewPrivileges=yes
ProtectSystem=strict
ProtectHome=read-only - 若需绑定1024以下端口（如80/443），改用setcap 'cap_net_bind_service+ep' /usr/local/bin/myapp，而非用root运行
- 禁用服务自动加载内核模块（CapabilityBoundingSet=~CAP_SYS_MODULE）和ptrace调试（RestrictAddressFamilies=AF_UNIX AF_INET AF_INET6）
自动化脚本与CI/CD：权限即代码，每次执行前做静态校验
运维脚本、部署流水线中的chmod、chown、cp -r等操作极易引发越权。应在脚本头部声明预期权限模型，并集成简单校验逻辑，失败则中止执行。
- 在部署脚本开头加入检查段：
if [[ "$(stat -c '%U:%G %a' /etc/myapp/config.yaml)" != "root:myapp 640" ]]; then echo "Config perm broken"; exit 1; fi - CI/CD流水线中，对生成的包或镜像执行docker run --read-only --cap-drop=ALL ...测试运行时最小能力是否足够
- 禁止在脚本中使用chmod -R 777或chown -R root:root等无差别操作；改用精确路径+明确用户/权限组合
最小权限不是一劳永逸的配置项，而是需要嵌入日常运维节奏的习惯：新用户入职先配sudo规则、上线新服务必审systemd单元、发布前跑一次权限快照比对。防护的本质，是把“不小心”挡在“不可为”之外。
