如何限制 Root 用户对关键系统二进制文件的调用实战

限制 root 权限本质是让其主动放弃不必要的权限，重点管控长期运行、处理外部输入或可能被滥用的二进制文件；通过 capabilities、seccomp-bpf 和启动降权三步实现动态权限收敛，并辅以 SUID 禁用、审计监控等配套措施。

限制 root 用户对关键系统二进制文件的调用，本质不是“禁止 root 执行”，而是让 root 进程在运行时**主动放弃不必要的权限**，从而缩小攻击面——因为 root 本身无法被“禁止”，但它的行为可以被约束。

明确目标：哪些二进制文件需要重点管控

并非所有 root 程序都要限制，重点是那些：

• 长期运行、暴露网络端口的服务（如 sshd、nginx、redis-server）
• 处理外部输入的工具（如 cron、rsyslog、dbus-daemon）
• 可能被滥用为提权跳板的程序（如 find、cp、mount —— 尤其当它们被误配 SUID 时）

判断依据：用 ps aux | grep '^[r]oot' | awk '{print $11}' | sort -u 查看当前以 root 身份运行的命令，再结合 ls -l /usr/bin/ /bin/ | grep '^...s' 扫描 SUID 程序，优先锁定这两类。

实战一：用 capabilities 替代完整 root 权限

不让程序全程以 UID 0 运行，而是只赋予它真正需要的内核能力。例如：

• 让 nginx 绑定 80 端口，但不给它读取 /etc/shadow 的能力：
  sudo setcap 'cap_net_bind_service=+ep' /usr/sbin/nginx
• 让 ping 发送原始 ICMP 包，但禁止修改路由表：
  sudo setcap 'cap_net_raw=+ep' /bin/ping
• 验证是否生效：getcap /usr/sbin/nginx；运行后用 capsh --print | grep cap_net_bind_service 确认进程确实持有该能力

实战二：用 seccomp-bpf 拦截危险系统调用

即使程序有某项 capability，也能进一步禁止它执行具体高危操作。例如阻止任何 root 进程调用 mount 或 setuid：

• 编写简易 seccomp 规则（JSON 格式），指定拒绝 mount、umount、setuid、ptrace 等调用
• 用 scmp_bpf_compiler 编译为 bpf 字节码
• 启动服务时加载：
  sudo /usr/bin/seccomp-bpf-helper --bpf-rule-file rules.bpf nginx -g daemon off
• 或集成进 systemd service：在 [Service] 下添加 SystemCallFilter=~@mount @setuid @ptrace

实战三：启动即降权，避免全程高权限

多数服务只需 root 启动（绑定低端口、读取私钥），之后应立即切换为低权限用户运行：

• nginx 配置中设置：user www-data;（启动后自动 drop 到该用户）
• systemd 服务中指定：User=www-data + Group=www-data，配合 CapabilityBoundingSet=CAP_NET_BIND_SERVICE 和 NoNewPrivileges=true
• 自研程序应在初始化完成后调用 setuid(getuid()) 和 setgid(getgid()) 彻底清除有效 UID/GID

关键点：降权必须在首次敏感操作（如 listen()、open()）之后、业务逻辑开始前完成，否则内核仍视其为 root 上下文。

配套防护：防止绕过与持续监控

单靠代码层控制不够，需叠加运行时与审计措施：

• 禁用 SUID/SGID 滥用：mount -o remount, nosuid,noexec /usr（对 /usr 分区）
• 定期扫描异常权限：find /usr/bin /bin -xdev -type f ( -perm -4000 -o -perm -2000 ) 2>/dev/null
• 开启 auditd 记录 root 进程的 execve：-a always,exit -F uid=0 -S execve
• 容器场景下强制 no-new-privileges: true，防止子进程重新提权

不复杂但容易忽略：权限控制不是设一次就完事，而是从启动、运行到退出全过程的动态收敛。