Ubuntuパッケージのセキュリティは監査されますか？
Ubuntuのパッケージセキュリティの現在の手順が何であるかわかりません。
Ubuntuのパッケージリポジトリで何かが発生すると、パッケージは中央の信頼できるチームによって監査されますか？その場合、どのレベルの監査が行われますか？
パッケージがチェックされるかどうかに興味があります：
- 既知の脆弱性/ CVEとの定期的なマッチング（パッケージメンテナーにはリアルタイムでCVEリリースが通知され、パッチが適用されていない（ベンダーによって）CVEが削除されたパッケージと同様）。
- 明らかな悪意のあるコード（リバースシェル、ランダムシェルコード、トロイの木馬など）
- 低いコード品質（例：意図しないコマンドインジェクションの脆弱性）
- 脆弱性のすべてのコードの完全なセキュリティ監査
さまざまな種類のサポートを表す buntu Archivesの 'pockets' がいくつかあります。mainのパッケージはCanonicalによってサポートされ、universeのパッケージはコミュニティによってサポートされます。
Ubuntuのデフォルトのインストールに含めるには、パッケージがメインにある必要があります。
開発サイクル中に、開発者は メインに含めるパッケージを提案 できます。このプロセスの一部は、パッケージがセキュリティ関連であるかどうか（たとえば、特権で実行するが信頼できないユーザーとやり取りする、複雑な形式を解析するなど）かどうかを判断し、そうである場合はUbuntuセキュリティチームに クイックセキュリティレビュー =。私はこれらのレビューの多くを行います。
提案された各パッケージに完全な詳細監査を行うことはできません。私は、パッケージが最新の安全なプログラミング標準を使用して専門的な方法で開発されたように見えるかどうかをすぐに知りたいと思っています。
バイナリ出力を検査して、コンパイルされたプログラムとライブラリが 標準のセキュリティ緩和策 でコンパイルされていることを確認します。アドレス空間レイアウトのランダム化、スタックカナリア、Fortifyソースの位置独立実行のサポートなど（一般的ないくつかをキャッチします） Cの問題）、およびBind NowとRELRO（シンボルリンクを乱用するエクスプロイトを軽減）。 （オンになっているスタッククラッシュの欠陥に対する緩和策、および一部の新しいプロセッサでのIntelの制御フロー整合性チェックのサポートがありますが、 hardening-check はそれらのチェック方法をまだ認識していません。 ）また、Sudoルール、udevルール、setuidビットまたはsetgidビット、パッケージスクリプト、起動スクリプトなどを検証して、パッケージに予期しない特権のソースがないことを確認します。
Coverity 、 cppcheck 、および shellcheck などの自動スキャナーでソースコードを検査します。一般的なプログラミングの欠陥を見つけるのに役立つ簡単なツールを作成しました（これらのツールは欠陥を検出することを目的としていませんが、たとえばすべてのメモリ割り当てルーチン、すべてのネットワークルーチン、特権オペレーティングシステム関数のすべての使用などを検査する非常に迅速な方法を提供します）。欠陥がある可能性が高いパッケージ内のコード行をすばやく参照できます。
私たちは欠陥を見つけるかもしれませんが、さらに重要なことは、コードを書くときに開発者が適切に防御的であったかどうかを知ることです。ソフトウェアがどのように機能するか、どのように開発されたか、および作成者がどのような脅威モデルを想定しているかについての感触をつかむことができます。
ファジングをときどき実行します。 （ファジングを実行するのは簡単（そして楽しい）な部分です。これから何らかの価値を引き出すために、クラッシュもそれらを修正するのに十分なほど調査する必要があります。これは高価な部分です。これをもっと実行したいと思います。将来的には、はるかに価値があるのは、人々にとって oss-fuzzで実行できるプロジェクトにファズテストを提供する インフラストラクチャであり、結果を著者に直接提供することです。コベリティについても同様です-- すべてのコミットでCoverityを直接実行し、新しい問題が追加されたときにメールを受け取る 単一の「ここにCoverityが見つかった問題のリスト」よりも価値があります。）
監査結果に応じて、パッケージをそのまま受け入れるか、変更を要求するか、パッケージをメインに受け入れない場合があります。何人かのプロジェクトの作者は、フィードバックに取り組むために、そしてそれを超えて作業することは素晴らしいです。 （ほぼすべてのプロジェクト作成者は、誰かがコードを読んでフィードバックを提供してくれていることに満足しています。）
これらのステップはすべて、メインに入れるパッケージを決定する1回限りのタスクです。
Ubuntu Security TeamはCVE Triageタスクを毎日実行します。 CVEのデータベースがあります どのパッケージがどの欠陥に影響されているか、Ubuntuのどのリリース、どのバージョンが修正されているか、修正が見つかる場所、サポートドキュメント、軽減策などを追跡するために使用します問題の重要性や影響を減らし、次に修正するパッケージを決定するときに使用する優先度を減らします。 MITRE、NVD、Debian、メーリングリスト（パブリックおよびプライベート）などからデータを収集します。
セキュリティ研究者とユーザーは問題を私たちに報告します。できる限り調査し、必要に応じて上流の開発者に問題を転送します。
メインのパッケージは完全なセキュリティサポートを取得します。上流の作者からのパッチをバックポートし、パッチを作成し、パッケージをテストして、リグレッションを導入するリスクを軽減します。すべてのリグレッションをキャッチすることはできませんが、より広い視野により、上流の開発者が見逃す可能性があるリグレッションをキャッチできます。制限事項、リグレッション、または不完全なパッチが見つかった場合、修正を改善するために、必要に応じて上流の開発者およびより広いコミュニティと協力します。
ユニバース内のパッケージはコミュニティでサポートされています。コミュニティのメンバーは、問題の修正を準備し、パッケージをビルドし、パッケージをテストし、ビルドおよび配布するパッチを提供します。変更の信頼性を検証し、パッケージの変更を検証し、新しいパッケージをビルドして配布します。残念ながら、これにより、十分にサポートされているものとサポートされていないものを知ることが難しくなります。 （私たちはこれに取り組んでいます。）一部のエンタープライズユーザーは、環境のセキュリティサポートを確実に取得するために、メインからのパッケージのみを使用します。
誰もがスポンサーにdebdiffを提出できます。Launchpadのページでソースパッケージのバグを開き、それをPublic Securityとしてマークし、debdiffを添付し、テストを記述して、サブスクライブしますubuntu-security-sponsors。 変更の準備 最初は圧倒的に見えるかもしれませんが、Debianパッケージでの作業を支援する大きなコミュニティがあります。
すでにメインにある包括的な再監査パッケージのプロジェクトはありません。私たちは多くのパッチを読み、パッケージ内の同様の欠陥を探し、周囲のコードを調べますが、パッケージを最初から頻繁に再確認することはありません。
FIPS、CC、STIG、およびCIS 認定のLTSリリースを提出します。これらは、さまざまな標準を使用して暗号化パッケージおよびセキュリティの影響を受けやすいパッケージを監査するための規制フレームワークを提供します。認証は特定の産業にとって重要です。この作業は、ディストリビューションに影響を与え、フィードバックします。監査人は必ずしもプロセス、最低限のセキュリティ標準や設定などの順守ほどの欠陥を探しているわけではありません。しかし、特に重要なパッケージの正確さを再確認することは、一部のユーザーにとって非常に安心です。
Ubuntuセキュリティチーム以外でも、2つのすばらしいコミュニティのメリットを組み合わせて利用できます。DebianとUbuntuの両方の開発者コミュニティは、FOSSエコシステムの他の場所にあるアップストリーム開発者、ダウンストリームユーザー、および他の開発者との関係を築いています。全員が協力して、監視、フィードバック、協力、コミュニケーションを提供します。完璧なソフトウェアはありませんが、私たちのコミュニティの共同の努力は素晴らしい結果をもたらします。