对于我即将实施的一些高度安全的堡垒虚拟机，我正在考虑在/boot启动后卸载 - 当然还有其他措施。仅用于更新内核时安装。
- 测试了一下，似乎没有出现问题；它有我遗漏的副作用吗？
- 该系统可能基于 Debian Linux（其他情况下，基于 Redhat）。两者都是系统化的。
/boot重新启动后在 systemd 系统上卸载的正确方法是什么？为了测试我只是sudo umount /boot。 - 我正在考虑是否要使用 BIOS 或 UEFI。由于它们将是虚拟机，所以这是一个选择问题。UEFI 似乎是一个更明智的选择，因为它更现代。但我不确定是否有安全优势。相反，因为它更复杂，可能更容易出现漏洞。
- 如果是UEFI，那么
efi分区呢？它/boot默认安装在内部，尽管我认为/efi可以使用（我还没有尝试过）来将它们分开并在管理员方面更透明地处理。启动后可以卸载/boot/efi吗？/efi没有副作用吗？
答案1
理论上，启动后两者都不/boot/常用/boot/efi。两者构成了 BIOS（或类似的）和操作系统之间的桥梁。它们通常不在运行时使用。
安装它们是为了让您可以重新配置启动，并让您的操作系统可以更新/升级其启动顺序。也就是说，在 Debian 上，apt/dpkg将触发对两者的更改。
除了 dpkg（或 Redhat 衍生产品上的 rpm）之外，任何东西都不太可能想要访问/boot文件树。
从安全角度我会挑战卸载的智慧。它们对于除 root 之外的所有用户都应该是只读的。如果用户获得 root 访问权限，那么他们就可以安装它们。另一方面，阻止系统应用更新（包括安全补丁）可能会造成比您堵住的漏洞更多的漏洞。
反而，您是否考虑过隔离堡垒访问与chroot等？ Chroot 允许登录者仅访问子文件树和 pid 命名空间，而用户命名空间可以防止某些内容逃逸（chroot单独使用是不够的）。
最简单的方法可能是将 SSH 服务器替换为泊坞窗（或者播客）在容器内运行 openssh。这将使任何 SSH 客户端留在 Docker 容器内，而看不到主机系统。该容器内的文件系统可能非常小，例如高山 Linux 容器除了最少的命令行之外几乎什么都没有。
为了清楚起见，请注意：chroot 不足以隔离进程。通过 root 访问权限，进程可以逃脱 chroot。然而，其他隔离（例如 pid 和用户命名空间以及删除功能）应该对保护 chroot 监狱内的进程发挥很大作用……因此建议使用 docker。
答案2
副作用 ：我自己从来没有注意到过。当然除了必要性带来的负担之外确定在安装新内核之前安装它。 （一定要确定，因为如果不是，安装将优雅地、静默地将内核安装在根目录的 /boot 目录中……）
然而，安全性方面的好处是值得商榷的。
正确的进行方式（无论 init 系统是什么）几乎肯定......不会在启动时安装它......因为它实际上从未被需要;-P
检查 fstab 中的相关条目并简单地添加一个不自动参数，这可能看起来像：LABEL=LTUX_BOOT /boot ext4 noauto,noatime 0 2
如果您确实想要安装它（以便稍后卸载），您可以受益于x-systemd.空闲超时安装系统的特点。在 fstab 的 /boot 条目中添加类似的内容noauto,x-systemd.automount,x-systemd.idle-timeout=1s会在中间时间 1 秒后自动卸载其文件系统。
答案3
现在我想了一下，你是从堡垒虚拟机的具体角度来问这个问题的。这些通常是无状态的，安装的很少。
如果您非常担心黑客可能造成的损害，/boot那么大部分损害将在虚拟机重新启动时生效。
如果你想对此有一个极端的看法，你实际上可以完全破坏你的启动分区和启动后。毕竟它是一个虚拟机。要“重新启动”甚至应用安全更新，您只需启动一台新虚拟机并拆除旧虚拟机即可。那么黑客就“无法”干扰虚拟机的启动顺序。
正如我的其他答案中所述，除了应用安全更新之外，没有真正的理由保留/boot和安装。/boot/efi
答案4
/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 时至少有两个条件：
- 安装引导加载程序更新时
- 安装 UEFI 固件更新时
目前，与内核更新的情况不同，似乎没有用于向这些事件添加自定义脚本的标准挂钩。