Kra*_*out 9 boot bios unmounting systemd uefi
对于我即将实施的一些高度安全的堡垒虚拟机，我正在考虑/boot在启动后卸载 - 当然还有其他措施。仅用于更新内核时安装。
/boot重新启动后在 systemd 系统上卸载的正确方法是什么？为了测试我只是sudo umount /boot。efi分区呢？它/boot默认安装在内部，尽管我认为/efi可以使用（我还没有尝试过）来将它们分开并在管理员方面更透明地处理。启动后可以卸载/boot/efi吗/efi？没有副作用吗？Phi*_*ing 26
理论上，启动后/boot/两者都不/boot/efi常用。两者构成了 BIOS（或类似的）和操作系统之间的桥梁。它们通常不在运行时使用。
安装它们是为了让您可以重新配置启动，并让您的操作系统可以更新/升级其启动顺序。也就是说，在 Debian 上，apt/dpkg将触发对两者的更改。
除了 dpkg（或 Redhat 衍生产品上的 rpm）之外，任何东西都不太可能想要访问/boot文件树。
从安全角度来看，我会质疑卸载其中任何一个是否明智。它们对于除 root 之外的所有用户都应该是只读的。如果用户获得 root 访问权限，那么他们就可以安装它们。另一方面，阻止系统应用更新（包括安全补丁）可能会造成比您堵住的漏洞更多的漏洞。
相反，您是否考虑过使用等隔离堡垒访问chroot？Chroot 允许登录者仅访问子文件树和 pid 命名空间，而用户命名空间可以防止某些内容逃逸（chroot单独使用是不够的）。
最简单的方法可能是将 SSH 服务器替换为在容器内运行 openssh 的docker（或podman ）。这将使任何 SSH 客户端留在 Docker 容器内，而看不到主机系统。该容器内的文件系统可能非常小，例如alpine Linux 容器，除了最小的命令行之外几乎什么都没有。
请注意： chroot 不足以隔离进程。通过 root 访问权限，进程可以逃脱 chroot。然而，其他隔离（例如 pid 和用户命名空间以及删除功能）应该对保护 chroot 监狱内的进程起到很大作用……因此建议使用 docker。
MC6*_*020 16
副作用：我自己没有注意到。当然，除了在安装新内核之前必须确保安装它所带来的负担之外。（一定要确定，因为如果不是，安装将优雅地、静默地将内核安装在根目录的 /boot 目录\xe2\x80\xa6 中）
\n然而，安全性方面的好处是值得商榷的。
继续的正确方法（无论初始化系统是什么）几乎肯定是 \xe2\x80\xa6 不要将其安装在 boottime\xe2\x80\xa6 上，因为实际上从未需要它；-P
\n检查 fstab 中的相关条目并简单地添加一个noauto参数，这可能看起来像：LABEL=LTUX_BOOT /boot ext4 noauto,noatime 0 2
如果您确实想要安装它（以便稍后卸载），您可以受益于安装系统的x-systemd.idle-timeout功能。noauto,x-systemd.automount,x-systemd.idle-timeout=1s在 fstab 的 /boot 条目中添加类似的内容会在中间时间 1 秒后自动卸载其文件系统。
现在我想了一下，你是从堡垒虚拟机的具体角度来问这个问题的。这些通常是无状态的，安装的很少。
如果您非常担心黑客可能造成的损害，/boot那么大部分损害将在虚拟机重新启动时生效。
如果你想对此有一个极端的看法，你实际上可以完全破坏你的启动分区和启动后。毕竟它是一个虚拟机。要“重新启动”甚至应用安全更新，您只需启动一台新虚拟机并拆除旧虚拟机即可。那么黑客就“无法”干扰虚拟机的启动顺序。
正如我的其他答案中所述，除了应用安全更新之外，没有真正的理由保留/boot和安装。/boot/efi
\n\n测试了一下，似乎没有出现问题；它有我遗漏的副作用吗？
\n
不，不是真的，只是有些工具实际上可能需要安装它，而您可能没有想到（例如，GRUB在更新时需要安装它，而不仅仅是内核更新）。
\n\n\n该系统可能基于 Debian Linux（其他情况下，基于 Redhat）。两者都是系统化的。重新启动后在 systemd 系统上卸载 /boot 的正确方法是什么？为了进行测试，我只需 sudo umount /boot。
\n
正如其他地方所指出的，首先不要安装\xe2\x80\x99t。只需添加到其条目noauto中的选项即可。/etc/fstab
\n\n我正在犹豫是否要使用 BIOS 还是 UEFI。由于它们将是虚拟机，因此这是一个选择问题。UEFI 似乎是一个更明智、更现代的选择。但我不确定安全方面的好处（如果有的话）。相反，因为它更复杂，可能出现漏洞的可能性更大。
\n
如果您使用 UEFI，理论上您甚至可以避免需要引导加载程序，但在 Debian（以及除 Gentoo 之外的大多数其他 Linux 发行版）中做到这一点非常复杂。
\n安全启动通常也需要 UEFI，这听起来像是您可能想要的，尽管 \xe2\x80\x99 在虚拟机中很难正确使用。
\n除此之外，无论哪种方式，\xe2\x80\x99s 都没有多大好处，因为您无法审核任一情况下涉及的代码（这意味着您无法正确推断任一选项比另一个选项更安全）。
\n\n\n如果是UEFI，那么efi分区呢？它默认安装在 /boot 内，尽管我认为 /efi 可以使用（我没有尝试过），以将它们分开并在管理员方面更透明地处理。/boot/efi 或 /efi 是否可以在启动后卸载而不产生副作用？
\n
与 的评论相同/boot。虽然它可以安装在任何地方，但约定表明这/boot/efi是预期的安装点。
其原因有两个：
\n/boot./boot，因为它在大多数类 UNIX 系统上已经存在很长时间了。顺便说一句，相对于正确实施所涉及的总体难度而言，这实际上并没有显着提高安全性。
\n正常的保护方法/boot是确保除 root 用户之外的任何人都不能写入 xe2x80x99，或者如果您感觉特别偏执，除了 root 之外的任何人都无法读取或遍历。这种方法意味着 EUID 不为 0或CAP_DAC_OVERRIDE 功能的任何人都无法修改 下的任何内容/boot，但值得注意的是，不需要任何特殊处理即可使更新正常工作。
您的方法还意味着任何没有 EUID 0或CAP_DAC_OVERRIDE 功能的人（例如，具有此功能的人可以重写，/etc/fstab以便/boot在启动时安装，然后找到多种创造性方法中的任何一种来强制执行重新启动系统，或者作为另一个例子，可以直接写入底层块设备）不能修改 下的任何内容/boot，但只有当没有任何合法修改下的任何内容时/boot（因为需要/boot安装合法的修改）。它还需要特殊处理以确保内核更新、引导加载程序更新和一小部分其他类型的更新（例如第三方内核模块更新）正常工作。请注意，自动挂载在这里不起作用，因为如果您设置了自动挂载，那么有人只需尝试访问该目录即可挂载它。
请注意，您的方法没有针对专门的攻击者提供有效的保护，但使您更有可能意外地破坏某些内容（例如，在未安装的情况下运行更新）。
\n/boot通常由引导加载程序（通常由 GRUB）使用。在典型用法中，/boot将包含可能需要在内核更新时更新的任何引导加载程序配置文件，以及已安装内核版本的内核和 initramfs 文件。如果引导加载程序需要一些其他文件，也可以将它们放置在 中/boot。
由于引导加载程序需要在操作系统内核出现之前运行，因此它不能依赖“安装文件系统”等 Linux 内核概念。相反，当引导加载程序访问文件系统时，它必须使用固件支持（UEFI 系统上的 EFI 系统分区）或引导加载程序自己的文件系统驱动程序来执行此操作。此类引导加载程序级驱动程序通常经过简化，仅提供读取访问，不使用高级缓存或任何其他方法来提高性能，因为它们唯一的工作是加载引导操作系统内核所需的少数文件。
您通常无法将引导加载程序的文件系统驱动程序的状态转移到内核的控制中，并且由于内核通常具有更高性能的文件系统驱动程序，因此您甚至不想这样做。
一旦引导加载程序成功地将内核（对于 Linux，通常还有 initramfs 文件）加载到 RAM 内存并启动内核，文件系统的工作/boot就基本上完成了。Linux 内核和 initramfs 文件通常都不需要/boot文件系统之外的任何内容。/boot作为系统启动的一部分进行安装的唯一原因是为了在安装内核更新时可以随时使用它。
因此，/boot在绝大多数情况下，“启动后卸载”的最佳方法是简单地将其注释掉或为其/etc/fstab添加安装选项，即首先不在启动时安装它。noauto
似乎有一组标准目录可供在内核更新时运行的脚本：
/etc/kernel/preinst.d/安装新内核之前应运行的脚本/etc/kernel/postinst.d/安装新内核后应运行的脚本/etc/kernel/prerm.d/分别/etc/kernel/postrm.d/表示应在删除已安装内核之前和之后运行的脚本。这些目录中的脚本将按照文件名的通常 US-ASCII 排序顺序执行。如果您放置一个脚本/boot作为/etc/kernel/preinst.d/000-mountboot和进行挂载/etc/kernel/prerm.d/000-mountboot，并使用另一个脚本将其再次卸载为/etc/kernel/postinst.d/zzz-umountboot和/etc/kernel/postrm.d/zzz-umountboot，那么您应该获得您想要的功能，假设您的发行版的标准内核包是为了在适当的阶段调用这些脚本而构建的。
UEFI 的 ESP 分区（通常挂载为/boot/efi）完全相同，但用于系统固件而不是引导加载程序。一旦固件成功*.efi从 ESP 分区加载引导加载程序文件（以及引导加载程序可能存在的任何补充文件），ESP 的主要工作就会完成，并且在引导加载程序更新或下一个引导周期之前不再需要它。
然而，UEFI ESP 分区可以具有辅助功能：如果 UEFI 固件支持“固件更新胶囊”（即从正在运行的操作系统内调度系统固件更新的标准化方式），则固件更新文件需要写入设置更新过程之前的 ESP。Linux 有使用此机制的工具：请参阅命令 和/或 的fwupdate手册fwupdmgr页fwupdtool。如果此机制最终取代特定于供应商的 UEFI/BIOS 更新工具，则必须安装 ESP 时至少有两个条件：
目前，与内核更新的情况不同，似乎没有用于向这些事件添加自定义脚本的标准挂钩。