无 Root 即可实现的 Linux 进程沙箱：Landlock 技术深度解析与实战指南
Linux 内核中的隐形守护：Landlock 的基本原理
在现代 Linux 系统的安全架构中，Linux Security Modules (LSM) 一直扮演着关键的访问控制角色。然而，传统的 LSM 机制如 SELinux 或 AppArmor 往往需要管理员介入、复杂的策略编写以及 Root 权限才能激活。Landlock 的出现，打破了这一常规。它是一个自主访问控制 (DAC) 框架，允许一个已经运行的进程主动请求内核，剥夺其自身对文件系统的访问权。这种“自我限制”的能力，意味着无需 Root 权限，也无需外部守护进程或庞大的容器环境，即可在单个进程层面构建安全沙箱。
Landlock 的核心价值在于其轻量级和声明式的特性。它不像传统的安全模块那样需要在系统启动时就定义好策略，而是在运行时，由进程自身通过一系列系统调用来定义和加载限制规则。这种设计使得 Landlock 非常适合用于保护第三方库、未经验证的脚本或是需要限制文件访问的服务组件。内核自 5.13 版本开始引入了 Landlock，这意味着目前绝大多数主流发行版的最新内核都已经具备了支持能力，为广大用户提供了这项技术的可用基础。
编程模型：从零开始的限制构建
要在代码中使用 Landlock，首先需要确保系统环境已就绪。这包括拥有 5.13 及以上版本的内核、标准的 C 编译工具链，以及确保 Landlock LSM 在当前内核配置中被启用。验证方法也很简单，通过检查 /sys/kernel/security/lsm 文件内容是否包含 landlock 字样。对于 Ubuntu 22.04 及以后的版本，以及当前的 Fedora 和 Arch 发行版，Landlock 通常已经默认开启，无需额外配置。
Landlock 的编程接口相对直接，主要依赖于 landlock family 的系统调用。文章详细介绍了其中三个最基础也是最常用的系统调用：landlock(2) 中的 LANDLOCK_ATTRIBUTE_FS_ROOT、LANDLOCK_ATTRIBUTE_FS_CREATE 以及 LANDLOCK_ATTRIBUTE_FS_REMOVE。这些调用允许进程指定它希望保留访问权限的根目录，以及对目录的创建、删除等操作权限。理解这些调用的语义，是构建沙箱的第一步。
编写第一个限制者：一个自降权的程序
文章通过一个具体的 C 语言示例，展示了如何编写一个能够自我限制的程序。示例程序的逻辑非常直观：它首先尝试去读取系统敏感文件 /etc/hostname 和临时文件 /tmp/secret.txt。在应用 Landlock 限制之前，这两个操作都能成功执行。随后，程序调用 Landlock 接口，明确声明只允许访问 /etc 目录。当再次尝试读取 /tmp/secret.txt 时，操作被内核拦截，返回“FAILED (Permission denied)”的错误。
这个过程生动地演示了 Landlock 的工作机制：进程主动向内核申请剥夺部分权利。值得注意的是，这种限制是不可逆的（或者说是难以逆转的），一旦规则加载，进程就真的失去了对被禁止路径的访问能力。这为构建不可逃逸的沙箱提供了技术保障，确保即使程序后续逻辑出现漏洞，也受限于内核强制施加的访问约束。
进阶陷阱与规则交互：开发者必须知道的四大惊喜
在实际使用 Landlock 的过程中，作者特别列举了四个极易被忽视但又至关重要的“惊喜”，这些往往是导致安全策略失效的根源。首先是 no_new_privs 标志的强制关联。Landlock 规则的生效并非简单的权限划分，它必须在 no_new_privs 标志被设置的进程上下文中才能真正生效。这意味着，如果父进程没有开启这个标志，子进程尝试使用 Landlock 很可能会静默失败或产生意外行为。
其次是规则之间的交集特性。Landlock 不会自动“宽容”之前的规则，新加入的限制规则会与旧的规则进行交集运算。这听起来直观，但在复杂的程序链中，开发者很容易误以为新规则会覆盖旧规则，从而导致安全边界模糊。实际操作中，必须清楚地了解当前进程已经拥有哪些权限，以及新规则会如何与之相互作用，才能避免“安全盲区”的出现。
第三点涉及子进程的继承问题。当一个受 Landlock 约束的父进程 fork 或 exec 一个新程序时，子进程并非自动继承了这些限制。每个新的执行路径都需要重新申请和加载 Landlock 规则。这对于需要通过子进程处理数据的场景来说是一个关键的设计考量，开发者不能指望一次设置永久生效。
最后，也是最隐蔽的是 exec 陷阱。这是 Landlock 用户最容易踩的坑。即使一个进程成功地使用 Landlock 限制了自己的文件系统访问，当它调用 exec 执行一个新的二进制程序时，新程序将完全失去之前的 Landlock 约束。内核在执行新程序时会清空之前的安全上下文。这意味着，如果你希望一个受限的程序在启动新子程序后仍然保持沙箱状态，必须在 exec 之前小心处理，或者在新程序的入口处重新应用 Landlock 规则，这在设计多阶段工作流时需要特别小心。
路径发现与 ABI 版本的兼容性
构建有效的沙箱策略离不开对程序实际需要访问哪些路径的精准判断。文章提供了一种寻找程序所需路径的方法，这通常涉及对程序运行时的文件系统调用进行跟踪和分析。开发者需要通过工具或日志，确定程序启动所需的配置文件、数据文件以及库文件的具体路径，然后在 Landlock 规则中精确地列出这些路径。
此外，Landlock 的系统调用接口经历了不同的 ABI (Application Binary Interface) 版本演进。了解当前系统运行的 Landlock ABI 版本对于编写兼容性代码至关重要。不同版本的结构体布局和标志位可能存在细微差异，这在跨发行版或不同内核版本部署时可能会带来编译或运行时的兼容性问题。文章建议在代码中进行版本检查，或针对特定内核版本编写回退逻辑，以确保沙箱规则能够在不同环境中可靠地加载和执行。
总结与展望：内核安全的民主化
Landlock 的出现标志着 Linux 系统安全机制的一次重要民主化进程。它让普通用户和开发者无需依赖 Root 权限或复杂的基础设施，即可在单个进程层面实现强大的访问控制。从文章的实践来看，Landlock 的学习曲线相对平缓，其系统调用接口设计合理，文档也相对清晰。对于需要在共享主机上运行的微服务、浏览器插件或者是为了安全研究而隔离的环境，Landlock 提供了一种轻量级、高效的替代方案。
展望未来，随着内核对 Landlock 支持的不断深化以及用户空间工具链的完善，我们有理由相信这种基于进程的自我限制机制将会被应用在更广泛的场景中。它或将成为容器安全的补充层，或成为沙箱即服务平台的核心组件。对于关注系统安全的开发者而言，掌握 Landlock 这项技术，不仅是对内核能力的深度挖掘，更是未来构建更安全、更精细化软件系统的必备技能。