LWN：Fedora中完整性检验的又一个方案！
关注了就能看到更多这么棒的文章哦～
Another Fedora integrity-management proposal
By Jake Edge
January 4, 2022
DeepL assisted translation
https://lwn.net/Articles/880263/
在过去一年多里，Fedora 发行版中的文件完整性管理（File-integrity management）是许多不同功能的提案的主要主题。总体来说，这些提案都受到了挑战，人们怀疑这些功能是否是符合 Fedora 的目标的，以及今后它们会如何改变 RPM 包的构建过程。同样，最近一个允许系统进行（可选的）远程验证（remote attestation）的新提案也同样遇到了阻力。在这次的讨论中提出了几个跟之前不同的问题。
Background
按照提出新功能提案的一贯做法，Fedora 项目经理 Ben Cotton 代表功能负责人 Roberto Sassu 将其发布到 Fedora 开发邮件列表。这个修改建议在 Fedora wiki 上也有一份。此项新功能将会使用 Digest Lists Integrity Module (DIGLIM) 功能（Sassu 创建的对内核的完整性测量架构(IMA)的一个补充）。IMA 需要负责确保文件内容和元数据不发生意外变化是 IMA 的工作，而 DIGLIM 是对 IMA 的一个优化。
IMA 有许多不同功能，但其核心是维护管理文件内容以及 metadata 的 "摘要（digest）"；这些摘要都是加密哈希值，可以用来可靠地检测出文件是否发生了变动。IMA 还可以使用摘要来与系统的可信平台模块（TPM，Trusted Platform Module）配合计算出一个数值，从而证明系统正在运行的系统确定都是已知版本的软件。这个值可以用来确保系统已被安全启动，也可被发送到其他地方用来远程确定系统的状态。
在 IMA 保护之下的每个文件都需要把它的摘要数值跟文件存储在一起，这通常是利用了文件系统中的扩展属性（extended attributes）来完成的。IMA 可以配置成在访问每个文件之前都先检查它的摘要是否仍然与之前存下来的值相匹配。如果不在匹配了就马上拒绝访问。在文件被评估的时候，它们的摘要可以被提交给 TPM 来扩展一个 Platform Configuration Register（PCR），得出的最终数值可以跟此时被测量的文件数据有关，但它同时也会根据访问顺序不同而受到影响。
根据 DIGLIM 的提议（其中包括 Fedora 的 patch 以及 kernel 的 patch），在这个检查期间会由于并行执行而导致 TPM 提供出不同的结果。也就是说，哪怕用了相同的代码也可能会给出不同的结果。DIGLIM 提供了一种机制来获取所有安装上来文件的摘要值，然后用它来计算最终的 attestation value。只会用那些尚未被包括在整个 "installation digest" 中的文件才会被用来进一步扩展 TPM 中的 PCR。
它的实现，是通过提供一种机制将已安装文件的摘要值注册到内核的 "摘要列表（digest list）"中，然后就可以在访问文件时查阅该列表了。当一个文件的摘要出现在了列表中，那么可以认为此文件是没有改动过的，它的摘要值也不会被提交给 TPM；否则的话就说明该文件已经被修改、或者根本没有包括在摘要列表中，所以访问可能会被拒绝，文件的摘要也就会被添加到 attestation value 中。后者很可能意味着系统的认证就失败了。
人们可能会认为，给系统上所安装的所有文件都添加摘要，会耗费很多内存，但事实证明，这个操作的影响非常小。"Fedora 33 的一个按照最小安装方式的系统中，可执行文件和共享库的摘要库占用了不到 800k 的内存。"
比起为每个文件都计算摘要值，DIGLIM for Fedora 方案会使用那些已经计算出来并存储在 RPM 头文件中的值来安装软件包。这些值都是用 Fedora release 的 GPG 密钥签名过的，所以它们可以被信任。内核需要能够验证 GPG 签名，这也是 DIGLIM 内核功能的一部分。Fedora release 的 GPG 公钥可以被添加到内核钥匙圈（keyring）从而用来进行验证。RPM header 数据将在启动过程中很早起的时候就被用来进行处理。"会有一个运行在用户空间的解析器，在系统启动早期阶段由内核发起执行，用来解析 initial ram disk 的/etc/diglim（由一个定制过的 dracut 脚本来包含进来的）中所找到的 RPM header，并将它们上传给内核。"
在某种程度上来说，DIGLIM 的目标还是为系统提供一种处理完整性管理的方法，这样就不再需要发行版提供商来密切参与这一过程。对于需要 remote attestation （远程验证）的系统来说，就可以有办法实现这个功能，而不需要 Fedora（或任何其他发行版）来直接管理这个过程。DIGLIM 也可以用来检测出对已安装文件的篡改，就像 IMA 一样，但是根据 kernel patch 中的描述，它完成这个功能的时候性能比起标准的 IMA 机制更加好。
这里会需要维护一个相当长的 kernel 先决条件清单，"从而有可能让它们被上游内核所接受"。事实上，正如邮件讨论中可以看出，除非这些 patch 能够进入 upstream，否则 Fedora 不太可能采用这个方案。这里有一些额外的工作需要在 Fedora 中完成，从而能在那些希望启用此功能的系统中正确处理 RPM header，这也是该提案中的另外一半的工作。
Reaction
因为该功能是可选的，并且使用场景相当局限，这就意味着它对绝大多数 Fedora 用户基本没有影响。这也意味着它对这些用户是没有多少作用的，甚至可以说是毫无用处的。一些有顾虑、或者提出了反对意见的人似乎误解了一点，那就是它只能由用户来选择，而不是由发行方决定。例如，Kevin Kofler 说。"[……]我不明白这个改动所实现的'功能'具体提供了什么不违背自由软件定义的价值。" 他担心会无法安装由第三方或用户自己 build 出来的软件。
但是，正如 Mattia Verga 所说，这个方案的意图完全不是这样："它并不拒绝用户安装任何他们想要的软件，它是为了防止那些不需要的、不请自来的、恶意的软件在未经用户（管理员）批准的情况下就被安装进来。" 然而，Kofler 担心这样做会慢慢变成 iOS 式的软件来源集中控制的情况，这显然与自由软件的理想是相悖的。但似乎很少有人赞同这种想法。Michel Alexandre Salim 看到的是与 Fedora 的目标更加一致：
如果有这样的东西被发布和提供的话，我希望 Fedora 能对自己设个规定，就像是 SELinux 的 "targeted" policy 一样：保护 Fedora 提供的 RPM 不被篡改，并可以让用户在此基础上做任何事情。有一个选项可以完全关闭它，或者更严格地执行。
事实上，Sassu 说他在 DIGLIM 上的工作已经提供了一个如何处理第三方代码的例子：
我自己正在使用一个 COPR[Cool Other Package Repo]仓库来构建带有 DIGLIM patch 的 kernel package。该 kernel 里还包括了由 COPR 为我生成的我个人的 GPG 密钥。
尽管还没有决定下来，但很可能 Fedora 内核会要包含 Fedora 的官方密钥，而用户自己将可以添加新的密钥（包括来自 COPR 的密钥）。
在一个比较长的回复之中，Sassu 试图减轻对该功能的一些担忧和恐惧。"[……]它的主要目标是帮助用户满足他们的安全需求，并让他们自己决定要如何做"。他指出，该功能已经在基于 Fedora 的 openEuler 发行版中得到了产品化使用（already in production use），但他也认识到很有必要能让该功能进入 upstream。Neal Gompa 同意 Fedora 通常 "不在其 Linux 内核 build 中包括那些不是来自 upstream 的功能"，但也指出 DIGLIM 可能会是有用的：
我也同意这个功能不太可能影响到人们，因为这个功能在默认情况下不会被启用。它对于构建基于 Fedora 的设备的人来说会非常有用，这些设备由于各种原因需要防止篡改。而 Fedora 的衍生产品（如 RHEL/CentOS、Amazon Linux、openEuler 等）也可以从我们集成进来的这个功能中受益，即使我们并没有默认启用此功能。
DRM
显然，TPM 和远程验证（remote attestation）可以用在各种数字版权管理（DRM）。DRM 在某种程度上被人们称为 digital restrictions management。Nico Kadel-Garcia 确信，该功能 "除了数字版权管理外没有任何用途"。但 Sassu 指出其实是有其他用途的：
如果你想强制执行 IMA measurement policy，那么每次对文件的访问都会被允许，无论 hash list 有签名与否。在这种情况下，IMA 将会直接记录这些未知文件的执行情况，而不光是记录你生成的摘要列表。
IMA measurement list 仍然会保存在你的系统中，除非你决定你的系统需要由一个远程验证方来进行远程验证。
Kadel-Garcia 坚称这都是给 DRM 用的，但 Gompa 试图进一步澄清：
IMA/verity 和 DRM 的区别在于，前者是在系统所有者的控制之下（在这种情况下，是 你 来控制），而后者则不是。
[……]如果用户能控制这种能力，会有非常重要的好处。而且，这一切都不是默认开启的，而是由 你 来自己决定开启的。
Implementation questions
Zbigniew Jędrzejewski-Szmek 对该功能及其实现有一些疑问。具体来说，有人质疑是否需要一个由内核来运行的用户空间解析器，但 Sassu 说，这个解析器需要在 init 进程之前运行从而能对 init（及其所有的依赖文件）也利用摘要列表来进行完整性检查。这是一个鸡生蛋蛋生鸡的问题，这也从而导致 Sassu 需要确保这个 helper 程序是静态链接的，这样在用它添加所有其他的摘要之前，只需要添加这一个文件的摘要就好了。
Lennart Poettering 认为，摘要信息应该简单地提取到一个特殊的 initrd 中，然后传递给内核。这就会避免把摘要 "上传" 到内核的做法，但是，正如 Sassu 指出的，这就会把内核与特定的摘要列表格式绑定起来。Sassu 说，这个功能的最初版本差不多就是这样实现的：解析器在内核中，它从 RPM 头文件中读取信息，但每当有新的格式需要支持时（例如 Debian deb 文件），内核就必须进行改动。
Poettering 也对静态链接的这个 helper 程序感到不太满意（他说 "static linking is a mess."），但 Sassu 解释说这样可以更容易来启动完整性检查：
我认为这种方法是可以自成一体的：启动 DIGLIM 所需的一切都包含在 kernel-tools-diglim 这个 package 中。在动态链接的情况下，你就还需要处理好所有的共享库。由于解析器尚未发挥作用（内核还处于 enforcing mode），这样就需要为每个希望加载的共享库都生成一个本地格式（在 spec 文件中）的摘要列表。
我喜欢这个事实：只要你有了修改过的内核和恰当的 GPG 密钥，以及 kernel-tools-diglim，你就能够运行 IMA appraisal（评估），而不需要为对其进行管理而做更多的工作。
在 1 月 3 日的 Fedora 工程指导委员会（FESCo）会议上有提出一个问题，就是 DIGLIM 功能跟最近讨论的 fs-verity 提案之间的关系。Sassu 说，主要区别在于 DIGLIM 是可以直接用现有的 RPM 包及其格式就可以工作了，而 fs-verity 的支持则需要在 RPM header 中为每个文件都增加额外信息：
DIGLIM 采用了 RPM 的现有方案，用一个签名来验证 RPM 中所包含的全部文件。由于这种数据格式不适合在 Linux 内核中使用，因此为了确保 integrity policy，DIGLIM 会提取摘要并将它们添加到存储在内核内存中的哈希表中。Enforcement（这里如果说是 security decision 会更加恰当）是通过在哈希表中进行查找来实现的。
主要的优点是，DIGLIM 不需要对现有的 RPM 做任何改变就可以实现目标，提供出参考值。
RPM 的开发者 Panu Matilainen 很喜欢这个方案：
除了不再需要为每个文件增加数据从而使 RPM 变得臃肿之外，这也回避了与 IMA 和 fs-verity 相关的一些其他问题：那两个方案都需要一个额外的签名步骤来提供文件签名，这也是一个不可忽略的开销以及复杂工作，这个方案跟他们不同，文件的哈希值也已经用正常的 rpm 级别的签名就可以覆盖了（从而受到保护）。
很明显，DIGLIM 功能不会被 Fedora 采用，除非 DIGLIM 本身被合并到 mainline kernel 中。甚至也许到那时也不会被 Fedora 采用。对 locked-down system 以及 DRM 的担忧在某种程度上确实是合理的，但这根本不是 DIGLIM 的目标。另一方面，尽管它看起来是一个小众功能，但它对大多数 Fedora 用户的影响是可以忽略不计的，这有点像一把双刃剑。它不会影响大多数用户，因为它也不会帮助到他们，以及他们的使用场景。
但是有一些使用场景确实会受益，而 Fedora 中完整性管理（integrity management）的其他竞争方案似乎都更加复杂。DIGLIM 和 fs-verity 都在 FESCo 的关注之中，所以我们应该很快可以知道结果。鉴于 fs-verity 方案的侵扰性（intrusiveness），以及 DIGLIM 在 mainline 中的未来命运尚不明确，我们可以基本确定这两个方案都会至少被推迟到 Fedora 37 的时候。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～