LWN：Qubes OS 4.1 的计划！

关注了就能看到更多这么棒的文章哦～

Moving toward Qubes OS 4.1

By Jake Edge
October 20, 2021
DeepL assisted translation
https://lwn.net/Articles/873255/

10 月 11 日，Qubes OS 4.1 版的第一个 RC 版本公布了。Qubes OS 是一个专注于安全的桌面操作系统，使用多个虚拟机（VM 或称为 "qubes"）来隔离各类的功能。其理念是将不同的应用程序和操作系统子系统分隔开来，以保护不受别人影响，并且在某个应用程序被破坏时避免访问到用户的数据。4.1 版将带来几个重要的增强功能，使得 Qubes OS 可以继续践行其座右铭："一个合理安全的操作系统"。

自从我们首次详细介绍 Qubes OS 3.2 以来，已经过去了将近五年的时间了，其实我们在 2010 年就第一次提到它之后还简单谈过几次。就像安全领域的其他许多事情一样，在使用 Qubes OS 时需要做出权衡，但它所提供的安全水平在其他方案中很难达到。此外，它使用了 Linux 和其他开源工具，这样用户就可以根据需要来检查和修改系统。

Moving the GUI out

Qubes OS 使用 Xen hypervisor 和一个不断增长的 qubes 集合来把各个部分隔离开来。运行 host 操作系统的 Xen Dom0 顶层域（top-level domain）是继 hypervisor 之后在系统中最具特权的部分。它为整个系统提供了管理接口，同时也作为所有 qubes 的 display manager。既然控制了 display manager，使得 Qubes OS 能够在强制在各个窗口边框上设置不同的颜色，来表明它们属于哪个 qube。Qubes OS 4.1 的主要特点之一是将 display 的处理分成了一个单独的 GUI domain。

把 GUI 分离出来是有多种原因的，其中主要的一个动机就是减少 Dom0 所承担的功能：

目前 Qubes 最大的安全问题之一就取决于 Dom0 中有多少能力。一旦有人可以控制 Dom0 了，那么就可以做任何事情了。虽然我们将它与各个应用程序 Qubes 内运行的东西隔离开了，但 dom0 仍然是一个比较大而臃肿、复杂的 domain，执行了许多不同的功能。它负责管理其他 domain、图形显示以及生成图形界面、管理许多设备（包括音频设备）、管理内存和磁盘，等等。

Qubes 操作系统已经有了一个 GUI 协议，是用来对图形处理进行隔离的。"除非是通过非常受限的 Qubes-GUI 协议，否则虚拟机中的应用程序不能与 dom0 中的 GUI toolkit 进行交互，应用程序 VM 中的 GUI toolkit 也不能直接与 dom0 的 X server 通讯。" 但是，这种机制要求 Dom0 需要直接把 qubes 的内存 map 进来从而取得其窗口的缓冲区 buffer，这一点有些令人担忧。把这个功能复制到另一个独立的 domain 中去，其实效果上是产生了两个 Dom0，从而增加了攻击面。

在 4.1 版本中，这个协议也已经被修改了，GUI 处理不再需要访问各个应用程序 qube 内存。它使用了 "一种抽象的机制，qube 必须明确地授权访问特定区域的内存 page"。已经实现了一个针对 Xen 的支持（使用 grant table 机制），但其他环境（例如 KVM）下也可以使用类似机制。

除了内存处理之外，现有的图形处理还依赖于 Dom0 能够控制任何 qubes 的能力。权限较低的 GUI domain 仍然需要这个能力，但是有了更多限制：

但是，如果我们想实现一个更加受限的、权限较小的 GUI domain，那么如果允许它在所有被管理的 qubes 中运行任意 qvm-run 来执行任意任务，那就违背了初衷了。Qubes 4.0 引入了一个特殊的 qubes.StartApp qrexec 服务，它只会运行已经在目标 qube 中指定好的应用程序（目前在 Linux 中通过 .desktop 文件来指定，在 Windows 中是通过 .lnk 文件定义，位于指定目录中）。这种机制允许 qube 明确定义 "GUI domain 在我之内可以执行什么功能"，而不是将所有权力都交给这个管理域。

这个新的 GUI domain 是 Qubes OS 4.1 的一个实验性功能。正如介绍该功能的详细文章中的 future plan 部分所指出的那样，它会使系统进一步朝着 2010 年初版 Qubes 架构规范中所规定的方向来发展。

Qrexec

Qubes OS 4.1 的另一大新功能就是对 qrexec 设施及其 policy 处理相关的改进。Qrexec 为 qube 之间的 request 提供了一个远程过程调用（RPC）机制，但是，显然需要对可以进行哪些 request 来进行限制：

当然，如果总是允许所有的事情的发生，那会将是非常危险的。因此，qrexec 的一部分，即 "qrexec policy"，也被用来强制确保只有谁可以做什么、在哪里做。此外，我们希望能够跟踪审查（audit）这里所做的事情，qrexec 的 logging 功能就可以确保这一点。至于如何实现，这是由 qrexec 服务来控制的，这些服务是由 qrexec 来执行，在设计时同样也必须要按 secure 和 resilient （弹性的）的标准来设计。

那篇详细的博文描述了 qrexec 在 4.1 版本中进行的几个方面的升级，首先是介绍了 policy format 的变动。Qubes OS 4.0 的 policy format （也继续保持了支持）会根据目标 service 来把 policy 分割开来，形成几十个独立的文件。

采用了这个新格式之后，可以更容易找全单个 qube 的所有 policy，进行解析以及编辑。[……] 例如，现在可以很容易禁止对某个特定 qube 的所有调用，或在禁止时加上一些例外条件。这使得 policy 制定的时候会更加以 qube 为中心，虽然结果在理论上是一样的，但是在一个 [地方] 的几条规则和分布在几十个文件的几十条规则之间有很大的区别。

此外，策略系统被设计为 "fail closed" 的行为模式。policy 文件中的任何语法错误或其他问题都会导致 qube 不会授予任何权限。这与 sudo 等其他那些以 security 为重点的工具的行为类似。

在这个版本中，qrexec 的性能也得到了大幅提升。数据现在是以更大的 block 来传输（也就是 64KB，而不是 4KB 了 ），这有助于加快大块数据的传输速度。此外，还有一个新的 policy daemon，而不是为每个 qrexec 请求都启动和加载一个进程来处理 policy。这减少了初始化时间，这对于重复调用很重要。

Reproducibility

为了确保一个特定的二进制文件是由它所声称的源代码所创建的，就需要有一种方法来可靠地从源代码中重新生成一个二进制文件。这就是 "Reproducible Builds project" 项目存在意义。Qubes 项目一直在努力将 reproducible build 纳入其持续集成（CI）基础设施。

具体来说，目前的目标是能够完全通过可重复构建的软件包来构建 Qubes OS Debian templates。Qubes OS 中的 template 一些 VM image，是可以用来快速启动应用程序 qube。qube 对于 template 中的 root 文件系统有 read-only 访问权限，因此同一个 root 文件系统可以与多个应用程序 qube 公用。Fedora 和 Debian 的几个变种都有官方正式 template，其他几个发行版也有一些由社区维护的 template。

一直以来，Debian 都处于 reproducible build 工作的前沿，所以 Qubes OS 将其当前的 reproducible build 工作集中在 Debian 上，也就不足为奇了。但是，Qubes 在从 snapshot.debian.org 服务中获取旧版本的 Debian 软件包时遇到了一些问题，众所周知，这项服务有一些限制，使得它在这方面并不完全可靠。于是该项目建立了自己的 snapshot 服务，并使用它重新构建了 Debian 软件包。

截至 10 月初，80% 的 Debian unstable 软件仓库的内容已经被成功重建出来了。这个过程也再次开始针对 Debian 11（"bullseye"）软件库来启动了，该软件库仍有 "几千个软件包需要重新生成"。等完成之后，unstable 的重新构建工作就会完成了。这一切都是在 Frédéric Pierret 家中的几个服务器上完成的。

下一个目标是让 Debian template 要拒绝安装所有无法被验证通过是来自其所声称的源代码的软件包。还有一项工作是将 Fedora 加入到这个组合中。值得注意的是，Reproducible Builds project 正在使用 Qubes OS 所报告的结果来作为 "它多年来一直倡导的一个榜样"。

And more

当然，这个版本中还有其他的一些功能，以及我们在上面提到的内容的许多针对性的细节。release note 中有一个很长的新功能列表，是一个到该项目的 GitHub 仓库中关于该版本的已经 close 的问题列表。正如人们都可以预料到的，4.1 版本也有一长串的 bug fix。

Qubes 操作系统的上一个主要版本就是 4.0，是在 2018 年发布的。半年之后，项目创始人 Joanna Rutkowska 从她的领导岗位上卸任，去从事其他项目了。这种变化通常都是会对项目带来很大破坏的，但该项目看起来已经走出了困境。在这段时间里，已经有了几个小的版本发布（最近的一个是 3 月份的 Qubes OS 4.0.4）以及持续不断的用来以解决 Qubes 的安全公告问题的更新。

根据这个公告，第二个 RC 版本将在 "几周到几个月内" 出现，这取决于发现的 bug 的数量和严重程度。如果我们以 4.0 版本情况为参考的话，可以预期在最终发布 4.1 版本之前的 8 个月内会有 5 个 RC 版本。当然，如果有更多的 test 和 fix 就可能会加快整个过程，但目前看来明年春末或者夏初（北半球）的时候，应该会有一个最终版本发布。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～