SELinux和AppArmor均为Linux内核级MAC机制，需按场景选型：RHEL系优先SELinux（细粒度上下文策略），Ubuntu系适用AppArmor（路径式直观规则）；启用前须验证内核支持、策略生效及备份配置，策略应基于日志分析生成并遵循最小权限原则，运维中须持续更新、扫描未防护进程并纳入CI/CD流程。
SELinux 和 AppArmor 都是 Linux 内核级强制访问控制（MAC）机制，能显著限制进程行为，即使服务被攻破，攻击者也难以越权读写文件、访问端口或执行敏感操作。关键不在于“开或关”，而在于选择合适策略、正确启用并持续维护。
明确适用场景：SELinux 适合高安全要求的服务器，AppArmor 更易上手
SELinux 默认集成于 RHEL、CentOS、Fedora 和 Rocky Linux，策略粒度细、规则基于上下文（如 system_u:object_r:httpd_exec_t:s0），适合需要精细隔离的生产环境；AppArmor 主流用于 Ubuntu、Debian 和 SUSE，用路径+权限声明（如 /usr/bin/nginx PUx），规则直观，适合快速部署和容器宿主机加固。
- RHEL/CentOS 系统优先用 SELinux，避免卸载或禁用，改用 permissive 模式调试
- Ubuntu/Debian 环境可直接启用 AppArmor，检查状态：aa-status，确认内核模块已加载
- 云环境或容器平台（如 Kubernetes 节点）建议搭配使用：AppArmor 做节点级约束，容器内通过 seccomp+bpf 补充
启用前必须完成的三步验证
跳过验证极易导致服务启动失败或功能异常，尤其对数据库、Web 服务、自定义守护进程。
- 确认内核支持：运行 getenforce（SELinux）或 aa-status（AppArmor），非 “Disabled” 即已编译进内核
- 检查当前策略是否生效：SELinux 下用 sestatus -b 查看布尔值（如 httpd_can_network_connect），AppArmor 下用 sudo aa-unconfined 找出未受保护进程
- 备份原始配置：复制 /etc/selinux/targeted/active/modules/ 或 /etc/apparmor.d/ 到安全位置，便于回滚
策略编写与调试：从日志驱动到最小权限落地
不要手工硬编码规则。所有策略都应源于真实访问行为，再逐步收紧。
- SELinux：开启 auditd 后，用 ausearch -m avc -ts recent | audit2why 分析拒绝事件，再用 audit2allow -a -M mypolicy 生成模块，semodule -i mypolicy.pp 加载
- AppArmor：运行 sudo aa-genprof /path/to/binary 启动交互式配置向导，按实际操作触发访问，自动记录路径和权限，最后选 “Finish” 生成配置
- 始终遵循最小权限原则——比如 Web 应用只需读取 /var/www、写入 /var/log/myapp，禁止访问 /etc/shadow 或执行 /bin/bash
运维中必须坚持的四项实践
策略不是一次配置终身有效。内核更新、软件升级、配置变更都会打破原有策略边界。
- 将策略变更纳入 CI/CD 流程：例如 Ansible Playbook 中包含 semodule 或 apparmor_parser 调用，并做 dry-run 校验
- 每周扫描未受保护进程：sudo aa-unconfined --paranoid（AppArmor）或 ps -eZ | grep "unconfined"（SELinux）
- 对关键服务（如 sshd、nginx、mysql）启用 enforcing 模式，其他低风险服务可暂留 permissive，但需定期审查日志
- 禁用不必要布尔值或 profile：如关闭 httpd_can_sendmail（除非真需发信），删除未使用的 AppArmor profile（sudo aa-disable /path/to/profile）
真正提升防御能力的不是工具本身，而是把访问控制变成日常运维的一部分：每次部署新服务，先想它该有什么权限；每次修改配置，先查它会不会触发策略拒绝；每次看到 audit 日志里的 avc denied，别急着关 SELinux，把它当作一次加固机会。
