実装しようとしている非常に安全な一部の要塞VMでは、/boot起動後のアンインストールを検討しています。もちろん、他のアクションも含まれます。カーネルを更新するときにのみインストールされます。
- テストしてみると問題がないようです。私が逃した副作用はありますか？
- システムはDebian Linux（他の場合はRedhat）に基づいています。どちらも体系的です。
/boot再起動後にシステムシステムを削除する正しい方法は何ですか？テストするにはsudo umount /boot。 - BIOSを使用するかUEFIを使用するかを心配しています。仮想マシンになるので選択の問題です。 UEFIはより現代的なので、より賢明な選択肢のようです。しかし、セキュリティ上の利点があるかどうかはわかりません。むしろ複雑なため、脆弱性が高い可能性があります。
- UEFIなら
efiパーティションはどうですか？/bootデフォルトでは内部的にインストールされますが（/efiまだ試していません）、それを分離して管理者側でより透明に処理できると思います。起動後に削除できますか/boot/efi？/efi副作用はありませんか？
答え1
理論的には、どちらも起動後に/boot/一般的に使用されません/boot/efi。 2つはBIOS（または同様）とオペレーティングシステムの間のブリッジを形成します。通常、実行時には使用されません。
起動を再構成し、オペレーティングシステムが起動順序を更新/アップグレードできるようにインストールされます。つまり、Debianでは、apt/がdpkg両方の変更を引き起こします。
/bootdpkg（またはRedhat派生製品のrpm）以外のものがファイルツリーにアクセスしようとする可能性はほとんどありません。
セキュリティの観点から除去の知恵に挑戦したい。ルートを除くすべてのユーザーは読み取り専用でなければなりません。ユーザーにrootアクセス権がある場合はインストールできます。一方、セキュリティパッチを含むアップデートがシステムに適用されないようにすると、接続するよりも多くの脆弱性が発生する可能性があります。
代わりに、検疫要塞へのアクセスを検討しましたか？そしてchroot待って？ Chrootは、ログインしたユーザーがサブファイルツリーとpidネームスペースにのみアクセスできるようにしますが、ユーザーネームスペースは特定のアイテムがエスケープするのを防ぎます（chrootこれだけでは不十分です）。
最も簡単な方法は、おそらくSSHサーバーを次に置き換えることです。ドッカー（またはポッドキャスト）コンテナ内でopensshを実行します。これにより、ホストシステムを確認せずにSSHクライアントがDockerコンテナ内に保持されます。コンテナ内のファイルシステムは非常に小さい場合があります。Alpine Linuxコンテナ最小限のコマンドライン以外にはほとんど何もありません。
明確にするために、以下を参照してください。chrootはプロセスを分離するのに十分ではありません。 root アクセスにより、プロセスは chroot から離れることができます。ただし、他の隔離（pidおよびユーザーの名前空間と削除機能など）は、chroot刑務所内のプロセスを保護するのに非常に役立つはずです。したがって、dockerをお勧めします。
答え2
副作用：自分に気づかなかった。もちろんやむを得ない負担とは別に確信する新しいカーネルをインストールする前に、まずインストールしてください。 （そうでない場合は、インストール時にルートの/bootディレクトリにカーネルを正常に自動的にインストールするので注意してください。）
しかし、セキュリティ上の利点は議論の余地があります。
正しい進行方法（初期化システムが何であれ）ほとんど確実に…起動時にインストールしないでしょう…実際にはまったく必要ないからです。 ;-P
fstabで関連項目を見つけて、単に追加してください。自動ではありませんパラメータは次のとおりです。LABEL=LTUX_BOOT /boot ext4 noauto,noatime 0 2
本当にインストールしたい場合（後で削除するために）、次の利点を享受できます。x-systemd.idletimeout設置システムの特徴。 fstab の /boot エントリにこのような内容を追加すると、noauto,x-systemd.automount,x-systemd.idle-timeout=1s1 秒の中間時間後にファイルシステムが自動的にアンマウントされます。
答え3
今考えてみると、要塞VM関連の観点からこの質問をされたようです。これは通常状態の非保存であり、ほとんどインストールされません。
ハッカーが被るダメージが少しでも気になる場合、ほとんどのダメージは仮想/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）はまったく同じですが、システムファームウェアブートローダの代わりに。ファームウェアが*.efiESPパーティションからブートローダファイル（およびブートローダに存在する可能性がある追加のファイル）を正常にロードすると、ESPの主な作業は完了し、ブートローダの更新または次の起動サイクルまでは不要になります。
ただし、UEFI ESPパーティションには補助機能があります。 UEFIファームウェアが「ファームウェアアップデートカプセル」（つまり、実行中のオペレーティングシステム内でシステムファームウェアアップデートをスケジュールする標準化された方法）をサポートしている場合は、ファームウェアアップデートファイルをアップデートプロセスを設定する前にESP。 Linuxにはこのメカニズムを使用するためのツールがあります。コマンドfwupdateとfwupdmgr/orのマニュアルページを参照してくださいfwupdtool。このメカニズムが最終的にベンダー固有のUEFI / BIOSアップデートツールを置き換える場合は、ESPをインストールするときに少なくとも2つの条件を満たす必要があります。
- ブートローダアップデートをインストールするとき
- UEFIファームウェアアップデートをインストールするとき
現在のカーネルアップデートの場合とは異なり、これらのイベントにカスタムスクリプトを追加するための標準フックがないようです。