実行する前にプログラムの署名を検証するOSはありますか？
もしそうなら、これらのOSは何ですか？彼らは特別に細工されていますか？このようなプログラム検証を日常のOSに適用するのはどれほど難しいのでしょうか。
そうでなければ、なぜ人々はそのようなOSを発明しなかったのですか？
パッケージ署名の検証は、今日のパッケージマネージャーではかなり一般的です。私が尋ねているのは、ロード時の署名検証です。
iOSとAndroidは両方とも、コードをメモリにロードする前に、すべてのコードの署名を検証します。
Windows UWPアプリも、読み込まれる前にすべて署名がチェックされます。
パッケージ署名の検証は、今日のパッケージマネージャーではかなり一般的です。私が尋ねているのは、ロード時の署名検証です。
パフォーマンスの点で大きな違いがあります。パッケージの署名は、インストール時ではなく、インストール時にチェックされます。
効果的であるためには、実行またはロードされる前に、すべてのバイナリのコード署名をチェックする必要があります。
さらに、実行可能としてマークされたメモリページが署名されている（または、少なくとも適切に署名されたものから読み込まれている）ことを確認するために、OS（またはランタイム環境）によって特別な注意が必要です。この要件は、多くのレガシーコードを破壊する傾向があるため、コード署名を考慮して設計されていない環境に適用することは非常に困難です。
すべてのOSがプログラムの署名を検証しないのはなぜですか？初期の頃は、ほとんどのプログラムがローカルで作成およびコンパイルされていたため、現在でも、一部のビジネスアプリケーションはローカルで構築されています。多くの高品質なプログラムがソースとして配布され、canはローカルでコンパイルされます。特定のニーズに合わせてプログラムを微調整するためにコンパイルオプションを使用できるため、高性能サーバーではしばしば意味があります。よく知られたソースからの署名済み実行ファイルしか使用できない場合、それはすべて不可能です。
もちろん、AndroidまたはiOSのようなエンドユーザーを対象とするOSの場合、状況は異なります。既知のソースからインストールされた実行可能ファイルのみを許可することは理にかなっています。
しかし、私のWindowsボックスでも、CまたはC++でプログラムを作成、ビルド、および実行できなかった場合は、とてもがっかりします...
教育や企業環境で時々使用される1つの例は AppLocker です。これにより、署名の発行者名や特定のファイルのハッシュなど、管理者が定義した属性に基づいてアプリケーションの実行をホワイトリストに制限できます。 。
最大の問題はもちろん管理のオーバーヘッドであり、ユーザーが必要とする可能性のあるすべてのプログラムを具体的にホワイトリストに登録する必要があります。さらに、多くの発行元はアプリケーションに署名していません。そしてもちろん、それは完全な解決策ではありません-例えばホワイトリストに登録されたプログラムのバグは、引き続き任意のコードを実行するために悪用される可能性があります1。
実際、実行可能ファイルの署名は重要な部分すらありません。ホワイトリストは、すべての違いのパスによって実装できます。このスキームで重要なのは、ユーザーがプログラムディレクトリへの書き込み権限を持っていないことです。2。それが真実であると仮定すると、実行時の検証はインストール時の検証に比べてどのような利点がありますか？インストールされているプログラムを変更することはできません。攻撃経路がファイルのオフライン編集である場合、完全なディスク暗号化が正解です。
1 このようなバグのほとんどは、特権の昇格につながらない通常の環境では重大とは見なされません。 W ^ X は [〜＃〜] rop [〜＃〜] でバイパスできます。
2 実行可能ファイルの署名の検証でさえ、デフォルトでは外部モジュール（動的にリンクされたライブラリなど）を見逃します。そして、それを有効にする パフォーマンスに大きな影響を与える可能性があります 。
Linuxはすでに [〜＃〜] ima [〜＃〜] と呼ばれるカーネルに必要なメカニズムを持っています（バージョン3.7以降）：
カーネル整合性サブシステムの目的は、ファイルがリモートまたはローカルで誤ってまたは悪意を持って変更されたかどうかを検出し、拡張属性として保存された「良好な」値に対してファイルの測定値を評価し、ローカルファイルの整合性を適用することです。これらの目標は、SElinuxやSmackなどのLSMモジュールによって提供される強制アクセス制御（MAC）保護を補完するものであり、ポリシーに応じて、ファイルの整合性を保護しようとします。
IMAを使用すると、機密ファイルに「不変」というラベルを付けることができ（これは実行可能ファイルで行うことです）、特別なRSAキーで署名します。署名はファイルアクセス時に検証され、オフラインでの改ざんを防止します。不変ではないファイルの実行は、SElinuxポリシーで禁止できます。
もちろん、そのようなシステムの使いやすさは低下します。このようなシステムで独自のファイルを構築して実行するには、最初にそれらに署名するための信頼できる秘密鍵が必要です。ソフトウェアのアップグレードは、不変のファイルがロックされる前に更新するために 再起動が必要 になる可能性があります。
読み込み時間の検証は非常に高価であり、完全な証拠ではありません。
実行する前にプログラムの署名を検証するOSはありますか？
[〜＃〜] edit [〜＃〜]：コメントで指摘されているように、そのようなオペレーティングシステム。例：ChromeOS.
もしそうなら、これらのOSは何ですか？彼らは特別に細工されていますか？このようなプログラム検証を日常のOSに適用するのはどれほど難しいのでしょうか。
ロード時にプログラムを検証することはかなり困難です。さらに、正常に実行した場合でも、プログラムが開始された後も、攻撃者は不正な入力を与えて大混乱（バッファオーバーフロー）を引き起こす可能性があります。そうは言っても、ロード時に署名を検証するソフトウェアモジュール（ソフトウェア認証、たとえばFIPS準拠のOpenSSL）があります。オペレーティングシステムですべてのプロセスに対してそれを実行すると、非常にコストがかかります。
焦点がクラウドコンピューティングに移るにつれて、信頼できないシステムでも高保証ソフトウェアを実行できるようにする必要があります。システム上で実行されているソフトウェアからシステムを保護することについては、あまり研究が行われないと思います。代わりに、信頼できない環境でも信頼できる計算を行うことに重点が置かれます。ロード時に必要な場合は、システムまたはソフトウェアの証明（下部のリンクを参照）などの基本的な信頼の連鎖を持つことができます。重要なことは、実行時にソフトウェアが侵害されないようにすることです。
このディスカッションを見てください： 実行中の解釈済みプログラムは、それが公開されたソースコードバージョンと同じであることを暗号で証明できますか？
多くの回答が比較的最近のサポートを備えた一般的なOSについて言及していますが、TPMおよび Trusted Computing Group については言及していません。 TPMは、標準化されたコンシューマーグレードのマザーボードモジュールとして、ファームウェアブートからの完全性のチェーンで署名付き実行を実行するために必要な最小限のハードウェアを提供します。これは、ブートステージが実行前に後続の各ステージの測定値でハッシュレジスタを拡張できるようにし、これらのハッシュレジスタ値を条件とすることができるロックされたキーストアメカニズムを提供することで機能します。
TPMがPKIと初期ブートのChicken and Eggの問題を解決すると、コード自体が悪用されない範囲で、リソースアクセスを特定のポリシーで許可されたソフトウェアに制限できます。 検証済みのブートがなければ、PKIシステムとポリシーが変更されていないと信じる理由もなく、実行時の署名チェックにはほとんど意味がありません。
私の知る限りでは（現在ではありません）、AppleとGoogleはハードウェアプラットフォームを十分に制御でき、デフォルトでTPMを試すことができました。完全なTCGを実装したとは思いません。検証済みブートのスタイルですが、これらの新しいデバイスの突然の取り込みに取り残されるという脅威により、OSベンダーはいくつかのランタイム整合性コンポーネントの実装を開始しました。
NetBSDにはveriexecがあります。
https://wiki.netbsd.org/guide/veriexec/
https://www.netbsd.org/docs/guide/en/chap-veriexec.html
これは、セキュリティレベルを上げるとともに、インターネットに接続するサーバーに非常に適しています（ https://wiki.netbsd.org/kernel_secure_levels/#index2h1 ）。
Microsoft Windows 7+ 設定可能 Authenticodeで署名されたプログラムの実行のみを許可します。
しかし、これはあなたがあなたのコンピュータを破壊したウイルスを作った人を知ることを意味するだけであることを理解する必要があります。これは、署名されているアプリケーションについて何も通知しないため、実際にはセキュリティ機能ではありません。はい、中国、ウクライナ、アンゴラの$ RANDOM_GUYがどこで作成されたか知っています。しかし、もしあなたの貴重なデータが暗号化されていて、$ RANDOM_GUYがそれを解読するために20BTCを要求するなら、これは本当にあなたに何をするでしょう。そして、ソフトウェアがすべてのデータを盗んだ場合、$ RANDOM_GUYがおそらくそれを盗んだことを知っているとしたら、それはどのようなメリットがありますか？
まず、私はこれから言うことは何でも専門家ではないので注意が必要です...
私が住んでいるフリーソフトウェアの世界では、人々は 再現可能なビルド に取り組んでいます。目標は、ダウンロードされたすべてのバイナリが、ユーザー自身がビルドして検証できるようにすることです。多くの distrosとソフトウェアプロジェクト がそれに興味を持っています。私の記憶が正しければ、このアイデアはビットコインの人々によって開始され、その後にTorプロジェクトが続きました。
私が聞いたところによると、十分な数のパッケージが再現可能になった後、ハッシュをいくつかのp2p方法で共有することができると示唆する人もいました。したがって、私の意見では、あなたの質問に答えるために、検証者は読み込み時にバイナリをハッシュし、それが他の人が公開したハッシュと一致するかどうかを確認できますが、これはインターネット接続速度によっては遅い場合があります（接続がtorを通過します）。
また、他のディストリビューションよりも2つのディストリビューションをよく知っているので、詳しく説明します。
私が聞いたことから、Debianは reproducible-build を十分な数のパッケージが再現可能になった後でポリシー要件にします。
Guixは guix challenge コマンドを実装しているため、Hydraの公式ビルドでローカルビルドのハッシュを確認できます。
私は「専門家」ではなく、いくつかのツールの一般的なユーザーです。
再現可能なビルドについての共有はもう少し、コメントが適切な場所ではなかったため、ここで共有しています。私が理解し、使用し、実験したことのほとんどから、それが何をするのかは、.buildinfoテキストファイルと共に.debパッケージを提供します。 buildinfoテキストファイルには、バイナリを作成するためにビルド環境で必要なすべてのライブラリの名前とバージョン番号が含まれます。
そのため、buildinfoテキストファイルが含まれている（アーカイブから、または外部から）バイナリパッケージについて疑わしい場合、正確なビルド環境を再作成して最終版のハッシュを比較することでパッケージをテストするのは簡単ではないかもしれませんバイナリパッケージ。
より多くの人々がジャンプしてハッシュが一致すると言うことである程度信頼性を高めることができるように、ある種の信頼の網を持つことも可能かもしれませんおそらく。私が知らないEdgeケースがあるかもしれません。