关键进程权限加固本质是实施最小能力原则：明确“谁调用、以何身份、访哪些资源、是否过度授权”四层关系，通过专用用户、capability限制、protectsystem/protecthome、seccomp-bpf、privatetmp等机制实现运行时上下文收敛与隔离。
关键进程的权限访问上下文加固，本质是让每个进程只拥有完成其职责所必需的最小能力——既不是“全权root”，也不是“随便读写任意路径”。重点不在改一个chmod命令，而在于理清“谁在调用、以什么身份、访问哪些资源、是否被过度授权”这四层关系。
识别高风险进程及其真实执行上下文
不能只看ps aux里显示的USER列，要结合实际启动方式和运行时行为判断：
- 查进程启动源：用
systemctl show nginx.service | grep ExecStart确认nginx主进程是否真的以www-data身份启动，而非root派生后降权失败 - 看文件访问行为：用
sudo strace -p $(pgrep -f "python app.py") -e trace=openat,open,connect 2>&1 | grep -E "(etc|home|tmp)"观察实际打开的敏感路径 - 检查capability：运行
getpcaps $(pgrep -f "redis-server")，确认是否意外继承了CAP_NET_BIND_SERVICE或CAP_SYS_ADMIN - 验证SELinux/AppArmor上下文：对CentOS/RHEL系，执行
ps -Z | grep redis；对Ubuntu/Debian，用aa-status --enabled确认策略是否生效且未被绕过
按角色收敛执行身份与文件系统权限
避免“一个账号走天下”，为不同职责分配隔离身份：
- Web服务进程（如Nginx/Apache）：属主设为
www-data:www-data，配置文件目录/etc/nginx权限设为750，属组www-data仅保留读权限，不给写 - 数据库进程（如PostgreSQL）：使用专用系统用户
postgres，数据目录/var/lib/postgresql设为700，日志目录/var/log/postgresql设为640，组为adm - 后台任务进程（如cron job脚本）：不直接用root跑，改用
systemd --scope或runuser -u appuser --启动，确保环境变量、HOME、umask均受控 - 容器内进程：在Dockerfile中明确
USER 1001:1001，配合chown -R 1001:1001 /app，禁止挂载宿主机敏感路径（如/etc/passwd）到容器内
限制系统调用与资源边界，堵住提权路径
权限不仅体现在文件归属上，更体现在能做什么系统操作：
- 用
systemd服务单元限制能力：在.service文件中添加NoNewPrivileges=yes、RestrictSUIDSGID=true、ProtectSystem=strict、ProtectHome=read-only - 设置cgroup资源约束：通过
MemoryMax=512M、TasksMax=50防内存耗尽或fork炸弹，避免进程失控后影响其他服务 - 禁用危险系统调用：对高敏服务（如SSH daemon），在
seccomp.json中显式屏蔽ptrace、mount、clone等调用，再通过SystemCallFilter=@default白名单收紧 - 关闭不必要的文件描述符继承：在启动命令前加
exec 3>&- 4>&-，防止子进程意外继承父进程打开的敏感句柄（如日志文件、密钥文件fd）
验证与持续监控基线一致性
加固不是一次性动作，而是建立“定义—执行—校验—告警”的闭环：
- 用Ansible或Bash脚本固化基线：例如检查
nginx进程是否始终以www-data运行，且/etc/nginx/nginx.conf权限为640，否则自动修复并记录事件 - 用
inotifywait -m -e attrib /proc/*/exe监控进程可执行文件被替换（常见于恶意注入），触发告警 - 定期审计capability变更：用
find /usr/bin -type f -perm /u+s,g+s 2>/dev/null | xargs getcap比对上次基线快照，发现新增setuid二进制立即排查 - 将进程上下文检查嵌入CI/CD：部署前校验镜像中
ENTRYPOINT是否含su或sudo，拒绝构建含CAP_SYS_ADMIN的容器镜像
