こんにちは、ITインフラエンジニアです。
ここ最近のLinuxコミュニティ、少しお祭り騒ぎが過ぎませんか？「Copy Fail」「Dirty Frag」といったカーネルの根幹を揺るがす重大な脆弱性が次々と公開され、全国のインフラ屋の皆さんも落ち着かない日々をお過ごしのことと思います。
一般ユーザーからほぼ確実にroot（最高管理者権限）が奪取できる――HPC（高性能計算）環境を預かる身としては、悪夢以外の何物でもありません。
今回は、そんな危機の中で私が提案したセキュリティ対策が、社内で「やりすぎ」と全否定された話を、技術的なおさらいを交えてご紹介します。
—
1. なぜ「ホストベース認証」を無効化しようとしたのか
私の現在のミッションは、AlmaLinuxやRockyLinux、Ubuntuといった主要なLinuxディストリビューションの上で動く商用ミドルウェア（ジョブスケジューラの「PBS Professional」など）をサポートすることです。
そんな中、「一般ユーザーがrootを奪取できる」というカーネル脆弱性のニュースが飛び込んできました。私は、万が一クラスタ内の1台が突破されても、被害が芋づる式に全サーバーへ横展開（ラテラルムーブメント）するのだけは防がなければ、と考えました。
そこで注目したのが、SSHの HostbasedAuthentication（ホストベース認証） の明示的な無効化です。
ここで、混同されがちな2つの認証方式を整理しておきます。
公開鍵認証（PubkeyAuthentication）
ユーザー個人の鍵ペアを使う方式です。家の鍵（秘密鍵）と鍵穴（公開鍵）のペアで、「この人が本人かどうか」を確認します。PBS Proが計算ノード間でパスワードなしに通信するために必須なのは、こちらの「パスフレーズなしの公開鍵認証」です。
ホストベース認証（HostbasedAuthentication）
マシン（ホスト）そのものを丸ごと信用する古い仕組みです。「このマシンから来た通信は全部OK」と玄関ドアを開け放つようなイメージで、現代のセキュリティでは原則「非推奨」とされています。PBS Proの稼働にも一切必要ありません。
今回のカーネル脆弱性でrootを奪われると、システムが保持する「ホスト秘密鍵」が攻撃者に渡ります。もしホストベース認証が有効なままだと、その鍵を使って隣のサーバーへ他人のアカウントでするりと侵入できてしまいます。これは「マスターキーを盗まれたのに、全部屋のドアを開けたままにしている」状態です。
だからこそ、この不要なバックドアを先回りして塞ぐため、製品への影響確認を含めた「検証プラン」を作成し、社内で承認を取りにいきました。
2. 「公式の指示通りにやれ」という判断
プロとして製品への影響を確かめるための検証を提案した私に対し、上長から返ってきた答えは大意こうでした。
> 「RedHatやUbuntuのようなディストリビューターが指示していることを、独自の判断で変えてはいけない。公開されている対処方法と実質同じでも、勝手に変えるのはNG。自分の主張を通したいなら、余暇でやってほしい。」
なるほど。「公式の手順に従うこと」「独自判断でスコープを広げないこと」という組織の判断として、一定の理解はできます。変更管理（チェンジマネジメント）の観点では、公式手順から逸脱することで新たなリスクを生む可能性もゼロではありません。
一方で、「製品固有の影響確認」はインフラエンジニアとして当然行うべきプロセスだという考えも、私は今も変わっていません。
—
3. 「公式準拠」の強みとトレードオフ
今回の件を通じて、組織のセキュリティ対応における2つのアプローチを改めて考えました。
公式準拠アプローチ
– 責任の所在が明確になる
– 変更管理が容易
– ただし、自環境特有のリスクに対応しきれない場合がある
エンジニア主導アプローチ
– 環境固有のリスクに先回り対応できる
– ただし、スコープ拡大・独自変更によるリスクを自分で負う必要がある
どちらが正解かは組織の文化やリスク許容度によりますが、重要なのは「なぜそうするか」を言語化して合意形成すること、だと思います。
今回のカーネル脆弱性対応として私が実施したのは、公式手順の文面そのままでの暫定処置です。その上で、HostbasedAuthenticationの無効化については引き続き検討中です。
—
4. Wizも推奨：SELinux / AppArmor による多層防御
ホストベース認証の無効化と並んで、クラウドセキュリティ企業のWizが2026年5月のDirty Frag解説記事（[参考](https://www.wiz.io/blog/dirty-frag-linux-kernel-local-privilege-escalation-via-esp-and-rxrpc)）で明示的に推奨しているのが、SELinux または AppArmor の有効化です。
SELinux / AppArmor とは？
どちらも MAC（強制アクセス制御） と呼ばれる仕組みで、「番犬がすべての部屋の前に立って、誰がどこに入れるかを強制管理する」イメージです。
通常のLinuxは「rootになれば何でもできる」という構造（DAC：任意アクセス制御）です。これは「マスターキーを持てばどの部屋も入れるホテル」のようなもの。今回の脆弱性でrootを奪われると、そのマスターキーがそのまま攻撃者の手に渡ります。
SELinux/AppArmor を有効にしておくと、たとえrootを奪われても「このプロセスはこのディレクトリにしか書き込めない」「このサービスはネットワークの外には出られない」というポリシー（ルール）が強制的に適用されます。マスターキーを盗まれても、番犬が通さない部屋がある、という状態です。
Wizが推奨した具体的な理由
Dirty Fragの悪用には `CAP_NET_ADMIN`（ネットワーク管理権限）という高めの権限が必要です。SELinuxのポリシーでこの権限を持てるプロセスを絞っておけば、脆弱性の悪用そのものを困難にできます。
各ディストリビューションの対応状況
| ディストリビューション | デフォルト設定 |
|—|—|
| RHEL / AlmaLinux / RockyLinux | SELinux が Enforcing（有効） |
| Ubuntu / Debian | AppArmor が 有効 |
| openSUSE | AppArmor が有効 |
多くの環境ではすでに有効になっているはずですが、HPC環境では「パフォーマンスへの影響を嫌って無効化している」ケースが少なくありません。まず現状確認から始めることをお勧めします。
“`bash
# SELinuxの状態確認（RHEL系）
getenforce
# AppArmorの状態確認（Ubuntu系）
aa-status
“`
HostbasedAuthenticationの無効化が「外からの不正な横移動を塞ぐ」対策だとすれば、SELinux/AppArmor は「侵入されてしまった後の被害を最小化する」対策です。この2つを組み合わせることで、多層防御（Defense in Depth）として機能します。
—
5. まとめ：今回の脆弱性対応で押さえておきたいこと
– 今回の脆弱性（Copy Fail / Dirty Fragなど）は、一般ユーザーからのroot奪取を可能にする深刻なもの
– 最優先対応はカーネルパッチの適用（各ディストリビューターの公式情報を確認）
– 横移動の封じ込めとして、`sshd_config` で `HostbasedAuthentication no` が維持されているかチェックを
– 侵入後の被害最小化として、SELinux / AppArmor が有効になっているか確認する（Wiz推奨）
– この2つを組み合わせることで多層防御（Defense in Depth）が成立する
環境によって最適解は異なりますが、「公式手順＋自環境の影響確認」を組み合わせた対応が、インフラエンジニアとしての基本スタンスだと私は考えています。
皆さんの環境でも、ぜひ確認してみてください。
カーネル脆弱性の嵐の中で、「ホストベース認証」を無効化しようとしたら「失格」と言われた話
