Nginx 安全加固怎么通过 SELinux 或 AppArmor 强化进程隔离-Nginx-PHP中文网

selinux和apparmor不是给nginx“加一层隔离”，而是从启动起将其限定在强制权限边界内，即使被攻破也无法读取密码文件、加载恶意模块或修改其他服务配置。

nginx 安全加固怎么通过 selinux 或 apparmor 强化进程隔离

SELinux 和 AppArmor 不是给 Nginx “加一层隔离”，而是让 Nginx 进程从启动那一刻起，就在操作系统强制划定的权限边界里运行——哪怕它被攻破，也无法跳出这个沙盒去读取密码文件、加载恶意模块或修改其他服务配置。

SELinux 对 Nginx 的保护基于类型强制（TE）策略：主进程（nginx_t）和 worker 进程（httpd_t 或 nginx_worker_t）拥有独立安全上下文，各自能访问的文件、端口、系统调用都由策略硬性规定。

确认 SELinux 处于强制模式：getenforce 返回 Enforcing；若为 Permissive，需修改 /etc/selinux/config 中 SELINUX=enforcing 并重启
检查 Nginx 进程是否已受控：ps -eZ | grep nginx 应显示类似 system_u:system_r:httpd_t:s0 的上下文
关键目录需匹配正确类型：
- /etc/nginx 应为 system_conf_t 或 httpd_config_t（用 ls -Z /etc/nginx 查看，不匹配则执行 restorecon -Rv /etc/nginx）
- /var/log/nginx 默认应为 httpd_log_t，确保 worker 可写但不可执行其中文件
- Web 根目录如 /var/www/html 建议设为 httpd_sys_content_t（只读），上传目录另设 httpd_sys_rw_content_t 并严格限制
启用布尔值微调策略：例如允许 Nginx 连接后端数据库，执行 setsebool -P httpd_can_network_connect_db 1，避免粗暴放行所有网络行为

AppArmor 更适合快速落地，尤其在容器化或轻量部署中。它不依赖标签，直接通过路径规则限制 Nginx 能打开哪些文件、执行哪些命令、绑定哪些端口。

在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...

下载

为 Nginx 创建 profile：aa-genprof /usr/sbin/nginx，按提示操作完成学习模式采集，生成 /etc/apparmor.d/usr.sbin.nginx
编辑 profile，显式声明：
- 只允许读取：/etc/nginx/** r,、/usr/share/nginx/** r,
- 只允许写入日志：/var/log/nginx/*.log w,
- 禁止执行临时目录脚本：/tmp/** Pix,（拒绝并记录）、/dev/shm/** m,（禁用共享内存滥用）
- 限制网络绑定：network inet stream,（仅 TCP 流），禁用 raw 或 packet
加载并验证：apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx，再运行 aa-status | grep nginx 确认处于 enforce 模式
避免长期使用 complain 模式：它只记录不拦截，容易误判为“策略已生效”，实则毫无防护力

SELinux/AppArmor 的策略必须与 Nginx 的多进程模型对齐，才能把“单点失守”真正关进笼子。

确保 user nginx nginx; 配置生效，且该用户无登录 shell（/sbin/nologin），这样每个 worker 进程都以受限身份运行，策略才有实际作用对象
禁用高风险模块：ngx_http_perl_module、ngx_http_xslt_module 等可能绕过策略执行任意代码，编译时剔除或配置中注释掉
worker 进程不得持有 root 权限：即使主进程以 root 启动，也应在 post_accept 后立即降权；检查 ps auxZ | grep nginx，worker 行不应出现 root 用户名
共享内存区（如 limit_req_zone）虽提升性能，但也成为攻击面，其 backing 文件（通常在 /dev/shm/）需在 AppArmor 中明确限制，或在 SELinux 中设为 httpd_tmpfs_t 类型