MACと機能の実際的な違いは何ですか
必須アクセス制御と機能の両方で、実行中のユーザーが継承した特権に関係なく、または特権の代わりに、きめ細かな特権をアプリケーションに割り当てることができます。
これらの2つのアプローチの間に実際的な違いはありますか？たとえば、機能ベースのオペレーティングシステムは渡されるトークンに依存することができ、SELinuxなどのMACシステムは基本的にACLに依存することができることを理解しています。
ただし、実際には両方の手法を使用すると、アプリケーションはきめ細かな権限で制限されます。実践的な観点から見たアプローチに違いはありますか？
機能はより強力と見なされます。これらは、アプリケーションが他のユーザーの代わりに機能する混乱した代理攻撃を防ぎ、アクセス許可を削減および委任するための明確なパラダイムを提供します。これは、Androidまたはマイクロカーネルシステム）のように、アプリケーションが相互に通信するシステムで重要です。実際、NICTAは、seL4セキュリティの証明の結果として、機能が機能がなければ、リファレンスモニター（OS、マイクロカーネル）がMACテーブルのすべてのアプリケーションを検索できるように、グローバルネームスペースが必要です。
ミラーらによる「能力神話解体」いくつかの主要な概念の概要を説明します。ただし、Usenix Securityでの提出の試みから得られたレビューを検討することもできます。 http://www.eros-os.org/pipermail/cap-talk/2003-March/001133.html
私が最初にあなたが意味した機能を誤解したので（申し訳ありませんが、Linuxは正解です！）個人的にはまだ何も明らかにされていないので、別の答えを使用します。
まず最初に、アクセス制御の土地での物事のあり方。
- アクセス制御は特定の種類のサブジェクト間で委任されるため、任意アクセス制御 はこのように呼ばれます。具体的には、ある種類の主題はユーザーであり、別の種類はプログラムです。ユーザーがプログラムを実行すると、プログラムは原則としてユーザーの権限を「継承」します。
必須のアクセス制御 はより細かい粒度です。各プロセス（またはスレッド、またはサブジェクトのより細かい定義）には独自の権限が与えられ、それらを実行したユーザーから（理論上）何も継承しません（したがって必須ではありません）。重要なのは、提供されたポリシーで指定されている場合を除き、継承しないことです。この分野の要は、 Type Enforcement の概念です。この論文のアイデアは、SELinuxポリシーと非常によく似ています。基本的な概念は、型のスコープが非常に広いか、範囲が非常に狭く、プロセスまたはアプリケーションドメイン（サブジェクト）に型（オブジェクトコレクション）へのアクセス権を与えることです。
MLS、MCSなどはMACと密接に関連していますが、追加のカテゴリアクセスまたは読み取り/書き込みなし、またはその両方でタイプとドメインを拡張することがよくあるため、このようなシステムはTEなしのMACではありません。この例は 必須の整合性制御 であり、Windowsのシステムであり、基本的な読み取り、書き込み不可の権限を実装していますが、TEはありません。 。 [〜＃〜] te [〜＃〜] の別のリンク。
[〜＃〜] rbac [〜＃〜] は似ていますが、上記の2つとは異なります。だから私は発散しないでください。 Windowsのユーザーグループについて考えてみましょう。
これらすべてのケースで、保護されたリソースにアクセスするプロセスは次のようになります。
- リソースをリクエストします。
- OSを入力してください。 OSはACLを調べ、アクセスを許可するかどうかを決定します。
- OSが応答します。その後、プロセスは違いを解決します。
概念的には、これは電話で必要なものを要求するようなものです。上記のシステムはすべてこれに基づいて機能します。呼び出し音が鳴り、オペレーターが質問を聞いて保留にし、上司または一部のレコードを調べて、応答を返します。
機能は異なります。能力は仕事のパスを持つようなものです。正しい番号が記載されたパスを振って現れると、目的地にたどり着きます。実際、適切に拡張するには、ニーズごとに1つずつ、複数のパスを持つようなものです。それらのニーズがどれほどきめ細かいかはシステム設計の選択なので、今すぐ質問に答えてください。どちらのシステムでも、DACの処理に加えてプロセスを制限できます。
問題は、「まあ、私のパスで確認できますが、まだ確認する必要があります。これは、電話での確認を意味します」（オペレーティングシステムで確認する必要があります）。はい、そうです;しかし、これは機能ベースのシステムの裏側です：
- このトークンは、ユーザープロセスで変更できないようにする必要があります。ここでの類似物は、エンドユーザーが改ざんできない追記型ストレージです。このようなセキュリティを保証するように、これは難しい問題です。
- トークンを渡すことは、パスを他の誰かに渡すのと同じように機能する必要があります。あなたがそれについて考えるならば、これは理にかなっています-ある時点で、誰か、どこかで、信頼できる人が必要なパスをすべて作成し、それらを配り始めなければなりませんでした。
プログラムが保持するこれらの機能を保護することは難しい部分です。実際、 ハードウェア拡張機能 が議論されてきましたが、ほとんど実装されていません。 this.joshが（+1）について説明しているように、 L4.sec はIPCを使用して機能を転送します。与えられたIPCは、システムの残りの部分が機能するためにL4スーパーバイザコアによって提供される関数です（L4はマイクロカーネルなので、 ほとんどのシステムはIPC ）、そのスーパーバイザコアはIPCを使用して、転送中の機能の整合性をチェックし、受信プロセスに適用できます。
とにかく、トピックに戻ります-機能ベースのシステムでは、機能管理が完全なものである必要があります。トークンを保持している場合は、信頼されます。
彼らは同じに見え、同じにおいがしますか？まあそれはすべて表面上のアクセス制御の形式ですが、基礎となるメカニズムは完全に異なる概念です。 1つのシステムで、要求をチェックします。他のトークンには鍵があり、あなたはあなたの人生でそれらの鍵の完全性を守ります。
MACは、その学術的な形式では、アクセス制御ではなく、情報の流れについてのものです。これは、機能とは根本的に異なるアプローチです。 MACは、完全性と機密性のどちらが心配されているかに応じて、情報フローが高レベルから低レベル、または低レベルから高レベルに流れるのを防ぐことを目的としています。そのように階層的です。能力は私が理解している範囲ではありません。オブジェクトがフラットモデルで実行できるアクションを定義するだけです。
実用的なレベルでは、MAC（SELinuxで実装されている）では、システム内のすべてのオブジェクト（ファイル、ディレクトリ、プロセス、およびユーザー）にラベルを付ける必要があります。特に指定されていないオブジェクトにはデフォルトのラベルが付けられます。また、許可されたアクセスのラベル付きオブジェクトのタイプを説明するポリシーも必要です。モニターはアクセス要求を監視し、ラベルを要求されたアクセスと比較します。新しいタイプのオブジェクトでは、ポリシーの書き換えと、システム上のすべてのオブジェクトのラベルの変更が必要になる可能性があります。
機能（L4REで実装）には、リソース（メモリ、処理、I/O）の必要性とアクセスを許可するサービスのプログラムを明示的に示すために、個々のプログラムまたはサービスが必要です。プロセス間の通信チャネルが監視され、IPCを介したアクセスは、メッセージの送信者と受信者が属するプログラムと、各プログラムが他のプログラムに付与した機能に基づいて許可または拒否されます。
MACでは、システム全体を説明するために高レベルのアーキテクトが必要ですが、設計をいくつかの特定の高価値制御に集中させることができます。ただし、システムへの大幅な変更のコストは高くなります。
能力は、すべてのプログラムが一般に他のプログラムとどのように相互作用するかについての低レベルのビューを必要としました。初期費用は高いですが、大きな変化への対応は低いです。
SELinuxのようなMACシステムでは、Firefoxが任意のフォルダへの書き込みアクセス権を持つことを防ぐことができます。
SELinuxを使用すると、Firefox（またはその他の不正なアプリケーション）が特定のラベルが付いたフォルダーへの書き込みアクセス権を持つことを防止できます。他のフォルダには、Firefoxがアクセスできるようにするラベルが付いている場合があります。
アプリケーションがそのアクセスを機能として事前に要求した場合、これは機能ベースのオペレーティングシステムでは機能しませんか？機能ベースのオペレーティングシステムでそのようなアクセスを制限する方法はありますか？
機能ベースのオペレーティングシステムでは、（カーネルではなく）ファイルシステムを実装する人なら誰でも、個々のフォルダを制御できる機能を提供できます。ファイルシステムは、その機能をユーティリティに委任して、ユーザーが個々のフォルダにアクセスを設定できるようにすることができます。したがって、ユーザーは、任意のWebブラウザーアプリケーションがフォルダーまたはフォルダーセットへの書き込みアクセスを許可されないように指定できます。一般的なクラスのWebブラウザーを、HTMLを生成および消費するプロセスとして定義する方が、Firefoxを指定するよりも簡単な場合があります。
機能ベースのOSには、必ずしもユーザーの階層（管理者、ルート、アプリケーションユーザーなど）がないことに注意してください。アクセスの制限は、個々のプロセスがカーネルおよび他のプロセスの正しい動作を妨げないようにすることに重点が置かれています。アクセスを許可するには、2つのプロセス間の調整が必要です。
テキストエディターは、ファイルシステムからフォルダーへの書き込みアクセスを要求する方法を知っている必要があり、ファイルシステムは、テキストエディターへの書き込みアクセスを許可するが、Webブラウザーへの書き込みアクセスを拒否する方法を知っている必要があります。サービス（ファイルシステム）が条件1（テキストエディター）へのアクセスを許可し、条件2（Webブラウザー）へのアクセスを拒否するというポリシーの暗黙の概念はまだあります。