実装しようとしている非常に安全な一部の要塞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をお勧めします。