キースクック 私はブログに投稿します バグ修正プロセスに関する懸念を提起しました Linuxカーネルの安定したブランチで進行中です。 毎週約XNUMXの修正が含まれていることに言及してください 安定した枝の上に、これは多すぎると、Linuxカーネルをベースとした製品を維持するために多くの労力を必要とします。
キーズによると、カーネルエラー処理プロセスがバイパスされ、 カーネルには少なくとも100人の追加開発者が不足しています この分野で協調して働くこと。 また、主要なカーネル開発者が定期的にバグを修正していることにも言及していますが、これらの修正がサードパーティのカーネルバリアントに引き継がれる保証はありません。
そうすることで、彼は、さまざまなLinuxカーネルベースの製品のユーザーも、どのバグが修正され、どのカーネルがデバイスで使用されるかを制御する方法がないと述べています。 最終的に、ベンダーは製品のセキュリティに責任を負いますが、安定したカーネルブランチで非常に高い割合のパッチに直面し、すべてのパッチを移行するか、最も重要なパッチを選択的に移行するか、すべてのパッチパッチを無視するかの選択に直面しました。 。
アップストリームカーネル開発者はバグを修正できますが、ダウンストリームベンダーが製品に組み込むことを選択するものを制御することはできません。 エンドユーザーは製品を選択できますが、通常、修正するバグや使用するカーネル（それ自体の問題）を制御することはできません。 最終的には、ベンダーは安全な彼らの製品のコアを維持する責任があります。
キースクック 最適な解決策は、最も重要な修正と脆弱性のみを転送することであることを示唆していますただし、主な問題は、これらのエラーを一般的なフローから分離することです。これは、新たに発生する問題のほとんどがC言語の使用の結果であり、メモリとポインタを操作するときに多くの注意が必要になるためです。
さらに悪いことに、多くの潜在的な脆弱性修正はCVE識別子でタグ付けされていないか、パッチがリリースされた後しばらくしてCVE識別子を受け取りません。
メーカーが主要なセキュリティ上の問題からマイナーな修正を分離するためにこのような環境では、それは非常に困難です。 統計によると、脆弱性の40％以上がCVE割り当ての前に削除され、修正リリースとCVE割り当ての間の平均遅延はXNUMXか月です（つまり、最初は、解決策を一般的な間違いとして認識します。
その結果、 脆弱性の修正を含む個別のブランチがない これのセキュリティやその問題との接続に関する情報を受信していません、 Linuxカーネルベースの製品の製造業者は、すべての修正プログラムを転送する必要があり 新しい安定した枝の。 しかし、この作業は労働集約的であり、製品の通常の動作を混乱させる可能性のある退行的な変更の恐れがあるため、企業からの抵抗に直面しています。
キーズクック カーネルを長期的に妥当なコストで安全に保つ唯一の解決策は、パッチエンジニアを移植することであると考えています クレイジーなカーネルビルドへl協調して協力する アップストリームカーネルのパッチと脆弱性を維持するため。 現状では、多くのベンダーが自社の製品に最新のカーネルバージョンを使用しておらず、バックポートの修正を独自に行っています。つまり、さまざまな企業のエンジニアがお互いの作業を複製し、同じ問題を解決していることがわかります。
たとえば、それぞれが同じ修正をサポートするエンジニアを持つ10社が、10つの修正を移行する代わりに、これらのエンジニアをリダイレクトしてバグを上流に修正する場合、全体的な利益のためにXNUMXの異なるバグを修正するか、一緒になってバグを確認することができます。提案された変更。 また、カーネルにバグのあるコードを含めないでください。 リソースを使用して、何度も何度も発生する典型的なエラークラスを早期に自動的に検出する新しいコード分析およびテストツールを作成することもできます。
キーズクック また、より積極的に自動化されたテストとファジングを使用することを提案しています カーネル開発プロセスで直接、継続的インテグレーションシステムを使用し、電子メールによる開発の古風な管理を放棄します。
出典 https://security.googleblog.com