Changaco/linux-security

本文档总结了我对 Linux 安全性的深入研究，该研究始于 2026 年 4 月，重点关注沙盒机制。 ## Linux 沙盒工具对比 ### 无需或只需少量细节知识即可使用的沙盒 [firejail](https://firejail.wordpress.com/) 是成熟的 Linux 应用程序沙盒，最早可追溯到 [2014 年 4 月](https://github.com/netblue30/firejail/blob/46a111166e23a2a1c99bb079616c0fd8687ae533/RELNOTES#L1676-L1680)。firejail 使用 C 语言编写，它可以轻松地对程序施加一些限制，但很难做到仅授予程序运行所需的最少严格权限。我曾为[一个已知漏洞提供了一个快速的修复方案](https://github.com/netblue30/firejail/pull/7154)。 [bubblejail](https://github.com/igo95862/bubblejail) 创建于 2019 年 11 月。它使用 Python 编写，旨在作为一种采用不同技术路径的 firejail 替代品。bubblejail 附带了一个通用配置文件和少量的特定应用程序配置文件，而 firejail 则拥有一个默认配置文件和超过一千个特定于应用程序的配置文件。 #### 与特定包格式绑定 这些项目将沙盒机制与特定的应用程序打包和分发方式绑定在一起，这是有问题的，因为其他的安装方式将继续存在。[社区可以说不需要这样的系统，而且显然也不需要两个相互竞争的系统。](https://distrowatch.com/weekly.php?issue=20160704#opinion) [flatpak](https://github.com/flatpak/flatpak) 的首次提交是在 2014 年 12 月，并[自 2016 年起](https://lists.freedesktop.org/archives/flatpak/2016-May/000204.html)开始使用现在的名称。它使用 C 语言编写，[十年来](https://web.archive.org/web/20160607053606/https://flatpak.org/)一直将自己描述为“未来”。[Flatpak 的沙盒机制](https://docs.flatpak.org/en/latest/sandbox-permissions.html)存在弱点（[1](https://www.linuxjournal.com/content/when-flatpaks-sandbox-cracks-real-life-security-issues-beyond-ideal), [2](https://www.openwall.com/lists/oss-security/2026/05/19/1), [3](https://youtu.be/NsVhkz2Xl0E?t=258)）。目前[正在考虑对其进行完全重写](https://www.heise.de/en/background/Linux-App-Summit-2026-Meeting-of-the-Linux-Desktop-Avant-garde-11316647.html)。 [snapd](https://github.com/canonical/snapd) 的首次提交同样是在 2014 年 12 月。它使用 Go 语言编写，并未得到所有主要发行版的官方支持。[Snap 的沙盒机制](https://snapcraft.io/docs/explanation/security/)同样并不完美。 ### 底层沙盒 这些工具并不打算供普通人直接使用。 [sydbox](https://gitlab.exherbo.org/sydbox/sydbox) 拥有悠久的历史：首次提交在 2009 年 2 月。它当前的主要版本是从 C 语言重写为 Rust 的，创建于 2023 年 9 月。syd 旨在为软件包构建提供沙盒。[syd 手册的“bugs”部分](https://man.exherbo.org/syd.7.html#BUGS)描述了 Linux 内核中存在问题的限制。 [systemd](https://en.wikipedia.org/wiki/Systemd) 的首次提交是在 2009 年 11 月。它的第一批沙盒指令是在 [2010 年 4 月](https://github.com/systemd/systemd/commit/15ae422b7471cf6f41ccf450243d8afd8ea0a054)添加的，随后几年中又添加了许多指令。systemd 使用 C 语言编写，它提供了 [`systemd-analyze security`](https://man.archlinux.org/man/systemd-analyze.1#:~:text=systemd-analyze%20security%20[UNIT...]) 命令，以便于审查和改进系统服务的沙盒化方式。 [systemd-nspawn](https://man.archlinux.org/man/systemd-nspawn.1) 于 [2011 年 3 月](https://github.com/systemd/systemd/commit/88213476187cafc86bea2276199891873000588d)首次提交。它使用 C 语言编写，旨在管理容器，但也可用于在沙盒中运行非容器化程序（例如 `systemd-nspawn -D / --volatile -a -- ls -l /`）。 [systemd-run](https://man.archlinux.org/man/systemd-run.1) 的[首次提交是在 2013 年](https://github.com/systemd/systemd/commit/c2756a68401102786be343712c0c35acbd73d28d)。它使用 C 语言编写，由于它能够派生用户会话管理器进程，因此可能会允许程序突破某些沙盒。systemd-run 会毫不保留地将完整的命令行记录在 systemd journal 中，这在某些情况下可能是不希望发生的。 [nsjail](https://nsjail.dev/) 的首次提交是在 2015 年 5 月。它使用 C++ 编写，其显著特点是支持在不需要管理员权限的情况下，授予沙盒程序有限的网络访问权限（例如 `nsjail -Mo --chroot / --use_pasta -- /usr/bin/curl …`）。 [bubblewrap](https://github.com/containers/bubblewrap) 的首次提交是在 2016 年 2 月，但它是[从更早的项目衍生而来的](https://blogs.gnome.org/alexl/2018/06/20/flatpak-a-history/)。它使用 C 语言编写，值得注意的一点是，它[不支持在授予应用程序互联网访问权限时不让它们访问本地网络和抽象 socket](https://github.com/containers/bubblewrap/issues?q=is%3Aissue%20state%3Aopen%20network)。 [gVisor](https://gvisor.dev/) 的首次提交是在 2018 年 4 月。这个大型项目使用 Go 语言重新实现了 Linux 内核的很大一部分，以最大限度地降低内核 bug 被沙盒化程序利用的风险。它主要用于服务器，但也可能对终端用户设备有用。 [sandwine](https://github.com/hartwork/sandwine) 的首次提交是在 2023 年 2 月。它使用 Python 编写，专门用于通过 [Wine](https://www.winehq.org/) 运行 Windows 应用程序。sandwine 构建在 bubblewrap 之上，因此目前无法完全对需要互联网访问权限的应用程序进行沙盒化。 [landrun](https://github.com/Zouuup/landrun) 于 2025 年 3 月首次提交。它使用 Go 语言编写，并未封堵所有离开沙盒的路径。 ### 面向开发环境的沙盒 这类沙盒工具的出现，是为了应对过去几年中针对开发者的供应链攻击。以下所有工具的首次提交均在 2025 年。 [drop](https://github.com/wrr/drop)（2025 年 7 月）使用 Go 语言编写。它的 `drop` 命令旨在隔离特定目录。它必须被显式调用，这就留下了忘记执行此操作的风险。 [litterbox](https://github.com/Gerharddc/litterbox)（2025 年 8 月）使用 Rust 编写。与本节中提到的其他工具不同，它构建在容器之上。正如其 README 中所述，这并不能让它更安全。 [island](https://github.com/landlock-lsm/island)（2025 年 10 月）同样使用 Rust 编写。与 drop 不同，island 旨在自动隔离特定目录，这得益于一种 `zsh` 集成，它可以根据当前工作目录启用和禁用沙盒。其 README 警告称它“尚未准备好用于生产环境”。 [sheld](https://github.com/pierrelegall/sheld) 同样出自 2025 年 10 月，也使用 Rust 编写，并且同样提供 shell 集成，但它的设计初衷是仅对特定命令进行沙盒化，而不是对在特定目录中执行的所有命令进行沙盒化。sheld 构建于 bubblewrap 之上，因此目前无法完全对需要互联网访问权限的程序进行沙盒化。 注意：shell 集成存在[局限性](https://github.com/landlock-lsm/island/blob/7735885d0343562e1daf36012ecfd276ef1129e3/assets/shell/hook.zsh#L54-L64)。这些问题可以通过修改 shell 来修复，但我认为更好的解决方案是[将 shell 本身运行在一个能够捕获所有 `execve` 系统调用的部分沙盒中](https://github.com/pierrelegall/sheld/issues/1#issuecomment-4316290849)。 ### 面向 AI agent 的沙盒 [sandlock](https://github.com/multikernel/sandlock) 是最年轻的工具（2026 年 3 月）。它使用 Rust 编写，旨在限制 AI agent 允许执行的操作。它的源代码本身至少有一部分是由 AI 生成的。[它使用 seccomp 通知的方式可能仍然不安全。](https://github.com/multikernel/sandlock/issues/27) ## 交互式网络过滤 [opensnitch](https://github.com/evilsocket/opensnitch) 的首次提交是在 2017 年 4 月。它使用 Python、Go 和 C 语言编写，让用户能够对所有应用程序建立的网络连接进行细粒度控制。 ## Linux 安全模块 [LSM](https://en.wikipedia.org/wiki/Linux_Security_Modules) 框架使内核模块能够强制执行自定义的访问控制规则。 [SELinux](https://en.wikipedia.org/wiki/SELinux) 于 [2000 年 12 月](https://marc.info/?l=linux-kernel&m=97749381725894)首次发布，并于 2003 年被合并到内核中。它被广泛使用，包括在许多作为 [Android Application Sandbox](https://source.android.com/docs/security/app-sandbox) 组成部分的终端用户设备上。 [AppArmor](https://en.wikipedia.org/wiki/AppArmor) 自 2005 年起开始使用现在的名称，并于 2010 年被合并到内核中。它在 Ubuntu 中得到了显著应用。 [Yama](https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama.html) 于 2012 年被合并到内核中。这个小模块实现了对 [ptrace](https://en.wikipedia.org/wiki/Ptrace) 系统调用使用的进一步限制。 [Landlock](https://docs.kernel.org/userspace-api/landlock.html) 于 2016 年首次发布，并于 [2021 年 5 月](https://lore.kernel.org/linux-security-module/161992097730.25025.14142306394400248363.pr-tracker-bot@kernel.org/T/)被合并到内核中。与以往为系统管理员设计的模块不同，Landlock [专为非特权用户使用而设计](https://landlock.io/talks/2024-06-06_landlock-article.pdf)。因此，它只允许添加限制，而不能移除限制，而修改 SELinux 或 AppArmor 策略的权力同时也是解除对任何应用程序限制的权力。 ## 后续工作 ### 更多章节？ 可以扩展本文档以涵盖更多的 Linux 安全主题。在 [Arch Linux wiki 的“Security”文章](https://wiki.archlinux.org/title/Security)以及 [Kicksecure 的强化指南](https://www.kicksecure.com/wiki/Comparison_with_Others)中可以找到一些可能的主题。 ### 维基百科条目？ 这里收集的信息可用于创建一个[“Linux sandboxing”的维基百科条目](https://en.wikipedia.org/wiki/Linux_sandboxing)。除了列出可用的工具外，该条目还可以解释它们工作原理的基础知识。已有的相关条目包括 [Sandbox (computer security)](https://en.wikipedia.org/wiki/Sandbox_\(computer_security\)), [Containerization (computer)](https://en.wikipedia.org/wiki/Containerization_\(computing\)), [seccomp](https://en.wikipedia.org/wiki/Seccomp), [Linux namespaces](https://en.wikipedia.org/wiki/Linux_namespaces), [Firejail](https://en.wikipedia.org/wiki/Firejail), [Flatpak](https://en.wikipedia.org/wiki/Flatpak) 和 [Snap (software)](https://en.wikipedia.org/wiki/Snap_\(software\))。 ### 审计？ 我目前尚未了解到任何现有的沙盒工具经历过完整的审计。 ### 跨发行版统一强化 systemd unit？ 许多系统服务在运行时仍然拥有超出其所需的权限。运行 `systemd-analyze security` 通常会显示大多数 unit 被评级为 `UNSAFE`。（这些评级仅基于 unit 的配置，并没有考虑到某些守护进程在启动时拥有大量权限，但会迅速丢弃这些权限。） [SandboxDB](https://sandboxdb.org/) 提供了不同发行版如何对相同服务进行沙盒化的对比，但自 2022 年 12 月以来就未再更新过。它的[源代码](https://github.com/erdnaxe/sandboxdb.org)可以加以改进，以支持持续且高效地更新数据。 ### 内核更改？ 几乎可以肯定，需要对 Linux 内核进行修改，才能创建出更好的用户空间沙盒工具。在我指出了竞态条件漏洞后，sandlock 的创建者开始着手[为 seccomp 添加一项新功能](https://lore.kernel.org/all/?q=f%3Axiyou.wangcong%40gmail.com+s%3Aseccomp)。我还建议[为 Landlock 添加一项新功能](https://github.com/landlock-lsm/linux/issues/61)，以方便对需要互联网访问权限的应用程序进行沙盒化。 ### 通用沙盒工具？ 可能需要一种新的沙盒工具，因为现有的工具在范围上似乎都太有限了。这个新工具必须经过设计，以解决非特权用户的所有沙盒需求，包括对整个会话的保护（即确保所有程序在执行时都带有适当的限制，无论它们是如何以及在哪里被安装和启动的）。 ## 保持最新状态 您可以[关注此仓库](https://github.com/Changaco/linux-security/subscription)，或将其[提交动态](https://github.com/Changaco/linux-security/commits.atom)添加到您的新闻聚合器中。 如果您还没有订阅，您可能还希望订阅 [oss-security 邮件列表](https://oss-security.openwall.org/wiki/mailing-lists/oss-security)，但您应该记住，一直接收坏消息可能会损害您的心理健康。 ## 资金支持 这项研究得到了 [Liberapay](https://liberapay.com/) 社区隐性的众筹支持。如果您从中受益，请考虑向 [Liberapay 团队](https://liberapay.com/Liberapay)或[我本人](https://liberapay.com/Changaco)捐款。 ## 版权声明 只要您遵守 [CC By-SA 4.0](https://creativecommons.org/licenses/by-sa/4.0/) 许可协议，即可自由分享和改编本作品，无需申请许可。 本仓库中有 0% 的 AI 生成内容。

标签：可视化界面, 子域名枚举, 安全, 应用隔离, 日志审计, 沙箱, 系统安全, 超时处理, 逆向工具