Mickaël Salaün 发布了一个补丁，旨在改进 landlocked 进程之间的通信。Landlock 是一个安全模块，它创建一个隔离的“沙箱”，即使进程本身被恶意攻击者入侵，也能阻止进程与系统其余部分交互。最终目标是允许普通用户进程以这种方式隔离自身，从而降低它们可能成为攻击系统入口点的可能性。

Mickaël 的补丁在审查过程中没有取得很大进展，但其具体目标是允许 landlocked 进程使用系统调用来操作其他进程。为了做到这一点，他希望强制 landlocked 进程遵守可能也适用于目标进程的任何约束。例如，目标进程可能不允许其他进程跟踪其执行。在这种情况下，应阻止 landlocked 进程这样做。

Andy Lutomirski 查看了该补丁并提供了一些技术建议，但经过进一步思考，他认为 Mickaël 的方法过于复杂。他认为这个补丁本身可能根本没有必要，但如果它确实有价值，那么它应该简单地阻止任何 landlocked 进程跟踪另一个进程的执行。Andy 指出了某些内核特性，这些特性会使整个问题变得更加复杂。他说：“如果像 Tycho 的通知器这样的东西被加入，那么就不明显了，仅仅因为你有一组相同的过滤器，你就拥有相同的特权。同样，如果一个允许过滤器查询其 cgroup 的功能被加入（而你曾经提出过这个！），那么你在这里实现的逻辑就是错误的。”

Andy 对 landlock 的总体评估是：“我认为这进一步证明了 Landlock 作为 seccomp 的一部分比作为一个完全独立的东西更有意义。我们已经非常仔细地审查了 seccomp 的这些东西。请不要让我们从头再来一遍。”

但 Mickaël 认为 landlock 确实有一些 Andy 没有提到的有效用例——例如，“运行一个受某些 Landlock 程序约束的容器”。Mickaël 认为，如果没有他的补丁，在这种情况下用户将无法调试他们的工作。正如他所说，“这个补丁添加了拥有有意义的 Landlock 安全策略所需的最低限度的保护。没有它，它们可能很容易被绕过，因此毫无用处。”

至于将 landlock 折叠到 seccomp 中，Mickaël 回复说：“Landlock 比 seccomp 更复杂，因为它有不同的目标。seccomp 限制性较小，因为它更简单。”

Andy 回复了 Mickaël 关于运行受 Landlock 程序约束的容器的例子，他说：“任何理智的容器想要像这样使用 Landlock 也会创建一个 PID 命名空间。问题解决了。”他补充说：“听起来你想让 Landlock 本身成为一个完整的容器系统。我不同意这个设计目标。”而且，他说他仍然认为应该简单地删除这个补丁。

但显然，在进一步深入代码之后，Andy 觉得他的批评不太正确。他仍然认为应该删除这个补丁，但他已经完善了他这样做的理由。他说

我可以看到一个论点，即应该有一个标志，可以在添加 seccomp 过滤器时设置，该标志表示“阻止 ptrace 任何没有安装此确切堆栈的子进程”，但我认为这可以在以后添加，不应作为初始提交的一部分。目前，Landlock 用户可以完全阻止 ptrace() 或使用 PID 命名空间。

但 Mickaël 说，除了他的容器示例之外，还有其他用例。他说

...另一个是内置沙箱（例如，用于 Web 浏览器），另一个是用于沙箱管理器（例如，Firejail、Bubblewrap、Flatpack）。在某些用例中，特别是从开发人员的角度来看，您可能想要/需要调试您的应用程序（无需 root 权限）。对于嵌套的 Landlock 访问控制（例如，容器 + 用户会话 + Web 浏览器），可能不允许创建 PID 命名空间，但您仍然希望拥有有意义的访问控制。

但是，Andy 并没有被说服。他更加强烈地辩称：“如果真的有必要添加这种类型的自动 ptrace 保护，那么无论如何，让我们将其作为通用的 seccomp 功能添加。”

Mickaël 同意这些功能对于 seccomp 也很有意义，但他仍然认为他自己的补丁除了这一点之外也很有用。至此，讨论结束。

这种安全辩论通常很难跟踪或预测。开发人员永远不知道什么时候内核中看似遥远的部分的人会关注他们的补丁，说它在其他地方创建了一个安全漏洞，或者该功能本身真的属于其他地方。许多小时的工作可能会白费，仅仅是因为开发人员不知道他们正在做的事情在内核的完全不同的部分会更受欢迎。同样，批评他们补丁的人可能遗漏了一个关键细节，突然在许多电子邮件之后，结果证明最初的编码员毕竟做对了——瞧，这段代码有很多用途。不可能猜测辩论会朝哪个方向发展，这也是内核开发人员经常会非常努力地表达自己的观点的原因之一，甚至到了在给定问题上显得难以驾驭的地步。

注意：如果您在上面被提及，并想在评论区上方发布回复，请将包含您的回复文本的消息发送至 ljeditor@linuxjournal.com。