- Linuxカーネルのセキュリティチームは、報告された脆弱性を可能な限り早く修正して公開リポジトリにマージし、別途告知や発表は行わない
- このチームはCVE発行を担当するカーネルCVEチームとは別組織で、全員が個人資格で活動しており、企業所属とは無関係に運営されている
- セキュリティバグは単なる一般バグと同様に扱われ、修正後も別個の「セキュリティパッチ」としては表示しない
- **7日を超える非公開（embargo）**は維持せず、ほとんどの修正は即時公開される
- このアプローチはオープンソースの特性と多様な利用環境を考慮したもので、カーネルのセキュリティ対応における透明性と独立性を維持している
Linuxカーネルセキュリティチームの役割
- カーネルセキュリティチームは、報告された潜在的なセキュリティバグを分類し、迅速に修正する開発者グループ
- 彼らは、Kernel Self-Protection Projectが進める長期的な予防策とは別に、**リアクティブ（reactive）**なセキュリティ対応を担当する
- 報告手順は単純なテキストメールで行われ、HTML・バイナリ添付ファイル・暗号化は許可されない
- 暗号化された報告は、複数受信者構成のため処理できない
- チームメンバーは主要なカーネルサブシステムを代表する中核開発者で、雇用主や外部に議論内容を共有することはできない
- この独立性により、各国の法的要件（CRAなど）に左右されず一貫した対応が可能になる
バグ修正手順
- 報告されたバグが特定のサブシステムに関連する場合、そのサブシステムのメンテナーをメールでの議論に加えて解決する
- 問題が繰り返し発生するサブシステムでは、メンテナーがセキュリティチームのメーリングリストに直接参加することもある
- 報告者が修正パッチを提供した場合は貢献が認められ、そうでない場合は開発者が自ら解決する
- 修正が完了すると、メインのカーネルブランチと stable リリースにマージされる
非公開（Embargo）ポリシー
- 7日を超える非公開期間は認められず、ほとんどの修正は即時公開される
- 修正後は、報告者が望む場合にのみ外部告知を行うことができ、セキュリティチーム自体はいかなる発表も行わない
- CVEの割り当てはその後カーネルCVEチームが行い、セキュリティチームとは別である
「バグはただのバグ」原則
- 2008年にLinus Torvaldsは、セキュリティバグを別個に表示すべきではないと明言した
- 「セキュリティ修正」という区分は、他のバグの重要性を歪めるという理由から
- すべてのバグ修正は等しく重要であり、セキュリティ・機能・性能の区別なくすべて即時反映される
セキュリティ告知が存在しない理由
- カーネルレベルのほぼすべてのバグは、潜在的にセキュリティ問題になり得る
- メモリリーク、サービス拒否、情報漏えいなどさまざまな形がある
- オープンソースの特性上、開発者はユーザーの実際の環境を知ることができない
- あるユーザーには些細な修正でも、別のユーザーには致命的な脆弱性になり得る
- したがって方針は単純である
- 既知のバグは即座に修正する
- 修正済みリリースを可能な限り早く配布する
- 「修正が問題を引き起こす可能性がある」という懸念よりも、既知のバグを放置するほうが危険だという立場である
ハードウェアセキュリティの問題
- Spectre、Meltdownの事例のように、OSとハードウェアの両方を含む問題には例外的な手順が必要になる
- このために**「Hardware Security Policy」**が整備され、制限付きの暗号化メーリングリストを通じて協力する
- このプロセスは遅く複雑だが、最近では多くのハードウェアバグがこの手順なしで解決されている
- 今後はCRA法の応答時間要件により、長期の非公開はさらに難しくなる見込みである
カーネルセキュリティチーム誕生の背景
- 2005年以前は公式なセキュリティ連絡窓口が存在しなかった
- 開発者間の非公式ネットワークだけで報告が行われていた
- 2005年、Steve Bergmanのメール提案で議論が始まり、
Chris Wrightがセキュリティ連絡先と文書を追加するパッチを作成した
- その後、**中央メールエイリアス（security@kernel.org）**が正式化された
セキュリティ告知および事前通知の不在
- カーネルセキュリティチームは、いかなる形のセキュリティ告知や事前通知リストも運営していない
- CVE IDの割り当てはカーネルCVEチームが担当し、セキュリティチームは関与しない
- 事前通知リストへの要望は多いが、情報漏えいリスクと公共性の原則のため存在しない
- 「もし政府がそれを許すなら、そのプロジェクトは実際には使われていないものだろう」という立場である
1件のコメント
Hacker Newsの意見
最近のLinuxデスクトップでは、仮想化体験を滑らかにする技術が急速に進歩している
GPUドライバはMesaを通じてネイティブコンテキストをサポートし、Waylandのゲスト–ホスト間の共有機能も改善されている
以前は sommelier や wayland-proxy-virtwl のような複雑なプロトコル解析が必要だったが、今では wl-cross-domain-proxy プロジェクトがこれをきちんと実装しつつある
これらの機能を活用するVMMとしては muvm、そしてそれらを統合するソリューションとして munix がある
一時停止して転送し、再開する形で仮想マシンを移せるなら素晴らしいと思う
こういう理由で、Red Hatは2025年になっても依然として重要だ
この種のインフラ作業は常に必要になる
Red Hatがセキュリティ関連のコミットを選択的に取り込む(cherry-pick)とき、上流(upstream)でどのコミットがセキュリティに関係しているか明示されなければ、どうやって判断できるのか？
ときどき100%完全に安全なOSを夢見ることがある
おそらく形式検証(formal verification) やRustが鍵なのかもしれない
ハッキングされないという確信がほしい
結局のところ、人間自身が最大の脆弱性だ
アセンブリまで検証されており、Dafny もここから生まれた
しかし市場では「高品質より速い出荷」が優先されるため、こうした考え方が主流になるまでには何十年もかかる
本当の隔離には仮想化や物理的分離が必要になる
だから「100%安全なOS」に多くの貢献者を集めるのは難しい
それでもこの話題に興味があるなら、いくつものOS開発プロジェクトがある
セキュリティは終わりのない競争だ
一方で2026年になっても、Gregの個人サイトはまだTLSをサポートしていない
Caddyで設定するのは簡単だが、個人ブログのような静的サイトなら暗号化の実利はほとんどない
どうせドメインとIPは平文で露出するので、大きな違いはない
彼らが本当にそう考えているなら、CNAを削除すべきではないか？
だが一部の研究者はCVE件数を増やすことばかり狙う傾向があり、実際には無害なバグにも高い優先度を付けようとする
「セキュリティ問題を報告するのに暗号化を強制するなら、この方針を見直せ（英国政府のことだ）」
この部分はただただ笑える
「バグは単なるバグにすぎない」という言い方は単純すぎる
root権限が必要なDoSと、非特権ユーザーからのシステム掌握はまったく別物だ
ある種のバグは明確にセキュリティ境界の侵害を引き起こすので、そうしたものはセキュリティバグとして分類すべきだ
Gregにはこれは何十年も説明されてきた話だ
要するに、最新バージョンを動かしていなければカーネルは完全にはパッチ適用されていない
CVEは避けられ、脆弱性修正はコミットログに隠され、攻撃者はそれを見て気付く
なぜわざわざこれを強調する必要があるのか分からない
顧客がDockerイメージにカーネル関連のパッチを求めてくる
だがDockerはカーネルを含まないのに
カーネルなしでイメージを配布する方法が必要だ
一般的なベースイメージはカーネルを含まない