linux capabilities 通过内核在系统调用入口处检查进程的 cap_effective 位图实现权限控制，缺失所需能力则直接返回 -eperm；它不拦截系统调用本身，而是作为轻量级门控嵌入各 handler 开头，与 seccomp 协同构成纵深防御。
linux capabilities 本身不拦截系统调用，它控制的是进程在发起某些系统调用时是否具备执行权限。真正做拦截的是内核在系统调用入口处对当前进程的能力位图（cap_effective）进行检查——若所需能力缺失，调用直接返回 -eperm，不进入具体实现逻辑。
Capabilities 是如何嵌入系统调用执行链的
每个系统调用在内核中都有对应的 handler 函数（如 sys_mount、sys_settimeofday）。这些函数开头通常会插入能力检查代码，例如：
-
capable(CAP_SYS_ADMIN)用于mount、umount、chroot等操作 -
capable(CAP_NET_BIND_SERVICE)在inet_bind中判断能否绑定端口 -
capable(CAP_SYS_TIME)控制settimeofday是否放行
这种检查发生在用户态调用刚进入内核态之后、核心逻辑执行之前，属于轻量级权限门控，不依赖 BPF 或 seccomp 过滤器。
能力位图（Capability Bitmap）的运行时管理
每个进程 task_struct 中包含三个能力集：cap_permitted、cap_effective、cap_inheritable。Docker 启动容器时通过 prctl(PR_SET_CAPBSET_DROP, ...) 和 capset() 系统调用预设这些位图：
- 默认容器只保留
CHOWN、DAC_OVERRIDE、NET_BIND_SERVICE等 14 项基础能力 -
--cap-add=NET_ADMIN实际是将对应 bit 置 1，并确保它同时存在于permitted和effective -
--cap-drop=ALL则清空effective，再逐个恢复白名单项
能力状态在 fork/exec 时按规则继承，但不会自动提升——子进程不能获得父进程未授予的 capability。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
Capabilities 与 Seccomp 的协作关系
两者作用层级不同，常配合使用：
- Seccomp 在系统调用号层面拦截（如禁止所有
ptrace调用），发生在能力检查之前 - Capabilities 在调用已确定允许执行后，进一步判断“你有没有资格干这件事”
- 例如：即使 seccomp 允许
mount，若容器没CAP_SYS_ADMIN，调用仍失败
典型加固组合是：seccomp 黑名单高危调用 + cap-drop=ALL + cap-add=最小必需项。
为什么不能靠 Capabilities 阻止所有危险行为
Capabilities 只覆盖内核显式检查的场景，存在天然盲区：
- 不防护未做能力校验的系统调用（如部分
ioctl子命令） - 无法限制参数内容，例如
openat(AT_FDCWD, "/host/etc/shadow", ...)若路径穿越成功且 DAC 权限满足，CAP_DAC_OVERRIDE会放行 - 对命名空间逃逸类漏洞（如 userns + overlayfs）无约束力
因此，Capabilities 必须与 User Namespace、Seccomp、ReadOnlyRootfs 等机制协同，才能构成纵深防御。
