Linux服务访问控制策略_最小权限设计解析【教程】

linux服务访问控制核心是默认拒绝、按需放行；需结合CapabilityBoundingSet/NoNewPrivileges、连接级白名单、SELinux类型强制、精确socket绑定实现最小权限。

Linux 服务访问控制策略的核心不是“怎么加权限”，而是“默认拒绝、按需放行”。最小权限设计不是安全锦上添花的选项，而是服务一旦暴露在非可信网络中就必须落地的基本前提。

systemd 服务的 CapabilityBoundingSet 和 NoNewPrivileges

很多服务（如 nginx、redis）默认以 root 启动后降权，但降权不等于权限收敛。若未显式限制 capabilities，进程仍可能通过 cap_sys_admin 等能力绕过文件权限或挂载命名空间。

• CapabilityBoundingSet=CAP_NET_BIND_SERVICE —— 仅允许绑定 1024 以下端口，禁止其他系统级操作
• NoNewPrivileges=true —— 阻止 fork+exec 提权（例如调用 setuid 二进制或加载特权模块）
• 避免使用 Capabilities=...（它赋予权限），优先用 CapabilityBoundingSet（它削减权限）
• 配合 User=www-data 和 RestrictSUIDSGID=true，可封堵 setuid 二进制滥用路径

iptables/nftables 的连接级白名单而非 IP 黑名单

用 iptables -A input -s 192.168.1.0/24 -p tcp --dport 22 -j ACCEPT 是典型误区：它没限制源端口、连接状态、甚至没拒绝其他端口。真正最小权限应基于连接上下文过滤。

• 只允许 ESTABLISHED/RELATED 连入：-m state --state ESTABLISHED,RELATED -j ACCEPT
• 对管理端口（如 ssh）额外限制源 IP 段 + 源端口范围（例如仅接受来自跳板机的 --sport 32768:65535）
• 禁用 ICMP 重定向和源路由：-p icmp --icmp-type redirect -j DROP、-m pkttype --pkt-type multicast -j DROP
• nftables 更推荐：nft add rule inet Filter input tcp dport 80 ct state established,related accept

SELinux 类型强制下的服务域隔离

即使用户、capability、网络都收紧，一个被攻陷的 httpd_t 域仍可能通过共享内存或 unix socket 访问同主机上的 mysqld_t。SELinux 的 type enforcement 才是跨服务隔离的最后一道防线。

• 确认服务运行在专用域：ps -eZ | grep httpd 应显示 system_u:system_r:httpd_t:s0，而非 unconfined_t
• 禁止跨域通信：semanage permissive -a httpd_t 仅用于调试，上线必须移除
• 细粒度布尔值控制：setsebool -P httpd_can_network_connect_db off，而非全局开 httpd_can_network_connect on
• 自定义策略时用 audit2allow -a -M myapp 生成最小规则，避免直接 audit2allow -a -M myapp -i（它会包含冗余权限）

socket 激活与监听地址绑定的隐式权限泄漏

用 systemd-socket-activate 启动服务看似优雅，但若 socket unit 中 Listenstream=0.0.0.0:80，服务进程实际继承的是全网卡监听能力——哪怕 service unit 里写了 BindTo=lo 也无效。

• 监听地址必须在 socket unit 中指定具体 IP：ListenStream=127.0.0.1:8080 或 [::1]:8080
• 禁用 FreeBind=true（它允许绑定未配置的 IP），除非明确需要 VIP 切换
• 对本地 IPC，优先用 ListenStream=/run/myapp.sock + SocketMode=0600 + SocketUser=appuser
• 检查实际监听：ss -tlnp | grep :80，确认 Local Address:Port 列不是 *:80

最小权限不是配置项堆砌，而是每次添加一条规则、开启一个 capability、暴露一个端口时，都得反问：这个权限此刻是否被当前任务严格必需？是否能被更窄的上下文（比如特定 socket、特定 SELinux 类型、特定 netfilter 连接状态）替代？漏掉任意一环，攻击面就可能从单个服务横向撕开整台主机。