LWN：禁用root帐号，跟rescue模式有冲突！

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

Locked root and rescue mode

By Jake Edge
December 22, 2021
DeepL assisted translation
https://lwn.net/Articles/879272/

Fedora 是诸多 Linux 发行版中的一员。默认情况下它锁定了 root 账户，不给它密码也不让人用它登录。但是，Linux 传统上来说，有一个 "rescue mode （救援模式）" 会将系统启动到单用户模式，这就需要一个 root 密码了。像 Fedora 这种完全没有 root 密码的系统，这种情况当然无法提供出来了。Fedora 提议在这种情况下去掉要求输入密码的步骤，而直接进入 root shell。虽然这个建议估计不会成功，但它似乎已经引出了一些更好的根本解决这个问题的方法。

针对 Fedora 36 提出的一个提案是 "使救援模式在 locked root 下也能使用"，这是由 Fedora 项目经理 Ben Cotton 在 12 月 6 日代表此功能的负责人（Michel Alexandre Salim, Neal Gompa, 和 David Duncan ）来发布的。问题是，如果用户需要通过 single-user mode 来修复他们的系统，那么对于 root 账户被锁定的系统来说，"当前这种缺省用户体验"是很差的，他们会被提示要提供一个他们根本无法提供出来的密码，不得不求助于其他方式来启动这个出了问题的系统（比如使用光盘等其他启动方式）。另一个选择是用内核的 cmdline 选项（比如加上 "init=/sysroot/bin/bash"）来启动，但这对用户来说也不是特别方便。

这个改动的核心是如果发现 root 密码无法访问或者 root 登录被禁用的话，就使用 sulogin 的 –force 选项，从而进入 single-user mode 时跳过密码输入的步骤。但是，正如 man 手册里面所说，这个选项应该只在 "你确信 console 在物理上受到保护，不会被非法访问到" 的情况下才可以使用。该提案认为，这一改动 "不会带来更多的安全风险"，因为攻击者已经有了其他的绕过密码需求的手段（例如上面说的 init=），或者如果他们能直接触碰到这台机器，完全就可以破坏系统了。那些想为 single-user mode 强制要求使用密码的人，直接设置一个 root 密码就好了。

这个实现是基于 Fedora CoreOS 中的一个类似功能（patch 在 https://github.com/coreos/fedora-coreos-config/commit/eb74f2ea3e9b453902315539e4f327481162c4f8 ）。默认情况下，Fedora 36 会安装一个 RPM 来改变 systemd 的配置，从而绕过密码需求。不想要采用这种策略的用户或 Fedora 变种则可以删除该 RPM 或者干脆不安装。

正如大家可以猜到的，这里所下的没有增加风险的结论引出了不同意见。Zbigniew Jędrzejewski-Szmek 说，至少有两种情况中，哪怕拥有物理访问权也不一定有能力破坏该系统：

如果数据是加密的，那么在解密之前，就算设置 init 也并不能达到攻击目的。第二种情况是管理员锁定了 kernel 的 cmdline 参数，而依靠正常的认证机制来保护系统。在这两种情况下，你的建议在系统已经运行起来之后配置好系统完整性检查来保护未加密的数据的情况下，创建了一种新的攻击路径。采用这个提案之后，任何可能会导致系统进入紧急模式的机制都会变成一个可能的攻击途径。

他说，正在解决的这个问题确实存在，但这个解决方案并不理想：

从本质上讲，你提出的行为是这么一个情况："这里有问题有问题，所以让我们在没有认证的情况下就把一切都放开吧"，这对调试和开发场景来说是好的建议，但对一个真正的生产系统来说，是不能接受的。

正确的解决方案是加强登录机制，以便在救援模式下也能使用现有的密码来进行认证。现在不可能做到这一点，这是一个需要修复的 bug。

他对未来的解决方法提出了一些建议，包括可能会将密码 hash（使用更强大的 yescrypt hashing algorithm）添加到 initial ramdisk（initrd）或启动时可访问到的其他地方（例如 EFI variable 等）。此外，可信任平台模块（TPM，Trusted Platform Module）也可以用起来，采用系统特定的方式对密码进行加密。

Richard W.M.Jones 提问说这个 threat model 以及跳过密码在现实中会造成什么问题："从另一个角度看，我确实就遇到了所描述的问题，这个问题非常让人反感——它使得 rescue 模式在默认情况下就毫无用处了。" Jędrzejewski-Szmek 承认这个问题是 "让人不爽的真实存在的问题"，但他指出，这个建议违反了我们管理系统访问权限的基本原则：

系统的安装有很多很多种各不相同的方式，但一般的原则是，[一旦]系统启动了，你就需要有效的密码才能登录。因此，在系统运行起来之前对系统的保护也就是在保护静止的数据，这可以通过许多不同的方式进行，并且是你的责任，而在系统运行起来之后，你知道正常的系统机制会起效果。在这个提案中就打破了这个承诺。

他举的一个例子是一个 kiosk-installed system （安装在信息亭等位置的系统），这种情况下的用户都可以使用到键盘，"如果你能影响系统，使其不能正常启动，仅仅也许是创造一个足够长的 delay 就行，就足以获得不受限制的访问权限了。"

Vit Ondruch 询问说是否有什么现在正在进行的工作就是针对这里所说的解决方案的。Jędrzejewski-Szmek 说，最近版本的 systemd 已经支持了一些底层机制（也就是 encrypted-secret 存储功能），但仍然缺少上层机制的实现：

但我们还缺少上层的部分，也就是如何去实际使用以及更新密码。我甚至没有提到这个，因为我们还没有针对一个完整的流程。我认为有必要从头开始写一些 pam module 以及 authentication helper。

Lennart Poettering 说，Fedora（和其他 Unix 系统）上的 "wheel" group 就是用来包含所有带有管理权限的用户的，所以应该可以使用该组中任意一个用户的密码就可以了。他也赞同确实有不少工作要做，比如收集这些密码、用 TPM 加密，并将其存储在启动时可以到访问的地方，这一切还有很多工作要做，但其最终得到的好处将远远不局限于仅仅启动到 single-user mode：

有了这样的机制，我们就有了很好的语义：如果一个用户被指定为拥有管理权限，那么就足以让他拥有能够登录到 root 账户的能力，不需要再手工进行一些配置了，而且它会对整个操作系统运行期间都有效：从 initrd 到常规系统，再到 sudo 场景，都可以生效。

Chris Murphy 不太希望将解决方案与 TPM 联系起来，因为有些系统没有这个设备，或者某些内核不包含对其的支持。Poettering 说，默认使用 TPM 是合理的做法，哪怕我们确实需要 "为条件不具备的那些环境使用更合理的后备方案"。

但 Chris Adams 更加喜欢最初的提议。管理员如果想进一步确保他们的系统是 lock 的状态，可以很简单地删除 RPM 或设置一个 root 密码就可以了。"对系统的缺省配置要进一步设置 lock down 功能的话，需要修改好几处地方，所以我不认为把这个步骤加进来有什么问题"。Jędrzejewski-Szmek 认为这是一种退步：

我也不认为我们应该假设管理员会做一系列的 "加固步骤（hardening steps）"。这就是我们在 90 年代的情况：你会安装一个原始发行版，然后按照一些基本步骤进行逐项检查，让系统事情变得更安全。我们还是别再回到那个时代的做法了。

Murphy 也有些担心 Fedora CoreOS 的改动方案。如果跳过密码检查的想法是不合理的，那么 "是否应该把 CoreOS 中的改动 revert 掉？" Jędrzejewski-Szmek 说，这会使得 CoreOS image 不再适合通用场景："也许在一部分情况下是可以这么做的，也就是只有当你是 host 上的管理员时才有可能进行 '物理'访问的环境下。"

虽然功能负责人并没有过多地参与讨论，但 Salid 显然在跟踪这些讨论。他说，他倾向于不急于为 Fedora 36 提供完整的解决方案，而是将其推迟到 Fedora 37。他也认为关于 CoreOS 应该做些什么这是一个好问题。除此之外，使用 wheel group 来限定哪些密码是有效的，以及是否需要让该功依赖 TPM，这些问题都需要逐步确定。

他还在思考是否可以用一些 recovery password，这个问题在讨论中中也被提出来，作为需要让安装在另一个系统（也就是会有一个不同的 TPM）的磁盘也能工作的手段。这个问题被认为是另一个独立的问题了。此外，Björn Persson 认为 recovery password 其实更适合于那些使用了其他认证机制（如硬件令牌）的情况，而且可能会丢失或被破坏：

只要用户通常使用自己的 passphrase 来登录，那么我认为没有必要为救援模式设置另一个专门的口令。Root 或 wheel 用户的常用口令应该都是可以的。

为了解决 Fedora 36 的燃眉之急，Salim 建议说如果没有设置 root 密码的话就把救援模式从启动选项中移除。此外，如果有人试图在这种情况下用 cmdline 来进入救援模式的话，"应该显示一个错误，而不是提示要求输入一个根本就不存在的密码"。Persson 认为这些听起来都很合理。Fedora 工程指导委员会原定在 12 月 20 日的会议上讨论这个提案，但由于没有达到法定人数而取消了，估计会在 1 月 3 日这个下一次会议上重新安排。

总的来说，使用 wheel group 密码的想法似乎获得了相当多的支持，另一个得到较多赞同的意见是不要创建新的能够不用认证就获取 root 权限。我们的系统已经足够复杂了，而且是采用了许多不同的方式和运行环境，如果开放了新的不经认证就获取 root 的做法的话总是会引起一些人的异议。但另一方面，如果提示要求输入用户根本无法提供的密码，肯定会让人不爽，而此时用户可能本来就已经在担心他们自己系统还是不是能恢复正常运行的状态，不应该再让他们为其他事情头痛了。为这个问题提供更好的解决方案的方式似乎相当清晰，如果幸运的话，我们会在 2022 年底的 Fedora 37 中看到它。

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

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

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