👩🏽‍🔬 🤜🏼 🔈 必須リンクに基づくセキュリティの概要（機能ベースのセキュリティ） ➰ ✨ 🎆

現在のほとんどのオペレーティングシステムでは、セキュリティモデルはUnixに根ざしており、ユーザーが実行するプログラムを信頼できるという前提を継承しています。しかし、実践が示すように、この声明は基本的に間違っています。

マーク・スティーグラーは、これを管理人を雇ってマスターアンドオンリーキーを与える状況と比較します。マスターアンドオンリーキーは、掃除する部屋を開くだけでなく、そして金の金庫のドア。つまりクリーナーに鍵を渡さないという2つの選択肢しかありません。そうすれば、彼は仕事をすることができなくなります。

機能ベースのセキュリティモデルは、この問題の解決策を提供します。

モデルは、最小特権の原則に基づいています。たとえば、テキストエディターでファイルを開くと、エディタープログラムは特定の1つのファイルのみにアクセスできます。プログラムが期待どおりにファイルを編集するかどうかはまだわかりませんが、ファイルを暗号化せず、復号化にお金が必要になりますが、レートは現在大幅に低くなっています。

既定では、すべてのプログラム（および理想的には任意のコード）は理想的なサンドボックスで実行されます-ファイルシステム、ネットワーク、または他のプログラムにアクセスできません。一部の実装では、メモリを割り当ててプロセッサリソースを消費する権利すらありません！

プログラムは、外部リソースへの必須リンク（Eng。機能、POSIX機能と混同しないでください）を使用して、サンドボックスを超えることができます。

これまでのところ、この主題に関するロシア語の文献はまったくありません。そのため、この記事を書くには、「能力」という用語の翻訳を自分で発明しなければなりませんでした。だから、知り合いになる：

信任状リンクは、最初にオブジェクトを識別する（したがって「リンク」）、次にそのオブジェクトで許可される操作（したがって「信任状」）を定義する特別な形式のリンクです。必須リンクは共存でき、同じオブジェクトを参照しますが、有効な操作の異なるセットを指定します。

必須リンクを所有しているユーザーは、このリンクで許可されているオブジェクトに対して常に操作を実行できます。操作中に追加のチェックは実行されません。すべてのチェックは、サブジェクトが必須リンクを受信する前に行われます-彼がそれを受信した場合、これはすべてのチェックがサブジェクトによって渡されたことの証明として機能します。

比較のために、文字列形式のファイルへのパスはオブジェクトを識別しますが、そのオブジェクトに対する有効な操作を決定しません-したがって、特定の方法でファイルに対して操作が実行されるたびに、OSはアクセス制御チェックを実行する必要があります。

一方、開いているファイル記述子は必須リンクと見なされる場合があります。記述子が作成される前にアクセス制御が行われ、ファイルが開かれたモードは記述子に関連付けられたデータ構造に格納されます。

必須の参照に基づいたセキュリティ文献では、「リソース」および「サブジェクト」という用語（ PDF ）を見つけることができます。「リソース」は、参照されたリンクが指すオブジェクトが果たす役割です。「サブジェクト」とは、必須リンクを持ち、リソースに対して操作を実行できる人です。サブジェクトとリソースの間には多対多の関係があります。各サブジェクトは異なるリソースへの任意の数の必須リンクを持つことができ、任意の数のサブジェクトは1つのリソースを参照できます。

一部の実装では、「対象」と「リソース」は、コンテキストに応じて同じオブジェクトが果たすことができる役割です。他では、これらは異種オブジェクトですが、一種のリソースは別のサブジェクトとの通信チャネルです。何らかの方法で、オブジェクトは必須リンクを使用して相互に通信できます。リンクを所有するオブジェクトは、OOPのように、参照先オブジェクトにメッセージを送信できます。将来的には、表示の便宜上、オブジェクトは同種であると仮定します。「対象」と「リソース」は、状況に応じた役割にすぎません。

モデルは、オブジェクトの内部状態がカプセル化され、メッセージを送信しない限り変更できないと想定しています。

必須リンクの動き

オブジェクトは、限られた数の方法で必須リンクを受信できます。

初期条件の一部として、システムの初期化（たとえば、OSのインストール）時に、オブジェクトの特定の初期グラフが作成されます。これは、ここで説明する規則に従ってさらに開発されますが、初期グラフはチート方法を使用して作成できます。
新しいオブジェクトを作成する場合 - 新しいオブジェクトを作成する操作は、利用可能な権限の最大量を備えた必須リンクを返します。
持参金 -子オブジェクトを作成することで、親は利用可能な権限の一部を転送できます（OOPの用語でコンストラクター引数を渡します）
相互の知り合いを通じて -アリスがボブへのリンクを持っていない場合、キャロルは（彼女が望むなら）彼女にこのリンクを与えることができます。これを行うために、OOPの用語では、キャロルはメッセージをアリスに送信し、パラメーターとしてボブへのリンクを渡します。

これは、キャロルにアリスとボブの両方への必須の参照がある場合にのみ発生します。アリスへの参照は、このメッセージの送信を許可するはずです。キャロルは、ボブにアクセスする権限を、彼女が持っているよりも大きい範囲に移すことはできません（多分、少ない範囲ですが、それについては後で詳しく説明します）。

これらの規則により、検討中のシステムをオブジェクトのグラフとして提示し、既存の通信チャネル、および新しい接続の出現の場所と条件を正式に分析できます。

モデルの観点から見ると、グローバル変数の全体（従来のファイルシステムを含む任意の形式）は、誰でもアクセスできる単一のオブジェクトです。そのようなオブジェクトの存在はモデルと矛盾しませんが、システムのセキュリティの穴です。標準Javaライブラリでのシングルトーンの負荷とグローバルファイルシステムアクセスは、 J-Kernelシステムの作成者にとって深刻な問題になっています。 .NETプラットフォームにも同じ問題が存在します。

ご覧のように、上記のルールはシステム全体にアクセス権をどのように分配できるかを説明していますが、以前に付与された権限をどのように調整できるかは説明していません。実際、必須リンクに基づくセキュリティモデルは、一度付与された権利を選択できなくなるという仮定から始まります。このプロパティはモデルに対する批判の原因ですが、実際には問題ではありません（ PDF ）。

「ファイルを読み取る」権利を与える代わりに、プログラムは「アクセスが取り消されるまでファイルを読み取る」権利を与えられます。これは、プロキシオブジェクトを使用して実装されます。以下のコードは、このメカニズムを非常に単純化された形式で示しています。

using System; using System.Collections.Generic; namespace CapRevokeDemo { //  ,      interface IFile { char read(int index); int length { get; } } //  ,    interface IApplication { void openFile(IFile reader); } class FileAlreadyExistsException : Exception { } class FileNotFoundException : Exception { } class AccessRevokedException : Exception { } // ,       class FileManager { public FileManager() { files_ = new Dictionary<string, IFile>(); openedFiles_ = new Dictionary<string,List<FileProxy>>(); } public void addFile(string fileName, IFile reader) { if (files_.ContainsKey(fileName)) { throw new FileAlreadyExistsException(); } files_.Add(fileName, reader); } public void openFileInApplication(string fileName, IApplication app) { IFile reader; if(!files_.TryGetValue(fileName, out reader)) { throw new FileNotFoundException(); } FileProxy proxy = new FileProxy(reader); List<FileProxy> proxies; if(!openedFiles_.TryGetValue(fileName, out proxies)) { proxies = new List<FileProxy>(); openedFiles_.Add(fileName, proxies); } proxies.Add(proxy); app.openFile(proxy); } public void revokeAccessToFile(string fileName) { List<FileProxy> proxies; if(openedFiles_.TryGetValue(fileName, out proxies)) { foreach(FileProxy proxy in proxies) { proxy.revokeAccess(); } openedFiles_.Remove(fileName); } } // -,      . private class FileProxy : IFile { public FileProxy(IFile file) { file_ = file; } public char read(int index) { if(file_ == null) { throw new AccessRevokedException(); } return file_.read(index); } public int length { get { if(file_ == null) { throw new AccessRevokedException(); } return file_.length; } } public void revokeAccess() { file_ = null; } private IFile file_; } private Dictionary<string, IFile> files_; private Dictionary<string, List<FileProxy> > openedFiles_; } //   class Program { class DemoFile : IFile { public DemoFile(string data) { data_ = data; } public char read(int index) { return data_[index]; } public int length { get { return data_.Length; } } private string data_; } class DemoApp : IApplication { public void openFile(IFile file) { file_ = file; index_ = 0; } public void closeFile() { file_ = null; index_ = 0; } public void read() { char c = file_.read(index_++); System.Console.WriteLine("c = {0}", c); } private IFile file_ = null; private int index_ = 0; } public static void Main(string[] args) { try { FileManager manager = new FileManager(); manager.addFile("file", new DemoFile("SECRET")); DemoApp app = new DemoApp(); manager.openFileInApplication("file", app); app.read(); app.read(); app.read(); manager.revokeAccessToFile("file"); app.read(); } catch(Exception e) { System.Console.WriteLine("Exception: {0}", e.Message); } } } }

私はこのアプローチからアクセスを取り消す可能性が前もって世話をされなければならないという結果に注目したいです。これに対して対策が講じられていない場合、事後にそれを行うことは不可能です！

プロキシオブジェクトは、時間だけでなく、他のパラメーターによってもアクセスを制限するために使用できます。ファイルの一部にのみアクセスを提供したり、読み取り/書き込みアクセス権がある場合は、読み取り専用アクセスを許可するプロキシオブジェクトを作成できます。このようにして、サブジェクト領域に固有のアクセス権を設定できます。ドキュメントにコメントを残すことはできますが、ドキュメント自体の内容を変更することはできません。従来のシステムでは、これらの操作を分離することはできません-OSレベルでは、どちらもバイナリファイルの変更のように見えます。

プロキシオブジェクトは再帰的に適用できます。1つのオブジェクトはその権利の一部を別のオブジェクトに委任し、2番目は3番目に委任します。各ステップで、権利の一部のみが転送され、残りはプロキシオブジェクトを使用して切断されます。接続ごとに、使用できる特権の量はますます少なくなっています。これは、アクセス許可の減衰と呼ばれます。

偽造セキュリティ

委任リンクには、偽造からの保護という重要なプロパティが必要です。上記の規則に従って提供されなかった必須リンクを「推測」することは不可能です。

記述子の場合、このプロパティは1つのプロセスのフレームワーク内では正しくありません。記述子コードを生成する原理を知っていれば、許容可能な時間内に正しい記述子を作成することができます。つまりホストプロセスに読み込まれたプラグインは、ホストプラグインインターフェイスを介してアクセスできなかったデータにアクセスできます。

ファイルパスの場合、このプロパティは原則として満たされていません-コードに「C：\ Windows \ system32 \ drivers \ etc \ hosts」と記述するだけで、重要なシステムファイルへのリンクが既にあります。

必須リンクを偽物から保護する方法は？これを確実にするために、私は4つの主要なアプローチを知っています：

記述子としての資格-プロセスはオブジェクトです。必須リンクを使用したすべての作業は、OSの機能を介して実行されます。 OSはプロセスごとに、現在利用可能な必須リンクのリストを保存します。プロセスは、このリンクが対応するリストにある場合にのみ、必須リンクで操作を実行できます。
暗号化ツール -このアプローチは、リンクを偽造できないという絶対的な保証を与えるものではなく、代わりに必要な最小限の偽造の複雑さを提供します。このプログラムは、OS機能への暗号化された必須リンクを提供します。OS機能は、その正確性を確認し、使用前に復号化します。必須リンクの暗号化/復号化のオーバーヘッドが大きいため、この方法は同じマシン内でセキュリティを実装するために使用されるのではなく、ネットワークシステムで使用されます。
パスワード付き必須リンク（英語のパスワード機能） -前の2つの方法のハイブリッド（詳細はこちらとこちら）。資格情報リンクは、識別情報とパスワードで構成されます。パスワードは、システムによって生成されるビットのランダムなシーケンスです。パスワードを推測する確率は2 ^-kで、kはパスワードの長さです。システムは、パスワードと識別情報を関連付ける辞書を保存します。資格情報リンクのパスワードが辞書のパスワードと一致する場合、資格情報リンクは正しいと見なされます。
コマンド/言語システムのレベルでの保護 -通常、ターゲットマシンのコマンドシステムには、任意のビットシーケンスを必須リンクとして解釈できるコマンドが含まれていないか、そのようなコマンドは特権があり、カーネルのみがアクセスできます。この場合、ターゲットマシンは、実デバイス（ Plessey System 250 、 IBM System / 38 、RSRE FLEX Computer System）または仮想マシン（ J-KernelプロジェクトはJVMに基づいて実装されます）のいずれかです。

連載

実用的な適用性のために、必須リンクに基づいてセキュリティを実装するシステムは、後者のシリアル化をサポートする必要があり、これは非常に重要なタスクです。システムは、必須リンクのシリアル化されたイメージが改ざんされていないこと、リンクが指すリソースがまだ存在していること、逆シリアル化を実行するプロセスが実際にシリアル化を実行したプロセスの復活であることを確認する必要があります。

これらすべての問題に対する優れたソリューションとして、 透過的または直交永続 性のメカニズムが確立されています。オペレーティングシステムは状態の保存と復元をすべて行い、アプリケーションは抽象永続単一レベルメモリで動作します。オペレーティングシステムは時々、すべてのプロセスの状態の完全なスナップショットをディスクに保存し、起動時に、正常に保存された最新バージョンをメモリにロードします。同時に、プログラムはディスクに直接アクセスできず、プログラムによってディスク上のシリアル化されたイメージを偽造することはできません。

投獄

アリスがボブによって作成されたプログラムを使用してデータを処理するとします。ボブは、誰も彼のプログラムの内部にアクセスしたくない。さらに、ボブは自分のプログラムをデータでパラメーター化することもできます。これは、実行可能コードを含むバイトの配列としてではなく、オブジェクトとしてプログラムをアリスに提供する機会です。しかし、アリスは、このプログラムが機密データを部外者に転送しないことを確認したいと考えています。また、オブジェクトは他のオブジェクトへのリンクを保存したり、他のオブジェクトが読み取れる可変状態を持つことができます。この場合のオブジェクトの使用は、アリスの安全にとって危険です。

Aliceに渡されるオブジェクトに制限を課すことは、このシナリオでAliceがこのオブジェクトを安全に使用できるようにすることを、オブジェクトの制限と呼びます。

上記のモデルの枠組み内に閉じ込めることを可能にする特許取得済みのソリューションがあります。ただし、このソリューションの作成者自身が指摘しているように、よりエレガントでシンプルなソリューションは、推移的不変の属性を導入することであり、その正確性はシステムによって保証される必要があります。これにより、プログラムが単にアリスの機密データを書き込む場所を持たないことが保証されます。この場合、Aliceが可変状態のオブジェクトを必要とする場合、Aliceに転送されるオブジェクトはファクトリーとして設計され、ファクトリーに含まれるデータとAliceが提供するデータから新しいオブジェクトを作成する必要があります。

おわりに

必須の参照セキュリティモデルにより、相互に疑わしいコンポーネントが安全に通信できます。このモデルにより、結果を恐れることなく、未知のソースからマシン上で任意のコードを安全に実行できます。これは、従来のシステムでは考えられません。このモデルは、任意の特権でシステムの任意のコンポーネントで使用できますが、従来のシステムでは、新しいユーザーとグループを作成するには管理者特権が必要です。

私の意見では、必須リンクに基づくセキュリティは、OOP、言語ベースのセキュリティ、および直交永続性とともに最も便利かつエレガントに実装されます。これらすべての概念を実装するプラットフォームが、OSの進化の次の章を書くと信じています。しかし今のところ、必須リンクに基づくセキュリティは、実験的なOSの運命のままです。必須リンクのアイデアに読者が興味を持って、そのようなプロジェクトがマスOSになる日を少しでも近づけることを願っています。

必須リンクに基づくセキュリティの概要（機能ベースのセキュリティ）

必須リンクの動き

偽造セキュリティ

連載

投獄

おわりに

参照：

More articles: