test

Trusted Solaris 管理の手順

第 16 章 ソフトウェアの追加

この章では、次の項目について説明します。

この章では、次の操作手順について説明します。

用語と概念の確認

セキュリティ管理者は、次のタイプのソフトウェアを追加することができます。

この章では、Trusted Solaris システムで使用する、コマンド、アクション、スクリプトの作成方法や使用方法が、標準 Solaris の場合とどう違うかをまとめています。また、特権がコマンドやアクションによってどのように使用されるかを確認し、次の作業を行う方法を紹介します。

デフォルトのシステム構成では、セキュリティ管理者役割とシステム管理者役割の両方が、次の処理を行えます。

通常、プログラムやスクリプトのインポート、作成、使用の前に、セキュリティ管理者役割による審査は必要ありません。ただし、そのソフトウェアが次の条件を満たしている場合に限ります。

ソフトウェアの作成と使用の制限

セキュリティ管理者役割は、デフォルトのシェルとしてプロファイルシェルをユーザーに割り当てることによって、プログラム、アクション、およびスクリプトを作成できるユーザーを制御できます。All Commands プロファイルは、すべてのコマンドへのアクセスを許可します。All Actions プロファイルは、すべてのアクションへのアクセスを許可します。All プロファイルは、すべてのコマンドおよびアクションへのアクセスを許可します。

ユーザーまたは役割アカウントが「アクション作成 (Create Action)」アクションなどのファイル編集ツールへのアクセス権を持っていない場合、そのアカウントはアクションを作成できません。アカウントがアクションを作成できる場合でも、セキュリティ管理者役割の協力がなければ、アカウントは新しいアクションを使うことができません。すべてのユーザーが新しいアクションを使えるようにするには、セキュリティ管理者役割は、そのアクションを 1 つまたは複数のプロファイルに追加し、そのプロファイルをアカウントに割り当てる必要があります。あるいは、セキュリティ管理者役割は、All プロファイルまたは All Actions プロファイルのいずれかをアカウントに割り当てることもできます。

ソフトウェアのインポートの制限

同様の機構が、プログラム、アクション、スクリプトのインポートを制御するためにも用意されています。セキュリティ管理者は、個々にデバイスの割り当て承認を付与したり取り消したりすることで、ソフトウェアを導入できるユーザーを制御します。デバイスの割り当て承認を付与されたアカウントの場合、データのインポートまたはエクスポートを認可上限内の単一機密ラベルに制限されます。

特権

特権を持っているということは、セキュリティポリシーのある面を無効にする権限があるということです。

標準の UNIX システムでは、ユーザー ID 0 で実行されるコマンドにはスーパーユーザーの全権限があるのに、それ以外のユーザー ID で実行されるコマンドには権限がありません。一方 Trusted Solaris システムでは、どのユーザー ID を使用するコマンドでも、標準の UNIX システムのスーパーユーザーに割り当てられた権限の一部を使用するように構成することができます。 Trusted Solaris システムでは、UNIX のスーパーユーザーの権限 (アクセス制限の回避、制限されたコマンドの実行、他のユーザーが使用できないコマンドオプションの使用など) は、特権に置き換えられます。標準 Solaris のオペレーティング環境やその他の UNIX オペレーティングシステムのスーパーユーザーが、すべての DAC 制限を回避する権限をはじめ、システム内のすべての特権を持っているのに対し、Trusted Solaris の特権機構では、スーパーユーザーの権限を細分化し、MAC 制限を回避するために必要な補助的な権限を提供します。特権を個々に付与することで、プログラムに不要な特権は付与せず、作業上必要な特権だけを割り当てます。

必須特権

コマンドやそのオプション、アクションなどを正しく実行するために特権が必要な場合、その特権を必須特権といいます。必須特権を使用できない場合は、コマンド、オプション、アクションは全く動作しません。必須特権は、次の文に示すように、マニュアルページ上では、「必要です (must have)」という言葉で表されます。「ifconfig(1M)コマンドには、ネットワークインタフェースを変更するためのsys_net_config 特権が必要です。」

無効化特権

コマンドまたはアクションがセキュリティポリシー内で動作するように設計されていて、特定の DAC または MAC の検査に合格しないとエラーになるときは、セキュリティ管理者役割の判断で、無効化特権を割り当てることができます。アクセス制限を無効化するために使用される特権の名前は、マニュアルページ上では、「エラー (ERRORS)」の節に記述されています。

DAC 無効化特権は、file_dac_read と file_dac_write です。MAC 無効化特権は、file_mac_read と file_mac_write です。セキュリティ管理者役割は、ユーザーがファイルへの DAC または MAC アクセス権を持っていない場合、どちらのアクセス権を適用するか、読み取り、書き込みのどのアクセス 権が必要かによって、コマンドやアクションにこれらの無効化特権の 1 つまたは両方を割り当てることができます。

特権の割り当て以外の方法

コマンドまたはアクションを実行するためには、無効化特権を割り当てる以外の方法もあります。セキュリティ管理者役割は、次のオプションを利用することができます。

セキュリティ管理者役割は、特権の使用を避けるために、コマンドやアクションが他のユーザー ID や代替グループ ID を使用して実行されるように構成したり、他の ID のアクセス権や ACL に基づいてファイルまたはディレクトリにアクセスするように設定します。呼び出したユーザーの実際の UID (GID) 以外の UID (GID) を使ってソフトウェアを実行することを、「実効 UID (GID) を使って実行する」といいます。コマンドやアクションが MAC 無効化特権を付与する必要のない機密ラベルで実行されるように指定することもできます。

最少特権の法則

最少特権の法則とは、システム内の各コマンドまたはアクションに、ユーザーが作業を行うために必要な最低限の特権しか付与しないことを言います。具体的な方法としては、プログラムに必要なときだけ特権を使用できるようにしたり、特権ブラケットを使用することが考えられます。特権ブラケットとは、プログラムの特権の使用・不使用を切り換えるためにプログラム内で使用するものです。特権ブラケットを使用すると、特権は、プログラムの実行中、特定の目的のために使用されている間しか有効になりません。特権ブラケットの詳細は、『Trusted Solaris 開発ガイド』参照してください。

ファイル特権セット

実行可能プログラムファイルには、「強制された特権」と「許容された特権」の 2 つのファイル特権セットを割り当てることができます。「許容セット」とは、プログラムが使用を許可される特権のセットです。「強制セット」はプログラムを実行するシェルやユーザーに関係なく常に使用可能な特権のセットです。

Trusted Solaris で 2 つの標準プログラムが特権を使用する方法

ls(1)、mount(1M) が特権を使用する方法を例に挙げて、これまでに説明した法則の一部についてわかりやすく説明します。

lsは、一般的なプログラムの 1 つです。DAC 制限と MAC 制限によって参照することが許可されているファイルを一覧表示する場合であれば、このプログラムに特権は必要ありません。つまり、ls には必須特権はありません。ただし、何らかの理由で、ls が DAC または MAC のセキュリティポリシーを回避する必要がある場合は、セキュリティ管理者役割によって、無効化特権が割り当てられます。

一般ユーザーが自分のコンピュータにマウントされているファイルシステムを確認する目的で実行する場合、mount(1M) には特権は必要ありません。けれども、mount コマンドでファイルシステムをマウントする場合は、sys_mount 特権が必ず必要になります。つまり、sys_mount は mount の必須特権です。リモート操作でファイルシステムをマウントするために使用するのか、マウント時のセキュリティ属性を指定するために使用するのかによって、いくつかの無効化特権が必要になることもあります。デフォルトの設定では、mount の実行可能プログラムファイルには、すべての「許容された特権」が指定され、「強制された特権」は一切指定されていません。デフォルトでシステム管理者役割に割り当てられる System Management プロファイルには、ファイルシステムをマウントするときに mount が継承する必要のあるすべての特権が定義されています。mount の特権要件に関する詳細は、mount(1M) マニュアルページを参照してください。

アクション

アクションとは、CDE からアクセスできる機能のことです。Trusted Solaris 環境でも広範囲にわたるアクションを使用できますが、その使用法や作成法には、いくつかの制限があります。これは、Trusted Solaris セキュリティポリシーとの互換性を保つためです。アクションの使用上および作成上の制限については、「アクションを追加する場合」で説明します。

アクションとは、各種作業を自動化するために書かれた指示「アプリケーションの編集や実行のためにファイルを開く」などのことです。アクションは、アプリケーションマクロやプログラミング関数とほぼ同様に定義され、アクションごとに、実行時に使用する名前が定義されます。アクションは、アイコン、フロントパネル上のアイテム、メニューアイテムに割り当てられます。

コマンドやアクションの使用に対する実行プロファイル

セキュリティ管理者役割は、アカウントの実行プロファイルに次のいずれかを指定することにより、そのアカウントがシステムのセキュリティポリシーを回避できるようにします。

実行プロファイルに指定された特権は、コマンドやアクションに継承され、使用可能になります。

ユーザーアカウントには、All プロファイルを付与することができます。こうすると、そのアカウントは標準の UNIX ユーザーと同様、すべてのアクションやコマンドに自由にアクセスすることができるようになります。ただし、このとき「継承可能な特権」は与えられません。

標準の UNIX シェルがデフォルトシェルである場合、または、プロファイルの 1 つに標準 UNIX シェルが 記述されている場合、ユーザーはそのシェルで使用できるすべてのコマンドを実行することができます。ただし、継承可能な特権は与えられません。また、アカウントのプロファイルに設定されているアクションの内容によっては、すべてのアクションを起動できないことがあります。ユーザーや役割アカウントは 、All または All Action プロファイルを割り当てられている場合以外は、自分の実行プロファイルに明示的に指定されているアクションセットしか使用できません。一方、ユーザーや役割アカウントが使用できるコマンドはアカウントのプロファイルに記述されているコマンドのみとなります。ただし、アカウントのデフォルトシェルがプロファイルシェルである場合に限ります。

1 つのアカウントには、複数のプロファイルを割り当てることができます。この場合、プロファイルを割り当てる順序が重要で。これは、ウインドウシステム内のプロファイルシェルやトラステッドプロセスが、ユーザーマネージャで指定されている順序でプロファイルを検索するからです。プロファイルシェルやトラステッドプロセスは、複数のプロファイルやコマンドを検索してアクションを検出します。そして、コマンドやアクションには、それが検出された最初のプロファイルに割り当てられているセキュリティ属性が付与されます。

たとえば、表 16-1 に示す、roseanne というアカウントのプロファイルセットには、プロファイルが、All、A、B、C の順で割り当てられています。

表 16-1 アカウントリスト内の誤った順番のプロファイルの例
 アカウント名 デフォルトシェル プロファイル コマンド
 roseanne pfsh All inheritable privs=none が指定された すべてのコマンド
   プロファイル Ainheritable privs=1,2,3 が指定された command1
   プロファイル Binheritable privs=2,3,5 が指定された command1
   プロファイル Cinheritable privs=7,9, 12 が指定された command1

roseanne が command1 を実行すると、プロファイル機構により、検索がスター トします。すると、まず All プロファイルが検出され、ここで検索が終了します。All プロファイルには、特殊な属性なしで任意のコマンドの使用を許可する働きがあり、ここで、roseanne は、特権またはその他の特別な属性なしでコマンドを実行できるようになります。command1 に特権 7、9、12 が付与されていなければ roseanne の作業が失敗する場合は、セキュリティ管理者役割が、プロファイル C を roseanne のプロファイルリストの先頭 (All プロファイルの前) に移動させます。

All プロファイルを割り当てる場合は、アカウントのプロファイルリストの最後に設定し、コマンドの代替機構として働くようにします。すると、アカウントの他のプロファイルにコマンドが明示的に指定されていなくても、特権、実効 UID (GID)、指定された機密ラベルなしで、任意のコマンドを使用することができます。

プロファイルシェル、システムシェル、トラステッドプロセス

プロファイルシェル pfsh(1M) は、セキュリティ管理者役割、システム管理者役割およびスーパーユーザー役割のデフォルトのシェルです。ただし、セキュリティ管理者役割の判断により、プロファイルシェルを他のユーザーまたは役割アカウントのデフォルトシェルとして割り当てることもできます。プロファイルシェルで作業しているアカウントは、自分の実行プロファイルに指定されているコマンド以外は使用できません。

システムシェル sysh(1M) は、実行制御 (rc) スクリプトから実行されるコマンドによって、特権の使用を制御することができます。sysh は、すべてのコマンドの実行を許可しますが、コマンドの実行時に使用する特権、実効ユーザー ID、実効グループ ID、機密ラベルについては、プロファイルで確認します。sysh に関する詳細は、「ブート時にコマンドを実行するには」を参照してください。

ウィンドウシステムのトラステッドプロセスには、次のものがあります。

ウィンドウシステム内のトラステッドプロセスは、だれでも使用できます。ただし、ウィンドウシステムからアクセスできるアクションは、自分の実行プロファイルに指定されたアクションのみです。たとえば、アプリケーションマネージャの「システム管理 (System_Admin)」フォルダにある一連の管理アクションは、アカウントのプロファイルに指定されている場合に限って使用できます。したがって、デフォルトではセキュリティ管理者役割は、セキュリティ管理者役割に割り当てられている Object Label プロファイル内の「エンコーディングの編集 (Edit Encodings)」アクションを使用できますが「マウント・ポイントの設定 (Set Mount Points)」アクションを使用することはできません。

ファイルマネージャ では、アカウントのプロファイルに指定されていないアクションのアイコンは表示されません。ワークスペースのメニューには、アカウントのプロファイルに指定されていないアクションも表示されますが、そのアクションを呼び出すとエラーになります。

CDE ウィンドウマネージャー dtwm(1) は、Xtsolusersession スクリプトを呼び出します。このスクリプトをウィンドウマネージャーと組み合わせて使用すると、ウィンドウシステムで起動しアクションを呼び出すことができます。ユーザーがコマンドを実効する際にプロファイルシェルがユーザーのプロファイルを調べるのと同様、 Xtsolusersession も、アクションの起動時に、ユーザーのプロファイルを調べます。このときアクションがユーザーのプロファイルに指定されていれば、そのアクションはユーザーのプロファイル内で指定されているそのアクションのための特権、実効 UID、実効 GID などの属性を使用して実行されます。

プロセス、プログラム、その特権

プロセスは、実行可能プログラムが格納されているファイルから派生し、常にプログラムを実行しています。プロセスは、fork(2) システムコールを使用して作成されます。 fork(2) とは、呼び出し元プロセスの複製を作成するシステムコールです。こうして作成された新しいプロセスは、現在実行中のプログラムを含め、親の属性をすべて継承します。また、プロセスは、exec(2) システムコールを使用して、実行中のプログラムを変更することができます。このシステムコールには、プロセスのアドレス空間全体を、exec コールで指定されたプログラムファイルから派生した新しいバージョンに置き換える働きがあります。

たとえば、pfsh というプロファイルシェルを実行しているプロセスで exec を使用し、mount コマンドを実行することができます。

プロセス特権セット

各プロセスには、次の 4 種類の特権セットが割り当てられます。

プロセスが execve(2) システムコールを使用してプログラムを実行すると、「許可セット (P)」と「有効セット (E)」は、プログラムファイルの「許容された特権 (A)」、「強制された特権 (F)」、プロセスの以前に存在していた「継承可能な特権 (I)」のすべてを集めた特権のセットになります。


P=E=(I[process] union F[program] restricted by A[program])

実行中のプログラムの「強制された特権」または「許容された特権」を参照せずに「継承可能な特権」を設定する利点については、「継承可能な特権が重要な理由 」を参照してください。

setuid(2) によって元の UID とは異なる実効 UID が設定された場合、「有効セット (E)」が「保存セット (S)」にコピーされ、「有効セット (E)」は消去されます。


S=E; E=0

プロセスが実効ユーザー ID を元の値に戻すと、「保存セット (S)」が「有効セット (E)」にコピーされ、特権の状態が復元されます。


E=S

プロセスが特権を獲得する方法の例

次の例では、プログラムの実行時にプロセスが特権を獲得する方法を標準の UNIX シェルの場合とプロファイルシェルの場合で比較しています。標準の UNIX シェルで実行される場合、プログラムのプロセスが使用できるのは、プログラムの「強制セット」と「許容セット」両方に (共通に) 含まれる特権だけです。プロファイルシェルで実行される場合、プログラムのプロセスは、シェルの「継承可能セット」から特権を獲得し、このうちプログラム自身の「許容セット」と共通の特権を使用することができます。説明を簡潔にするため、例の中では、特権には、名前ではなく番号が割り当てられています。

標準のシェルの場合

図 16-1 の左側の円は標準の UNIX シェルのプロセスを表しています。ここで、ユーザーは programX というコマンドを入力します。シェルのプロセスのものとして示される継承可能セットは、空 (null) になっています。これは、標準シェルのプロセスが特権を持っていないためです。

図 16-1 通常のユーザーシェルで実行時に強制された特権を獲得するプロセス

Graphic

図 16-1 では、中央の四角形は programX を表し、このプログラムには、「強制された特権」と「許容された特権」があります。強制された特権は、1、3、5、許容された特権は、1、3、5、11、12、19 です。右側の円は、programX を実行するプロセスを表しています。ここでは、「許容セット」と「有効セット」に、プログラムファイルに割り当てられた「強制された特権」が与えられています。図 16-1 では、親プロセスが標準のシェルで、「継承可能な特権」はありません。そのため、新しいプロセスに割り当てられる特権セットには、プログラムファイルから獲得した「強制された特権」のみが含まれ、新しいプロセスの「継承可能セット」は空のままになっています。

プロファイルシェルの場合

図 16-2 は、ユーザーや役割アカウントが、プロファイルシェルで programY を実行する場合を表しています。

図 16-2 プロファイルシェルから特権を継承するプロセス

Graphic

上の図 1-2 では、プロファイルシェルは、どのユーザーまたは役割がコマンドを実行しているのかを確認し、そのコマンドがアカウントのプロファイルに含まれていることを確かめます。また、アカウントのプロファイルにそのコマンドに対する特権が指定されているかどうかを確認して、指定された特権だけを自分の「継承可能セット」に追加します。図に示すように、実行可能な programY 自体は「強制された特権」を持たず、「許容セット」には、10、12、19 が含まれています。programY の「許容セット」には 10、12、19 の 3 つの特権が含まれているため、programY を実行するプロセスは、親プロセスから特権 10、12、19 を継承し、プロセスの「有効セット」と「許可セット」には特権 10、12、19 が設定されます。

プログラムファイルの「許容セット」に特権がない場合、そのプログラムを実行するプロセスの「許可セット」と「有効セット」は、常に空になります。

mount コマンドを実行するプロセスが特権を獲得する方法

この節では、「Trusted Solaris で 2 つの標準プログラムが特権を使用する方法」で例に挙げた mount コマンドがプロファイルシェルのプロセスでどのように実行され、どのように特権を獲得するかを説明します。mount がプロファイルシェルで実行されるとき、pfsh を実行しているプロセスは、次の処理を行います。

mount のプロセスでは、「継承可能な特権」は、mount を呼び出したプロファイルシェルのプロセスの「継承可能な特権」と同じに設定されます。次に、mount のプログラムファイルの「強制された特権」と「許容された特権」が「継承可能セット」と組み合わされプロセスの許可された特権、「有効な特権」、「保存された特権」が決定します。

「許可セット」と「有効セット」を決定するためには、まず、プロセスの「継承可能な特権」と、プログラムファイルの「強制された特権」の中の追加特権とが組み合わされます。mount には、「強制された特権」がないため、ここではこの特権は適用されません。「継承可能な特権」と「強制された特権」の組み合わせは、プログラムファイルに指定されている「許容された特権」に制限されますが、mount プログラムファイルに「許容された特権」すべてがあるため、すべての「継承可能な特権」を使用することができます。その結果、mount を実行するプロセスの「許可セット」および「有効セット」は、「継承可能な特権」のセットと同じになります。

mount の「保存セット」には、「継承可能セット」と、mount のプログラムファイルの「強制された特権」および「許容された特権」が設定されます。

継承可能な特権が重要な理由

「継承可能な特権」については、「プロセス特権セット 」で詳しく説明しています。継承可能な特権がセキュリティ管理者役割にとって重要である理由は、特権の継承が次のように使用されるためです。

プログラムファイルが「許容された特権」を持っていない場合

プログラムファイルが「許容された特権」を持っていない場合、プログラムを実行するプロセスの「継承可能な特権セット」は、プログラムの「許容された特権」に合わせて削減されることがありません。「許容された特権」を持たないプログラムを実行するプロセスは、特権を使用することができません。これは、他のトラステッドプロセスから特権を継承したとしても、「有効セット」に特権を設定することができないからです。ただし、このようなプロセスは、「継承可能な特権」を他のプログラムに引き渡すことができます。そのプログラムが「許容された特権」を持っていれば、「継承可能な特権」を使用することができます。次の図を参照してください。

図 16-3 特権を使用できないプログラムが使用できるプログラムに特権を引き渡す 方法

Graphic

プログラムファイルが「強制された特権」を持っていない場合

プロセスの「継承可能セット」が、プログラムの「強制された特権」によって増加することはありません。シェルスクリプトの「強制された特権」が、強制特権シェルスクリプトで呼び出されたコマンドに渡されることはありません。つまり、標準の UNIX シェル sh(1)、csh(1)、ksh(1) で実行されるシェルスクリプトで特権が使用されることはありません。次の図を参照してください。

図 16-4 強制された特権シェルスクリプトが「強制された特権」をコマンドに渡さないようにする方法

Graphic

特権がコマンドとアクションに割り当てられる方法

ここまで説明したように、デフォルトの Trusted Solaris のコマンドとアクションは評価済みであり、実行するために特権が必要なものには、特権が割り当てられています。サイトの構成後に特権が付与されるコマンドやアクションは、それを呼び出すユーザーが信頼できる方法で特権を使用すると確信できたものに限定されます。特権の付与はサイトのセキュリティ管理者役割が行います。

セキュリティ管理者役割は、次の方法で特権を使用可能にします。

コマンドに「強制された特権」を付与する

セキュリティ管理者役割は、コマンドの実行可能ファイルに「強制された特権」を割り当てることができます。特権の割り当ては、ファイルマネージャ の「特権 (Privileges)」ダイアログボックスを使用するか、プロファイルシェルに setfpriv(1) コマンドを入力することによって行います。この方法については、「コマンドに強制された特権を付与するには」を参照してください。

「強制された特権」を持つコマンドと実行する場合、「強制された特権」は、実行プログラムの「有効セット」に組み込まれます。特権を持つコマンドの実行を禁止する唯一の方法は、コマンドへのアクセスを制御することです。プロファイルシェルをアカウントのデフォルトシェルとして、そのアカウントのプロファイルにコマンドやその他のシェルを一切割り当てないようにします。

実行可能ファイルの特権を変更するには、プロセスの機密ラベルによって、ファイルへの MAC 書き込みアクセスが許可されていなくてはなりません (DAC 書き込み許可は必要ありません)。ファイルの「強制セット」と「許容セット」を変更できるのは、同じかそれより低い機密ラベルの所有者 (write-equal または write-up) か、ADMIN_LOW ワークスペースの (デフォルトシステムに設定) セキュリティ管理者役割 (write-up) だけです。

つまり、ファイルの「強制セット」と「許容セット」を変更できるのは、次のユーザーまたはプロセスに限られます。

コマンドやアクションに「継承可能な特権」を付与する

セキュリティ管理者役割は、プロファイルマネージャを使用して実行プロファイルにコマンドまたはアクションの「継承可能な特権」を指定し、ユーザーマネージャを使用してユーザーまたは役割アカウントにそのプロファイルを割り当てることができます。ユーザーマネージャとプロファイルマネージャの使用方法については、第 5 章「ユーザーマネージャを使ったアカウントの設定」、第 8 章「ユーザーおよび役割のための実行プロファイルの管理」を参照してください。

注 -

コマンドの「許容セット」に指定されていない特権を「継承可能な特権」に指定することはできません。

特権プログラムがトラステッド共用ライブラリを使用する理由

ほとんどのアプリケーションは、共用ライブラリルーチンを使用します。Trusted Solaris 環境では、セキュリティ管理者役割は、特権を必要とするアプリケーションで使用する共用ライブラリを常にトラステッドディレクトリ内に設定しておかなくてはなりません。特権アプリケーションが非トラステッドのライブラリにリンクしようとすると、エラーが発生し、リンクに失敗します。


ld.so.1: fatal: application-name: open failed: No such file or directory. Killed.

Trusted Solaris と標準 Solaris の両方の環境において、LD_LIBRARY_PATH は setuid プログラムと setgid プログラムだけが使用できるように制限されています。さらに Trusted Solaris では、LD_LIBRARY_PATH は特権プログラムだけが使用できるように制限されています。setuid、setgid、および特権プログラムの場合、動的ライブラリは次の表に示すトラステッドディレクトリ以外からは読み込めません。

表 16-2 共用ライブラリが格納されているデフォルトのディレクトリ
 Trusted C 関数ライブラリ X サーバーへの Trusted 拡張機能
/usr/lib /usr/openwin/lib
/etc/lib/usr/dt/lib

setuid、setgid、または特権プログラムからのライブラリへのアクセスを許可する最良の方法は、そのライブラリを上記デフォルトのトラステッドディレクトリの 1 つに移動することです。ディレクトリは、必須アクセス制御 (MAC) および任意アクセス制御 (DAC) によって保護されているため、管理者以外のユーザーが書き込みやライブラリファイルの変更を行うことはできません。

ライブラリの移動が不可能なサイトの場合、Trusted Solaris では、rtld ファイルにエントリを作成することによって、トラステッドディレクトリの一覧を拡張できます。

セキュリティ管理者役割は「管理用エディタ (Admin Editor)」アクションを使って、/etc/security/tsol/rtldファイルを作成または変更できます。あるいは、このファイルの中に、トラステッドディレクトリの一覧に追加する、コロンで区切ったディレクトリ群を指定できます。詳細は、「トラステッドプログラムをトラステッドライブラリにリンクするには」を参照してください。

rtld ファイルに登録されているアプリケーションのライブラリは「信頼できる」ようになるため、間違って変更されることがないように、これらのライブラリにはデフォルトのライブラリと同じレベルの保護が必要です。セキュリティ管理者役割は、rtld ファイル内のディレクトリ上に、デフォルトのトラステッドライブラリと同じ MAC および DAC のアクセス権があることを確認する必要があります。

オブジェクトファイルのリンクエディタと rtld ファイルに関する詳細は、ld(1) マニュアルページを参照してください。

トラステッドパスについての注意点

トラステッドパス属性は、ブート時、あるいはプログラムが管理役割ワークスペースで動作しているときに使用できます。多くの管理コマンドおよびアクションにはトラステッドパス属性が必要です。詳細は、「トラステッドパス属性」を参照してください。

トラステッドパス属性をプログラムで利用可能にする

コマンドがトラステッドパス属性を取得できるのは、そのコマンドがブートファイルに登録されているか、あるいは、管理役割に割り当てられているプロファイル内にあるときだけです。管理役割がプログラムを実行したとき、そのプログラムが管理役割のどの実行プロファイル内にもない場合、トラステッドパス属性は無効になります。

新しいプログラムまたはスクリプトを追加するとき、そのプログラムまたはスクリプトが、トラステッドパス属性を必要とする、次のようなプログラムではないことを確認します。

トラステッドパスの警告

デフォルトのシステムでは、作業しやすくなるように、管理役割には All Commands プロファイルが割り当てられています。All Commands プロファイルが割り当てられている役割は、特権または他の拡張セキュリティ属性なしにコマンドを実行できます。あるプログラムが役割のどのプロファイルにも明示的に指定されていない場合、プロファイルシェルはトラステッドパス属性を無効にし、次のようなメッセージを表示します。

WARNING: Command operating outside of the Trusted Path!

プログラムが成功したときでも、この警告メッセージは表示されます。プログラムの実行時にエラーが発生したとき、この警告メッセージは、そのプログラムがトラステッドパス属性を持っていないことを知らせます。この警告メッセージを抑制するには、-Q オプションを使います。つまり、管理役割はプロファイルシェルのコマンド行で set -Q と入力するか、$HOME/.profile ファイルに set -Q を設定します。

ほとんどの管理作業で使われる Solstice AdminSuite ツールはトラステッドパス属性を調べます。したがって、表 4-1 にあるプログラムやオプションにアクセスする必要がある新しい役割をセキュリティ管理者役割が作成する場合、新しい役割は管理役割でなければなりません。

ソフトウェアを追加するときのセキュリティ管理者役割の作業

デフォルトの Trusted Solaris プログラムやアクションには、あらかじめ、その機能を果たすために必要な特権、実効 UID、実効 GID などが割り当てられています。この節では、次の種類のソフトウェアを追加する際の問題や作業について説明します。

既存のプログラムを追加する場合

既存のプログラムを Trusted Solaris システムに追加する場合は、そのプログラムが社外で作成されたアプリケーション、Solaris の別パッケージのソフトウェアプログラム、社内で作成されたプログラムのいずれの場合でも、次の指示に従って作業を行なってください。

  1. そのアプリケーションが Trusted Solaris システム内で変更なしに正しく実行できることを 確認します。

    特権を付与したり修正を加えたりしないで実行できる場合、ここで作業は終了です。

  2. プログラムが失敗した場合は、その原因を見つけます。

    Trusted Solaris オペレーティング環境には、セキュリティポリシーを施行するために特別な修正が加えられています。そのため、Solaris 用に作成された別パッケージのソフトウェアやサン以外のアプリケーションの中には、Trusted Solaris 環境で実行できないものもあります。たとえば、カーネルとリンクするソフトウエアは、Trusted Solaris 用に修正されたカーネルデータ構造とは互換性がない場合があります。同様の理由で、読み込み可能なデバイスドライバやその他のソフトウエアも、コードを変更しない限り、この環境で実行できない可能性があります。

    アプリケーションがカーネルにリンクしているか、オペレーティングシステムの修正された部分に依存している場合、そのプログラムに特権を付与しても、コードを変更しない限り、Trusted Solaris で実行できない可能性があります。

  3. Solaris オペレーティングシステムの Trusted Solaris 用に修正された部分には依存していないプログラムで、特権を使用しないとエラーが発生する場合、必要な特権やその他の属性を判断します。

  4. 特権の使用が必要な場合、プログラムが信頼できる方法で特権を使用するかどうかを調査します。

    「特権を使用しないとエラーが発生するプログラム」を参照してください。

  5. プログラムが、特権またはその他の必要な属性を使用して、Trusted Solaris のセキュリティポリシーや独自に導入しているセキュリティポリシーに違反することなく安全に実行できる場合は、必要な特権を割り当てます。この方法については、「特権がコマンドとアクションに割り当てられる方法」参照してください。

  6. プログラムのソースコードへのアクセス権がある場合、コードを修正した後、セキュリティを熟知したセキュリティコンサルタントやプログラマが特権を追加できる場合もあります。

    このような修正では、特権ブラケットを使用したり、プログラムに Trusted Solaris のセキュリティポリシーを認識させるためのコードを追加したりします。

  7. プログラムで特権を使用できるようにする場合、そのプログラムが使用するライブラリがトラステッドとして認識されるかどうかを確認する必要があります。「特権プログラムがトラステッド共用ライブラリを使用する理由」を参照してください。

  8. プログラムが信頼できる方法で特権を使用できない場合や、修正が不可能な場合は、特権を使用可能にしてはなりません。

特権を使用しないとエラーが発生するプログラム

Trusted Solaris 環境において特権がないためにエラーを発生するもっとも典型的なプログラムは、標準 Solaris 環境でスーパーユーザーとして実行する必要があるプログラムです (たとえば、setuid をスーパーユーザーにして動作するようなプログラム)。この種類のプログラムには、プロファイルでスーパーユーザーの実効 UID を割り当てることができます。あるいは、実 UID を必要とする場合は、(セキュリティ管理者役割の判断により)、そのプログラムをスーパーユーザー役割に割り当てることもできます。

ほとんどのアプリケーションは、MAC などの Trusted　Slaris のセキュリティ機構を持たない環境で作成されます。このため、セキュリティと、新しいプログラムで実現しようとしている内容について完全に理解しなければ、プログラムを評価することができません。

ユーザーに代わってあらかじめ厳密なチェックを行なったとしても、DAC に違反するような標準 UNIX アプリケーション管理者が、MAC と同様のチェックを行うことはありません。つまり、このようなプログラムに MAC の無効化特権を付与した場合、ユーザーが任意で MAC を無効にできる方法を提供してしまうことになります。

セキュリティ上の考慮が必要な点について、UNIX プログラムで一般的に使用される rcp(1) の動作を例に挙げて説明します。rcp コマンドは、ネットワーク内でファイルをコピーするコマンドで、setuid を root として実行されます。root として実行すると、プログラムは、標準の UNIX システムのすべての特権を使用して実行されます。このプログラムは DAC 制限の回避を許可されていますが、ファイルの DAC アクセス権をチェックして、rcp コマンドを実行したユーザーが、ファイルへのアクセス権を持っていることを確認します。ただし、rcp では MAC 制限は行われません。また、 file_mac_read 特権や file_mac_write 特権を付与したとしても、ファイルへのアクセス時に MAC 関連のチェックを行う組み込み機能もありません。したがって、rcp は、システムのセキュリティポリシーを実現するために割り当てられた特権を使用することができません。

これと類似したプログラムに、実行に必要な特権を単純に割り当て、Trusted Solaris のセキュリティポリシーに従って動作するように修正しなかった場合、そのプログラムはシステムセキュリティに違反することになります。システムセキュリティに違反せずに実行できるようにするには、プログラムのソースコードにコードを追加する必要があります。たとえば、ファイルの読み取りや書き込みを行うときに MAC 制限を回避しなければならない場合、必要な MAC チェックを行うコードを追加して、ソースコードを変更する必要があります。

ソフトウェアの中には、特権が必要な理由が明確でないものもあります。さらに、プログラムの実行に特権が必要ないものもあります。けれども、システムのセキュリティポリシーに違反するような機能を持たないプログラムであっても、共用ログファイル中の処理の履歴を追跡したり、/dev/kmem (mem(7D) を参照) から読み取りを行うなど、セキュリティに違反する内部作業を行なっている可能性があります。内部で発生するポリシー違反は、ユーザーに便利な機能を提供するだけで、アプリケーションを正しく操作するためには特に重要でない場合があります。サイトでソースコードを調べられる場合は、アプリケーションのパフォーマンスに影響を与えることなく、ポリシーの無効化を必要とする操作を削除できないか検討します。

MAC 検査を行わずにファイルの読み取りや書き込みを行うなど、いくつかの面で Trusted Solaris のセキュリティポリシーに違反するプログラムについては、可能であれば、ソースコードに必要な MAC 検査を追加します。そうでなければ、そのプログラムの移植は控えてください。

アプリケーションをスーパーユーザーがインストールする場合

通常、特殊なアプリケーションやパッケージをインストールするソフトウェアの場合、正常に処理を行うためには、スーパーユーザーの実効 UID が必要です。プロファイル機構では、アプリケーションに実効 UID を割り当てられるのはセキュリティ管理者役割だけなので、インストールプログラムのプロファイルにスーパーユーザーの UID を割り当てるのは、セキュリティ要件に適合しません。コマンドがスーパーユーザーの実 UID で実行できるようにする唯一の方法は、スーパーユーザー役割がそのコマンドを実行することです。セキュリティ管理者役割は、アカウントにスーパーユーザー役割を割り当て、Custom Root Profile などのプロファイルにコマンドを追加できます。詳細は、「アプリケーションの設定: スーパーユーザーの実 UID を使用して実行する」を参照してください。

アプリケーションをスーパーユーザーが実行する場合

スーパーユーザーが実行するアプリケーションについては、次の 3 つのオプションを使用して、サイトのセキュリティポリシーと矛盾がないか評価する必要があります。これはセキュリティ管理者役割の業務です。

プログラムに必要な特権の検索

runpd(1M) コマンドは任意のコマンドを実行して、そのコマンドが使った特権を記録します。

runpd コマンドにはトラステッドパス属性が必要です。コマンドがトラステッドパス属性を取得できるのは、そのコマンドがプロファイル中に指定されており、管理役割によって実行されるときだけです。したがって、通常のユーザーは runpd を実行して、通常のユーザーに必要な特権を見つけることはできません。runpd を実行するためにスーパーユーザー役割を使ってはなりません。これは、UID 0 が他の UID よりも多くのアクセス権をコマンドに与えてしまうためです。runpd コマンドを使うと、コマンドが使用されるラベルにおいて、そのコマンドがどの特権を使うのかテストできます。管理役割 (スーパーユーザー役割を除く) として runpd を実行すると、コマンドがユーザーの認可範囲内の機密ラベルで実行された場合、通常のユーザーに必要な特権が記録されます。

デフォルトでは、セキュリティ管理者役割は、そのプロファイル内に runpd コマンドが割り当てられている唯一の役割です。「アプリケーションに必要な特権を調べるには」で説明している手順に従うと、特権デバッグを有効にできます。その手順では、特権デバッグ専用の管理役割を作成する方法についても説明しています。

コマンドが必要とする特権は、自動的に割り当ててはなりません。特権を割り当てる前に、他の方法を検討してください。

プログラムがファイルにアクセスするときに DAC または MAC の制限を回避する必要がある場合、セキュリティ管理者役割は実効 UID または GID を割り当てることによって、特権を不要にすることも可能です。詳細は、「特権の割り当て以外の方法」を参照してください。

ソフトウェアに特権、あるいは代替の UID または GID が割り当てられているとき、そのソフトウェアは、Trusted Solaris セキュリティポリシーを無効にできるという意味で「トラステッド (信頼できる)」になります。したがって、「信頼できない」ソフトウェアでも「トラステッド (信頼できる)」になってしまうことに注意してください。セキュリティ管理者役割は、ソフトウェアが信用に値する方法で特権を使うことが確信できるまで、そのソフトウェアに特権を与えてはなりません。ソフトウェアを十分に調べ、システムのセキュリティポリシーの範囲内で特権を使っていることが判明した場合にのみ、そのソフトウェアは「信頼のおける」プログラムであると言えます。

新しいトラステッドプログラムを追加する場合

プログラムの開発者がソースコードに組み込む特権をセットを操作できてもセキュリティ管理者役割がプログラムに必要な特権を割り当てなければ、プログラムで特権を使用することはできません。セキュリティポリシーを無効にできなければ、そのプログラムは期待通りの処理を完全に行えなかったり、Trusted Solaris システムで実行することができなかったりします。

開発者の業務

Trusted Solaris システムに追加されるプログラムを作成する開発者には、次の条件が必要です。

  1. プログラムが機能するために特権が必要かどうか判断できる

  2. 特権ブラケットなどの技術を習得しており、プログラムで安全に特権を行使するために使用できる

  3. プログラムに特権を割り当てるときは、セキュリティの実現に注意し、プログラムがセキュリティポリシーに違反しないことを確認する

  4. セキュリティ管理者役割との共同作業により、「特権プログラムがトラステッド共用ライブラリを使用する理由」の説明に従って、プログラムにリンクされた共用ライブラリをトラステッドディレクトリ内に格納する。また、プログラムをコンパイルするときは、「」 に従って、トラステッドディレクトリの場所を使用する

    プログラム内で特権を使用する方法については、『Trusted Solaris 開発ガイド』を参照してください。

セキュリティ管理者役割の業務

セキュリティ管理者役割は、Trusted Solaris のシステムコールやルーチンを使用してセキュリティポリシーの範囲内で処理を行うプログラムが、絶対に Trusted Solaris システムのセキュリティに違反しないようにする必要があります。

  1. プログラマやプログラム配布プロセスが信頼できることを確認する

  2. 次の情報源から、プログラムに必要な特権を決定する

    1. プログラマに確認する

    2. ソースコードを調べて、プログラムが使用する予定の特権を検索する

    3. runpd を使用する。これについては、「アプリケーションに必要な特権を調べるには」で説明しています。

  3. ソースコードを綿密に調査し、処理に必要な特権を使用する際に信頼できる方法で動作することを確認する

アクションを追加する場合

Trusted Solaris システムでアクションを作成し、使用する方法は、標準 Solaris の場合とほとんど変わりません。アクションの追加方法については、『Solaris 共通デスクトップ環境 上級ユーザ及びシステム管理者ガイド』で説明しています。

Trusted Solaris では、アクションの使用は実行プロファイル機構によって制御されます。アクションには、任意の実行プロファイルに特権、実効 ULD、実効 GID などのセキュリティ属性を割り当てることができ、継承可能セットからアクションに特権を引き渡すことのできるウィンドウシステムのトラステッドプロセスの中で呼び出された場合は、特権を使用して実行することができます。Trusted Solaris システムでは、多数のアクションの実行プロファイルに特権が割り当てられていて、そのプロファイルはデフォルトで特定の役割に割り当てられています。表 16-3 に、Trusted Solaris システムでアクションを作成したり使用するときの重要な相違点についてまとめます。

表 16-3 Trusted Solaris の制限下でアクションを作成したり使用する際の相違点
 標準 CDE Trusted Solaris
 新しいアクションは、だれでも自分のホームディレクトリ内に作成できる。また、作成者は自動的に新しいアクションを使用できるようになる。 アクションは、ユーザーや役割の実行プロファイルに含まれている場合だけ使用可能。
  プロファイルに、「アクション作成 (Create Action)」 アクションまたはコマンド、ファイルの編集を許可するアクションがある場合、ユーザーや役割は、自分のホームディレクトリ内に新しいアクションを作成することができる。ただし、それを使用することはできない。
  ユーザーが新しいアクションを使用するためには、セキュリティ管理者役割が新しいアクションの名前をアカウントの実行プロファイルの 1 つに追加するか、All プロファイルが割り当てられていることが必要。All プロファイルは、アクションに対するすべてのチェックを無効にするため、ユーザーは、常駐するアクションでも、一時的アクションでも、すべてのアクションを使用することができる。
  実行プロファイルによってアクションの使用を許可されているアカウントであれば、ファイルマネージャを使用してホームディレクトリからアクションを起動することができる。デフォルトのシステム管理者役割とセキュリティ管理者役割は、公開ディレクトリにアクションを配置することが許可されている。
 アクションをフロントパネルにドラッグ＆ドロップすることが可能。フロントパネルは、トラステッドパスの一部。ウィンドウマネージャは、システム全体のアクションファイルが保存されている /usr/dt および /etc/dt サブディレクトリにある、管理者が追加したアクションだけを認識する。したがって、一般ユーザーまたは管理役割以外のアカウントが自分のホームディレクトリに新しいアクションを作成し、All Accounts プロファイルを持っていたとしても、ユーザーのホームディレクトリからフロントパネルにドラッグされた新しいアクションは、ウィンドウマネージャに認識されない。ウィンドウマネージャは公開ディレクトリ内だけを検索する。
 アクションが特権を付与された処理を行うためには、スーパーユーザー (root) によって実行されなくてはならない。 呼び出し元のアカウントの実行プロファイルで、特権を持つことが指定されているアクションの場合、トラステッドプロセスから起動されたときは、特権を継承することができる。つまり、アクションが特権を付与された処理を行うためには、アカウントのプロファイルに特権を割り当てておかなくてはならない。

シェルスクリプトの作成方法と使用方法

通常の UNIX シェル (sh, csh, csh) が割り当てられているユーザーは、特権を使用しないでシステム内の任意のコマンドを実行する、新しいシェルスクリプトを作成することができます。このスクリプトに特権を必要とするコマンドが含まれていない場合、ソフトウェアへのアクセス権を持ち、シェルスクリプトを解釈するためのシェルを実行できるユーザーは全員、シェルスクリプトを使用することができます。

シェルスクリプトで実行されるコマンドに特権を付与することができるのは、セキュリティ管理者役割だけです。シェルスクリプトの実行時に特権を使用するかどうかに影響する Trusted Solaris の制約について確認します。

特権を使用してコマンドを実行できる 2 つの方法を確認します。

「強制された」特権コマンドは、どのシェルでも特権を使用して実行できます。これは、プログラムファイルに付与された「強制された特権」が、シェル自体に特権がなくても、コマンドの実行に適用されるからです。「強制された特権」を csh、sh、ksh シェルスクリプトに割り当てても、シェルスクリプトが実行するコマンドに特権を付与することにはなりません。これは、スクリプトから起動されたシェルが「強制された特権」を使用して実行された場合でも、シェルの「継承可能セット」に特権が設定されていないからです。プロセスが特権を取得する方法については、「プロセス特権セット 」で説明した規則を参照してください。

注意 - 注意 -

実行可能プログラムを編集する際、オブジェクトコードやシステムスクリプトが無許可で改ざんされないようにするために、そのファイルに付与されていた「強制された特権」と「許容された特権」は削除されます。プログラムファイルの「許容セット」が空の場合、継承可能な特権は「許容セット」にマスクされ、使用することができません。ただし、プロファイル機構 は、「継承可能な特権」を使用可能にするときに、シェルスクリプトの「強制された特権」と「許容された特権」を参照しません。このため、シェルスクリプトは修正されても気付かれないことがあります。セキュリティ管理者役割は、「継承可能な特権」を使用するシェルスクリプトを使用可能にする前に、改ざんに対する保護が、プログラムに有効であってもシェルスクリプトに対しては有効でないことに留意しておく必要があります。

Trusted Solaris システムにおけるシェルスクリプトの動作のまとめ

図 16-5 pfsh で呼び出されたシェルスクリプトがコマンドに継承可能特権を引き渡す方法

Graphic

プロファイルシェルを呼び出すシェルスクリプトの詳細

#!/bin/pfsh という行で始まるシェルスクリプトを一般ユーザーが呼び出した場合、その動作は管理役割が呼び出した場合の動作とは異なります。

一般ユーザーが呼び出した場合の動作

管理役割が呼び出した場合との違い

プログラムファイルが編集された場合、継承可能な特権を使用できないようにする方法

オブジェクトコードに対し承認されていない変更が行われるのを防ぐために、実行可能プログラムが編集された場合には必ず、そのファイルに以前与えられた「強制された特権」や「許容された特権」はすべて削除されます。この措置により、何者かが本来の意図とは異なる目的で特権を利用することを防ぐことができます。セキュリティ管理者役割は、そのようなファイルの編集を行う前に、同ファイルに与えられた特権のリストを保存しておき、編集後に復元することができます。詳細は、「ファイルを編集したときに特権を保存および復元するには」を参照してください。

ブート時にコマンドを実行するには

標準 Solaris システムの場合と同じく、Trusted Solaris システムのブート時に実行されるコマンドは、管理アクションによって追加したり、もしくは変更したりすることが可能です。基本的な動作については、『Solaris のシステム管理 (第 1 巻)』の実行制御スクリプトに関する記述、および init.d(4) のマニュアルページに説明されています。システムサービスを開始するスクリプトに付ける番号に関するガイドラインについては、各 /etc/rcn.d 内のREADME ファイルを参照してください。次節「前提知識」にも簡単な説明があります。

以下の節では、システムのブート時に起動されるサービスが必要とする Trusted Solaris の拡張セキュリティ属性を提供するために、セキュリティ管理者役割が行わなければならない事項について説明します。このようなサービスは、特権の継承、特定の機密ラベルや ADMIN_LOW 以外の認可上限を使った起動、スーパーユーザー以外の UID や GIDの 割り当てなどを行う必要があります。詳細については、「デフォルトの Trusted Solaris ブートスクリプト」、「新しい Trusted Solaris ブートスクリプト」、「ブート時に実行するコマンドに拡張セキュリティ属性を使用するかどうかを指定するには」を参照してください。

前提知識

ブート時に、各 /sbin/rcn スクリプトは、それぞれに対応する /etc/rcn.d ディレクトリに含まれている一連のスクリプトを実行します。これらの実行制御スクリプト名とそれに対応するディレクトリ名に付けられている番号 n は、実行レベルを表しています。

/etc/rcn.d ディレクトリに含まれている一連のスクリプトは、/etc/init.d ディレクトリに実際に置かれているスクリプトに対するハードリンクになっています。たとえば、次の例に示すように、/etc/rc0.d、rc1.d、rc2.d ディレクトリには、それぞれ異なる名前を持つ sendmail スクリプトが 1 つずつ存在しますが、これらは実際にはいずれも /etc/initd.d/sendmail スクリプトへのハードリンクになっています 。

/etc/rcn.d ディレクトリ内に存在する /etc/initd.d/sendmail へのリンク


/etc/rc0.d/K57sendmail
 /etc/rc1.d/K57sendmail
 /etc/rc2.d/S88sendmail

/etc/rcn.d ディレクトリ内のスクリプトのうち、起動オプションで実行される必要があるものには接頭辞 S で始まる名前が付けられており、停止オプションで実行される必要があるものには接頭辞Kで始まる名前が付けられています。上記の図に示すように、接頭辞 K で始まる名前の sendmail ファイルが rc0.d および rc1.d に置かれている場合、実行レベルが 0 および 1 に移行すると sendmail(1M) は停止します。同様に、接頭辞 S で始まる名前の sendmail ファイルが rc2.d に置かれている場合、実行レベルが 2 に移行すると sendmail(1M) は起動されます。

/etc/init.d に新しいスクリプトをインストールした場合、セキュリティ管理者役割は以下のことを行います。

デフォルトの Trusted Solaris ブートスクリプト

Trusted Solaris システムでは、起動されるサービスが特権や拡張セキュリティ属性を必要とすることがあるために、/sbin/rcn スクリプトが sh(1)(Bourneシェル)ではなく、 sysh(1M)(システムシェル)を使うように変更されています。デフォルトの Trusted Solaris システムでは、ブート時に起動されるコマンドのための拡張セキュリティ属性を指定するようにブート実行プロファイルが設定されています。/sbin/rcn スクリプトでは、/bin/sysh が引数としてのプロファイル名なしで使われていますが、これは同スクリプトがデフォルトでブートスクリプトを参照するようになっているためです。

警告 - 警告 -

boot プロファイルや /sbin/rcn スクリプトは変更しないでください。

新しい Trusted Solaris ブートスクリプト

各サイトでブート時に実行するコマンドを追加する必要がある場合、セキュリティ管理者役割は #!/sbin/sysh で始まるシステムシェルスクリプトを作成し、そのスクリプトでローカルに作成したブート時の実行プロファイルを指定します(これを行うには setprof コマンドを使います)。セキュリティ管理者役割はブート時実行プロファイルを作成して、セキュリティ属性を必要とするコマンドに割り当てます。次の例に示すように、このシステムシェルブートスクリプトの先頭行には #!/sbin/sysh が、2 番目の行には setprof local_boot_profile コマンドが含まれています。


#!/sbin/sysh
 setprof local_boot_profile

システムシェル (sysh) は、local_boot_profile を参照することにより、スクリプトによって起動されるコマンドにどのような拡張セキュリティ属性が割り当てられているかを判断します。たとえば、コマンドが ADMIN_LOW 以外の機密ラベルや認可上限を必要とする場合、プロファイルは、そのコマンド用に機密ラベル (min_SL フィールド) と認可上限 (max_ＳＬ フィールド)を設定する必要があります。さらに、コマンドがスーパーユーザー (root) の UID や別の GID を必要とする場合、プロファイルはこれを指定しなければなりません。

セキュリティ管理者役割は、「ブート時に実行するコマンドに拡張セキュリティ属性を使用するかどうかを指定するには」の手順に従って、スクリプトによって実行されるコマンドの名前を持つ新しいプロファイルを作成する必要があります。また、sysh の setprof オプションを使用して新しいプロファイルを参照するように指定し、スクリプト内で sysh シェルを使用する必要があります。

/etc/init.d ディレクトリのスクリプトを使用してサービスを開始・停止する

Solaris では、スーパーユーザーは、コマンド名とその後に start または stop オプションのいずれかを入力することにより、/etc/init.d ディレクトリ内の任意のコマンド (サービスとも呼ばれます) を開始または停止することができます。たとえば、次のように入力できます。


# /etc/init.d/sendmail start

および


 # /etc/init.d/sendmail stop

上の図に示すように、sendmail など、Trusted Solaris システム内のコマンドを停止または開始するには、特権は必要ありません。ただし、コマンドは、管理者役割によって、トラステッドパス属性を持つ管理役割のワークスペースで実行されなくてはなりません。同時に、スクリプト名がアカウントの実行プロファイルの 1 つに指定されている必要もあります。

ソフトウェアを追加する手順

パッケージを追加するために CD-ROM をマウントするには

  1. システム管理者役割になり、ADMIN_LOW ワークスペースに移動します。

    必要に応じて 「ログイン後、特定の管理役割になるには」を参照してください。

  2. CD-ROM デバイスを割り当てます。

    「トラステッドパス (Trusted Path)」メニューの「デバイスを割り当てる (Allocate Device)」オプションを使うか、フロントパネルの「トラステッドデスクトップ (Trusted Desktop)」サブパネルからデバイス割り当てマネージャを起動します。「デバイス割り当てマネージャ (Device Allocation Manager)」ダイアログボックスが表示されます。

  3. 「利用可能なデバイス (Available Devices)」一覧から CD-ROM デバイスの名前をダブルクリックして、「割り当てられたデバイス (AllocatedDevices)」一覧に移動します。

    「デバイス割り当て: ラベルを選択 (Device Allocation: Select Label)」ダイアログボックスが表示されます。

  4. 「ラベルを選択 (Select Label)」ダイアログボックスにおいて、機密ラベルとして ADMIN_LOW が指定されていることを確認し、「了解 (OK)」をクリックします。

    次のようなプロンプトが現れて、指定したラベルが表示されます。


    Insert disk into /dev/dsk/c0t6d0s0.
 Make sure disk is labeled:
     ADMIN_LOW
 Press RETURN when cdrom_0 is ready or ^C to cancel...

  5. CD-ROM をドライブに挿入し、Return キーを押します。

    次のようなプロンプトが表示されます。


    Do you want cdrom_0 mounted: (y/n)?

  6. y と答えます。

    /cdrom ディレクトリが存在しない場合は作成されます。そして、/cdrom ディレクトリに CD-ROM がマウントされます。

  7. プロンプトが表示されたら、Return キーを押して、ウィンドウを閉じます。

アプリケーションの設定: スーパーユーザーの実 UID を使用して実行する

  1. セキュリティ管理者役割になり、ユーザーマネージャを使用して、インストール作業を担当する信頼できるユーザーのアカウントにスーパーユーザー役割を割り当てます。

    詳細は、第 5 章「ユーザーマネージャを使ったアカウントの設定」を参照してください。

  2. プロファイルマネージャを使用して、スーパーユーザーに割り当てられているプロファイルの 1 つにアプリケーションプログラムの名前を割り当てます。

    詳細は、第 8 章「ユーザーおよび役割のための実行プロファイルの管理」を参照してください。

  3. (推奨) ユーザーマネージャを使用し、作業が終了した時点でアカウントからスーパーユーザーの役割を削除します。

アプリケーションの設定: スーパーユーザーの実効 UID を使用して実行する

  1. プロファイルマネージャを使用して、適切なプロファイルにアプリケーションプログラムのコマンド名を割り当て、コマンドにスーパーユーザーの UID を付与します。

    詳細は、第 8 章「ユーザーおよび役割のための実行プロファイルの管理」を参照してください。

  2. ユーザーマネージャを使用して、プロファイルシェルを持つ任意のアカウントに、追加されたコマンドが登録されているプロファイルを割り当てます。

    第 5 章「ユーザーマネージャを使ったアカウントの設定」を参照してください。

アプリケーションに必要な特権を調べるには

  1. セキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動します。

    詳細は、「ログイン後、特定の管理役割になるには」を参照してください。

  2. (省略可能) 新しいプロファイルを作成し、そのプロファイルを管理役割に割り当てます。

    注 -

    デフォルトの構成において、セキュリティ管理者役割は runpd コマンドが割り当てられている唯一の役割です。この手順では、特権デバッグ専用の管理役割も作成できます。この役割を使うと、通常のユーザーがユーザー認可範囲内のラベルでコマンドを実行したとき、あるいは管理役割が管理ラベルのいずれかでコマンドを実行したとき、そのコマンドに必要な特権を見つけることができます。

    1. プロファイルマネージャを使って、/usr/sbin/runpd、/bin/getfpriv、および /bin/setfpriv 特権、「システムをシャットダウン」、「ログインを有効化」、および 「ファイルの特権を設定」 承認、さらに、必要であれば、「管理用エディタ (Admin Editor)」アクションを持つ新しいプロファイルを作成します。そして、/usr/sbin/runpd を実行する前に、役割が以下の手順に従って特権デバッグを実行できるように設定します。

    2. ユーザーマネージャを使って、管理役割 (たとえば prvdbg) を作成し、その役割に上記プロファイルを割り当てます。必要であれば、All プロファイルも割り当てます。

    3. 特権デバッグ役割をアカウントに割り当てます。

  3. 「管理用エディタ (Admin Editor)」アクションを使って、/etc/system ファイル内の tsol_privs_debug 設定を 1 に変更します。


    set tsol_privs_debug=1

  4. 「管理用エディタ (Admin Editor)」アクションを使って、/etc/syslog.conf ファイル内の kern.debug から始まる行の前にあるコメントマーク (#) を削除します。

    次の行は、システムコールやデーモンに必要な特権を /var/log/privdebug.log ファイルに記録します。


    kern.debug;daemon.debug;local0.debug  /var/log/privdebug.log

  5. 「トラステッドパス (TP)」メニューの「シャットダウン」オプションを使ってコンピュータをシャットダウンし、リブートします。


    ok  boot

  6. ログインし、セキュリティ管理者役割になります。あるいは、特権デバッグ専用の役割を作成した場合 (手順 2 を参照)、特権デバッグ専用の役割になります。

  7. 適切な機密ラベルを持つ端末エミュレータで、runpd コマンド、検査対象のコマンド、およびそのコマンドがどのように特権を使うのかを調べるためのオプションを (この順番で) 入力します。

    注 -

    ワークスペースの機密ラベルは、コマンドが通常実行される機密ラベルである必要があります。管理役割が管理ラベルでアプリケーションを実行することもあれば、一般ユーザーがユーザー認可範囲内のラベルで同じアプリケーションを実行することもあります。

    次の例に示すように、runpd は、プログラムが正常に実行されるために必要な特権の名前、試行されたアクセスの種類 (たとえば create)、資源の名前 (たとえば RAW_SOCKET) を並べて表示します。


    $ runpd pathname_of_command_and_any_options

runpd: child terminated with a status of 0

process pathname_of_command pid process_ID lacking privilege privilege_name
to perform type_of_access upon resource resource_name (MM DD HH:MM)

    次の例は、ping(1M) で runpd(1M) を実行した結果を示しています。この例の目的は、ping の強制された特権が削除されていることを確認することです。


    $ runpd /usr/sbin/ping sif 
sif is alive runpd: child terminated with a status of 0 
process /usr/sbin/ping pid 5138 lacking privilege net_rawaccessto create raw
socket (Oct 25 18:33) process /usr/sbin/ping pid 5138 lacking privilege sys_
net_config to manage transport opts (Oct 25 18:33)

  8. ADMIN_HIGH ワークスペースに移動し、ログファイルに特権デバッグのメッセージがあるかどうかを調べます。

    次に、典型的な特権デバッグのログエントリを示します。


    $ cat /var/log/privdebug.log
Mar 29 12:18:43 hostname unix: DEBUG: pathname_of_command pid 
process_ID lacking privilege number to 
number_of_type_of_access number_resource

    次の例は、ping で runpd を実行したときの privdebug.log エントリを示しています。


    Oct 25 18:33:35 tribble unix: DEBUG: /usr/sbin/ping pid 5138 lacking privilege
36 to create raw socket
Oct 25 18:33:35 tribble unix: DEBUG: /usr/sbin/ping pid 5138 lacking privilege
68 to manage transport opts

    「privilege」の後に特権番号が表示されます。この特権番号を /usr/include/sys/tsol/priv_names.h ファイルで検索すると、特権の名前がわかります。たとえば、特権番号 36 は、net_rawaccess という名前の特権に割り当てられています。特権番号とその後の 「to」 に続く番号は、試行されたアクセスの種類で、その後に資源の番号が表示されます。

  9. 必要な特権を割り当てる方法については、「コマンドに強制された特権を付与するには」を参照してください。また、プロファイルマネージャを使用して継承可能な特権を割り当てる方法については、第 8 章「ユーザーおよび役割のための実行プロファイルの管理」を参照してください。

    注 -

    コマンドが強制された特権または継承可能な特権を使用するためには、その特権がコマンドの許容された特権セットで使用可能になっている必要があります。

  10. 特権デバッグを無効にするには、手順 3 から手順 4 までで変更した /etc/system ファイルと /etc/syslog.conf ファイルの内容をすべて元に戻し、コンピュータを再起動します。

コマンドに強制された特権を付与するには

  1. ファイルの所有者、ファイル所有者承認の役割を持つユーザー、またはセキュリティ管理者として、プログラムファイルが格納されているディレクトリに移動します。

    指定のディレクトリに移動するにはファイルマネージャを使うか、コマンド行から cd(1) コマンドを使います。詳しくは、『OpenWindows ユーザーズガイド』および『Solaris 共通デスクトップ環境 ユーザーズ・ガイド』を参照してください。

  2. ファイルが実行可能であることを確認します。

    ファイルマネージャの「アクセス権 (Permissions)」ダイアログボックスで所有者、グループ、その他の「実行 (Execute)」チェックボックスにチェックマークが付いていることを確認します。ファイルマネージャの「アクセス権 (Permissions)」オプションについての詳細は、『Trusted Solaris ユーザーズガイド』を参照してください。プロファイルに setfpriv（1） コマンドが設定されていて、コマンドのプログラムファイルの所有者でもある場合、デフォルトのセキュリティ管理者役割である場合、あるいは「ファイルの所有者を変更」承認を持っている場合は、コマンド行から setfpriv（1） を実行して、他のユーザーがそのコマンドを実行できるようにすることもできます。

  3. コマンドに割り当てられている「許容された特権」が、これから割り当てる予定の「強制された特権」と同じであることを確認します。

    1. ファイルマネージャの「アクセス権 (Permissions)」ダイアログボックスで、「許容された特権 (Allowed)」を選択して許容された特権を割り当て、次に「強制された特権 (Forced)」を選択して強制された特権を割り当てます。

    2. 自分に割り当てられているプロファイルの 1 つに、必要な特権と一緒に setfpriv(1) が設定されている場合 (デフォルトでは、セキュリティ管理者役割) は、setfpriv を使用して許容セットと強制セットに同じ特権を割り当てます。

      次の例では、file_dac_read と file_dac_write を許容された特権と強制された特権に設定しています。


      $ setfpriv -s -f file_dac_read,file_dac_write -a file_dac_read,file_dac_write test.priv.file

トラステッドプログラムをトラステッドライブラリにリンクするには

  1. セキュリティ管理者役割になり、ADMIN_LOW ワークスペースに移動します。

    詳細は、「ログイン後、特定の管理役割になるには」を参照してください。

  2. 可能な場合は、特権アプリケーションが使用する共用ライブラリを表 1-4 に示したデフォルトのトラステッドライブラリディレクトリに移動します。

    表 16-4 共用ライブラリのデフォルトディレクトリ
     トラステッド C 関数ライブラリ X サーバー用トラステッド拡張
    /usr/lib /usr/openwin/lib
    /etc/lib/usr/dt/lib

  3. 特権を必要とするアプリケーションの共用ライブラリをトラステッドディレクトリに移動できない場合は、rtld ファイルにそのライブラリ用のディレクトリ名を追加します。

    1. 「管理用エディタ」アクションを使用して、/etc/security/tsol/rtld ファイルを新規に作成するか、既存のファイルを開いて編集します。

      詳細は、「管理用エディタアクションを使用してファイルを編集するには」を参照してください。

    2. ライブラリディレクトリのパス名を指定します。

      複数のパス名を指定するときは、それぞれをコロンで区切らなければなりません。


      /usr/lib/libname1:/usr/lib/libname2

    3. rtld ファイルを保存し、処理を終了します。


      :wq

特権コマンドを実行するプロファイルシェルスクリプトを作成するには

注 -

継承された特権を使ってコマンドを実行するプロファイルシェルスクリプトを追加する場合、プロファイルマネージャを使って適切なプロファイルを更新する必要があります。この手続きによってシェルスクリプト内で動作するコマンドが登録され、コマンドに適切な特権が割り当てられます。ある役割が、新しいプロファイルシェルスクリプトを使う必要がある場合、特権を必要とするすべてのコマンドを、そのスクリプト名とともに、役割に適用される Custom role_name またはその他のプロファイルに追加します。これは、セキュリティ管理者役割の仕事です。

プロファイルシェルスクリプトを作成するための条件は、テキストエディタを使用できることです。

  1. スクリプトの 1 行目は /bin/pfsh （この他のシェルは使用しません） で開始します。 


    #!/bin/pfsh

  2. 特権が必要なコマンドと、このコマンドに必要な特権を判断します。

    次の例では、/usr/lib/fs/nfs/nfsfind は cron ジョブで、スーパーユーザーが所有しています。これを ADMIN_HIGH で正常に実行するには、特権が必要です。tfind コマンドには file_dac_search 特権と file_dac_read 特権が必要で、rm コマンドには file_dac_search、file_mac_write、file_dac_read、file_mac_write の各特権が必要です。詳細は、「アプリケーションに必要な特権を調べるには」を参照してください。


    #!/bin/pfsh
# Copyright (c) 1993, 1997, 1998, 1999 by Sun Microsystems, Inc.
#ident  "@(#)nfsfind.sh 1.5     97/05/21 SMI; TSOL 2.x"
#
# Check shared NFS filesystems for .nfs* files that
# are more than a week old.
# 
# These files are created by NFS clients when an open file
# is removed. To preserve some semblance of Unix semantics
# the client renames the file to a unique name so that the
# file appears to have been removed from the directory, but
# is still usable by the process that has the file open.
if [ ! -s /etc/dfs/sharetab ]; then exit ; fi
 for dir in `awk '$3 == "nfs" {print $1}' /etc/dfs/sharetab`
do 
    tfind $dir -M -name .nfs¥* -mtime +7 -mount -exec rm -f {} ¥;
done

  3. セキュリティ管理者役割になり、ADMIN_LOW シェルに移動します。

    詳細は、「ログイン後、特定の管理役割になるには」を参照してください。

  4. プロファイルマネージャを使用して適切なプロファイルを更新します。シェルスクリプト内で実行するコマンドを記述し、そのコマンドに必要な特権を割り当ててください。

    詳細は、「管理アプリケーションを起動するには」を参照してください。

    この例の場合、スーパーユーザーが必要な特権を使用して cron スクリプトを実行するためには、セキュリティ管理者がプロファイルマネージャで Custom Root プロファイル (デフォルトでスーパーユーザーに割り当てられています) を更新します。プロファイルは、file_dac_search 特権と file_dac_read 特権を持つ tfind コマンドと file_dac_search、file_dac_write、file_dac_read、file_mac_write の各特権を持つ rm コマンドを含むように変更されます。

    注意 - 注意 -

    プロファイルにコマンドを追加し、そのコマンドに特権やその他のセキュリティ属性を付与すると、そのコマンドは、プロファイルシェルスクリプト内だけでなく、プロファイルシェルのコマンド行から呼び出された場合でも、付与された特権を使用して実行されます (呼び出し元のユーザーにコマンドが追加されたプロファイルが割り当てられている場合)。プロファイルが複数割り当てられている場合は、その順番も重要です。これは、プロファイルシェルでコマンドやアクションを実行する際、最初のプロファイルに指定されているセキュリティ属性が使用されるためです。たとえば、tfind が特権付きで Custom Root プロファイルに登録されており、このプロファイルが tfind を含む最初のプロファイルである場合、スーパーユーザー役割がプロファイルシェルのコマンド行から tfind を実行すると、tfind は Custom Rootプロファイルに指定された特権を継承します。

プロファイルシェルで特権コマンドを実行する標準シェルスクリプトを作成するには

注 -

ユーザーは、特権付きのコマンドを実行する標準シェルスクリプトを作成できます。作成したスクリプトをプロファイルに追加し、スクリプトに含まれるコマンドに必要なすべての特権を使って実行されるように指定してください。すると、このスクリプトを含むプロファイルを持つユーザーによってプロファイルシェルから呼び出されるとき、スクリプトは特権を継承します。

  1. スクリプトの 1 行目は、(/bin/pfsh ではなく) 任意の標準シェルで開始します。 


    #!/bin/csh

    シェルスクリプトを記述するための条件は、テキストエディタを使用できることです。

  2. 特権が必要なコマンドと、このコマンドに必要な特権を判断します。

    詳細は、「アプリケーションに必要な特権を調べるには」を参照してください。autosetpriv という例では、セキュリティ管理者は、強制された特権と許容された特権の定義済みセットを executable と呼ばれるファイルに割り当てます。このスクリプトの setfpriv コマンドには、 file_setpriv 特権が必要です。

    注 -

    このシェルスクリプトは、例として作成されています。通常のシェルスクリプトは特権とファイル名を引数として受け取り、エラー検査を行います。ここで紹介するシェルスクリプトは、例の中で指定した特権を executable という実行可能ファイルに割り当てる目的以外では、使用できません。これを実行したユーザーは全員は、「強制された特権」と「許容された特権」を使用できるようになります。


    #!/bin/csh
 setfpriv -s -f ipc_mac_write,ipc_upgrade_il,proc_setsl,sys_trans_label
-a ipc_mac_write,ipc_upgrade_il,proc_setsl,sys_trans_label executable

  3. セキュリティ管理者役割になり、ADMIN_LOW シェルに移動します。

    詳細は、「ログイン後、特定の管理役割になるには」を参照してください。

  4. プロファイルマネージャを使って適切なプロファイルを更新します。シェルスクリプト内で実行されるコマンドを記述し、そのコマンドに適切な特権を割り当ててください。

    詳細は、「プロファイルマネージャを起動するには」を参照してください。

    setfpriv コマンドに必要な file_setpriv 特権を使用して autosetpriv と呼ばれるスクリプトを実行するためには、セキュリティ管理者がプロファイルマネージャで Object Privileges プロファイル (デフォルトで セキュリティ管理者役割に割り当てられています) を更新し、autosetpriv スクリプトを追加し、autosetpriv に file_setpriv 特権を割り当てます。

  5. 必要に応じて、プロファイルシェル内でシェルスクリプトのテストやデバッグを行なったり実行したりします。


    $ autosetpriv

ブート時に実行するコマンドに拡張セキュリティ属性を使用するかどうかを指定するには

注 -

デフォルトの boot プロファイルに、ブート時に Trusted Solaris の拡張セキュリティ属性を使って呼び出されるコマンドを追加することは避けてください。デフォルトのプロファイルを変更するのではなく、新しいプロファイルを作成し、新しい sysh(1M) スクリプト内で setprof コマンドを使うようにしてください。次に、この手順を説明します。

  1. 希望のコマンドを呼び出したり停止させたりする新しい sysh スクリプトを作成します。

    詳細は、『Solaris のシステム管理 (第 1 巻)』の実行制御スクリプトに関する記述、sysh(1M)マニュアルページ、「ブート時にコマンドを実行するには」を参照してください。このスクリプトの先頭行は次のようになります。


    #!/bin/sysh
    注 -

    シェルスクリプトを作成するための条件は、テキストエディタを使用できることです。

  2. setprof オプションを使って実行プロファイルの名前を指定します。

    このスクリプトの 2 行目は次のようになります。new_profile_name は特定のプロファイル名で置き換えます。


    setprof new_profile_name

  3. セキュリティ管理者役割になり、ADMIN_LOWワークスペースに移動します。

    詳細は、「ログイン後、特定の管理役割になるには」を参照してください。

  4. このスクリプトを /etc/init.d ディレクトリにインストールし、このスクリプトに対するハードリンクを適切な /etc/rcn.d 内に作成します。

    以下の例では、/etc/init.d 内の新しいスクリプトの名前を new_script とします。new_script を /etc/rc2.d/S89new_script と /etc/rc2.d/K8new_script にリンクするには次のように入力します。


    $ pwd
/etc/init.d
$ ln new_script /etc/rc2.d/S89new_script
$ ln new_script /etc/rc2.d/K89new_script

    1. コマンドを呼び出したり停止させたりする各実行レベルに対応する /etc/rcn.d ディレクトリに移動し、適切な名前を持つ対象ファイルから /etc/init.d ディレクトリへのリンクを作成します。

    2. 対象ファイルの名前には、コマンドの呼び出しならば S 、停止ならば K という接頭辞を付けます。

    3. 各実行レベルへの移行時にスクリプトが実行される順番が判るように、対象ファイルの名前には適切な番号を含めます。


      $ cd /etc/rc2.d
$ ln /etc/init.d/scriptname [S|K]nnscriptname

  5. 新しいプロファイルを作成し、新しいスクリプト内のコマンドに対して Trusted Solaris セキュリティ属性を割り当てます。

    1. プロファイルマネージャを起動し、ネームサービスを選択します。

      詳細は、「実行プロファイル中内にコマンドを指定するには」を参照してください。

    2. ネットワークサービスが開始される前にコマンドを呼び出す場合は、プロファイルマネージャの「ネームサービス(Naming Service)」メニューで「なし (None)」を選択し、プロファイルが /etc/security/tsol/tsolprof 内にローカルに作成されるようにします。

    3. ネットワークサービスが開始されてからコマンドを呼び出す場合は、プロファイルマネージャの「ネームサービス(Naming Service)」メニューで「NIS+」を選択し、プロファイルが NIS+ マスター上の tsolprof NIS+ マップ内に作成されるようにします。

    4. プロファイルマネージャを使用して、コマンドを設定し、GID、機密ラベル、認可上限を割り当てる、新しいプロファイルを作成します (任意)。

  6. 「トラステッドパス (TP)」メニューの「シャットダウン」オプションを使ってコンピュータをシャットダウンし、起動監視プロンプトからリブートします。


    ok boot

ファイルを編集したときに特権を保存および復元するには

  1. セキュリティ管理者役割になり、getfpriv(1) を使って、実行可能ファイルの特権の一覧を表示し、その出力を保存します。

    次の例では、一覧の出力を一時ファイルに保存しています。 


    $ getfpriv executable_file > tempfile

  2. 実行可能ファイルを編集してから、ファイルマネージャを使用して、必要に応じてファイルを実行可能にし、一時ファイル内に保存されている特権を復元します。