LWN：阻止root用户破坏已mount的文件系统！
关注了就能看到更多这么棒的文章哦～
Defending mounted filesystems from the root user
By Jonathan Corbet
August 21, 2023
ChatGPT assisted translation
https://lwn.net/Articles/941764/
让文件系统在面对恶意创建的文件系统映像（filesystem images）时也能足够可靠（robust）是一项很有挑战性的任务，即使在文件系统的实现一直在积极维护时，许多文件系统也未能达到这一目标。然而，有一种方法可以使这项任务变得更加困难：在文件系统映像被挂载时还继续偷偷修改这个文件系统映像。最近在 linux-fsdevel 邮件列表上的讨论就揭示了是否以及如何应对这种攻击的持续争论。
Gabriel Krisman Bertazi 最近发布了一组补丁，为不区分大小写的 ext4 和 F2FS 文件系统添加了 negative dentry 的支持。negative dentry 会把对不存在的文件进行查找的结果也缓存下来，加速后续的查找动作。由于这种操作经常发生（例如在通过 PATH 环境变量来查找可执行文件时），因此这是一个重要优化。然而，目前，negative dentry 在不区分大小写的文件系统上无法生效；这组补丁就纠正了这个问题。
在对这个系列的 review 讨论中，Eric Biggers 希望增加一个明确检查来查看 inode 是否设置了不区分大小写的 flag，哪怕文件系统尚未被 mount 为不区分大小写的模式。这个检查是由 Ted Ts'o 于 2019 年添加的，以修复在对文件系统进行 fuzz 测试时遇到的 crash 问题。Biggers 想知道为什么这个检查放在了 inode 首次从磁盘读取时而不是在使用该 inode 的地方。
Ts'o 回答说，在某些情况下，inode 在被读入内存后可以发生变化：
在 ext4_iget 中检查是不够的，因为在 inode 被获取后但在尝试使用之前，casefold 这个 flag 可以被修改成 1，这是有可能发生的，比如 syzbot 已经打开了块设备进行写操作，并且在 mount 时编辑了 superblock。
也许有人会认为在文件系统实现代码意识不到的情况下对已 mount 的文件系统是那种 "不应该这么做" 的情况之一。这个操作通常会导致问题。然而，关于应该如何处理这种情况，还是存在分歧。Ts'o 继续说道：
有人可以说，这是一个疯狂的威胁模型，但 syzbot 团队认为这可以用来打破 UEFI 安全启动后的内核锁定。这没问题，只是我认为我没有能够让任何公司（包括 Google）支付人员来解决这类问题，而且这类 syzbot 报告的不断涌现已经导致一个主要的文件系统开发人员筋疲力尽并辞职。
Biggers 回应说，去解决以这种方式引起的问题，本身就不是一个正确的处理方式：
嗯，内核社区可以做的一件事是确定大量的 bug 报告是否由单一问题引起（"用户空间能写入已挂载的块设备"），并针对该基本问题采取措施，而不是尝试 "修复" 大量独立的 "错误 "。
他指出，Jan Kara 已经发布了一系列补丁，通过添加 config 选项来禁止写入当前已挂载的块设备，从而解决这个问题。只要合入这组补丁，并正确地对内核进行 config, 就可以直接关闭掉这整个攻击途径，并且，Biggers 说，将让大量的 syzbot 报告的 bug 消失。
然而，这种方法也存在一些小问题。其中一个问题是，正如 Kara 在 patch cover letter 中所描述的，启用此选项会破坏内核和用户空间中的许多功能，包括 Btrfs mount、loopback mount 和文件系统 size 调整功能。解决这些问题似乎并不是非常困难的，但在这些问题被 fix 并引入到已部署的系统之前，不可以在内核中简单地启用这个选项。这可能是一个需要数年时间的过程。
即使那时这组补丁会阻止对已 mount 分区的写入，但不会阻止对整个设备的写入。并且正如 Ts'o 指出的，还存在其他可能的攻击，例如打开 SCSI-generic 设备并直接向存储设备发送命令。似乎，对于具有足够特权的帐户来说，总是有其他方式来制造混乱。
另一个问题是，根据 Ts'o 的说法，syzbot 开发人员不愿意打开这个配置选项，除非把这个配置选项缺省打开并且只有在一个新增的 CONFIG_INSECURE 选项里面才能关闭（从而宣布这样做将使系统不安全）。Ts'o 反对这种立场，因为这是基于一个我们还没有完全同意是否合理的威胁模型（threat model）的。
因此，即使 Kara 的这组 patch 被应用到内核中，它只是一个部分（尽管值得的）fix，不能在几年内在已部署的系统中启用，而且运行 fuzz 测试的人不会启用它。文件系统开发人员将要时不时得去 fix 问题的表现，也要应对大量的模糊测试报告，并质疑这些报告是否合理。可以说，这对所有相关方来说都不是一个希望面对的局面。
或许，实际问题在于内核社区内部没有就内核应该尝试解决的威胁达成共识。一个威胁模型（包括保卫系统免受其自身的 root 用户的攻击）会需要大量的加固（hardening）工作，许多开发人员认为这既不可能，也毫无意义，而且无论如何，这种工作缺乏所需的资金支持，很难成功。社区中推动这一威胁模型的少数人就因此与其他人发生了争论。解决这一分歧可能会是这个话题中最难处理的问题。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～