元 kernel.org CSO であり、Ubuntu セキュリティ チームのリーダーであり、現在は Google で Android と ChromeOS のセキュリティ保護に取り組んでいる Kees Cook 氏は、カーネルの安定版ブランチのバグを修正する現在のプロセスについて懸念を表明しました。 毎週、約 1 件の修正が安定ブランチに含まれており、次のリリースへの変更を受け入れるためのウィンドウを閉じると、その修正数は XNUMX 件に近づきます (メンテナはウィンドウが閉じるまで修正を保持し、「-rcXNUMX」の作成後は修正を保持します) Linux カーネルをベースにした製品の保守には多大な労力と労力がかかります。
Keys 氏によると、カーネル内のエラーに対処するプロセスには十分な注意が払われておらず、カーネルにはこの分野で調整された作業を行うための追加開発者が少なくとも 100 人不足しています。 コア カーネル開発者は定期的にバグを修正しますが、これらの修正がサードパーティが使用するカーネル バリアントに移植されるという保証はありません。 Linux カーネルをベースにしたさまざまな製品のユーザーも、どのバグが修正されるか、どのカーネルがデバイスで使用されるかを制御する方法がありません。 ベンダーは自社製品のセキュリティに対して最終的な責任を負っていますが、安定版カーネル ブランチではパッチ適用率が非常に高いため、すべてのパッチをバックポートするか、最も重要なものを選択して移植するか、すべてのパッチを無視するかの選択を迫られました。
最適な解決策は、最も重要な修正と脆弱性のみを移行することですが、そのようなエラーを一般的なフローから分離することが主な問題です。 発生する問題のほとんどは C 言語の使用に起因するため、メモリとポインタを扱う際には細心の注意が必要です。 さらに悪いことに、多くの潜在的な脆弱性修正には CVE 識別子が提供されていないか、パッチの公開後しばらくしてからそのような識別子を受け取ります。 このような状況では、メーカーにとって、軽微な修正を重大なセキュリティ問題から区別することは非常に困難です。 統計によると、脆弱性の 40% 以上が CVE が割り当てられる前に修正され、パッチのリリースから CVE の割り当てまでの平均遅延は XNUMX か月です (つまり、最初はパッチが一般的なものとして認識されます)。バグですが、脆弱性が修正されたことが判明するのは数か月後です)。
その結果、脆弱性の修正を含む別のブランチを持たず、特定の問題のセキュリティ関連情報を受け取ることもなく、Linux カーネルをベースにした製品のメーカーは、すべての修正を新しい安定したブランチから継続的に転送することになります。 しかし、この作業には多大な労力が必要であり、製品の通常の動作を混乱させる可能性のある退行的な変更を恐れて企業の抵抗に遭っています。
Linus Torvalds 氏によると、すべてのエラーは重要であり、脆弱性は他のタイプのエラーから分離して、別のより優先度の高いカテゴリに割り当てられるべきではない、ということを思い出してください。 この意見は、セキュリティ問題を専門としない一般の開発者にとって、修正と潜在的な脆弱性との関係が明らかではないという事実によって説明されます (多くの修正については、個別の監査によってのみ、それらがセキュリティに関連していることを理解できます) ）。 Linus 氏によると、潜在的な脆弱性を一般的なパッチ フローから隔離するかどうかは、Linux ディストリビューション上のカーネル パッケージの保守を担当するチームのセキュリティ チームにかかっています。
Kees Cook 氏は、妥当な長期コストでカーネルの安全性を維持するための唯一の解決策は、企業がローカルのカーネル ビルドへのパッチの移植に携わるエンジニアを移動させ、上流カーネルのパッチと脆弱性を維持するために協力的かつ協調的に作業できるようにすることだと考えています。 現在の形式では、多くのメーカーは製品に最新のカーネル バージョンを使用しておらず、独自にバックポート修正を行っています。 異なる会社のエンジニアがお互いの作業を重複させて、同じ問題を解決していることがわかりました。
たとえば、10 社の企業がそれぞれ 10 人のエンジニアを抱えて同じ修正を支援し、それらのエンジニアを上流のバグ修正にリダイレクトした場合、XNUMX つの修正を移植する代わりに、共通の利益のために XNUMX 個の異なるバグを修正したり、提案された変更のレビューに参加したりすることができます。カーネルにバグのあるコードが含まれるのを防ぎます。 また、テストとコード分析のための新しいツールの作成にリソースを充てることもできます。これにより、何度も発生する典型的なエラーのクラスを早い段階で自動的に特定できるようになります。
Kees Cook 氏はまた、コア開発プロセスで直接自動化されたファジング テストをより積極的に使用すること、継続的統合システムを使用すること、電子メールによる時代遅れの開発管理を放棄することも提案しています。 現在、主要なテストプロセスが開発から分離され、リリースの形成後に行われるという事実により、効果的なテストが妨げられています。 Keys はまた、バグを減らすために Rust などのより安全な言語を使用することを推奨しました。
出所： オープンネット.ru