やる気
システム内のデータのセキュリティとプライバシーを確保するためのほぼ唯一の方法は、認証（「誰がそれを言ったのですか？」）および承認（「彼はこのデータを処理する権利を持っていますか」）と見なされます。 つまり プログラムが何らかのデータにアクセスする必要がある場合、実際には2つのオプションがあります。拒否するか、信じるのです。 このプログラムを信頼しない場合、それを使用する機会を失い、重要な機能を失う可能性があります。 プログラム（および/またはその開発者）を信頼すると判断した場合、プログラムは実際にこの情報（またはコピー）の「主権者」になります。 文学におけるそのような原則は、All-Or-Nothing-「All or Nothing」と呼ばれます。
当然、この原則は十分な柔軟性がなく、さらに、バッファオーバーフローなどのシステムの多くの脆弱性の主な原因です。 一般に、この原則では、アクセス権が従来のアプリケーション（「アクセスなし」、「読み取り専用」、「読み取り/書き込み」）に限定されない、より興味深いアプリケーションを作成することはできません。 データへのアクセス権をより柔軟に区別できるシステム、つまり情報フローの管理をサポートするシステムがあることがわかりました。 これらのシステムの最も重要な機能は、システム内のライフサイクルを通じてデータを追跡することです。 従来、システムはデータへの初期アクセスのみに責任があることを思い出してください。たとえば、プログラムがファイルにアクセスできるかどうか、プログラムがこのデータをどう処理するかをチェックすることは、システムには関係ありません。
古典的な例。 システムにアリスとボブの2人のユーザーがいるとしましょう。 彼らは予約をしたいのですが、彼らの週間スケジュールについてあまり多くの情報を明らかにしないように。 マルチユーザーLinux / Unix / Windowsシステムでプログラムを作成して、AliceとBobの両方のカレンダーに同時にアクセスし、システムの両方のユーザーの機密性を保証することは可能ですか？
最も簡単な方法は、「スーパーユーザー」にそのようなプログラムの作成を依頼するか、少なくとも既存のソリューションに権利を正しく割り当てることです。 ただし、このパスでは少なくとも2つの問題が発生します。
1.プログラムに論理エラーが含まれていないこと、たとえば、Aliceのデータを他の場所にコピーしていないこと（または管理者が権限を誤って割り当てること）の保証はありません。
2.「スーパーユーザー」に100％信頼する必要があり、さらに、このようなプロセスは非対話型です。 管理者がそのようなプログラムを作成するか、権限を設定するまで待ちます。
最初の問題の解決は、情報フローの管理をサポートするシステムを使用して実行されます。
一般に、情報フローの管理をサポートするシステムは、従来、集中型と分散型（分散型）の2つのカテゴリに分類されます。 有名なSELinuxとAppArmorは 、集中型として分類されています。 同じ記事で、Flume OSを研究として使用する分散システムについて話そうとします（したがって、残念ながら実際の使用にはまったく適していません）。 彼女との「コミュニケーション」の経験がありました。 分散システムを使用すると、スーパーユーザーへの依存という2番目の問題を取り除くことができます。
（分散）情報フロー制御
要するに、情報の流れを制御するという考え方は簡単であり、送信者から受信者へのシステム内のデータの流れを追跡することにあります。 システムの主なタスクは、不正なデータ漏洩を防ぐことです。 一般に、プログラム（「特権」を除く）は、プライベートデータとモニター、プリンター、ソケット（AF_INET）などの「情報のシンク」（シンク）に同時に（プログラムライフのコンテキストで）アクセスできません。 つまり プログラムが個人ファイルを1回読み取った場合、その後、システムはこのプログラムがネットワークにアクセスすることを許可しません。
データをプライベートにするには、たとえば特別なフラグ/タグを使用して、これを明示的に指定する必要があります。 集中システムと分散システムの主な違いは次のとおりです。 最初のケースでは、データの正しい「タグ付け」とそのようなデータへのさまざまなプログラムのアクセス権の決定を担当する「セキュリティマネージャー」という特別なユーザーがいます。 たとえば、パスワードまたは個人所得情報を含むファイルに「トップシークレット」タグを割り当てて、権限のないVim / Emacsのみにアクセスを許可できます。（1）このデータをどこにでもエクスポートし、（2）これらのタグを削除します。 したがって、テキストエディタを危険にさらしても、システム（システム自体が安全でエラーなしで動作すると仮定）は、これらのファイルをシステム内のどこかに（/ tmp）他のより寛容なタグで保存し、何らかの方法で送信することを許可しませんインターネットで。 私はSELinuxを使用していなかったため、詳細については公式マニュアルを参照してください。
分散システムでは、任意のプログラム/エンティティが独自のタグを作成し、権利を割り当て、他のプログラムのデータへのアクセスを許可できます。
Flume OSでは、タグを作成して個人データにアクセスできます。 そして、あなたには選択肢があります。 このタグの割り当てにパブリックアクセスを許可したり、削除したりできます。 タグtag1を作成し、パブリックアクセスの権利{tag1 +}を付与すると、どのプログラムでもこのタグを独自のタグセットに配置できるようになります。 ファイルFを作成してtag1タグに関連付けると、プロセスp1はこのtag1をタグセットに含めることができ、その後tag1でマークされたすべてのデータを読み取ることができます。 ただし、{tag1-}はパブリックドメインにないため、このプロセスはタグセットからtag1を削除できず、今後はプロセスp1の類似セットのスーパーセットであるタグセットを使用してプロセスとのみ通信できます。
原則として、受信者が少なくとも送信者と同じ（またはそれ以上）のラベルセットを持っている場合にのみ、プロセスがメッセージを別のプロセスに送信できること、および空でないセットを持つプロセスが「 「情報」（誘導マットにより、このような条件のシステムが安全であることが証明されます）。 免責事項：元の記事には、より正式な言葉遣いがあり、セキュリティタグに加えて、整合性タグの概念がまだありますが、この記事では説明しません。
Flumeは、情報の流れの「正確さ」を保証する開発されたシステムの1つです。 システムレベルでは、Flumeは修正されたLSMシステムを備えたLinuxであり、基本的なシステムコールをインターセプトし、タグ、タグに関する情報を保存し、あるプロセスから別のプロセスへの正しいデータフローをチェックします。
アリスとボブのカレンダーの例に戻りましょう。 Flumeでは、アリスがカレンダーにタグAを割り当て、ボブを彼女に割り当てます-タグB。アリスは{A +}のパブリックアクセスを与え、ボブは{B-}を与えます。 ボブは、{A、B}というラベルのプログラムを実行します。つまり、 両方のカレンダーにアクセスできます。 このプログラムは、アリスもボブもビジーではないいくつかの便利な時間間隔を見つけ、タグB（パブリックドメインの{B-}）を削除し、結果をファイルFに書き込みます。ファイルFは自動タグA（{A-}オープンアクセス）。 アリスはファイルFを開きます。 彼女はタグAの所有者であり、「Suggested by Bob」のリストから特定の日付を選択します。 念のため、{B +}はパブリックドメインではないため、アリスはボブのカレンダーを読むことができません。
おわりに
残念ながら、DIFCのアイデアの適用可能性のすべての領域をカバーすることはできません（問題の動機付けとして使用したものも含めて）。 このトピックに興味がある場合は、たとえばMITのResinフレームワークについて、より詳細/正式に話すことができます。 かつて、私は幸運にも、情報の流れを制御するトピック、他のタスクへのこれらの原則の適用性についてバーバラリスコフ （おそらくこの分野の主要な当局の1つ）と話をすることができ、単にこのトピックにうんざりしていました。 このアイデアの開発には、いくつかの興味深い「ビジョン」があります。W5 （壁のないワールドワイドウェブ）またはFabricです。 しかし、これは全く異なる話です...