为什么 Linux 允许“init=/bin/bash”?

为什么 Linux 允许“init=/bin/bash”?

我最近发现,如果我在启动之前编辑 GRUB 并添加,rw init=/bin/bash我最终会得到一个 root shell。

处于一种我想了解一切的状态,我想知道为什么会发生这种情况。我的意思是这是一个错误吗?这是一个功能吗?它是否可以帮助管理员解决问题,因为它只有在您可以物理访问计算机时才有效?

它是由 GRUB 还是实际内核提供的?

答案1

这是一项功能,用于系统维护:它允许系统管理员从混乱的初始化文件中恢复系统或更改忘记的密码。

红帽邮件列表中的这篇文章解释了一些事情:

在类 Unix 系统中,init 是第一个运行的进程,也是所有运行的进程的最终祖先。它负责运行所有初始化脚本。

您告诉 Linux 内核将 /bin/bash 作为 init 运行,而不是系统 init。 [...]

因此,您没有利用任何东西,您只是使用标准内核功能。

此外,如评论中所述,该rw标志与 分开init=,它只是告诉系统将根文件系统挂载为读写(因此您可以编辑错误配置的文件或更改密码)。

答案2

您的系统具有运行和调试机制(如 init 参数),并且可能具有安全机制来阻止不需要的用户利用它们。这些是功能,而不是错误。

引导加载程序负责启动操作系统。操作系统安全显然在此时不适用。您可以加载不同的内核、initrd、root fs 或设置不同的选项(如 init 路径)。如果您想阻止用户这样做,则必须在引导加载程序中完成。

您的系统(可能是 PC,即 BIOS)会加载引导加载程序,因此显然引导加载程序安全性不适用于它。如果您想阻止用户从 USB 等方式启动 BIOS,您需要在该级别上执行此操作。

您的系统可能位于桌子上的某个地方。如果您想阻止用户打开计算机并将硬盘切换为自己的硬盘或移除驱动器以将其安装到他们的计算机中,您需要在物理级别上执行此操作。但这并不能阻止他们拿起整张桌子并开着他们的逃亡车离开......

安全就是这样。大象一路下来。

答案3

这就是内核的设计方式。必须有某物在计算机启动时运行,虽然有默认值,但内核命令行允许您更改该默认值。

通常它运行一个名为“init”的程序,通常可以在/bin/init或 处找到/sbin/init。该程序负责所有系统启动并创建可用环境。

指定init=/bin/bash告诉内核运行/bin/bash(这是一个 shell)。指定rw告诉内核以读写模式而不是只读模式引导硬盘。传统上,内核以只读模式启动磁盘,然后在切换到读写模式之前检查磁盘的完整性。

答案4

init=可以采取任何可执行文件

init=可以接受任何可执行文件,包括外壳脚本。根本原因很可能是execsyscall 可以直接处理 ELF 可执行文件和 shebangs

例如,我在这里演示如何创建任意最小的 C 编译init如何创建一个只运行一个程序而不运行其他程序的自定义 Linux 发行版?

那么为什么会这样不是Accept /bin/bash,最重要的是,它只是一个常规的可执行文件,实际上有用吗? :-)

init接下来,您还应该尝试了解与您的常规系统(例如 systemd 或 Busybox)之间的权衡是什么?

基本上,使用 raw /bin/bash,您:

作业控制可以在 Busybox 的 init 和其他类似的 init 上恢复,并带有-以下开头inittab

tty3::respawn:-/bin/sh

更正常的inittab条目,使用登录并在您执行 Ctrl+D 时保持生成 shell 是:

::respawn:/sbin/getty -L ttyS0 0 vt100

它使用getty可执行文件,但 TODO:如果没有 Busybox ,我自己无法生成这些文件initgetty 从命令行启动?

您可以使用这个设置尝试一下并得出上述结论。

相关内容