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

Solaris の「役割によるアクセス制御 (RBAC)」と特権は、スーパーユーザーよりも厳密な機密保護機能です。この章では、RBAC と特権についての概要を述べます。

この章の内容は次のとおりです。

• 「役割によるアクセス制御 (概要)」

• 「特権 (概要)」

RBAC の新機能

Solaris 10 8/07: このリリースから、project.max-locked-memory および zone.max-locked-memory 資源制御が導入されました。PRIV_PROC_LOCK_MEMORY 特権をあるユーザーや非大域ゾーンに割り当てる場合に、これらの資源制御を使えば、そのユーザーやゾーンがすべてのメモリーをロックしてしまうのを防ぐことができます。詳細については、「特権とシステム資源」を参照してください。

Solaris 10 10/08: このリリースでは、solaris.admin.usermgr 承認が再編成され、高度にセキュリティー保護されたインストールのセキュリティー要件である「責務の分離」をサポートするようになりました。責務の分離を満たすには、ユーザーアカウントの作成に 2 つのアカウントが必要になります。この要件に対応するようにソフトウェアを構成するには、『Oracle Solaris Trusted Extensions 構成ガイド』の「責務分離を実施する権利プロファイルを作成する」を参照してください。また、このリリースでは、役割のパスワードを変更する方法もこのマニュアルの 「役割のパスワードを変更する方法」で説明されています。

Solaris 10 9/10: このリリースでは、特権の基本セットに net_access 特権が追加されました。特権については、privileges(5) のマニュアルページを参照してください。

役割によるアクセス制御 (概要)

役割によるアクセス制御 (RBAC) は、通常はスーパーユーザーに限定されているタスクに対するユーザーアクセスを制御するセキュリティー機能です。RBAC では、プロセスやユーザーにセキュリティー属性を適用することで、スーパーユーザーの権限を複数の管理者に分けることができます。プロセス権管理は、「特権」を介して実装されます。ユーザー権管理は RBAC によって行われます。

• プロセス権管理については、「特権 (概要)」を参照してください。

• RBAC 関連の作業については、第 9 章役割によるアクセス制御の使用 (手順)を参照してください。

• 第 10 章役割によるアクセス制御 (参照)にも参考情報が挙げられています。

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

従来の UNIX システムでは、root ユーザー (スーパーユーザーとも呼ばれる) が全権を有します。root として実行されるプログラム、または setuid プログラムにも全権があります。root ユーザーは全ファイルの読み取り権とアクセス権、全プログラムの実行権を持ち、任意のプロセスに終了シグナルを送ることができます。実際、スーパーユーザーになるユーザーは、使用するサイトのファイアウォールの変更、監査トレールの変更、機密レコードの読み取り、ネットワーク全体の停止などを行えます。setuid プログラムがハイジャック (強奪) されると、システム上で何が起きても不思議はありません。

役割によるアクセス制御 (RBAC) は、絶対的なスーパーユーザーモデルに代わるより厳密な機密保護機能です。RBAC を使用することで、セキュリティーポリシーをきめ細かく適用できます。RBAC では、「最小特権」というセキュリティー原則が使用されます。最小特権は、ジョブを行う上で必要な特権だけをユーザーに与えることを意味します。通常のユーザーには、アプリケーションの実行、実行中のジョブの状態チェック、ファイルの出力、新しいファイルの作成などに必要なだけの特権が与えられます。通常のユーザー権限を超える権限は、権利プロファイルとしてグループ化されます。スーパーユーザー権限の一部が必要なジョブを行うユーザーは、適切な権利プロファイルを含む役割を引き受けます。

RBAC では、スーパーユーザー権限を「権利プロファイル」としてまとめます。これらの権利プロファイルは、「役割」と呼ばれる特殊なユーザーアカウントに割り当てられます。ユーザーは、スーパーユーザー権限の一部を必要とするジョブを行う場合に役割を引き受けることができます。Solaris ソフトウェアには、あらかじめ定義された権利プロファイルが用意されています。管理者は役割を作成し、プロファイルを割り当てます。

権利プロファイルを使用することで、さまざまな権限を提供できます。たとえば、Primary Administrator 権利プロファイルはスーパーユーザーと同等です。権限を限定して権利プロファイルを定義することもできます。たとえば、Cron Management 権利プロファイルは at ジョブと cron ジョブを管理します。役割を作成する場合は、多くの権限を持つ役割を作ることも、わずかな権限を持つ役割を作ることもできます。あるいはこの両方を作成することも可能です。

RBAC モデルでは、スーパーユーザーが 1 つ以上の役割を作成します。役割は、権利プロファイルに基づいて作成されます。続いてスーパーユーザーは、役割の作業に適したユーザーにその役割を割り当てます。ユーザーは、各自のユーザー名でログインします。ログイン後ユーザーは、限定された管理コマンドとグラフィカルユーザーインタフェース (GUI) ツールを実行できる役割を引き受けます。

役割は柔軟に設定できるため、さまざまなセキュリティーポリシーに対応できます。出荷時の Solaris オペレーティングシステム (Solaris OS) には役割は定義されていませんが、推奨の 3 つの役割は簡単に設定できます。これらの役割は、同じ名前の権利プロファイルに基づいています。次にこれらの役割を示します。

• Primary Administrator – root ユーザー (スーパーユーザー) と同等の強力な役割。

• System Administrator – セキュリティーに関係のない管理作業を行う役割で、権限が限定されています。この役割ではファイルシステム、メール、ソフトウェアのインストールなどを管理できます。ただし、パスワードの設定は行えません。

• Operator – バックアップやプリンタ管理などが行える、補佐的な管理者向けの役割。

これらの 3 つの役割の実装は必須ではありません。役割は、組織のセキュリティー要件に応じて設定する機能です。役割は、セキュリティー、ネットワーク、ファイアウォールの管理など、特定の目的の管理に合わせて設定できます。別の方法として、強力な管理者役割を 1 つと上級ユーザー役割を作成することもできます。この上級ユーザー役割は、自分のシステムの各部を修正することを認められたユーザーに割り当てます。

スーパーユーザーモデルと RBAC モデルは共存できます。次の表は、RBAC モデルで設定できる権限 (スーパーユーザーから制限された通常ユーザーまで) を順に挙げ、両モデルで監視できる管理アクションを示しています。システム上での特権の効果だけをまとめた情報としては、表 8–2 を参照してください。

Solaris RBAC の要素と基本概念

Solaris OS の RBAC モデルでは、次の要素が導入されました。

• 承認 – セキュリティーに影響を及ぼす可能性のあるアクション群をユーザーまたは役割が実行できるようにするアクセス権。たとえばインストール時には、セキュリティーポリシーによって solaris.device.cdrw 承認が通常のユーザーに与えられます。この承認によってユーザーは CD-ROM デバイスの読み取りと書き込みが行えます。承認の一覧は、/etc/security/auth_attr ファイルを参照してください。

• 特権 – コマンド、ユーザー、役割、またはシステムに与えることができる個別の権利。特権によってプロセスの正常実行が可能となります。たとえば、proc_exec 特権によってプロセスは execve() を呼び出すことができます。通常のユーザーには基本特権が与えられます。自分の基本特権を確認するには、ppriv -vl basic コマンドを実行します。

• セキュリティー属性 – プロセス処理を可能にする属性。典型的な UNIX 環境では、通常のユーザーに禁止されているプロセス処理が、セキュリティー属性によって可能になります。たとえば、setuid プログラムと setgid プログラムはセキュリティー属性を持ちます。RBAC モデルでは、通常のユーザーが行う処理でセキュリティー属性が要求されることがあります。RBAC モデルでは、setuid プログラムや setgid プログラムだけでなく、承認と特権もセキュリティー属性です。たとえば、solaris.device.allocate 承認が与えられたユーザーは、デバイスを独占的に使用するためにそのデバイスの割り当てを行うことができます。sys_time 特権を持つプロセスは、システム時刻を操作できます。

• 特権付きアプリケーション – セキュリティー属性を確認することによってシステム制御に優先するアプリケーションまたはコマンド。典型的な UNIX 環境と RBAC モデルでは、setuid と setgid を使用するプログラムは特権付きアプリケーションです。RBAC モデルでは、処理を正常に実行する上で特権または承認を必要とするプログラムも特権付きアプリケーションです。詳細は、「特権付きアプリケーションと RBAC」を参照してください。

• 権利プロファイル – 役割またはユーザーに割り当てることができる管理権限の集まり。権利プロファイルには、承認から構成されるもの、セキュリティー属性を持つコマンドから構成されるもの、ほかの権利プロファイルから構成されるものがあります。権利プロファイルは、セキュリティー属性をグループ化する手段として便利です。

• 役割 – 特権付きアプリケーションを実行するための特殊な識別情報。この特殊な識別情報を取得できるのは、あらかじめ割り当てられたユーザーだけです。役割によって実行されるシステムではスーパーユーザーは不要です。スーパーユーザー権限はいくつかの役割に分散されます。たとえば、役割が 2 つ存在するシステムでは、セキュリティー作業をセキュリティー役割によって処理し、セキュリティー関連ではないシステム管理作業を他方の役割で処理できます。役割を細かく分割することも可能です。たとえば、暗号化フレームワーク、プリンタ、システム時刻、ファイルシステム、監査などをそれぞれ処理する個別の管理役割を作成できます。

次の図では、各 RBAC 要素の動作を示します。

図 8–1 Solaris RBAC 要素の動作

RBAC では、ユーザーに役割が割り当てられます。役割を引き受けると、ユーザーはその役割の権限を利用できる状態となります。役割の権限は権利プロファイルから取得されます。権利プロファイルには、承認、特権付きコマンド、その他の補足的な権利プロファイルを含めることができます。特権付きコマンドは、セキュリティー属性を使用して実行されるコマンドです。

次の図は、Operator 役割、Operator 権利プロファイル、Printer Management 権利プロファイルを例に、RBAC 要素の関係を示しています。

図 8–2 Solaris RBAC 要素の関係の例

Operator 役割は、プリンタ管理とメディアのバックアップを行うのに使用されます。この役割は、ユーザー jdoe に割り当てられています。jdoe は、この役割に切り替えて役割のパスワードを入力することにより、この役割を引き受けることができます。

Operator 権利プロファイルは、Operator 役割に割り当てられています。Operator 権利プロファイルには、2 つの補助プロファイル Printer Management と Media Backup が割り当てられています。これらの補助プロファイルは、Operator 役割の主要な作業を反映しています。

Printer Management 権利プロファイルは、プリンタ、印刷デーモン、およびスプーラの管理用プロファイルです。Printer Management 権利プロファイルには、 solaris.admin.printer.read、solaris.admin.printer.delete、および solaris.admin.printer.modify 承認が含まれています。これらの承認を使用することで、役割とユーザーはプリンタキューの情報を操作できます。Printer Management 権利プロファイルには、euid=lp が指定された /usr/sbin/lpshut、euid=0 が指定された /usr/ucb/lpq など、セキュリティー属性が指定された多数のコマンドも含まれます。

RBAC の承認

「承認」は、役割またはユーザーに許可できる個別の権限です。承認は、ユーザーアプリケーションレベルでポリシーを適用します。承認は、役割またはユーザーに直接割り当てることができます。一般に、承認は権利プロファイルに含められます。権利プロファイルは役割に含められ、役割がユーザーに割り当てられます。例については、図 8–2 を参照してください。

RBAC に準拠したアプリケーションは、ユーザーの承認を確認してから、アプリケーションまたはアプリケーション内の特定の操作に対するアクセス権を許可します。この承認の確認は、従来の UNIX アプリケーションが行なっていた UID=0 の確認に代わるものです。承認についての詳細は次の節で説明します。

• 「承認の命名と委託」

• 「auth_attr データベース」

• 「承認を必要とするコマンド」

承認と特権

特権は、カーネル内でセキュリティーポリシーを適用します。承認と特権の違いは、セキュリティーポリシーが適用されるレベルにあります。プロセスに適切な特権がないと、特権化された処理の実行がカーネルによって防止される可能性があります。適切な承認が与えられていないユーザーは、特権付きアプリケーションを使用できなかったり、特権付きアプリケーションに含まれるセキュリティーの厳しい処理を実行できなかったりする可能性があります。特権についての詳細は、「特権 (概要)」を参照してください。

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

システム制御に優先するアプリケーションとコマンドは、特権付きアプリケーションとみなされます。アプリケーションは、UID=0 のようなセキュリティー属性、特権、および承認によって特権化されます。

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

root (UID=0) やその他の特殊な UID または GID を確認する特権付きアプリケーションは、UNIX 環境に古くから存在します。権利プロファイルのメカニズムによって、特定の ID を必要とするコマンドを分離できます。任意のユーザーがアクセスできるコマンドの ID を変更する代わりに、実行セキュリティー属性を指定したコマンドとして権利プロファイルに配置できます。その権利プロファイルを持つユーザーまたは役割であれば、スーパーユーザー以外でもプログラムを実行できます。

ID として、実 ID または実効 ID を指定できます。実効 ID を割り当てた場合は、実 ID より優先されます。実効 ID は、ファイルアクセス権ビットの setuid 機能に相当します。実行 ID は、監査のために UID の識別も行います。ただし、root の実 UID を要求するシェルスクリプトやプログラムのために、実 ID も設定できます。たとえば、pkgadd コマンドは、実効 UID ではなく実 UID を要求します。コマンドを実行する上で実効 ID では十分でない場合は、ID を実 ID に変更する必要があります。手順については、「権利プロファイルを作成または変更する方法」を参照してください。

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

特権付きアプリケーションでは、特権の使用を確認できます。RBAC 権利プロファイルメカニズムを使用すれば、特定のコマンドに特権を指定できます。この方法では、アプリケーションまたはコマンドの実行時にスーパーユーザー権限を要求するのではなく、実行セキュリティー属性を指定してコマンドを権利プロファイルとして分離します。この権利プロファイルを持つユーザーまたは役割は、そのコマンドの実行に必要な特権だけを使用してコマンドを実行できます。

特権を確認するコマンドとして次のようなものがあります。

• Kerberos コマンド (kadmin、kprop、kdb5_util など)

• ネットワークコマンド (ifconfig、routeadm、snoop など)

• ファイルコマンドとファイルシステムコマンド (chmod、chgrp、mount など)

• プロセスを制御するコマンド (kill、pcred、rcapadm など)

コマンドに特権を指定して権利プロファイルに追加する方法は、「権利プロファイルを作成または変更する方法」を参照してください。特定のプロファイルに特権が存在するか確認するコマンドを調べる方法については、「割り当てられた特権の判断」を参照してください。

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

Solaris OS には、承認を確認するコマンドも用意されています。当然ながら、root ユーザーにはあらゆる承認が与えられます。このため、root ユーザーは任意のアプリケーションを実行できます。承認があるかどうかを確認するアプリケーションには次のようなものがあります。

• Solaris 管理コンソールのすべてのツール

• 監査管理用のコマンド (auditconfig、auditreduce など)

• プリンタ管理用のコマンド (lpadmin、lpfilter など)

• バッチジョブ関連のコマンド (at、atq、batch、crontab など)

• デバイス向けのコマンド (allocate、deallocate、list_devices、cdrw など)

承認の確認のためにスクリプトまたはプログラムをテストする方法については、例 9–24 を参照してください。承認が必要なプログラムの作成方法については、『Oracle Solaris セキュリティーサービス開発ガイド』の「承認について」を参照してください。

RBAC の権利プロファイル

「権利プロファイル」は、役割またはユーザーに割り当てることができるシステムの設定より優先されるオペレーションの集合です。権利プロファイルには、承認、割り当て済みのセキュリティー属性が指定されたコマンド、その他の権利プロファイルを含めることができます。権利プロファイル情報は、prof_attr データベースと exec_attr データベースに分けて保存されます。権利プロファイル名と承認は、prof_attr データベースに置かれます。権利プロファイル名と、割り当て済みのセキュリティー属性が指定されたコマンドは、exec_attr データベースに置かれます。

権利プロファイルの詳細は、次の節を参照してください。

• 「権利プロファイルの内容」

• 「prof_attr データベース」

• 「exec_attr データベース」

RBAC の役割

「役割」は、特権付きアプリケーションを実行できる特別な種類のユーザーアカウントです。役割は、ユーザーアカウントと同じ方法で作成され、ホームディレクトリ、グループ割り当て、パスワードなどを持ちます。権利プロファイルと承認は、役割に管理権限を与えます。役割は、ほかの役割やユーザーから権限を継承することはできません。個々の役割によってスーパーユーザー権限が分配されるため、安全な管理が行えるようになります。

ユーザーが役割を引き受けると、その役割の属性がすべてのユーザー属性を置き換えます。役割情報は、passwd、shadow、および user_attr データベースに保存されます。役割情報の追加は、audit_user データベースに対して行うことができます。役割の設定についての詳細は、次の節を参照してください。

• 「RBAC の実装を計画する方法」

• 「コマンド行から役割を作成する方法」

• 「役割のプロパティーを変更する方法」

各役割は、複数のユーザーに割り当てることができます。同じ役割になるすべてのユーザーは、同じ役割のホームディレクトリを持ち、同じ環境で動作し、同じファイルへのアクセス権を持ちます。ユーザーは、コマンド行から su コマンドを実行し、役割名とパスワードを指定して役割を引き受けることができます。Solaris 管理コンソールツールで役割を引き受けることもできます。

役割自体が直接ログインすることはできません。ユーザーがまずログインし、続いて役割を引き受けます。役割を引き受けたあとは、その役割を終了するまでほかの役割を引き受けることはできません。つまり、その役割を終了すれば、ほかの役割を引き受けることができます。

「root ユーザーを役割にする方法」に示しているように、root ユーザーを役割に変更することによって、匿名の root ログインを防ぐことができます。プロファイルシェルコマンド pfexec が監査の対象となっている場合、監査トレールにはログインユーザーの実 UID、そのユーザーが引き受けた役割、およびその役割が行ったアクションが記録されます。役割による処理を行うシステムまたは特定のユーザーを監査する方法については、「役割を監査する方法」を参照してください。

Solaris には、事前に定義された役割は用意されていません。ただし、ソフトウェアに付属している権利プロファイルは、役割に対応付けられています。たとえば、Primary Administrator 権利プロファイルを使用すると、Primary Administrator 役割を作成できます。

• Primary Administrator 役割を設定する方法については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

• ほかの役割の設定方法については、「GUI を使用して役割の作成および割り当てを行う方法」を参照してください。

• コマンド行で役割を作成する方法については、「RBAC の管理(作業マップ)」を参照してください。

RBAC におけるプロファイルシェル

役割は、特権付きアプリケーションを Solaris 管理コンソール起動ツールから実行することも、あるいは「プロファイルシェル」から実行することもできます。プロファイルシェルは、権利プロファイルに含まれるセキュリティー属性を認識する特殊なシェルです。プロファイルシェルは、ユーザーが su コマンドを実行して役割を引き受けたときに起動されます。プロファイルシェルには、pfsh、pfcsh、および pfksh があります。これらはそれぞれ、Bourne シェル (sh)、C シェル (csh)、および Korn シェル (ksh) に対応します。多くのシェルには、対応するプロファイルシェルが存在します。たとえば、Bourne シェル (sh)、C シェル (csh)、および Korn シェル (ksh) に対応するプロファイルシェルは、それぞれ pfsh、pfcsh、および pfksh です。プロファイルシェルのリストについては、pfexec(1) のマニュアルページを参照してください。

権利プロファイルが直接割り当てられたユーザーは、セキュリティー属性が指定されたコマンドを実行する場合、プロファイルシェルを起動する必要があります。操作性やセキュリティーに関する考慮事項については、「セキュリティー属性を直接割り当てる場合に考慮すべきセキュリティー事項」を参照してください。

プロファイルシェルで実行されるコマンドはすべて、監査の対象に含めることができます。詳細は、「役割を監査する方法」を参照してください。

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

ネームサービススコープは、RBAC を理解する上で重要な概念です。役割の適用範囲は、個々のホストに限定されることもあれば、ネームサービス (NIS、NIS+、または LDAP) のサービス対象となるすべてのホストとなることもあります。システムにおけるネームサービススコープは、/etc/nsswitch.conf で指定します。検索は、最初に一致した時点で停止します。たとえば、権利プロファイルが 2 つのネームサービススコープに存在する場合、最初のネームサービススコープに含まれるエントリだけが使用されます。最初に一致したものが files の場合、役割の適用範囲はローカルホストに限定されます。

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

一般にユーザーは、役割を通して管理権限を取得します。承認と、特権付きコマンドは、権利プロファイル内でグループ化されます。権利プロファイルは役割に含められ、役割がユーザーに割り当てられます。

権利プロファイルとセキュリティー属性を直接割り当てることも可能です。

• ユーザーには、権利プロファイル、特権、および承認を直接割り当てることができます。

• 役割には、特権と承認を直接割り当てることができます。

しかし、割り当てを直接行うことは安全とは言えません。特権が直接割り当てられたユーザーと役割は、カーネルがその特権を要求するどの場合でもセキュリティーポリシーに優先します。特権が権利プロファイルでコマンドのセキュリティー属性として指定される場合には、その特権はその権利プロファイルを持つユーザーによってそのコマンドでしか使用できません。そのユーザーまたは役割が実行するほかのコマンドでは使用できません。

承認はユーザーレベルで作用するため、承認の直接割り当ては特権の直接割り当てよりリスクが小さいと言えます。しかし、承認が与えられることでユーザーは高セキュリティーが求められる作業 (デバイス管理の委託など) でも実施できるようになります。

ユーザーに直接割り当てられた権利プロファイルでは、セキュリティーよりも操作性に関して問題が多く発生します。権利プロファイルでセキュリティー属性が指定されたコマンドは、プロファイルシェルでしか実行できません。ユーザーは、プロファイルシェルを開いてコマンドを入力する必要があります。権利プロファイルが割り当てられた役割は、プロファイルシェルを自動的に取得します。このため、コマンドはその役割のシェルで正常に実行されます。

権利プロファイルは、拡張性のある適切な手段として、特定の管理作業のセキュリティー特性をグループ化することができます。

特権 (概要)

プロセス権管理は、プロセスをコマンド、ユーザー、役割、またはシステムのいずれかのレベルに限定するために利用できます。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) のマニュアルページを参照してください。操作の手順は、「プログラムが必要とする特権を判断する方法」を参照してください。