selinux和apparmor是叠加在传统linux dac之上的mac层，必须同时满足rwx权限和策略标签才能访问；它们通过进程类型标签或路径绑定实现细粒度管控，防止越权与root滥用。
SELinux 和 AppArmor 不是替代传统 Linux 文件权限的，而是叠加在它之上的额外控制层。文件权限（DAC）决定“谁可以操作”，而 SELinux/AppArmor（MAC）决定“哪个进程在什么条件下可以操作什么资源”——两者必须同时满足，访问才被允许。
传统权限只看身份，MAC 看的是进程行为
Linux 原生的 rwx 权限基于用户 UID/GID 和文件属主/属组，root 几乎能绕过所有限制。但 SELinux 会为每个进程打上类型标签（如 httpd_t），为每个文件也打上类型（如 httpd_sys_content_t），再通过策略规则明确写死“httpd_t 只能读 httpd_sys_content_t 类型的文件”。哪怕 root 启动了 Apache，它也不能去读 /etc/shadow，因为 shadow_t 类型不在此规则范围内。
AppArmor 的逻辑类似，但它不依赖类型标签，而是直接绑定可执行文件路径，用配置文件声明“/usr/sbin/nginx 能访问哪些路径、能监听哪些端口、能调用哪些系统调用”。即使你把 nginx 改成 root 运行，它依然只能按 profile 允许的范围动作。
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
双重检查机制：一个被拒，整个访问就失败
访问发生时，内核先走 DAC 检查：当前进程 UID 是否匹配文件 owner/group/other 权限？如果失败，直接拒绝；如果通过，再交给 SELinux 或 AppArmor 做第二道判断。
- 文件权限是 644，/etc/shadow 被误设为全局可读 → DAC 放行，但 SELinux 的 shadow_t 类型只允许 passwd_t 访问 → MAC 拒绝
- Apache 进程被黑客利用拿到 root 权限 → DAC 允许它读写一切，但 SELinux 仍把它锁在 httpd_t 域里，无法碰 ssh_key_t 或 var_log_t
- 你用 cp -r 把网页文件复制进 /var/www/html → 文件继承源目录上下文（比如 user_home_t），导致 httpd_t 无法读 → DAC 没问题，MAC 卡住
运维中怎么快速识别是不是 MAC 在拦路
服务启动失败、文件读写报 Permission denied，别急着 chmod 777 或关闭 SELinux。先看日志：
- SELinux 环境下运行：ausearch -m avc -ts recent 或 journalctl -t setroubleshoot，找 AVC 拒绝记录
- AppArmor 环境下运行：sudo aa-status 看 profile 加载状态，再查 dmesg | grep apparmor 或 journalctl | grep DENIED
- 临时验证：SELinux 用 setenforce 0 切宽容模式；AppArmor 用 sudo aa-complain /path/to/binary 收集行为日志
修复思路不是“放权”，而是“对齐上下文或策略”
多数问题不是策略太严，而是上下文错配或端口/功能没授权：
- Web 目录文件类型不对 → 用 restorecon -Rv /var/www/html 重置 SELinux 上下文
- 自定义端口（如 httpd 改用 8080）→ 用 semanage port -a -t http_port_t -p tcp 8080
- PHP 需要写日志 → 开布尔值：setsebool -P httpd_can_network_connect_db on
- AppArmor 下程序缺某路径权限 → 编辑对应 profile（如 /etc/apparmor.d/usr.sbin.nginx），加一行 /var/log/myapp/** rw,，再执行 sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx
