啟動後解除安裝 /boot
對於我將很快實施的一些高度安全的堡壘虛擬機，我正在考慮
/boot在啟動後解除安裝——當然還有其他措施。將僅用於更新核心。
- 對此進行測試，似乎沒有出現任何問題；它會有我遺漏的副作用嗎？
- 這些系統可能基於 Debian Linux（其他場景，在 Redhat 上）。兩者都是系統化的。
/boot重新啟動後在 systemd 系統上解除安裝的正確方法是什麼？為了測試我只是sudo umount /boot.- 我正在爭論自己是要使用 BIOS 還是 UEFI。由於它們將是虛擬機，因此這是一個選擇問題。UEFI 似乎是更現代的更明智的選擇。但我不確定安全利益（如果有的話）。相反，因為它更複雜，可能存在更多漏洞的機會。
- 如果是 UEFI，
efi分區呢？它預設安裝在裡面/boot，雖然我認為/efi可以使用（我沒有嘗試過），將它們分開並更透明地處理，管理員方面。啟動後也可以解除安裝/boot/efi或/efi解除安裝而沒有副作用嗎？
理論上既不
/boot/也不/boot/efi常用開機後。兩者形成了 BIOS（或類似的）和作業系統之間的橋樑。它們通常不在執行時使用。它們已安裝，以便您可以重新配置引導，以便您的作業系統可以更新/升級其引導順序。也就是說，在 Debian 上，
apt/dpkg將觸發對兩者的更改。除了 dpkg（或 redhat 衍生產品上的 rpm）之外，任何東西都不太可能想要訪問
/boot文件樹。從安全的角度來看**，我會挑戰解除安裝的智慧**。它們都應該對除 root 以外的所有使用者都是只讀的。如果使用者獲得 root 訪問權限，那麼他們可以掛載它們。另一方面，阻止您的系統應用更新（包括安全更新檔）可能會打開比關閉更多的漏洞。
相反，您是否考慮過使用等隔離堡壘訪問
chroot？Chroot 讓那些登錄的人只能訪問一個子文件樹，一個 pid 命名空間和使用者命名空間可以防止某些東西逃逸（chroot僅靠它是不夠的）。最簡單的方法可能是用在容器內執行 openssh 的 docker （或 podman ）替換您的SSH 伺服器。這會將任何 SSH 客戶端留在 docker 容器中，而不是看不到主機系統。該容器內的文件系統可能非常小，例如一個alpine linux 容器，除了一個最小的命令行幾乎什麼都沒有。
為清楚起見，請注意： chroot 不足以隔離程序。通過 root 訪問，一個程序可以逃脫 chroot。然而，其他隔離（例如 pid 和使用者命名空間以及刪除功能）對於保護 chroot 監獄中的程序應該做很多事情……因此建議使用 docker。
副作用：我自己沒有註意到。當然，除了必須在安裝新核心之前安裝它所帶來的負擔之外。（可以肯定，因為如果不是這樣，安裝將優雅而靜默地將核心安裝在根目錄的 /boot 目錄中……）
然而，在安全性方面的好處是值得商榷的。
繼續進行的正確方法（無論 init 系統如何）幾乎可以肯定是……不要在啟動時掛載它……因為它實際上從來不需要；-P
檢查 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 秒的中間時間後自動解除安裝其文件系統。