对Flatpak不安全说法的回应

# Flatpak —— 一个安全噩梦 来源：https://oro.gay/posts/flatpak-an-insecurity-nightmare/ *注意不要与 Flatpack (https://en.wikipedia.org/wiki/Flatpack) 混淆。* 20多年来，Linux 被广泛应用于从服务器到嵌入式设备的各个领域。然而，它一直缺乏的一环是桌面领域。Windows 和 macOS 持续地将 Linux 挡在市场之外——游戏主要是 Windows 的天下，内容创作者则多使用 macOS。 过去十年间，Linux 桌面取得了长足的进步：Flatpak、Wayland、Portals、PipeWire 和 FreeDesktop 都在努力让 Linux 成为一个更适应现代（桌面）系统的操作系统。但我不会逐一展开介绍它们——正如标题所揭示的那样，这篇文章的主题是*Flatpak*！ ## 历史 让我们快速回顾一下服务器领域。服务器上运行着十年（甚至数十年）前的内核和库并不罕见。这是有道理的：服务器启动时间长，每次系统更新都有出问题的风险，还需要进行调试，宝贵的在线时间就会损失——对于 Google 这样的大型服务尤其如此。因此，服务器领域自然演化出了一种快速修补系统最相关部分的方法，从而避免安全问题。 然而，服务器上运行的软件可能只能利用新版本库中的新特性，而不是服务器所运行的那些陈旧软件。那么他们是如何解决这个问题的？ 容器。容器通常用于以一致且更安全的方式向多个客户交付软件，它允许你将软件隔离到一个小盒子中，包含所有所需的依赖项及其指定版本，同时对宿主系统的访问权限是受限的。 ## 现状 我们有 Android、macOS 和 iOS，它们都对系统施加了有限的访问权限，需要终端用户的明确授权才能访问某些资源。但 Linux 桌面呢？ 2015年，Flatpak 发布了，它将服务器上容器化所使用的全部技术应用到了桌面系统上。随之而来的是 Portals (https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html#xdg-desktop-portals) 和 Freedesktop SDK (https://freedesktop-sdk.io/)。这为开发者提供了一个一致且通用的平台和 API，与此前各不相同的依赖版本、核心系统库和打包格式的混战局面相比，是一个巨大的转变。 当然，在发行方式和开发流程维持了几十年之后，这种变化不可能一蹴而就。所需的 API 很多已经存在，但开发者需要抽出时间来迁移；而有些用户（具体来说，是那些讨厌 Flatpak 的用户）强烈拒绝协助改善这一状况，坚持认为我们应该继续使用旧的方式，为成千上万种不同的系统反复打包软件数百次。 简而言之，理所当然地，没有哪个头脑清醒的人会在乎这些。许多新的应用开发者在设计应用时就考虑了受限环境，并将软件发布到 Flathub，让软件以快速且安全的方式到达终端用户。 ### 应用沙箱化 那么那些旧应用呢？毕竟在 Flathub 上你可以找到十年前的应用。从这些应用中催生出了诸如"Flatpak - a security nightmare" (https://flatkill.org/)*嘿，你可能认得这个名字！* 这样的文章，以及 FOSS 社区中知名人士的各种回应 (https://theevilskeleton.gitlab.io/2021/02/11/response-to-flatkill-org.html)，旨在抵消这些文章中的错误信息和攻击性言辞。 对于这些应用，散布 FUD（恐惧、不确定和怀疑）的文章喜欢挑选最糟糕的反面案例，并以此声称 Flatpak 根本不值得推动。所以我想对此加以说明。 这些应用是按照不受限制的环境设计的，它们所需的 API 要么当时还不存在，要么它们没有更新以使用新的 API。挑选这些案例来证明 Flatpak 沙箱"不是沙箱" (https://hanako.codeberg.page/) 并不是有效的论据，这只表明这些应用本身就不安全。 当然，旧应用并非唯一的"罪魁祸首"。由于新 API 可能还不够成熟，较新的和较旧的应用都可能不得不依赖于静态权限 (https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html#static-permissions) 才能正常工作。对于大多数较新的应用来说，这没问题，因为它们能比旧应用限制*多*得多的权限。 Flatpak*是*沙箱。Flatpak*是*安全的。不安全的是*应用* (https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html#insecure)。改变"沙箱"一词的含义对谁都没有好处。仅仅因为某些应用所使用的沙箱达不到 iOS 或 Android 的水平，并不能取消其作为沙箱的资格。如果你想因此怪罪 Flatpak，*请便*（但我不建议）。这些应用依赖静态权限这一事实表明，应用本身是不安全的、依赖于不一致的接口；在某些情况下，也表明现有的 API 还不足以满足它们的使用场景 (https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html#why-do-static-permissions-still-exist)。我们应该专注于改善这种情况，而不是试图推翻它。 如果你想了解部分沙箱在现实中仍然有效的例子："fractureiser" 恶意软件 (https://prismlauncher.org/news/cf-compromised-alert/)。即使该恶意软件在 Linux 上本来就不能正常运行，它仍然说明了传统打包方式无法应对这样一个事实：现代桌面系统有很多途径可以导致系统被攻陷。运行"你信任的"软件并不足以保护你自己。引用相关文章中的注释： > 如果你使用 Linux，请使用 PrismLauncher 的 Flatpak 版本 (https://flathub.org/apps/org.prismlauncher.PrismLauncher)，并通过 Flatseal 等工具非常谨慎地决定授予它什么访问权限。默认情况下，它没有访问破坏系统所需目录的权限。 > 快速浏览一下反编译后的源代码，它确实会在默认的 PrismLauncher Flatpak 沙箱内无法正常运行；当前的恶意软件硬编码了用户的 `~/.config/` 目录。在 Flatpak 沙箱内创建文件时，如果应用没有对该真实路径的访问权限，文件会被写入一个在沙箱重启时被清空的 tmpfs 中。systemd 在 Flatpak 沙箱内也不可用，因此执行该命令会失败。该恶意软件似乎没有尝试绕过这些限制，而是假定它运行在无沙箱的环境中。 *免责声明：以下注释是我写的 :)* *关于静态权限和 Portals 的更深入了解，请参阅 TheEvilSkeleton (https://theevilskeleton.gitlab.io/about) 撰写的"Overview of Flatpak's Permission Models" (https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html#why-do-static-permissions-still-exist)。* ### 过时的依赖 有些人也喜欢把过时的依赖拿来作为论据。不，这无关紧要。运行时（runtime）本身会在有安全更新需要时进行更新（有时甚至会因为影响足够大而*破坏 ABI* (https://gitlab.com/freedesktop-sdk/freedesktop-sdk/-/blob/a90f92388b5c1c873168920c570769bee8a2beb1/utils/abidiff-suppressions.ini)），而应用开发者也不必手动更新捆绑的依赖，因为有自动更新检查机制 (https://github.com/flathub/flatpak-external-data-checker)。而且许多主要的库，比如 GPU 驱动，可以在你选择的情况下独立于运行时单独更新。过时的依赖从一开始就不算一个有效的论据。 如果某个应用*确实*使用了过时的库——无论是因为一次更新破坏了构建流程，还是开发者忘了设置数据检查器——在开发者解决这些问题之前，包裹在所有 Flatpak 应用周围的沙箱可以帮助缓解这些问题。 ## 未来 我们希望 Linux 桌面能迁移到对开发者更友好、也更有利于沙箱化的软件分发和编程方式。我们已经在 PipeWire 方面取得了长足进展，它为音频和视频方面的*许多*优秀功能铺平了道路（包括多个应用同时使用摄像头！），FreeDesktop 也是一样，但不可否认，在 Linux 成为开发者可以面向并交付软件的可行平台之前，我们还有很长的路要走。 没有 Wayland 和 Flatpak 这样的现代软件，我们就无法前进，不论有人多想用 Xorg 和传统打包方式来解决当前的困境。如果我们一直试图回到过去的做法，向开发者展示的只是 Linux 不是一个值得考虑的平台，最终对终端用户来说情况只会更糟；这会变成一个"先有鸡还是先有蛋？"的困境，并导致*非常*糟糕的用户体验。 我们不希望看到这种情况发生。 ## 延伸阅读 如果你想了解更多关于 Flatpak 的信息，以及它如何工作和当前状况的一般性信息，以下文章值得一读： - 对 flatkill.org 的回应 - TheEvilSkeleton (https://theevilskeleton.gitlab.io/2021/02/11/response-to-flatkill-org.html) - 对"Flatpak Is Not the Future"的回应 - TheEvilSkeleton (https://theevilskeleton.gitlab.io/2022/05/16/response-to-flatpak-is-not-the-future.html) - 传统打包方式不适合现代应用 - TheEvilSkeleton (https://theevilskeleton.gitlab.io/2022/08/29/traditional-packaging-is-not-suitable-for-modern-applications.html) - Flatpak 权限模型概述 - TheEvilSkeleton (https://theevilskeleton.gitlab.io/2023/05/11/overview-of-flatpaks-permission-models.html) - 对"开发者很懒，所以用 Flatpak"的回应 - TheEvilSkeleton (https://theevilskeleton.gitlab.io/2023/06/04/response-to-developers-are-lazy-thus-flatpak.html) - Linux 桌面应用的发行版打包方式是不可持续的 - memoryfile (https://memoryfile.codeberg.page/posts/Distribution-packaging-for-Linux-desktop-applications-is-unsustainable/) - 你其实并不对 Flatpak 生气 - Jordan Petridis (https://blogs.gnome.org/alatiera/2023/06/09/you-are-not-actually-mad-at-flatpak/)