Linux Landlock 怎样同时约束能力与命名空间

可以同时约束，但要把两件事拆开：Landlock 的 capability 规则限制进程已经拥有的 Linux 能力能否被使用，namespace 规则限制进程能创建、加入或取得引用的命名空间类型。它不会凭空授予能力，也不会替代 user namespace 的 UID/GID 映射。实用组合是：先按运行时 ABI 建立规则集，只放行必需的 CAP_* 和 CLONE_NEW*，再用 landlock_restrict_self() 约束当前线程及其后代。

官方资料：https://www.kernel.org/doc/html/next/userspace-api/landlock.html

Landlock 的两条限制边界

传统 capability 检查回答的是“这个线程是否具备执行特权操作的资格”；namespace 规则回答的是“它能不能使用某类隔离域”。当前内核文档中，LANDLOCK_PERMISSION_CAPABILITY_USE 控制能力使用，LANDLOCK_PERMISSION_NAMESPACE_USE 覆盖 unshare、clone、clone3、setns 以及部分 namespace 文件描述符获取路径。

user namespace 是最容易漏掉的边界：进程创建或进入新的 user namespace 后，会在那个命名空间中得到一套能力，但这些能力的作用范围受命名空间所有权限制。若规则集同时处理 namespace 和 capability，某个非 user namespace 操作还需要对应的 CAP_SYS_ADMIN，两条规则都放行后才可能通过传统检查。

先查 ABI，再组装规则集

不要把 ABI 12 写成无条件前提。先读取运行内核支持的最高 ABI；低于 12 时，可以继续使用文件系统或网络规则，但不能假设能力和命名空间规则已经生效。

#include 

int abi = landlock_create_ruleset(NULL, 0, LANDLOCK_CREATE_RULESET_VERSION);
if (abi 

上面是接口片段，不是可直接编译的完整程序：实际代码还要检查每个系统调用返回值，并在编译环境中确认头文件与运行内核 ABI 一致。若业务根本不需要创建 user namespace，就不要把 CLONE_NEWUSER 加入白名单；白名单越小，后续审计越清楚。

能力和 namespace 如何一起收紧

一个常见策略是只允许子进程创建 user namespace，同时只允许它使用一项明确的能力。若还要创建 mount namespace，就必须额外评估 CLONE_NEWNS 与 CAP_SYS_ADMIN；只放行其中一项并不能绕过另一项检查。

struct landlock_namespace_attr ns_rule = {
    .permissions = LANDLOCK_PERMISSION_NAMESPACE_USE,
    /* 需要挂载隔离时才增加 CLONE_NEWNS。 */
    .allowed_namespace_types = CLONE_NEWUSER | CLONE_NEWNS,
};

struct landlock_capability_attr cap_rule = {
    .permissions = LANDLOCK_PERMISSION_CAPABILITY_USE,
    /* 这里只列出策略确实需要的能力，未列出的能力会被拒绝。 */
    .allowed_capabilities = 1ULL 

这段示例只表达策略关系，不建议照抄成通用容器配置。CAP_SYS_ADMIN 权限面很大，能否缩减取决于具体 mount、网络或设备操作；如果只是读取工作目录，通常不应因为“方便”就放行它。LANDLOCK_RESTRICT_SELF_TSYNC 适合多线程进程在启动阶段统一同步规则；规则集一旦生效，只能继续叠加限制，不能撤销。

上线前检查四个容易漏的边界

• 先查 ABI：用 LANDLOCK_CREATE_RULESET_VERSION 探测，低版本明确记录降级或拒绝启动。
• 先关入口：在创建线程、启动插件或执行不可信子进程前完成 restrict_self；已有文件描述符的限制语义要单独审查。
• 按操作拆能力：把 CAP_SYS_ADMIN、CAP_NET_RAW 等大权限与实际系统调用对应起来，不用“全能力”代替排查。
• 验证后代：检查子进程是否继承 Landlock 域，并分别测试 unshare、setns、挂载和文件读写的拒绝路径。

Landlock 是额外的内核安全层，不会取代 DAC、seccomp、SELinux/AppArmor、cgroup 或容器运行时策略。目标应是把每个进程的环境收窄到够用的范围：需要什么能力就放行什么能力，需要什么 namespace 就放行什么类型，其余交给内核拒绝。

两个容易混淆的问题

只限制 namespace，能阻止 user namespace 带来的能力变化吗？ 不能。若允许创建 user namespace，就要把它视为一次能力边界变化；需要更小权限面时，同时处理 capability 使用规则。

ABI 不足 12 时，能不能用同样的字段强行提交规则？ 不应这样做。按照 ABI 查询结果屏蔽不支持的权限，或在安全要求不允许降级时直接拒绝启动；不要用内核版本字符串代替 ABI 探测。