JavaScript is required to for searching.
ナビゲーションリンクをスキップ
印刷ビューの終了
Oracle Solaris 11.1 の管理: セキュリティーサービス     Oracle Solaris 11.1 Information Library (日本語)
search filter icon
search icon

ドキュメントの情報

はじめに

パート I セキュリティーの概要

1.  セキュリティーサービス (概要)

パート II システム、ファイル、およびデバイスのセキュリティー

2.  マシンセキュリティーの管理 (概要)

3.  システムアクセスの制御 (タスク)

4.  ウイルススキャンサービス (タスク)

5.  デバイスアクセスの制御 (タスク)

6.  BART を使用したファイル整合性の検証 (タスク)

7.  ファイルアクセスの制御 (タスク)

パート III 役割、権利プロファイル、特権

8.  役割と特権の使用 (概要)

役割に基づくアクセス制御 (概要)

RBAC: スーパーユーザーモデルの代替機能

RBAC の要素と基本概念

特権エスカレーション

RBAC の承認

承認と特権

特権付きアプリケーションと RBAC

UID と GID を確認するアプリケーション

特権を確認するアプリケーション

承認を確認するアプリケーション

RBAC の権利プロファイル

RBAC の役割

プロファイルシェルと RBAC

ネームサービススコープと RBAC

セキュリティー属性を直接割り当てる場合に考慮すべきセキュリティー事項

セキュリティー属性を直接割り当てる場合の操作性に関する注意事項

特権 (概要)

カーネルプロセスを保護する特権

特権の種類

特権を使用したシステムにおける管理上の相違点

特権とシステムリソース

特権の実装方法

プロセスが特権を取得する方法

特権の割り当て

ユーザーまたは役割の特権の拡張

ユーザーまたは役割の特権の制限

スクリプトへの特権の割り当て

特権とデバイス

特権とデバッグ

このリリースでの RBAC について

9.  役割に基づくアクセス制御の使用 (タスク)

10.  Oracle Solaris のセキュリティー属性 (参照)

パート IV 暗号化サービス

11.  暗号化フレームワーク (概要)

12.  暗号化フレームワーク (タスク)

13.  鍵管理フレームワーク

パート V 認証サービスと安全な通信

14.  プラグイン可能認証モジュールの使用

15.  Secure Shell の使用

16.  Secure Shell (参照)

17.  簡易認証セキュリティー層の使用

18.  ネットワークサービスの認証 (タスク)

パート VI Kerberos サービス

19.  Kerberos サービスについて

20.  Kerberos サービスの計画

21.  Kerberos サービスの構成 (タスク)

22.  Kerberos エラーメッセージとトラブルシューティング

23.  Kerberos 主体とポリシーの管理 (タスク)

24.  Kerberos アプリケーションの使用 (タスク)

25.  Kerberos サービス (参照)

パート VII Oracle Solaris での監査

26.  監査 (概要)

27.  監査の計画

28.  監査の管理 (タスク)

29.  監査 (参照)

用語集

索引

特権 (概要)

プロセス権管理は、プロセスをコマンド、ユーザー、役割、またはシステムのいずれかのレベルに限定するために利用できます。Oracle Solaris では、特権を通してプロセス権管理を行います。特権は、システムに対するすべてのスーパーユーザー権限を 1 人のユーザーまたは 1 つのプロセスだけが持っている場合に伴うセキュリティーリスクを軽減します。特権と RBAC は、従来のスーパーユーザーモデルの代替となる強力なモデルを提供します。

カーネルプロセスを保護する特権

特権は、処理を実行するためにプロセスが必要とする個々の権利です。この権利はカーネルにおいて実効性があります。特権の基本セットの範囲内で動作するプログラムは、システムセキュリティーポリシーの範囲内で動作します。setuid プログラムは、システムセキュリティーポリシーの範囲を超えて動作するプログラムの例です。特権を使用することで、プログラムは setuid を呼び出さなくてすみます。

特権は、システム上で行える処理を個々にエミュレートします。プログラムは、その実行に必要な最小限の特権で実行できます。たとえば、ファイルを操作するプログラムには、file_dac_write および file_flag_set 特権が必要になることがあります。プロセス上のこれらの特権により、root としてプログラムを実行する必要がなくなります。

従来、システムは特権モデルを追求してきませんでした。むしろ、システムはスーパーユーザーモデルを使用していました。スーパーユーザーモデルでは、プロセスは root またはユーザーとして実行されます。ユーザープロセスは、ユーザーのディレクトリとファイルにだけ作用するように限定されました。root プロセスは、システム上の任意の場所にディレクトリとファイルを作成できました。ユーザーのディレクトリ以外の場所にディレクトリを作成する必要があるプロセスは、UID=0 を使用して (つまり root として) 実行されました。セキュリティーポリシーは、システムファイルを保護するのに、任意アクセス制御 (Discretionary Access Control、DAC) に依存していました。デバイスノードは、DAC によって保護されました。たとえば、グループ sys が所有しているデバイスをオープンできるのはこのグループのメンバーだけでした。

しかし、setuid プログラムやファイルアクセス権、管理アカウントなどは悪用される危険性があります。setuid プロセスに許可されているアクションは、このプロセスがその処理に必要な数を上回っています。setuid プログラムが侵入者に攻撃された場合には、全権を有する root ユーザーとしてふるまわれてしまいます。同様に、root パスワードにアクセスできるユーザーは誰でもシステム全体に損害を与えかねません。

これとは対照的に、特権によるポリシーを適用するシステムでは、ユーザー権限と root 権限との間に段階を付けることができます。あるユーザーに通常のユーザーの権限を越える動作を実行するための特権を付与したり、root の特権を root が現在所有している数より少ない数に制限したりできます。RBAC では、特権で実行されるコマンドを権利プロファイルとして分離し、これを 1 人のユーザーまたは 1 つの役割に割り当てることができます。表 8-1 は、特権を使用した RBAC モデルで利用できるユーザー権限と root 権限間の段階的な変化を示しています。

特権モデルでは、スーパーユーザーモデルより高いレベルのセキュリティーが実現されます。プロセスから削除された特権が悪用される可能性はありません。プロセス特権を利用することで、プログラムまたは管理アカウントが全機能のアクセス権を得ないように防止できます。プロセス特権は、DAC 保護だけでは弱点を突かれてアクセス権が取得される可能性があることから、重要なファイルを保護するための追加手段にもなります。

特権を使用することで、必要な機能しか持たないようにプログラムとプロセスを制限できます。これは、「最小特権の原則」と呼ばれます。最小特権が実装されたシステムでは、プロセスを取得した侵入者がアクセスできるのはそのプロセスに割り当てられた特権だけです。システムのほかの部分を攻撃することはできません。

特権の種類

特権は、それぞれの領域に基づいて論理的にグループ化されます。

その他の論理グループには、CONTRACTCPCDTRACEGRAPHICSVIRTWIN などがあります。

特権の中にはシステムに対する影響が少ないものもあれば、大きな影響を与えるものもあります。次の proc_taskid 特権の定義は、この特権の影響が小さいことを示しています。

proc_taskid
        Allows a process to assign a new task ID to the calling process.

net_rawaccess 特権の定義は、その影響が広範囲に及ぶことを示しています。

net_rawaccess
        Allow a process to have direct access to the network layer.

privileges(5) のマニュアルページには、すべての特権の説明が記載されています。コマンド ppriv -lv を実行すると、各特権の説明が標準出力に出力されます。

特権を使用したシステムにおける管理上の相違点

特権を持つシステムと特権を持たないシステムとでは、明白な違いがいくつかあります。次の表に相違点の一部を示します。

表 8-2 特権を持つシステムと特権を持たないシステムとの明白な違い

機能
特権なし
特権
デーモン
デーモンが root として実行されます。
デーモンが、ユーザー daemon として実行されます。

たとえば、デーモン lockd および rpcbind には適切な特権が割り当てられており、daemon として実行されます。

ログファイルの所有権
ログファイルは root によって所有されます。
ログファイルはログファイルを作成した daemon によって所有されます。root ユーザーがこのファイルを所有することはありません。
エラーメッセージ
エラーメッセージでスーパーユーザーが言及されます。

たとえば、chroot: not superuser

エラーメッセージで特権の使用が言及されます。

たとえば、chroot エラーと同等のエラーメッセージは chroot: exec failed

setuid プログラム
プログラムは、通常のユーザーが実行を許可されていないタスクを完了するために setuid を使用します。
多くの setuid プログラムは、特権を使用して実行されるように変更されました。

たとえば、コマンド auditikeadmipadmipsecconfpingtraceroute、および newtask は特権を使用します。

ファイルのアクセス権
デバイスアクセス権は DAC によって制御されます。たとえば、グループ sys のメンバーは /dev/ip を開くことができます。
デバイスを開くことができるユーザーをファイルアクセス権 (DAC) が予測することはありません。デバイスは、DAC デバイスポリシーによって保護されます。

たとえば、/dev/ip ファイルには 666 アクセス権がありますが、デバイスを開くことができるのは適切な特権を持つプロセスだけです。raw ソケットは依然として DAC によって保護されます。

監査イベント
su コマンドの使用の監査によって、多くの管理機能がカバーされます。
特権の使用の監査によって、ほとんどの管理機能がカバーされます。pmpsexua、および as 監査クラスには、デバイスポリシーや特権の使用をモニターする監査イベントが含まれています。
プロセス数
プロセスは、プロセスの所有者によって保護されます。
プロセスは特権によって保護されます。プロセス特権とプロセスフラグは、/proc/<pid> ディレクトリ内の新しいエントリである priv として確認できます。
デバッグ
コアダンプ内で特権の言及はありません。
コアダンプの ELF 注記セクションで、NT_PRPRIV および NT_PRPRIVINFO の注記としてプロセス特権とフラグについての情報が示されます。

ppriv コマンドやその他のコマンドでは、適切にサイズ設定されたセットの正しい数が示されます。これらのコマンドでは、ビットセット内のビットが特権名に正しく対応付けられます。

特権とシステムリソース

Oracle Solaris では、project.max-locked-memory および zone.max-locked-memory リソース制御を使用すると、PRIV_PROC_LOCK_MEMORY 特権が割り当てられているプロセスのメモリー消費を制限できます。プロセスはこの特権を使うことで、物理メモリー内のページをロックできます。

PRIV_PROC_LOCK_MEMORY 特権を権利プロファイルに割り当てると、この特権を持つプロセスに、すべてのメモリーをロックする権限を与えることになります。安全対策として、この特権ユーザーがすべてのメモリーをロックできないように、リソース制御を設定してください。特権付きプロセスが非大域ゾーン内で実行される場合には、zone.max-locked-memory リソース制御を設定します。特権付きプロセスがシステム上で実行される場合には、プロジェクトを作成し、project.max-locked-memory リソース制御を設定します。これらのリソース制御については、『Oracle Solaris 11.1 の管理: Oracle Solaris ゾーン、Oracle Solaris 10 ゾーン、およびリソース管理』の第 6 章「リソース制御 (概要)」および『Oracle Solaris 11.1 の管理: Oracle Solaris ゾーン、Oracle Solaris 10 ゾーン、およびリソース管理』の第 16 章「非大域ゾーンの構成 (概要)」を参照してください。

特権の実装方法

各プロセスには、プロセスが特定の特権を使用できるかどうかを判断する 4 セットの特権があります。カーネルは、特権「有効セット」を自動的に計算します。初期の特権「継承可能セット」は変更できます。特権を使用するように作成されているプログラムは、そのプログラムで使用する特権の「許可されたセット」を減らすことができます。特権「制限セット」は縮小できます。

カーネルは、「基本特権セット」を認識します。変更されていないシステムの場合、各ユーザーの初期の継承可能セットはログイン時の基本セットと同じです。基本セットを変更することはできませんが、ユーザーが基本セットからどの特権を継承するかは変更できます。

未変更のシステムでは、ログイン時のユーザーの特権セットは次のようになります。

E (Effective): basic
I (Inheritable): basic
P (Permitted): basic
L (Limit): all

このため、ログイン時には各ユーザーの基本セットは、それぞれの継承可能セット、許可されたセット、および有効セットに含まれます。ユーザーの制限セットは、ゾーン (大域または非大域) のデフォルトの制限セットと同等です。ユーザーの有効セットに特権を追加するには、そのユーザーに権利プロファイルを割り当てる必要があります。権利プロファイルは、通常、特権が追加されたコマンドを含みます。特権はユーザーまたは役割に直接割り当てることもできますが、そのような特権割り当てはリスクを伴います。リスクの詳細は、「セキュリティー属性を直接割り当てる場合に考慮すべきセキュリティー事項」を参照してください。

プロセスが特権を取得する方法

プロセスは特権を継承できます。あるいは、プロセスに特権を割り当てることもできます。プロセスは、その親から特権を継承します。ログイン時に、ユーザーの初期継承可能特権セットによって、そのユーザーのプロセスで使用できる特権が決まります。ユーザーの当初のログインの子プロセスはすべて、このセットを継承します。

プログラム、ユーザー、および役割に特権を直接割り当てることもできます。プログラムで特権が必要な場合は、権利プロファイル内でそのプログラムの実行可能ファイルに特権を割り当てます。そのプログラムの実行を許可されたユーザーまたは役割には、そのプログラムが入ったプロファイルを割り当てます。ログイン時、あるいはプロファイルシェルが開かれている場合、プログラムの実行可能ファイルがプロファイルシェルで入力されると、そのプログラムは特権を使用して実行されます。たとえば、Object Access Management プロファイルが含まれる役割は、file_chown 特権を使用して chmod コマンドを実行できます。

付加的な特権が直接割り当てられたプログラムを役割またはユーザーが実行する場合、割り当てられているその特権は役割またはユーザーの継承可能セットに追加されます。特権が割り当てられたプログラムの子プロセスは、親プロセスの特権を継承します。子プロセスが親プロセスよりも多くの特権を必要とする場合には、子プロセスに直接それらの特権を割り当てる必要があります。

特権を使用するように作成されているプログラムは、特権を認識する プログラムと呼ばれます。特権を認識するプログラムは、プログラム実行中に特権の使用を有効にしたり、無効にしたりします。本稼動環境で使用するためには、この特権をそのプログラムに割り当てる必要があります。

特権を認識するコードの例については、『Oracle Solaris 11 セキュリティーサービス開発ガイド』の第 2 章「特権付きアプリケーションの開発」を参照してください。特権を必要とするプログラムに特権を割り当てる場合は、例 9-18 を参照してください。

特権の割り当て

特権の割り当ては、セキュリティー管理者の権限を与えられたユーザーが行います。ベストプラクティスは、特権を権利プロファイル内のコマンドに割り当てることです。この割り当てのあと、この権利プロファイルを役割またはユーザーに割り当てます。

特権はまた、ユーザー、役割、または権利プロファイルに直接割り当てることもできます。セッションで特権を適切に使用すると信頼できるユーザーには、特権を直接割り当てることができます。直接の割り当てに適した候補としては、proc_clock_highres などの、影響が限られる特権があります。直接の割り当てに適しない候補としては、file_dac_write などの、影響が広範囲に及ぶ特権があります。

ユーザーまたはシステムに対して特権を拒否することもできます。ユーザーまたはシステムの初期継承可能セットまたは制限セットから特権を削除する場合は、注意が必要です。

ユーザーまたは役割の特権の拡張

ユーザーや役割には、継承可能な特権セットがあります。制限セットには初めにすべての特権が設定されるため、このセットは拡張できません。初期継承可能セットは、ユーザー、役割、システムを対象に拡張できます。プロセスには、継承可能セットに含まれない特権も割り当てることができます。

使用可能な特権を 3 つの方法で拡張できます。

特権を追加するのにもっとも適した方法は、プロセスごとの特権割り当てです。ユーザーに役割を割り当てることによって、そのユーザーが実行できる特権付き操作の数を拡張できます。この役割には、特権が追加されたコマンドを含む権利プロファイルが割り当てられます。役割を引き受ける際に、ユーザーはその役割のプロファイルシェルを取得します。その役割のシェルで権利プロファイルに含まれているコマンドが入力されると、それらのコマンドは追加された特権で実行されます。

権利プロファイルは、ユーザーが引き受ける役割にではなく、ユーザーに割り当てることもできます。ユーザーがプロファイルシェル (pfksh など) を開いたとき、そのユーザーは特権を使用して自分の権利プロファイル内のコマンドを実行できます。通常のシェルでは、特権によるコマンドの実行は行われません。特権が指定されたプロセスは、特権化されたシェルでしか実行できません。

ユーザー、役割、またはシステムの初期継承可能特権セットを拡張するのは、特権を割り当てる方法として安全とは言えません。継承可能セット内の特権はすべて、許可されたセットと有効セット内に存在します。シェル内でユーザーまたは役割が入力するコマンドはすべて、直接割り当てられた特権を使用できます。直接割り当てられた特権を使用すると、ユーザーまたは役割は、自分の管理責任の範囲を超えている場合もある操作を容易に実行できます。

このリスクを軽減するには、ユーザーまたは役割に特権を割り当てることにより、そのユーザーまたは役割が一度にオブジェクトに対して操作できるようにできます。可能性のあるオブジェクトとして、ネットワークポート、UID、およびファイルオブジェクトがあります。たとえば、/var/core ディレクトリ内のファイルに対する file_dac_read 特権をユーザーに割り当てることができます。file_dac_read 特権は、この拡張ポリシーが適用されるときに、そのユーザーのプロセスの実効セット内に存在する必要があります。その場合は、このディレクトリオブジェクトに対する拡張ポリシーがこのユーザーに割り当てられると、そのユーザーは /var/core ディレクトリ内のすべてのファイルを読み取ることができます。

システムの初期継承可能特権セットを拡張すると、そのシステムにログインするユーザー全員の基本特権が拡張されます。このような直接の割り当てを使用すると、システムのすべてのユーザーが、通常のユーザーの範囲外にある可能性のある操作を容易に実行できるようになります。


注 - 制限セットには初めにすべての特権が設定されるため、このセットは拡張できません。


ユーザーまたは役割の特権の制限

特権を削除することで、ユーザーまたは役割が特定のタスクを行わないようにすることができます。特権は、初期継承可能セットから削除することも、制限セットから削除することもできます。デフォルトセットよりも小さい初期継承可能セットまたは制限セットを配布する場合は、あらかじめ特権の削除を慎重にテストすることが望まれます。たとえば、初期継承可能セットから特権を削除したためにユーザーがログインできなくなる可能性があります。また、制限セットから特権を削除したために古い setuid プログラムでその特権が使えなくなり、プログラムが失敗する可能性があります。

スクリプトへの特権の割り当て

スクリプトは、コマンドと同様に実行が可能です。このため、コマンドに特権を追加する場合と同じ方法で、権利プロファイルでスクリプトに特権を追加できます。権利プロファイルが割り当てられたユーザーまたは役割がプロファイルシェルでスクリプトを実行すると、スクリプトは、それらの追加された特権で実行されます。スクリプトに特権が必要なコマンドが含まれている場合は、特権が追加されたコマンドも、割り当てられた権利プロファイルに含まれている必要があります。

特権を認識するプログラムは、プロセス単位で特権を制限できます。特権を認識するプログラムを使用するジョブは、プログラムで必要な特権だけを実行可能ファイルに割り当てます。続いて管理者はこのプログラムのテストを行い、タスクが正常に行われるか確認します。また、プログラムが特権を悪用しないかも確認します。

特権とデバイス

スーパーユーザーモデルではファイルアクセス権によってのみ保護されるシステムインタフェースを、特権モデルでは特権を使用して保護します。特権を使用したシステムでは、インタフェースを保護するほどの強さはファイルアクセス権にありません。proc_owner などの特権は、ファイルアクセス権をオーバーライドした上でファイルシステム全体へのフルアクセス権を与える可能性があります。

このため、Oracle Solaris では、デバイスを開くにはデバイスディレクトリの所有権では不十分です。たとえば、グループ sys のメンバーには、/dev/ip デバイスを開くことが自動的には許可されなくなります。/dev/ip のファイルアクセス権は 0666 ですが、デバイスを開くには net_rawaccess 特権が必要です。

デバイスポリシーは特権によって制御されます。getdevpolicy コマンドは、各デバイスのデバイスポリシーを表示します。デバイス構成コマンド devfsadm は、デバイスポリシーをインストールします。devfsadm コマンドは、デバイスの読み取りまたは書き込みを行うため open に特権セットを設定します。詳細は、getdevpolicy(1M) および devfsadm(1M) のマニュアルページを参照してください。

デバイスポリシーを使えば、デバイスを開く権限をより柔軟に付与できます。デフォルトのデバイスポリシーとは異なる特権や、デフォルトのデバイスポリシーよりも多くの特権を要求することができます。特権要件は、デバイスポリシーに合わせて変更することも、ドライバ本体に合わせて変更することもできます。特権の変更は、デバイスドライバのインストール時、追加時、または更新時に行えます。

add_drv および update_drv コマンドは、デバイスポリシーエントリやドライバ固有の特権を変更するために使用されます。デバイスポリシーを変更するには、完全な特権セットを持つプロセスを実行している必要があります。詳細は、add_drv(1M) および update_drv(1M) のマニュアルページを参照してください。

特権とデバッグ

Oracle Solaris には、特権のエラーを修正するツールが用意されています。ppriv コマンドと truss コマンドを使用して、デバッグ結果を出力できます。この例は、ppriv(1) のマニュアルページを参照してください。操作の手順は、「プログラムが必要とする特権を判断する方法」を参照してください。また、dtrace コマンドを使用することもできます。詳細は、dtrace(1M) のマニュアルページを参照してください。