Linux Capabilities与AppArmor/SELinux是互补的纵深防御机制：Capabilities控制能否执行某类系统调用，AppArmor按路径、SELinux按标签进一步限制具体资源访问。
linux capabilities 和 apparmor/selinux 是不同层级的安全机制，它们不是替代关系，而是互补配合：capabilities 控制“能不能做某类系统调用”，apparmor/selinux 控制“能不能访问某个具体资源”。只有两者协同，才能形成纵深防御。
Capabilities 是第一道权限筛子
它把传统 root 权限拆成约 40 个独立单元（如 CAP_NET_BIND_SERVICE、CAP_SYS_ADMIN），Docker 默认只保留 14 个基础能力。容器进程必须先拥有对应 capability，才可能触发后续的文件或网络访问行为——但有了 capability 并不等于能成功访问，还要过 AppArmor/SELinux 这一关。
- 例如：容器加了
CAP_NET_BIND_SERVICE，可以尝试绑定 80 端口；但如果 AppArmor profile 明确禁止bind系统调用，或 SELinux 策略拒绝该进程类型访问port_t标签端口，操作仍会失败 - 再如：
CAP_SYS_ADMIN允许挂载，但 AppArmor 可直接禁止所有mount操作，或 SELinux 要求挂载目标目录必须是container_file_t类型且有mounton权限
AppArmor 在路径层面补位限制
AppArmor 以文件路径为核心，对 capability 允许的操作做二次拦截。它不关心进程有没有某个 capability，只看“这个进程当前想读 /proc/sys/net/ipv4/ip_forward，它的 profile 是否允许？”
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
- 典型配合方式：容器启动时用
--cap-drop=ALL --cap-add=NET_BIND_SERVICE，再通过--security-opt apparmor=my-java-app加载一个 profile，其中明确允许/app/config/** r,、禁止/proc/*/mem rw,、禁止capability sys_admin, - 这样即使攻击者利用漏洞提权获得 cap_sys_admin，AppArmor 也会在内核 LSM 钩子处直接拒绝其 mount 或 ptrace 请求
SELinux 在标签层面实施策略裁决
SELinux 不依赖路径，而是为进程（如 container_t）和资源（如 etc_t、port_t）打上安全上下文标签，由策略规则决定是否放行。Capabilities 只是让进程“有资格发起请求”，最终能否成功，取决于 SELinux 的 TE（Type Enforcement）规则。
- 例如：Java 容器进程标签为
system_u:system_r:container_t:s0，它想写入/app/logs/app.log，该文件若被标记为container_file_t，且策略中定义了allow container_t container_file_t:file { write append };，则允许；否则拒绝 - Docker 启动时可传入
--security-opt label=type:container_t或使用z/Z卷选项自动打标，确保容器上下文与策略匹配
生产环境推荐组合策略
不要只靠单一机制。真实加固应分层叠加：
- 用
--cap-drop=ALL清空默认能力，再按需--cap-add（如只加NET_BIND_SERVICE，绝不加SYS_ADMIN） - 启用
--security-opt no-new-privileges:true防止运行时提权 - 搭配 AppArmor：Debian/Ubuntu 系统优先加载自定义 profile，禁用敏感路径和危险系统调用
- 搭配 SELinux：RHEL/CentOS 系统启用 enforcing 模式，用
container-selinux包提供的标准策略，并为应用数据卷正确打标（如-v /data:/app/data:z）
