特権 (概要)

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

• RBAC については、「役割によるアクセス制御 (概要)」を参照してください。

• 特権の管理方法については、第 11 章特権 (手順)を参照してください。

• 特権に関連した参考情報としては、第 12 章特権 (参照)を参照してください。

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

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

特権は、システム上で行える処理を個々にエミュレートします。プログラムは、その実行に必要な最小限の特権で実行できます。たとえば、日付を設定してその日付を管理ファイルに書き込むプログラムは、file_dac_write 特権と sys_time 特権があれば実行できます。この機能を利用することで、あらゆるプログラムを root として実行する必要がなくなります。

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

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

これとは対照的に、特権によるポリシーを適用するシステムでは、ユーザー権限と root 権限との間に段階を付けることができます。たとえば、通常のユーザー権限を超える処理が可能となる特権を特定のユーザーに与えたり、現在持っている特権よりも少なくなるように root の特権数を制限したりできます。RBAC では、特権で実行されるコマンドを権利プロファイルとして分離し、これを 1 人のユーザーまたは 1 つの役割に割り当てることができます。表 8–1 は、特権を使用した RBAC モデルで利用できるユーザー権限とスーパーユーザー権限間の段階的な変化を示しています。

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

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

特権の種類

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

• FILE 特権 – 文字列 file で始まる特権は、ファイルシステムオブジェクトに対して作用します。たとえば、file_dac_write 特権は、ファイルへの書き込みの際に任意アクセス制御に優先します。

• IPC 特権 – 文字列 ipc で始まる特権は、IPC オブジェクトアクセス制御を無効にします。たとえば、ipc_dac_read 特権を使用すると、DAC によって保護されている遠隔共有メモリーを読み取るプロセスが可能となります。

• NET 特権 – 文字列 net で始まる特権は、特定のネットワーク機能へのアクセスを可能にします。たとえば、net_rawaccess 特権を使用すると、デバイスをネットワークに接続できます。

• PROC 特権 – 文字列 proc で始まる特権は、プロセスがそれ自体の限定されたプロパティーを変更できます。PROC 特権の中には、ごくわずかな効果しかない特権もあります。たとえば、proc_clock_highres 特権は、プロセスが高分解能タイマーを使用できます。

• SYS 特権 – 文字列 sys で始まる特権は、各種のシステムプロパティーに対する無制限のアクセス権をプロセスに与えます。たとえば、sys_linkdir 特権を使用すると、プロセスはディレクトリに対するハードリンクの確立と解除が行えます。

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

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

file_setid 特権の定義は、この特権の影響が大きいことを示しています。

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

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

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

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

特権とシステム資源

Solaris 10 8/07 リリースから、PRIV_PROC_LOCK_MEMORY 特権が割り当てられたプロセスのメモリー消費を、project.max-locked-memory および zone.max-locked-memory 資源制御を使って制限できるようになりました。プロセスはこの特権を使うことで、物理メモリー内のページをロックできます。

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

特権の実装方法

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

• 有効特権セット (E) – 現在有効である特権の集合です。プロセスは、許可されたセット内の特権を有効セットに追加できます。プロセスは、E から特権を削除することもできます。

• 許可された特権セット (P) – 使用できる特権の集合です。プログラムは、継承または割り当てを通して特権を使用できます。実行プロファイルは、プログラムに特権を割り当てる方法の 1 つです。setuid コマンドは、root が持つすべての特権をプログラムに割り当てます。許可されたセットから特権を削除することはできますが、許可されたセットに特権を追加することはできません。P から削除された特権は、E からも自動的に削除されます。

  「特権を認識する」プログラムは、そのプログラムがまったく使用することのない特権をそのプログラムの許可されたセットから削除します。この方法では、不要な特権がそのプログラムや悪質なプロセスによって悪用されることが防止されます。特権を認識するプログラムの詳細は、『Oracle Solaris セキュリティーサービス開発ガイド』の第 2 章「特権付きアプリケーションの開発」を参照してください。

• 継承可能な特権セット (I) – exec 呼び出しでプロセスが継承できる特権の集合です。exec 呼び出しのあと、setuid プログラムの特殊なケースを除き、許可されたセットと有効セットは同じになります。

  setuid プログラムの場合、exec 呼び出しのあと、継承可能セットがまず制限セットによって制限されます。続いて、継承された特権のセット (I) から制限セット (L) が除かれたものが、そのプロセスの P と E に割り当てられます。

• 制限特権セット (L) – プロセスおよびその子プロセスで使用できる特権の外側の限界です。デフォルトでは、制限セットはすべての特権です。プロセスは制限セットを縮小することはできますが、制限セットを拡張することはできません。L は I の制限に使用されます。このため、L は exec の時点で P と E を制限します。

  特権が割り当てられたプログラムを含むプロファイルがユーザーに割り当てられている場合、通常そのユーザーはそのプログラムを実行できます。未変更のシステムでは、プログラムの割り当て済み特権はユーザーの制限セットの範囲内です。プログラムに割り当てられている特権は、ユーザーの許可されたセットの一部になります。特権を割り当てられたプログラムを実行するには、プロファイルシェルからそのプログラムを実行する必要があります。

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

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

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

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

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

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

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

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

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

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

特権の割り当て

特権の割り当ては、システム管理者の権限を与えられたユーザーによって行われます。この管理者は、通常、権利プロファイル内でコマンドに特権を割り当てます。この割り当てのあと、この権利プロファイルを役割またはユーザーに割り当てます。Solaris 管理コンソールには、特権を割り当てるためのグラフィカルユーザーインタフェース (GUI) が用意されています。特権の割り当ては、smuser や smrole のようなコマンドを使用しても行えます。GUI を使用して特権を割り当てる方法の詳細は、第 9 章役割によるアクセス制御の使用 (手順)を参照してください。

特権をユーザーに直接割り当てることもできます。セッションで特権を適切に使用すると信頼できるユーザーには、特権を直接割り当てることができます。直接の割り当てが適するものとしては、影響の少ない特権 (proc_clock_highres など) が挙げられます。影響が広範囲におよぶ特権 (file_dac_write など) は、直接の割り当てに適しません。

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

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

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

特権を追加するのにもっとも適した方法は、プロセスごとの特権割り当てです。ユーザーが実行できる特権化された処理の数は、役割の引き受けをそのユーザーに許可することで増やせます。役割には、追加された特権が指定されたコマンドを含むプロファイルを割り当てます。役割を引き受ける際に、ユーザーはその役割のプロファイルシェルを取得します。役割のプロファイルに指定されたコマンドをその役割のシェルで入力すると、追加された特権を使用してコマンドが実行されます。

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

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

システムの初期継承可能特権セットを拡張すると、そのシステムにログインするユーザー全員の基本特権が拡張されます。このような直接割り当てを行うと、通常のユーザーには禁止されている処理でもシステムの全ユーザーが簡単に行えるようになります。

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

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

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

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

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

特権とデバイス

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

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

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

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

デバイスポリシーエントリとドライバ固有の特権を変更するには、add_drv コマンドと update_drv コマンドを使用できます。デバイスポリシーを変更するには、すべての特権を使用してプロセスを実行していなければなりません。詳細は、add_drv(1M) および update_drv(1M) のマニュアルページを参照してください。

特権とデバッグ

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