Solaris のシステム管理 (セキュリティサービス)

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

このパートでは、役割によるアクセス制御 (RBAC) とプロセス権管理について説明します。RBAC コンポーネントには、役割、権利プロファイル、承認があります。プロセス権管理は、特権を介して実装されます。特権を RBAC と連携すると、スーパーユーザーによるシステムの管理よりも安全に管理することができます。

第 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 を参照してください。

表 8–1 スーパーユーザーモデルと特権を使用した RBAC モデルの比較


システムにおけるユーザー権限	スーパーユーザーモデル	RBAC モデル
すべてのスーパーユーザー権限を持つスーパーユーザーになる	はい	はい
すべてのユーザー権限を持つユーザーとしてログインする	はい	はい
権限が限定されたスーパーユーザーになる	いいえ	はい
ユーザーとしてログインし、散発的にスーパーユーザー権限を持つ	可能 (`setuid` プログラムのみ)	可能 (`setuid` プログラム、および RBAC を使用)
すべてのスーパーユーザー権限ではなく、一部の管理権限だけを持つユーザーとしてログインする	いいえ	可能 (RBAC を使用、および直接割り当てられた特権と承認を使用)
通常のユーザーよりも少ない権限を持つユーザーとしてログインする	いいえ	可能 (RBAC を使用、および特権を削除してログイン)
スーパーユーザーの処理を監視する	可能 (`su` コマンドを監査することによって監視)	可能 (プロファイルシェルコマンドを監査することによって監視) `root` ユーザーが無効になっている場合には、`root` 役割を引き受けたユーザーの名前が監査トレールに入ります

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 の確認に代わるものです。承認についての詳細は次の節で説明します。

承認と特権

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

特権付きアプリケーションと 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 データベースに置かれます。

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

RBAC の役割

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

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

各役割は、複数のユーザーに割り当てることができます。同じ役割になるすべてのユーザーは、同じ役割のホームディレクトリを持ち、同じ環境で動作し、同じファイルへのアクセス権を持ちます。ユーザーは、コマンド行から 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 を実行すると、各特権の説明が標準出力に送られます。

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

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

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


機能	特権なし	特権
デーモン	デーモンが `root` として実行されます。	デーモンが、ユーザー `daemon` として実行されます。たとえば、デーモン `lockd`、`nfsd`、`rpcbind` には適切な特権が割り当てられており、`daemon` として実行されます。
ログファイルの所有権	ログファイルは `root` によって所有されます。	ログファイルはログファイルを作成した `daemon` によって所有されます。`root` ユーザーがこのファイルを所有することはありません。
エラーメッセージ	エラーメッセージでスーパーユーザーが言及されます。たとえば、`chroot: not superuser`。	エラーメッセージで特権の使用が言及されます。たとえば、`chroot` エラーと同等のエラーメッセージは `chroot: exec failed`。
`setuid` プログラム	プログラムは、通常のユーザーに許可されていない作業を行うのに `setuid` を使用します。	多くの `setuid` プログラムは、特権を使用して実行されるように変更されました。たとえば、ユーティリティー `ufsdump`、`ufsrestore`、`rsh`、`rlogin`、`rcp`、`rdist`、`ping`、`traceroute`、`newtask` は特権を使用します。
ファイルのアクセス権	デバイスアクセス権は DAC によって制御されます。たとえば、グループ `sys` のメンバーは `/dev/ip` を開くことができます。	デバイスを開くことができるユーザーをファイルアクセス権 (DAC) が予測することはありません。デバイスは、DAC とデバイスポリシーによって保護されます。たとえば、`/dev/ip` ファイルには `666` アクセス権がありますが、デバイスを開くことができるのは適切な特権を持つプロセスだけです。raw ソケットは依然として DAC によって保護されます。
監査イベント	`su` コマンドの使用の監査によって、多くの管理機能がカバーされます。	特権の使用の監査によって、ほとんどの管理機能がカバーされます。`pm` や`as`の監査クラスには、デバイスポリシーを設定する監査イベントや特権を設定する監査イベントが含まれます。
プロセス数	プロセスは、プロセスの所有者によって保護されます。	プロセスは特権によって保護されます。プロセス特権とプロセスフラグは、`/proc/<pid>` ディレクトリ内の新しいエントリである `priv` として確認できます。
デバッグ	コアダンプ内で特権の言及はありません。	コアダンプの ELF 注記セクションで、`NT_PRPRIV` および `NT_PRPRIVINFO` の注記としてプロセス特権とフラグについての情報が示されます。 `ppriv` などのユーティリティーによって、適切にサイズ設定された特権セットの適切な数が示されます。これらのユーティリティーは、ビットセット内のビットを正しく特権名にマッピングします。

特権とシステム資源

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) のマニュアルページを参照してください。操作の手順は、「プログラムが必要とする特権を判断する方法」を参照してください。

第 9 章役割によるアクセス制御の使用 (手順)

この章では、個別の役割を使用することによってスーパーユーザーの機能を分散するための作業手順について説明します。役割が使用できるメカニズムとして、権利プロファイル、承認、および特権があります。この章では、次の作業マップについて説明します。

RBAC の概要については、「役割によるアクセス制御 (概要)」を参照してください。第 10 章役割によるアクセス制御 (参照)にも参考情報が挙げられています。RBAC を使用して、または RBAC を使用しないで特権を使用する方法については、第 11 章特権 (手順)を参照してください。

RBAC の使用 (作業マップ)

RBAC を使用するにあたって、RBAC の計画と構成、および役割を引き受ける方法を知ることが必要です。役割について熟知すると、RBAC をさらにカスタマイズして新しい操作を処理することができます。次の作業マップにこれらの主要な作業を示します。

作業	説明	参照先
RBAC の計画と構成を行います	使用するサイトで RBAC を構成します。	「RBAC の構成 (作業マップ)」
役割を使用します	コマンド行および Solaris 管理コンソールの GUI で役割を引き受けます。	「役割の使用 (作業マップ)」
RBAC をカスタマイズします	使用するサイト用に RBAC をカスタマイズします。	「RBAC の管理(作業マップ)」

RBAC の構成 (作業マップ)

RBAC を効果的に使用するには、計画が必要です。次の作業マップを使用して、サイトでの RBAC の計画と初期実装を行います。

作業	説明	参照先
1. RBAC を計画します	サイトのセキュリティー要件の調査、およびサイトでの RBAC の使用方法の決定が含まれます。	「RBAC の実装を計画する方法」
2. Solaris 管理コンソールの使用方法を理解します	Solaris 管理コンソールについて熟知することが含まれます。	『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」
3. 最初のユーザーと役割を構成します	Solaris 管理コンソールで RBAC 構成ツールを使用してユーザーと役割を作成し、作成した役割を作成したユーザーに割り当てます。	『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」
4. (省略可能) 役割を引き受けることができるほかのユーザーを作成します	管理役割を引き受けることができるユーザーが確実に存在するようにします。	『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」
5. (推奨) ほかの役割を作成し、ユーザーに割り当てます	RBAC ツールを使用して特定の管理領域に対する役割を作成し、作成した役割をユーザーに割り当てます。	「GUI を使用して役割の作成および割り当てを行う方法」
	RBAC ツールを使用して特定の管理領域に対する役割を作成し、作成した役割をユーザーに割り当てます。	例 9–5
	コマンド行を使用して役割を作成し、作成した役割をユーザーに割り当てます	「コマンド行から役割を作成する方法」
	コマンド行を使用して役割を作成し、作成した役割をユーザーに割り当てます	「役割をローカルユーザーに割り当てる方法」
6. (推奨) 役割の動作を監査します	役割の動作を記録する監査イベントを含む監査クラスを事前に選択します。	「役割を監査する方法」
7. (省略可能) `root` ユーザーを役割にします	セキュリティーホールである、匿名の `root` ログインを防ぎます。	「`root` ユーザーを役割にする方法」

RBAC の構成

RBAC は、次のユーティリティーで構成することができます。

Solaris 管理コンソールの GUI – RBAC に関連する作業は、GUI を使用して実行することをお勧めします。RBAC 要素を管理するコンソールツールは、「ユーザーツールコレクション (User Tool Collection)」にあります。
Solaris 管理コンソールのコマンド – smrole など、Solaris 管理コンソールのコマンド行インタフェースで、ネームサービスを操作することができます。Solaris 管理コンソールコマンドを使用してサーバーに接続するときは、認証が要求されます。このため、Solaris 管理コンソールコマンドは、スクリプトでは使用できません。
ローカルコマンド – useradd など、コマンド行インタフェースの user* と role* の組み合わせによって、ローカルファイルのみを操作することができます。ローカルファイルを操作するコマンドは、スーパーユーザーまたは該当する特権を持つ役割によって実行される必要があります。

RBAC の実装を計画する方法

RBAC は、組織の情報リソースを管理するときに、重要な役割を果たします。RBAC を計画する際には、RBAC の機能と組織のセキュリティー要件を十分に理解しておく必要があります。

RBAC の基本概念を理解します。

「役割によるアクセス制御 (概要)」を参照してください。RBAC を使用したシステム管理は、従来の UNIX の管理方法を使用した場合と大きく異なります。実装を開始する前に、RBAC の概念を理解する必要があります。詳細については、第 10 章役割によるアクセス制御 (参照)を参照してください。

セキュリティーポリシーを調査します。

組織のセキュリティーポリシーには、システムに対する潜在的な脅威を詳細に記述し、各脅威の危険性の分析結果に応じて適切な対応策を定義する必要があります。RBAC を使用したセキュリティー関連の作業とは切り離して行うことをお勧めします。推奨される役割とその構成をそのままインストールすることもできますが、セキュリティーポリシーによっては RBAC の構成のカスタマイズが必要になることがあります。

組織に必要な RBAC を決定します。

組織のセキュリティー要件に応じて、さまざまなレベルの RBAC を使用できます。
- 「RBAC を使用しない」 – すべての作業を root ユーザーとして実行できます。この構成では、通常のユーザーとしてログインします。その後、Solaris 管理コンソールツールを選択するときに、ユーザーとして root を入力します。
- 「役割を 1 つだけ使用する」 – この方式では、役割を 1 つ追加します。追加された 1 つの役割には、Primary Administrator 権利プロファイルが割り当てられます。この方式は、役割がスーパーユーザー機能を持つという点で、スーパーユーザーモデルと似ています。ただし、この方式では、役割を引き受けたユーザーを追跡することができます。
- 「推奨される役割」 – この方式では、Primary Administrator、System Administrator、および Operator の権利プロファイルに基づいた 3 つの役割が作成されます。さまざまな責任レベルの管理者がいる組織の場合は、この方式が適しています。
- 「カスタム役割」 – 独自の役割を作成して、組織のセキュリティー要件を満たすことができます。新しい役割は、既存またはカスタマイズした権利プロファイルに基づいて作成できます。責務の分離を適用するように権利プロファイルをカスタマイズする方法については、『Oracle Solaris Trusted Extensions 構成ガイド』の「Trusted Extensions での役割とユーザーの作成」を参照してください。
- 「root ユーザーを役割にする」 – この方式では、どのユーザーも root としてログインできないようにします。代わりに、通常のユーザーとしてログインしてから、root 役割を引き受ける必要があります。詳細については、「root ユーザーを役割にする方法」を参照してください。

組織に適した推奨される役割を決定します。

推奨される役割とそのデフォルトの権利プロファイルの機能を確認します。デフォルトの権利プロファイルにより、管理者は単一のプロファイルを使用して推奨される役割を構成することができます。

推奨される役割を構成するときは、次の 3 つのデフォルトの権利プロファイルを使用できます。
- 「Primary Administrator」権利プロファイル – すべての管理タスクを実行できる役割用。ほかのユーザーに権限を与えたり、管理役割に関連付けられた権限を編集したりすることができます。この役割のユーザーは、この役割をほかのユーザーに割り当てたり、ほかのユーザーに権利を与えたりすることができます。
- 「System Administrator」権利プロファイル – セキュリティーに関係しないほとんどの管理タスクを実行できる役割用。たとえば、System Administrator は、新しいユーザーアカウントは追加できますが、パスワードを設定したりほかのユーザーに権利を与えたりすることはできません。
- 「Operator」権利プロファイル – メディアバックアップやプリンタ管理など、単純な管理タスクを実行できる役割用。
権利プロファイルの詳細については、次のいずれかを参照してください。
- /etc/security ディレクトリで、prof_attr データベースおよび exec_attr データベースの内容を参照してください。
- Solaris 管理コンソールで、権限ツールを使用して権利プロファイルの内容を表示してください。
- このマニュアルで、一般的な権利プロファイルを要約した「権利プロファイルの内容」を参照してください。

追加する任意の役割または権利プロファイルが組織に適切であるかどうかを判断します。

使用するサイトで、アクセスを制限する必要があるアプリケーションを調べます。セキュリティーに影響するアプリケーション、サービス拒否が発生する可能性のあるアプリケーション、特別な管理者教育を必要とするアプリケーションには、RBAC を適用することをお勧めします。役割や権利プロファイルをカスタマイズして、組織のセキュリティー要件に対応することができます。
1. 新しい操作に必要なコマンドを決定します。
2. この操作に適切な権利プロファイルを決定します。
  
  既存の権利プロファイルがこの操作に割り当てられていないか、または別の権利プロファイルを作成する必要がないかどうかを確認します。
3. この権利プロファイルに適した役割を決定します。
  
  この操作の権利プロファイルを既存の役割に割り当てるかどうか、または新しい役割を作成するかどうかを決定します。既存の役割を使用する場合は、この役割を割り当てるユーザーにほかの権利プロファイルが適していないかどうかを確認します。

役割に割り当てるユーザーを決定します。

必要な権限だけを割り当てるために、ユーザーの信頼レベルに応じて役割を割り当てます。実行する必要のない操作にユーザーがアクセスできないようにすると、問題が発生する可能性が減少します。

GUI を使用して役割の作成および割り当てを行う方法

新しい役割を作成するには、スーパーユーザーになるか、 Primary Administrator 役割を使用します。この手順では、新しい役割の作成者が Primary Administrator 役割を引き受けています。

始める前に

使用するサイトで役割を引き受けることができるユーザーは、すでに作成されています。ユーザーをまだ作成していない場合は、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」に記載されている手順に従ってユーザーを作成してください。
Primary Administrator 役割は、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」の手順に従って割り当て済みです。

Solaris 管理コンソールを起動します。
# /usr/sbin/smc &
ログインの手順については、「Solaris 管理コンソールで役割を引き受ける方法」を参照してください。

「管理役割 (Administrative Roles)」アイコンをクリックします。

「アクション (Action)」メニューから「管理役割を追加 (Add Administrative)」を選択します。

一連のダイアログボックスのフィールドに入力して新しい役割を作成します。

作成可能な役割については、例 9–1 から例 9–4 を参照してください。

ヒント –
Solaris 管理コンソールの各ツールは、ページの下部またはウィンドウパネル左側に情報を表示します。このインタフェースでの作業について情報が必要な場合は、いつでも「ヘルプ (Help)」を選択できます。

役割をユーザーに割り当てます。

ヒント –
役割のプロパティーを入力すると、最後のダイアログボックスで、その役割のユーザーを入力するよう促されます。

端末ウィンドウで、ネームサービスキャッシュデーモンを再起動します。
# svcadm restart system/name-service-cache
詳細は、svcadm(1M) および nscd(1M) のマニュアルページを参照してください。

例 9–1 System Administrator 権利プロファイルの役割の作成

この例では、セキュリティーに関係しないシステム管理タスクを新しい役割が行うことができます。役割は、次のパラメータで前述の手順を実行すると作成されます。

役割名: sysadmin
役割の完全名: System Administrator
役割の説明: セキュリティーに関係しない管理タスクを行う
権利プロファイル: System Administrator

この権利プロファイルは、役割に含まれるプロファイルのリストの最上部にあります。

例 9–2 Operator 権利プロファイルの役割の作成

Operator 権利プロファイルは、プリンタを管理したりオフラインメディアにシステムをバックアップしたりすることができます。役割を交代で 1 人のユーザーに割り当てたいという場合があります。そのような場合には、「手順 1: 役割名を入力します (Step 1: Enter a Role Name) 」ダイアログボックスで、役割メーリングリストオプションを選択します。役割は、次のパラメータで前述の手順を実行すると作成されます。

役割名: operadm
役割の完全名: Operator
役割の説明: 操作をバックアップする
権利プロファイル: Operator

この権利プロファイルは、役割に含めるプロファイルのリストの先頭に配置する必要があります。

例 9–3 セキュリティー関連の権利プロファイルの役割の作成

デフォルトでは、セキュリティー関連のコマンドと権利を含む権利プロファイルだけが、Primary Administrator プロファイルとなります。Primary Administrator ほどの権限はないが、セキュリティー関連のタスクを処理できる役割を作成する場合には、役割を作成する必要があります。

次の例で、役割はデバイスを保護します。役割は、次のパラメータで前述の手順を実行すると作成されます。

役割名: devicesec
役割の完全名: Device Security
役割の説明: デバイスを構成する
権利プロファイル: Device Security

次の例で、役割はネットワーク上のシステムとホストのセキュリティーを保護します。役割は、次のパラメータで前述の手順を実行すると作成されます。

役割名: netsec
役割の完全名: Network Security
役割の説明: IPsec、IKE、および SSH を処理する
権利プロファイル: Network Security

例 9–4 適用範囲が制限された権利プロファイルの役割の作成

多くの権利プロファイルでは、適用範囲に制限があります。この例では、役割の唯一のタスクは DHCP を管理することです。役割は、次のパラメータで前述の手順を実行すると作成されます。

役割名: dhcpmgt
役割の完全名: DHCP Management
役割の説明: DHCP (Dynamic Host Config Protocol) を管理する
権利プロファイル: DHCP Management

例 9–5 ユーザーの役割の割り当ての変更

この例では、既存のユーザーに役割が追加されます。ユーザーの役割の割り当てを変更するには、Solaris 管理コンソールの「ユーザー」ツールの「ユーザーアカウント (User Accounts) 」アイコンをクリックし、ユーザーをダブルクリックし、オンラインヘルプに従ってユーザーの機能に役割を追加します。

注意事項

役割が持つべき機能を持っていない場合、次の内容を確認します。

役割の権利プロファイルが、GUI で最も権限のあるものから最も権限のないものへとリストされていること。

たとえば、All 権利プロファイルがリストの最上部にある場合、セキュリティー属性で実行されるコマンドはありません。セキュリティー属性を指定したコマンドを含むプロファイルは、リストで All 権利プロファイルの前に来なければなりません。
役割の権利プロファイルのコマンドに適切なセキュリティー属性を指定していること。

たとえば、ポリシーが suser のとき、 euid=0 ではなく、uid=0 となるコマンドもあります。
権利プロファイルが適切なネームサービスの適用範囲で定義されていること。権利プロファイルが定義されているネームサービスの適用範囲で役割が動作していること。
ネームサービスのキャッシュ、svc:/system/name-service-cache を再起動していること。

nscd デーモンには長い有効期間を設定することができます。デーモンを再起動して、現在のデータでネームサービスを更新します。

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

Solaris 管理コンソールの GUI は、RBAC を管理するための望ましい方法です。GUI の使用については、「GUI を使用して役割の作成および割り当てを行う方法」を参照してください。この手順で説明するように、コマンド行インタフェースを使用することもできます。

注 –

コマンド行インタフェースとグラフィカルユーザーインタフェースを同時に使って、RBAC を管理しないでください。構成に対して矛盾した変更が加えられ、予測していない動作が生じることがあります。両方のツールとも RBAC を管理することができますが、両方を同時に使用することはできません。

始める前に

役割を作成するには、Primary Administrator 権利プロファイルを含む役割を引き受けるか、root ユーザーに切り替える必要があります。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

次のコマンドのいずれかを選択して、コマンド行で役割を作成します。
- ローカルのネームサービスの適用範囲の役割には、roleadd コマンドを使用します。
  
  注 –
  roleadd コマンドは、Solaris 管理コンソールの GUI やコマンド行インタフェースに比べて制限されています。roleadd コマンドの実行後、usermod コマンドを実行して役割をユーザーに割り当てる必要があります。その後、ユーザーは、「役割をローカルユーザーに割り当てる方法」で説明するように、役割のパスワードを設定する必要があります。
  # roleadd -c comment \ -g group -m homedir -u UID -s shell \ -P profile rolename
  -c comment
  
  rolename について説明するコメントです。
  
  -g group
  
  rolename に対するグループの割り当てです。
  
  -m homedir
  
  rolename のホームディレクトリへのパスです。
  
  -u UID
  
  rolename の UID です。
  
  -s shell
  
  rolename のログインシェルです。このシェルはプロファイルシェルである必要があります。
  
  -P profile
  
  rolename の 1 つまたは複数の権利プロファイルです。
  
  rolename
  
  新しいローカル役割の名前です。
- smrole add コマンドを使用します。
  
  このコマンドは、NIS、NIS+、LDAP などの分散ネームサービスで役割を作成します。Solaris 管理コンソールサーバーのクライアントとして動作します。
  $ /usr/sadm/bin/smrole -D domain-name \ -r admin-role -l <Type admin-role password> \ add -- -n rolename -a rolename -d directory\ -F full-description -p profile
  -D domain-name
  
  管理対象のドメインの名前です。
  
  -r admin-role
  
  役割を変更できる管理役割の名前です。管理役割は solaris.role.assign 承認を得る必要があります。引き受けた役割を変更する場合、役割は solaris.role.delegate 承認を得る必要があります。
  
  -l
  
  admin-role のパスワードに対するプロンプトです。
  
  --
  
  認証オプションとサブコマンドオプションの間に必要な区切り文字です。
  
  -n rolename
  
  新しい役割の名前です。
  
  -c comment
  
  役割の機能を説明するコメントです。
  
  -a username
  
  rolename を引き受けることができるユーザーの名前です。
  
  -d directory
  
  rolename のホームディレクトリです。
  
  -F full-description
  
  rolename の詳細です。この説明は Solaris 管理コンソールの GUI に表示されます。
  
  -p profile
  
  rolename の機能に含まれる権利プロファイルです。このオプションには、役割に対する管理機能を備えたコマンドが用意されています。複数の -p profile オプションを指定することができます。

変更を有効にするには、「役割をローカルユーザーに割り当てる方法」を参照してください。

例 9–6 `smrole` コマンドを使用してカスタムの Operator 役割を作成する

smrole コマンドは、ネームサービスで新しい役割とその属性を指定します。次の例では、Primary Administrator が Operator 役割の新しいバージョンを作成します。役割には、標準的な Operator 権利プロファイルのほか、Media Restore 権利プロファイルが含まれます。コマンドによって、新しい役割のパスワードを入力するよう促されます。

% su - primaryadm
Password: <Type primaryadm password> 
$ /usr/sadm/bin/smrole add -H myHost -- -c "Backup and Restore Operator" \
-n operadm2 -a janedoe -d /export/home/operadm \
-F "Backup/Restore Operator" -p "Operator" -p "Media Restore"
Authenticating as user: primaryadm

Type /? for help, pressing <enter> accepts the default denoted by [ ]
Please enter a string value for: password :: <Type primaryadm password>

Loading Tool: com.sun.admin.usermgr.cli.role.UserMgrRoleCli from myHost
Login to myHost as user primaryadm was successful.
Download of com.sun.admin.usermgr.cli.role.UserMgrRoleCli from myHost was successful.

Type /? for help, pressing <enter> accepts the default denoted by [ ]
Please enter a string value for: password ::<Type operadm2 password>

$ svcadm restart system/name-service-cache

list サブコマンドを持つ smrole コマンドは、新しい役割を表示するのに使用されます。

$ /usr/sadm/bin/smrole list --
Authenticating as user: primaryadm

Type /? for help, pressing <enter> accepts the default denoted by [ ]
Please enter a string value for: password :: <Type  primaryadm password>

Loading Tool: com.sun.admin.usermgr.cli.role.UserMgrRoleCli from myHost
Login to myHost as user primaryadm was successful.
Download of com.sun.admin.usermgr.cli.role.UserMgrRoleCli from myHost was successful.
root                    0             Superuser
primaryadm            100             Most powerful role
sysadmin              101             Performs non-security admin tasks
operadm               102             Backup Operator
operadm2              103             Backup/Restore Operator

役割をローカルユーザーに割り当てる方法

この手順では、ローカル役割をローカルユーザーに割り当て、ネームキャッシュデーモンを再起動したあと、ユーザーが役割を引き受ける方法を示します。

分散ネームサービスで役割をユーザーに割り当てる方法については、「コマンド行から役割を作成する方法」および「役割のプロパティーを変更する方法」を参照してください。

始める前に

ローカル役割は追加済みです (「コマンド行から役割を作成する方法」を参照)。Primary Administrator 権利プロファイルを含む役割を引き受けるか、root ユーザーに切り替える必要があります。

役割をローカルユーザーに割り当てます。

roleadd コマンドによってローカル役割を追加した場合、この手順が必要です。smrole コマンドと Solaris 管理コンソールを使用して役割を作成したときは、この手順は省略可能です。
# usermod -u UID -R rolename login-name
-u UID

ユーザーの UID です。

-R rolename

ユーザーに割り当てられる役割です。

login-name

ユーザーのログイン名です。

変更を有効にするには、ネームサービスキャッシュデーモンを再起動します。
# svcadm restart system/name-service-cache
Solaris 管理コンソールのインタフェースで役割を追加した場合は、「役割の使用 (作業マップ)」に進んでください。そのほかの場合は、次の手順に進みます。

(省略可能) 役割アカウントのロックを解除するには、ユーザーがパスワードを作成する必要があります。

roleadd コマンドによってローカル役割を追加した場合、この手順が必要です。
% su - rolename Password: <Type rolename password> Confirm Password: <Retype rolename password> $

例 9–7 コマンド行からのローカル役割の作成と割り当て

この例では、Solaris の暗号化フレームワークを管理するための役割が作成されます。Crypto Management 権利プロファイルには、ローカルシステムでハードウェアおよびソフトウェアの暗号化サービスを管理する cryptoadm コマンドが含まれます。

# roleadd -c "Cryptographic Services manager" \
-g 14 -m /export/home/cryptoadm -u 104 -s pfksh \
-P "Crypto Management" cryptomgt
# usermod -u 1111 -R cryptomgt
# svcadm restart system/name-service-cache
% su - cryptomgt
Password: <Type cryptomgt password>
Confirm Password: <Retype cryptomgt password>
$ /usr/ucb/whoami
cryptomgt
$

Solaris の暗号化フレームワークの詳細については、第 13 章Solaris の暗号化フレームワーク (概要)を参照してください。フレームワークの管理方法については、「暗号化フレームワークの管理 (作業マップ)」を参照してください。

役割を監査する方法

役割が行う動作を監査することができます。監査記録に含まれるのは、役割を引き受けたユーザーのログイン名、役割名、および役割が行った動作です。6180:AUE_prof_cmd:profile command:ua,as 監査イベントによって、情報が収集されます。as クラスまたは ua クラスを事前に選択することにより、役割の動作を監査することができます。

監査を計画し、構成ファイルを編集します。

詳細については、「Solaris 監査 (作業マップ)」を参照してください。

audit_control ファイルの flags 行に ua クラスまたは as クラスを含めます。
## audit_control file flags:lo,as naflags:lo plugin:name=audit_binfile.so; p_dir=/var/audit
ua クラスおよび as クラスには、ほかの監査イベントが含まれます。クラスに含まれる監査イベントについては、audit_event ファイルを参照してください。bsmrecord コマンドを使用することもできます (例 30–27 参照)。

監査サービスの構成が終了したら、監査を有効にします。

詳細については、「監査サービスの構成と有効化 (手順)」を参照してください。

`root` ユーザーを役割にする方法

この手順では、ログインユーザーから役割へ root を変更する方法を示します。この手順を完了すると、シングルユーザーモード以外では、root としてシステムに直接ログインできなくなります。root 役割が割り当てられていることと、su コマンドによって root になることが必要です。

root ユーザーを役割に変更することにより、匿名の root ログインを防ぎます。ユーザーは、ログイン後、root 役割を引き受ける必要があるため、ユーザーのログイン ID が監査サービスに提供され、sulog ファイルに含められます。

この手順では、ローカルユーザーを作成し、このユーザーに root 役割を割り当てます。ユーザーがこの役割を引き受けることを防ぐには、例 9–8 を参照してください。

始める前に

root として直接ログインすると、この手順は実行できません。自分のユーザー名でログイン後、su コマンドによって root になる必要があります。

通常のユーザーとして、対象のシステムにログインします。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割の作成と作成した役割のユーザーへの割り当てについては、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

root 役割を引き受けることができるローカルユーザーを作成します。

安全のために、少なくとも 1 人のローカルユーザーを root 役割に割り当ててください。
$ useradd -c comment -u uid -d homedir username
-c comment

ユーザーについて説明するコメントです。

-d homedir

ユーザーのホームディレクトリです。このディレクトリはローカルシステム上にあります。

-u uid

ユーザーの識別番号です。

username

新しいローカルユーザーの名前です。
# useradd -c "JDoe's local account" -u 123 -d /export/home1 jdoe-local

ユーザーにパスワードを与えます。

# passwd -r files jdoe-local
New Password:    <Type password>
Re-enter new Password: <Retype password>
passwd: password successfully changed for jdoe-local
#

root としてログインしていないことを確認します。

# who
jdoe    console      May 24 13:51    (:0)
jdoe    pts/5        May 24 13:51    (:0.0)
jdoe    pts/4        May 24 13:51    (:0.0)
jdoe    pts/10       May 24 13:51    (:0.0)

root ユーザーを役割に変更します。
# usermod -K type=role root

root が役割であることを確認します。

user_attr ファイルの root エントリは、次のようになります。
# grep root /etc/user_attr root::::type=role;auths=solaris.*,solaris.grant;profiles=...

root 役割を自分のローカルアカウントに割り当てます。
# usermod -R root jdoe-local
注意 –
root 役割をユーザーに割り当てないと、シングルユーザーモード以外では誰もスーパーユーザーになれなくなります。シングルユーザーモードに入るには、root パスワードを入力する必要があります。

失敗した場合に返されるようにネームサービスを構成します。
1. 新しい端末ウィンドウを開き、root 役割を引き受けます。
  % whoami jdoe % su - jdoe-local Enter password: <Type jdoe-local password> % roles root % su - root Enter password: <Type root password> #
2. nsswitch.conf ファイルを編集します。
  
  たとえば、nsswitch.conf ファイルの次のエントリによって、ネームサービスを返すことができます。
  passwd: files nis [TRYAGAIN=0 UNAVAIL=return NOTFOUND=return] group: files nis [TRYAGAIN=0 UNAVAIL=return NOTFOUND=return]

(省略可能) root 役割をネームサービスで選択されたユーザーアカウントに割り当てます。

この手順については、「ユーザーの RBAC プロパティーを変更する方法」を参照してください。

例 9–8 `root` 役割がシステムの構成に使用されることを防ぐ

この例では、システムの構成にはいくつかの個別の役割を使用するように、サイトのセキュリティーポリシーで要求します。これらの個別の役割はすでに作成され、テストされています。root アカウントがシステムの構成に使用されることを防ぐために、セキュリティー管理者は root を役割に変更し、ただしその役割を割り当てないようにします。シングルユーザーモードでシステムに入ることができるように、root 役割のパスワードは維持します。

管理者はまず、root が役割として割り当て済みでないことを確認します。

% whoami
jdoe-local
% su - root
Password: a!2@3#4$5%6^7
# grep roles /etc/user_attr
jdoe-local::::type=normal;roles=secadmin
kdoe-local::::type=normal;roles=sysadmin

引き続き root アカウントで、root を役割に変更します。

# usermod -K type=role root

次に、user_attr ファイル内の root エントリの変更内容を確認します。

# grep root /etc/user_attr
root::::type=role;auths=solaris.*,solaris.grant;profiles=...

例 9–9 `root` 役割を変更して `root` ユーザーに戻す

この例では、管理者はシステムの使用を停止し、スーパーユーザーとしてデスクトップにログインします。システムはすでにネットワークから削除されています。

管理者はまず、root 役割を引き受け、root 役割の割り当てをすべて削除します。

% whoami
jdoe-local
% su - root
Password: a!2@3#4$5%6^7
# grep roles /etc/user_attr
jdoe-local::::type=normal;roles=root
kdoe-local::::type=normal;roles=root
# usermod -R "" jdoe-local
# usermod -R "" kdoe-local
# grep roles /etc/user_attr
#

引き続き root 役割で、root をユーザーに変更します。

# rolemod -K type=normal root

次に、user_attr ファイル内の root エントリの変更内容を確認します。

# grep root /etc/user_attr
root::::type=normal;auths=solaris.*,solaris.grant;profiles=...

注意事項

デスクトップ環境では、root が役割の場合、root として直接ログインすることはできません。このシステム上で root が役割になっていることを示す診断メッセージが表示されます。root 役割を引き受けることのできるローカルアカウントがない場合は、ローカルアカウントを作成します。root としてシングルユーザーモードでシステムにログインし、ローカルユーザーアカウントを作成し、この新しいアカウントに root 役割を割り当てます。次に、この新しいユーザーでログインし、root 役割を引き受けます。

root ユーザーを役割に変更し、次の割り当てのいずれかを実行できない場合、スーパーユーザーになることはできません。

有効なユーザーに root 役割を割り当てます。
root の権利プロファイルと同等の権利プロファイルを、有効なユーザーに割り当てます。Primary Administrator プロファイルは、root の機能に相当する権利プロファイルです。
root の機能を持った役割を作成し、この役割を有効なユーザーに割り当てます。Primary Administrator プロファイルが割り当てられた役割は、root 役割と同等です。

役割の使用 (作業マップ)

次の作業マップは、役割が割り当てられたあとにその役割を使用する手順を示しています。

作業	説明	参照先
Solaris 管理コンソールを使用します	自分を役割として認証して Solaris 管理コンソールで管理タスクを実行します。	「Solaris 管理コンソールで役割を引き受ける方法」
端末ウィンドウで役割を引き受けます	プロファイルシェルでコマンド行の管理タスクを実行します。	「端末ウィンドウで役割を引き受ける方法」

役割の使用

役割は、Solaris のデフォルトの権利プロファイルで設定し、ユーザーに割り当てると、使用できるようになります。役割は、コマンド行で引き受けることができます。Solaris 管理コンソールで、役割は、ローカルおよびネットワーク越しにシステムを管理するために使用することもできます。

端末ウィンドウで役割を引き受ける方法

始める前に

役割がすでに割り当てられている必要があります。そしてその情報でネームサービスを更新する必要があります。

端末ウィンドウで、引き受けることのできる役割を判断します。
% roles Comma-separated list of role names is displayed

su コマンドを使用して役割を引き受けます。
% su - rolename Password: <Type rolename password> $
su - rolename コマンドを実行すると、シェルがその役割のプロファイルシェルに変わります。プロファイルシェルは、セキュリティー属性 (承認、特権、および set ID ビット) を認識します。

役割になっていることを確認します。
$ /usr/ucb/whoami rolename
端末ウィンドウで役割のタスクを実行できるようになりました。

(省略可能) 自分の役割の機能を表示します。

この手順については、「役割が実行可能な特権付きコマンドを判断する方法」を参照してください。

例 9–10 Primary Administrator 役割を引き受ける

次の例で、ユーザーは Primary Administrator の役割を引き受けます。デフォルトの構成では、この役割はスーパーユーザーと同等です。その後、役割は、その役割のプロファイルシェルに入力されるどのコマンドでも利用可能な特権を確認します。

% roles
sysadmin,oper,primaryadm
% su - primaryadm
Password: <Type primaryadm password>
$ /usr/ucb/whoami Prompt has changed to role prompt
primaryadm
$ ppriv $$
1200:   pfksh
flags = <none>
        E (Effective): all
        I (Inheritable): basic
        P (Permitted): all
        L (Limit): all

特権の詳細については、「特権 (概要)」を参照してください。

例 9–11 `root` 役割を引き受ける

次の例で、ユーザーは root 役割を引き受けます。root 役割は「root ユーザーを役割にする方法」で作成されたものです。

% roles
root
% su - root
Password: <Type root password>
# /usr/ucb/whoami Prompt has changed to role prompt
root
$ ppriv $$
1200:   pfksh
flags = <none>
        E: all
        I: basic
        P: all
        L: all

特権の詳細については、「特権 (概要)」を参照してください。

例 9–12 System Administrator 役割を引き受ける

次の例で、ユーザーは System Administrator の役割を引き受けます。Primary Administrator 役割とは対照的に、System Administrator は、効果的に組み合わされた特権の基本セットを備えています。

% roles
sysadmin,oper,primaryadm
% su - sysadmin
Password: <Type sysadmin password>
$ /usr/ucb/whoami Prompt has changed to role prompt
sysadmin
$ ppriv $$
1200:   pfksh
flags = <none>
        E: basic
        I: basic
        P: basic
        L: all

特権の詳細については、「特権 (概要)」を参照してください。役割の機能の簡単な説明については、「System Administrator 権利プロファイル」を参照してください。

Solaris 管理コンソールで役割を引き受ける方法

Solaris 管理コンソールの GUI で情報を変更するには、管理機能が必要です。役割によって、管理機能が与えられます。情報を表示する場合は、solaris.admin.usermgr.read 承認が必要です。Basic Solaris User 権利プロファイルには、この承認が含まれます。

始める前に

ユーザーのプロパティーを変更できる管理役割がすでに割り当てられている必要があります。たとえば、Primary Administrator 役割は、ユーザーまたは役割のプロパティーを変更できます。

Solaris 管理コンソールを起動します。
% /usr/sbin/smc &
詳細については、『Solaris のシステム管理 (基本編)』の「Solaris 管理ツールを RBAC と組み合わせて使用する (作業マップ)」を参照してください。

操作に必要なツールボックスを選択します。

適切なネームサービスの適用範囲のツールまたはコレクションを含むツールボックスに移動し、アイコンをクリックします。適用範囲には、ファイル (ローカル)、NIS、NIS+、および LDAP があります。適切なツールボックスがナビゲーション区画に表示されていない場合は、「コンソール (Console)」メニューから「ツールボックスを開く (Open Toolbox)」を選択して、関連するツールボックスを読み込みます。

使用するツールを選択します。

ツールまたはコレクションに移動して、アイコンをクリックします。RBAC 要素を管理するツールは、「ユーザー」ツールにあります (次の図を参照)。

「ログイン: ユーザー名 (Login: User Name)」ダイアログボックスで、ユーザー名とパスワードを入力します。

「ログイン: 役割名 (Login: Role)」ダイアログボックスでユーザーを認証させます。

ダイアログボックスの「役割 (Role)」オプションメニューに、割り当てられる役割が表示されます。役割を選択して、役割のパスワードを入力します。

RBAC の管理(作業マップ)

次の作業マップは、役割によるアクセス制御 (RBAC) の初期実装後、RBAC をカスタマイズする手順を示しています。

作業	説明	参照先
役割のパスワードを変更します	承認されたユーザーまたは役割で、別の役割のパスワードを変更します。	「役割のパスワードを変更する方法」
役割のプロパティーを変更します	役割の機能 (特権、特権付きコマンド、プロファイル、承認) を変更します。	「役割のプロパティーを変更する方法」
権利プロファイルを作成または変更します	権利プロファイルを作成します。あるいは、権利プロファイルの承認、特権付きコマンド、または補助権利プロファイルを変更します。	「権利プロファイルを作成または変更する方法」
ユーザーの管理機能を変更します	役割、権利プロファイル、承認、または特権を通常のユーザーに追加します。	「ユーザーの RBAC プロパティーを変更する方法」
レガシーアプリケーションをセキュリティー保護します	レガシーアプリケーションの set ID アクセス権を有効にします。スクリプトでは set ID を有効にしたコマンドを使用できます。必要に応じて、レガシーアプリケーション内で承認を確認できます。	「RBAC プロパティーをレガシーアプリケーションに追加する方法」

これらの手順によって、RBAC で使用される要素を管理します。ユーザーの管理手順については、『Solaris のシステム管理 (基本編)』の第 5 章「ユーザーアカウントとグループの管理 (手順)」を参照してください。

RBAC の管理

Solaris 管理コンソールの GUI は、RBAC を管理するための望ましい方法です。

注 –

役割のパスワードを変更する方法

始める前に

User Security プロファイルを含んだ役割を引き受けているか、スーパーユーザーに切り替えている必要があります。ある役割のパスワードを変更するには、別の役割を使用する必要があります。使用している役割自体のパスワードを変更することはできません。

次のいずれかの方法で、役割のパスワードを変更します。
- スーパーユーザーとして、または User Security 権利プロファイルを含んだ役割で、passwd コマンドを実行します。
  $ passwd -r naming-service target-rolename
  -r naming-service
  
  パスワードの変更を files、nis、nisplus、または ldap のいずれかのリポジトリに適用します。リポジトリを指定しない場合は、files のパスワードが変更されます。
  
  target-rolename
  
  変更する既存の役割の名前です。
  
  コマンドオプションの詳細については、passwd(1) のマニュアルページを参照してください。
- Solaris 管理コンソールでパスワードを変更します。
  
  コンソールの起動については、「Solaris 管理コンソールで役割を引き受ける方法」を参照してください。
  1. スーパーユーザーとして、または User Security 権利プロファイルを含んだ役割で、コンソールにログインします。
    
    対象の役割ではログインできません。
  2. 適切な適用範囲を選択します。
    
    適用範囲として Files を選択すると、ローカルシステム上の役割のパスワードが変更されます。適用範囲として LDAP を選択すると、LDAP ネームサービス内の役割のパスワードが変更されます。
  3. 「管理役割 (Administrative Roles)」に移動し、左側の区画の指示に従って操作します。
    
    詳細は、オンラインヘルプを参照してください。
- スーパーユーザーとして、または User Security 権利プロファイルを含んだ役割で、smrole コマンドを modify サブコマンドとともに実行します。
  
  このコマンドは、Solaris 管理コンソールサーバーのクライアントとして動作します。
  $ /usr/sadm/bin/smrole -D domain-name -r admin-role -l <Type admin-role password> \ modify -- -n target-rolename -P password
  -D domain-name
  
  管理対象のドメインの名前です。
  
  -r admin-role
  
  対象の役割を変更できる管理役割の名前です。管理役割は solaris.admin.usermgr.pswd 承認を得る必要があります。管理役割と対象の役割は同じではいけません。
  
  -l
  
  admin-role のパスワードに対するプロンプトです。
  
  --
  
  認証オプションとサブコマンドオプションの間に必要な区切り文字です。
  
  -n target-rolename
  
  対象の役割の名前です。
  
  -P password
  
  target-rolename の新しいパスワードです。
  
  コマンドオプションの一覧については、smrole(1M) のマニュアルページを参照してください。

例 9–13 `passwd` コマンドによるローカル役割のパスワードの変更

この例では、スーパーユーザーがローカルの operadm 役割のパスワードを変更します。

# passwd -r files  operadm
New password: Type new password
Re-enter new password: Retype new password

例 9–14 LDAP リポジトリ内の役割のパスワードを変更する

この例では、Primary Administrator 役割が LDAP ディレクトリサービス内の operadm 役割のパスワードを変更します。

$ passwd -r ldap operadm
New password: Type new password
Re-enter new password: Retype new password

例 9–15 `smrole modify` コマンドによる役割のパスワードの変更

この例では、管理者が Solaris 管理コンソールサーバーに接続し、NIS ドメイン内の operadm のパスワードを変更します。管理者がパスワードを指定せずに Return キーを押すと、「New Password:」プロンプトが表示されます。

$ /usr/sadm/bin/smrole -D nis:/examplehost/example.domain \
-r primaryadm -l <Type primaryadm password> \
modify -- -n operadm -P Press the Return key
New Password: a!2@3#4$5%6*7
$

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

始める前に

Primary Administrator 権利プロファイルを含む役割を引き受けるか、root ユーザーに切り替えて役割のプロパティーを変更する必要があります。役割のプロパティーには、パスワード、権利プロファイル、および承認が含まれます。

注 –

役割のパスワードプロパティーを変更する方法については、「役割のパスワードを変更する方法」を参照してください。

次のいずれかの方法で、役割のプロパティーを変更します。
- Solaris 管理コンソールの「ユーザー」ツールを使用します。
  
  コンソールの起動については、「Solaris 管理コンソールで役割を引き受ける方法」を参照してください。左側の区画の指示に従って、管理役割の役割を変更します。詳細は、オンラインヘルプを参照してください。
- rolemod コマンドを使用します。
  
  このコマンドは、ローカルのネームサービスで定義される役割の属性を変更します。
  $ rolemod -c comment -P profile-list rolename
  -c comment
  
  役割の機能を説明する新しいコメントです。
  
  -P profile-list
  
  役割に含まれるプロファイルのリストです。このリストでプロファイルの現在のリストが置き換えられます。
  
  rolename
  
  変更する既存のローカル役割の名前です。
  
  コマンドオプションの詳細については、rolemod(1M) のマニュアルページを参照してください。
- modify サブコマンドを持つ smrole コマンドを使用します。
  
  このコマンドは、NIS、NIS+、LDAP などの分散ネームサービスで役割の属性を変更します。Solaris 管理コンソールサーバーのクライアントとして動作します。
  $ /usr/sadm/bin/smrole -D domain-name \ -r admin-role -l <Type admin-role password> \ modify -- -n rolename -r username -u username
  -D domain-name
  
  管理対象のドメインの名前です。
  
  -r admin-role
  
  役割を変更できる管理役割の名前です。管理役割は solaris.role.assign 承認を得る必要があります。引き受けた役割を変更する場合、役割は solaris.role.delegate 承認を得る必要があります。
  
  -l
  
  admin-role のパスワードに対するプロンプトです。
  
  --
  
  認証オプションとサブコマンドオプションの間に必要な区切り文字です。
  
  -n rolename
  
  新しい役割の名前です。
  
  -r username
  
  rolename を引き受けることができなくなったユーザーの名前です。
  
  -u username
  
  rolename を引き受けることができるようになったユーザーの名前です。
  
  コマンドオプションの詳細については、smrole(1M) のマニュアルページを参照してください。

例 9–16 `rolemod` コマンドによるローカル役割のプロパティーの変更

この例では、Media Restore 権利プロファイルを含むように operadm 役割を変更します。

$ rolemod -c "Handles printers, backup, AND restore" \
-P "Printer Management,Media Backup,Media Restore,All" operadm

これらの権利プロファイルは、policy.conf ファイルを介して与えられたプロファイルに追加されます。

例 9–17 `smrole modify` コマンドによるローカル役割のプロパティーの変更

次の例では、Media Restore 権利プロファイルを追加するように operadm 役割を変更します。

$ /usr/sadm/bin/smrole -r primaryadm -l <Type primaryadm password> \
modify -- -n operadm -c "Handles printers, backup, AND restore" \
-p "Media Restore"

例 9–18 `smrole modify` コマンドによるドメインの役割の変更

次の例では、clockmgr 役割を変更します。ID が108の NIS ユーザーは役割を引き受けることができなくなります。ID が 110 の NIS ユーザーは、clockmgr の役割を引き受けることができます。

$ /usr/sadm/bin/smrole -D nis:/examplehost/example.domain \
-r primaryadm -l <Type primaryadm password> \
modify -- -n clockmgr -r 108 -u 110

権利プロファイルを作成または変更する方法

権利プロファイルは、役割のプロパティーです。prof_attr データベースに必要な権利プロファイルが含まれていないときには、権利プロファイルを作成または変更してください。権利プロファイルの詳細については、「RBAC の権利プロファイル」を参照してください。

始める前に

権利プロファイルを作成または変更するには、Primary Administrator の役割を引き受けているか、スーパーユーザーに切り替えている必要があります。

次のいずれかの方法で、権利プロファイルを作成または変更します。
- Solaris 管理コンソールの「ユーザー」ツールを使用します。
  
  コンソールの起動については、「Solaris 管理コンソールで役割を引き受ける方法」を参照してください。左側の区画の指示に従って、「権利」の権利プロファイルを作成または変更します。詳細は、オンラインヘルプを参照してください。
- smprofile コマンドを使用します。
  
  このコマンドによって、権利プロファイルの追加、変更、一覧表示、または削除を行うことができます。このコマンドは、ファイル、および NIS、NIS+、LDAP などの分散ネームサービスで機能します。smprofile コマンドは、Solaris 管理コンソールサーバーのクライアントとして動作します。
  $ /usr/sadm/bin/smprofile -D domain-name \ -r admin-role -l <Type admin-role password> \ add | modify -- -n profile-name \ -d description -m help-file -p supplementary-profile
  -D domain-name
  
  管理対象のドメインの名前です。
  
  -r admin-role
  
  役割を変更できる管理役割の名前です。管理役割は solaris.role.assign 承認を得る必要があります。引き受けた役割を変更する場合、役割は solaris.role.delegate 承認を得る必要があります。
  
  -l
  
  admin-role のパスワードに対するプロンプトです。
  
  --
  
  認証オプションとサブコマンドオプションの間に必要な区切り文字です。
  
  -n profile-name
  
  新しいプロファイルの名前です。
  
  -d description
  
  プロファイルの簡単な説明です。
  
  -m help-file
  
  作成した /usr/lib/help/profiles/locale/C ディレクトリに配置した HTML ヘルプファイルの名前です。
  
  -p supplementary-profile
  
  この権利プロファイルに含まれる既存の権利プロファイルの名前です。複数の -p supplementary-profile のオプションを指定することができます。
  
  コマンドオプションの詳細については、smprofile(1M) のマニュアルページを参照してください。

例 9–19 コマンド行から権利プロファイルを変更する

次の例では、Network Management 権利プロファイルを Network Security 権利プロファイルの補助プロファイルにします。Network Security プロファイルを含む役割は、ネットワークおよびホストを構成できるようになり、加えてセキュリティー関連のコマンドを実行します。

$ /usr/sadm/bin/smprofile -D nisplus:/example.host/example.domain \
-r primaryadm -l <Type primaryadm password> \
modify -- -n "Network Security" \
-d "Manage network and host configuration and security" \
-m RtNetConfSec.html -p "Network Management"

管理者は、新しいヘルプファイル、RtNetConfSec.html を作成し、それを/usr/lib/help/profiles/locale/C ディレクトリに配置してから、このコマンドを実行します。

例 9–20 権利ツールを使用して新しい権利プロファイルを作成する

次の表では、「Build Administrator」と呼ばれる仮想権利プロファイルのサンプルデータを示します。この権利プロファイルには、サブディレクトリ /usr/local/swctrl/bin のコマンドが含まれます。これらのコマンドの実効 UID は 0 です。Build Administrator 権利プロファイルは、ソフトウェア開発のビルドとバージョンを管理する管理者が使用します。

タブ	フィールド	例
基本 (General)	名前	Build Administrator
	説明	ソフトウェアのビルドとバージョンの管理用。
	ヘルプファイル名 (Help File Name)	`BuildAdmin.html`
コマンド (Commands)	ディレクトリを追加 (Add Directory)	「ディレクトリを追加 (Add Directory)」をクリックし、ダイアログボックスに `/usr/local/swctrl/bin` と入力して、「了解 (OK)」をクリックします。
	拒否されたコマンド (Commands Denied) / 許可されたコマンド (Commands Permitted)	`/usr/local/swctrl/bin` を「許可されたコマンド (Commands Permitted)」列に移動します。
	セキュリティー属性を設定 (Set Security Attributes)	`/usr/local/swctrl/bin` を選択し、「セキュリティー属性を設定 (Set Security Attributes)」をクリックして、 Effective UID = `root` を設定します。
承認	含まれない承認 (Authorizations Excluded) / 含まれる承認 (Authorizations Included)	承認なし
補助権利 (Supplementary Rights)	含まれない権利 (Rights Excluded) / 含まれる権利 (Rights Included)	補助権利プロファイルなし

注意事項

権利プロファイルによって期待する機能を持つ役割が提供されない場合は、次を確認します。

役割の権利プロファイルが、GUI で最も権限のあるものから最も権限のないものへとリストされていること。

たとえば、All 権利プロファイルがリストの最上部にある場合、セキュリティー属性で実行されるコマンドはありません。セキュリティー属性を指定したコマンドを含むプロファイルは、リストで All 権利プロファイルの前に来なければなりません。
コマンドが、役割の権利プロファイルで複数回リストされていること。その場合、コマンドの最初のインスタンスに必要なセキュリティー属性がすべて指定されていること。

たとえば、コマンドはそのコマンドの特定のオプションのために特権を必要とする可能性があります。特権を必要とするオプションが成功するには、リストの一番上にある権利プロファイルのコマンドの最初のインスタンスに特権を割り当てる必要があります。
役割の権利プロファイルのコマンドに適切なセキュリティー属性を指定していること。

たとえば、ポリシーが suser のとき、 euid=0 ではなく、uid=0 である必要があるコマンドもあります。
ネームサービスのキャッシュ、svc:/system/name-service-cache を再起動していること。

nscd デーモンには長い有効期間を設定することができます。デーモンを再起動して、現在のデータでネームサービスを更新します。

ユーザーの RBAC プロパティーを変更する方法

ユーザーのプロパティーには、パスワード、権利プロファイル、役割、および承認が含まれます。ユーザーに管理機能を与える最も安全な方法として、ユーザーに役割を与えます。詳細については、「セキュリティー属性を直接割り当てる場合に考慮すべきセキュリティー事項」を参照してください。

始める前に

Primary Administrator 権利プロファイルを含む役割を引き受けるか、root ユーザーに切り替える必要があります。

次のいずれかの方法で、ユーザーの RBAC プロパティーを変更します。
- Solaris 管理コンソールの「ユーザー」ツールを使用します。
  
  コンソールの起動については、「Solaris 管理コンソールで役割を引き受ける方法」を参照してください。左側の区画の指示に従って、「ユーザーアカウント (User Accounts) 」のユーザーを変更します。詳細は、オンラインヘルプを参照してください。
  
  ヒント –
  承認、特権、または権利プロファイルをユーザーに直接割り当てることはお勧めできません。役割をユーザーに割り当てることが望ましい方法です。その後、ユーザーが、特権付きの操作を実行するための役割を引き受けます。
- usermod コマンドを使用します。
  
  このコマンドは、ローカルのネームサービスで定義されるユーザーの属性を変更します。
  $ usermod -R rolename username
  -R rolename
  
  既存のローカル役割の名前です。
  
  username
  
  変更する既存のローカルユーザーの名前です。
  
  コマンドオプションの詳細については、usermod(1M) のマニュアルページを参照してください。
- modify サブコマンドを持つ smuser コマンドを使用します。
  
  このコマンドは、NIS、NIS+、LDAP などの分散ネームサービスでユーザーの属性を変更します。Solaris 管理コンソールサーバーのクライアントとして動作します。
  $ /usr/sadm/bin/smuser -D domain-name \ -r admin-role -l <Type admin-role password> \ modify -- -n username -a rolename
  -D domain-name
  
  管理対象のドメインの名前です。
  
  -r admin-role
  
  役割を変更できる管理役割の名前です。管理役割は solaris.role.assign 承認を得る必要があります。引き受けた役割を変更する場合、役割は solaris.role.delegate 承認を得る必要があります。
  
  -l
  
  admin-role のパスワードに対するプロンプトです。
  
  --
  
  認証オプションとサブコマンドオプションの間に必要な区切り文字です。
  
  -n username
  
  rolename を割り当てられるユーザーの名前です。
  
  -a rolename
  
  username に割り当てる役割の名前です。複数の -a rolename オプションを指定することができます。
  
  コマンドオプションの詳細については、smuser(1M) のマニュアルページを参照してください。

例 9–21 コマンド行からのローカルユーザーの RBAC プロパティーの変更

この例では、ユーザー jdoe が System Administrator の役割を引き受けることができるようになります。

$ usermod -R sysadmin jdoe

この役割は、ユーザーが引き受けることのできる役割に追加されます。

例 9–22 `smuser` コマンドを使用したユーザーの RBAC プロパティーの変更

この例では、ユーザー jdoe に、System Administrator と Operator の 2 つの役割が割り当てられます。ユーザーと役割はローカルに定義されるため、-D オプションは必要ありません。

$ /usr/sadm/bin/smuser -r primaryadm -l <Type primaryadm password> \
modify -- -n jdoe -a sysadmin -a operadm

次の例では、ユーザーは NIS ネームサービスで定義されます。したがって、-D オプションは必要です。2 つの役割が、ネームサービスで定義されます。一方の役割、root は、ローカルに定義されます。

$ /usr/sadm/bin/smuser -D nis:/examplehost/example.domain \
-r primaryadm -l <Type primaryadm password> \
modify -- -n jdoe -a sysadmin -a operadm -a root

RBAC プロパティーをレガシーアプリケーションに追加する方法

レガシーアプリケーションは、コマンドまたはコマンドのセットです。セキュリティー属性は、権利プロファイルのコマンドごとに設定します。その後、権利プロファイルを役割に含めます。役割を引き受けるユーザーは、セキュリティー属性を指定したレガシーアプリケーションを実行することができます。

Solaris 管理コンソールにレガシーアプリケーションを追加する方法については、『Solaris のシステム管理 (基本編)』の「Solaris 管理コンソールにツールを追加する」を参照してください。

始める前に

権利プロファイルのコマンドのセキュリティー属性を変更するには、Primary Administrator の役割を引き受けているか、スーパーユーザーに切り替えている必要があります。

Solaris 管理コンソールの「ユーザー」ツールを使用します。

コンソールの起動については、「Solaris 管理コンソールで役割を引き受ける方法」を参照してください。左側の区画の指示に従って、「権利」の権利プロファイルを変更します。詳細は、オンラインヘルプを参照してください。

レガシーアプリケーションを実装するコマンドにセキュリティー属性を追加します。

レガシーアプリケーションにセキュリティー属性を追加するときは、コマンドに追加する場合と同じ方法で追加します。セキュリティー属性を指定したコマンドを権利プロファイルに追加する必要があります。レガシーコマンドに対して、euid=0 または uid=0 のセキュリティー属性を指定します。手順の詳細については、「権利プロファイルを作成または変更する方法」を参照してください。

レガシーアプリケーションを権利プロファイルに追加したあと、権利プロファイルを役割のプロファイルリストに含めます。

権利プロファイルを役割に追加する方法については、「役割のプロパティーを変更する方法」を参照してください。

例 9–23 スクリプトのコマンドへのセキュリティー属性の追加

スクリプトのコマンドが setuid ビットまたは setgid ビットセットを持つ必要がある場合、実行可能なスクリプトおよびコマンドに対して、権利プロファイルでセキュリティー属性を追加する必要があります。その後、権利プロファイルを役割に含め、含めた役割をユーザーに割り当てます。ユーザーが、役割を引き受け、スクリプトを実行すると、コマンドはそのセキュリティー属性で実行されます。

セキュリティー属性をコマンドまたはシェルスクリプトに追加する方法については、「権利プロファイルを作成または変更する方法」を参照してください。

例 9–24 スクリプトまたはプログラム内の承認の確認

承認用のスクリプトを用意するには、auths コマンドに基づいたテストを追加する必要があります。このコマンドの詳細については、auths(1) のマニュアルページを参照してください。

たとえば、次の行では、$1 引数に指定した承認がユーザーに与えられているかどうかをテストします。

if [ `/usr/bin/auths|/usr/xpg4/bin/grep $1` ]; then
        echo Auth granted
else
        echo Auth denied
fi

万全を期すために、テストにはワイルドカードを使用する別の承認を確認する論理を含めるようにしてください。たとえば、solaris.admin.usermgr.write 承認がユーザーに与えられているかどうかをテストするには、次の文字列を確認します。

solaris.admin.usermgr.write
solaris.admin.usermgr.*
solaris.admin.*
solaris.*

プログラムを作成している場合は、getauthattr() 関数を使用して、承認をテストします。

第 10 章役割によるアクセス制御 (参照)

この章は、RBAC に関する参照資料です。この章の内容は次のとおりです。

RBAC の使用方法については、第 9 章役割によるアクセス制御の使用 (手順)を参照してください。概要については、「役割によるアクセス制御 (概要)」を参照してください。

権利プロファイルの内容

この節では、いくつかの標準的な権利プロファイルについて説明します。権利プロファイルには、承認、セキュリティー属性を指定したコマンド、および補助権利プロファイルを含めることができます。権利プロファイルは、最も権限のあるものから最も権限のないものへとリストされます。権利プロファイルをサイトの役割に配布する際の方法については、「RBAC の実装を計画する方法」を参照してください。

「Primary Administrator」権利プロファイル – 1 つのプロファイルでのスーパーユーザーの機能を提供します。
「System Administrator」権利プロファイル – セキュリティーに関係しないほとんどのタスクを実行できるプロファイルを提供します。このプロファイルには、権限のある役割を作成するためにいくつかのほかのプロファイルが含まれます。
「Operator」権利プロファイル – ファイルおよびオフラインメディアを管理するための制限された機能を提供します。このプロファイルには、単純な役割を作成するための補助権利プロファイルが含まれます。
「Printer Management」権利プロファイル – 印刷を処理するための限られた数のコマンドと承認を提供します。このプロファイルは、単一の管理領域を対象とする複数のプロファイルのうちの 1 つです。
「Basic Solaris User」権利プロファイル – セキュリティーポリシーの範囲内でユーザーがシステムを使用できるようにします。このプロファイルは、デフォルトで policy.conf ファイル内にリストされます。
「All」権利プロファイル – 役割に対して、セキュリティー属性を指定していないコマンドへのアクセスを提供します。

それぞれの権利プロファイルには、関連するヘルプファイルが用意されています。ヘルプファイルは、HTML 形式で、カスタマイズが可能です。ヘルプファイルは、/usr/lib/help/profiles/locale/C ディレクトリにあります。

Primary Administrator 権利プロファイル

Primary Administrator 権利プロファイルには、システム上で最も強力な役割が割り当てられます。Primary Administrator 権利プロファイルを含む役割は、スーパーユーザーの機能を持ちます。

solaris.* 承認は、実質的に Solaris ソフトウェアから提供されるすべての承認を割り当てます。
solaris.grant 承認は、任意の権利プロファイル、役割、またはユーザーに任意の承認を割り当てます。
*:uid=0;gid=0 のコマンド割り当ては、UID=0 および GID=0 ですべてのコマンドを実行します。

ヘルプファイル RtPriAdmin.html は、必要に応じて、使用するサイトに合わせてカスタマイズできます。ヘルプファイルは、/usr/lib/help/profiles/locale/C ディレクトリに格納されています。

Primary Administrator 権利プロファイルがサイトのセキュリティーポリシーと矛盾する場合は、このプロファイルを変更したり、割り当てないようにしたりすることもできます。ただし、Primary Administrator 権利プロファイルのセキュリティー機能は、ほかの権利プロファイルの処理に必要となります。この場合、それらのほかの権利プロファイルを役割に割り当てます。

表 10–1 Primary Administrator 権利プロファイルの内容


目的	内容
すべての管理タスクを実行する	コマンド: `:uid=0;gid=0` 承認: `solaris.`、`solaris.grant` ヘルプファイル: `RtPriAdmin.html`

System Administrator 権利プロファイル

System Administrator 権利プロファイルは、System Administrator 役割用に設計されています。System Administrator では、Primary Administrator の強力な機能を持たないため、ワイルドカードは使用できません。その代わり、このプロファイルは、セキュリティーを対象外とする、一連の個別の補助的な管理権利プロファイルです。補助権利プロファイルの 1 つからのセキュリティー属性を指定したコマンドを示します。

All 権利プロファイルは、補助権利プロファイルのリストの最後にあります。

表 10–2 System Administrator 権利プロファイルの内容


目的	内容
セキュリティーに関係しない管理タスクを実行する	補助権利プロファイル: Audit Review、Printer Management、Cron Management、Device Management、File System Management、Mail Management、Maintenance and Repair、Media Backup、Media Restore、Name Service Management、Network Management、Object Access Management、Process Management、Software Installation、Project Management、User Management、All ヘルプファイル: `RtSysAdmin.html`
補助プロファイルの 1 つからのコマンド	Object Access Management 権利プロファイル、 `solaris` ポリシー: `/usr/bin/chgrp:privs=file_chown`、`/usr/bin/chmod:privs=file_chown`、`/usr/bin/chown:privs=file_chown`、`/usr/bin/setfacl:privs=file_chown` `suser` ポリシー: `/usr/bin/chgrp:euid=0`、`/usr/bin/chmod:euid=0`、`/usr/bin/chown:euid=0`、`/usr/bin/getfacl:euid=0`、`/usr/bin/setfacl:euid=0`

Operator 権利プロファイル

Operator 権利プロファイルは、権限の弱いプロファイルで、バックアップとプリンタ管理を行います。ファイルの復元は、セキュリティーに影響します。したがって、このプロファイルでは、デフォルトではファイルの復元機能は含まれていません。

表 10–3 Operator 権利プロファイルの内容


目的	内容
単純な管理タスクを実行する	補助権利プロファイル: Printer Management、Media Backup、All ヘルプファイル: `RtOperator.html`

Printer Management 権利プロファイル

Printer Management は、特定のタスクを実行する標準権利プロファイルです。このプロファイルには、承認とコマンドが含まれます。次の表では、使用できるコマンドの一部を示します。

表 10–4 Printer Management 権利プロファイルの内容


目的	内容
プリンタ、デーモン、スプール処理を管理する	承認: `solaris.print.`、`solaris.label.print`、`solaris.admin.printer.delete`、`solaris.admin.printer.modify`、`solaris.admin.printer.read`、`solaris.smf.manage.discovery.printers.`、`solaris.smf.value.discovery.printers.` コマンド: `/usr/lib/lp/local/lpadmin:uid=lp;gid =lp`、`/usr/sbin/lpfilter:euid=lp;uid=lp`、`/usr/sbin/lpforms:euid=lp`、 `/usr/sbin/lpusers:euid=lp`、`/usr/sbin/ppdmgr:euid=0` ヘルプファイル*: `RtPrntMngmnt.html`

Basic Solaris User 権利プロファイル

デフォルトでは、Basic Solaris User 権利プロファイルは、policy.conf ファイルによってすべてのユーザーに自動的に割り当てられます。このプロファイルでは、通常の操作に使用する基本的な承認を与えます。Basic Solaris User 権利プロファイルを使用するときは、サイトのセキュリティー要件を考慮する必要があります。高いセキュリティーを必要とするサイトでは、このプロファイルを policy.conf ファイルから削除することをお勧めします。

表 10–5 Basic Solaris User 権利プロファイルの内容


目的	内容
すべてのユーザーに自動的に権限を割り当てる	承認: `solaris.profmgr.read`、`solaris.jobs.user`、`solaris.mail.mailq`、`solaris.device.mount.removable`、`solaris.admin.usermgr.read`、`solaris.admin.logsvc.read`、`solaris.admin.fsmgr.read`、`solaris.admin.serialmgr.read`、`solaris.admin.diskmgr.read`、`solaris.admin.procmgr.user`、`solaris.compsys.read`、`solaris.admin.printer.read`、`solaris.admin.prodreg.read`、`solaris.admin.dcmgr.read`、`solaris.snmp.read`、`solaris.project.read`、`solaris.admin.patchmg.read`、`solaris.network.hosts.read`、`solaris.admin.volmgr.read` 補助権利プロファイル: All ヘルプファイル: `RtDefault.html`

All 権利プロファイル

All 権利プロファイルは、すべてのコマンドを使用できるようにワイルドカードを使用したプロファイルです。この権利プロファイルは、ほかのプロファイルに明示的に割り当てられていないすべてのコマンドにアクセスできる役割です。All 権利プロファイルまたはワイルドカードを使用するその他の権利プロファイルを使用しないと、役割は明示的に割り当てられているコマンド以外にはアクセスできません。このような制限された一連のコマンドは、あまり実用的でありません。

All 権利プロファイルを使用する場合は、最後に割り当ててください。それによって、ほかの権利プロファイルで明示的に割り当てたセキュリティー属性が誤って無効にされることがないようにできます。

表 10–6 All 権利プロファイルの内容


目的	内容
ユーザーまたは役割として任意のコマンドを実行する	コマンド: * ヘルプファイル: `RtAll.html`

権利プロファイルの順序

権利プロファイルのコマンドは、発生順に解釈されます。最初に発生したコマンドが、役割またはユーザーに対して使用されるコマンドの唯一のバージョンです。さまざまな権利プロファイルが、同一のコマンドを含むことができます。したがって、プロファイルのリスト内の権利プロファイルの順序が重要になってきます。ほとんどの機能を持つ権利プロファイルが先頭に来るようにします。

権利プロファイルは、Solaris 管理コンソールの GUI および prof_attr ファイルでリストされます。Solaris 管理コンソールの GUI では、ほとんどの機能を持つ権利プロファイルが、割り当てられた権利プロファイルのリストの一番上のプロファイルになります。prof_attr ファイルでは、ほとんどの機能を持つ権利プロファイルが、補助プロファイルのリストの最初に来ます。この配置において、セキュリティー属性を指定したコマンドがセキュリティー属性を指定していない同一のコマンドの前にリストされます。

権利プロファイルの内容の表示

Solaris 管理コンソールの権利ツールを使用して、権利プロファイルの内容を検査することもできます。

prof_attr および exec_attr ファイルでは、より細分化されて表示されます。prof_attr ファイルには、システムで定義されたすべての権利プロファイルの名前が含まれます。このファイルには、プロファイルごとの承認および補助権利プロファイルも含まれます。exec_attr ファイルには、権利プロファイルの名前と、セキュリティー属性を指定した権利プロファイルのコマンドが含まれます。

承認の命名と委託

RBAC の「承認」は、役割またはユーザーに許可できる個別の権限です。RBAC に準拠したアプリケーションによって承認が確認されてから、ユーザーはアプリケーションまたはアプリケーションの特定の操作へのアクセス権を取得します。この承認の確認は、従来の UNIX アプリケーションが行なっていた UID=0 のテストに代わるものです。

承認の命名規則

承認には、RBAC の内部およびファイル内で使用される名前があります。たとえば solaris.admin.usermgr.pswd などの承認名があります。また、グラフィカルユーザーインタフェース (GUI) に表示される短い説明もあります。たとえば、Change Passwords は、solaris.admin.usermgr.pswd 承認の説明です。

承認名の書式は、インターネット名と逆の順序になり、サプライヤ、被認証者領域、任意の下位領域、および承認の機能で構成されます。承認名の区切り文字はドット (.) です。たとえば、com.xyzcorp.device.access のように指定します。ただし、Sun から許可される承認では、インターネット名の代わりに接頭辞 solaris が使用されます。システム管理者は、承認を階層方式で適用することができます。ワイルドカード (*) は、ドットの右側の任意の文字列を表すことができます。

承認レベルの違いの例

ここでは、承認の使用方法の例を示します。 Operator 役割のユーザーは、多くの場合、solaris.admin.usermgr.read 承認に制限されます。この承認では、ユーザーの構成ファイルに対する読み取り権は許可されますが、書き込み権は許可されません。System Administrator 役割では、solaris.admin.usermgr.read 承認と、ユーザーのファイルを変更できる solaris.admin.usermgr.write 承認が許可されます。ただし、System Administrator には、solaris.admin.usermgr.pswd 承認が許可されないため、パスワードは変更できません。Primary Administrator では、これらの 3 つの承認がすべて許可されます。

Solaris 管理コンソールのユーザーツールのパスワードを変更するには、solaris.admin.usermgr.pswd 承認が必要です。この承認は、smuser、smmultiuser、および smrole コマンドのパスワード変更オプションを使用するときにも必要になります。

承認での委託権限

接尾辞が grant の承認が許可されたユーザーまたは役割は、割り当てられている承認のうち同じ接頭辞を持つ任意の承認を、ほかのユーザーに委託することができます。

たとえば、solaris.admin.usermgr.grant 承認と solaris.admin.usermgr.read 承認を持つ役割は、solaris.admin.usermgr.read 承認をほかのユーザーに委託できます。solaris.admin.usermgr.grant 承認と solaris.admin.usermgr.* 承認を持つ役割は、solaris.admin.usermgr 接頭辞を持つ任意の承認をほかのユーザーに委託できます。

RBAC をサポートするデータベース

次の 4 つのデータベースには、RBAC 要素のデータが格納されます。

拡張ユーザー属性のデータベース (user_attr) – ユーザーと役割を承認と権利に関連付けます
権利プロファイル属性のデータベース (prof_attr) – 権利プロファイルを定義し、その権利プロファイルに割り当てられた承認を指定し、関連するヘルプファイルを指定します
承認属性のデータベース (auth_attr) – 承認とその属性を定義し、関連するヘルプファイルを指定します
実行属性のデータベース (exec_attr) – 特定の権利プロファイルに割り当てられたセキュリティー属性を持つコマンドを指定します

policy.conf データベースには、すべてのユーザーに適用される承認、特権、および権利プロファイルが含まれます。詳細については、「policy.conf ファイル」を参照してください。

RBAC データベースの関係

各 RBAC データベースには、key= value という構文を使用して、値を格納します。この方式は、将来のデータベースの拡張に対応します。また、ポリシーが認識できないキーワードが検出された場合にも対応できます。key=value の内容によって、ファイルがリンクされます。4 つのデータベースの互いにリンクした次のエントリは、RBAC データベースの相互関係を示しています。

例 10–1 RBAC データベースの接続を示す

次の例で、ユーザー jdoe は、役割 filemgr を割り当てられることにより、File System Management プロファイルの機能を取得します。

ユーザー jdoe には、user_attr データベースの jdoe ユーザーエントリの役割 filemgr が割り当てられます。
# user_attr - user definition jdoe::::type=normal;roles=filemgr
役割 filemgr には、user_attr データベースの役割のエントリの権利プロファイル File System Management が割り当てられます。
# user_attr - role definition filemgr::::profiles=File System Management;type=role
ユーザーと役割は、ローカルシステムの passwd ファイルおよび shadow ファイル、または分散ネームサービスの同等のデータベースに一意に定義されます。

File System Management 権利プロファイルは prof_attr データベースに定義されています。また、このデータベースは File System Management エントリに 3 つの承認のセットを割り当てます。

# prof_attr - rights profile definitions and assigned authorizations
File System Management:::Manage, mount, share file systems:
help=RtFileSysMngmnt.html;
auths=solaris.admin.fsmgr.*,solaris.admin.diskmgr.*,solaris.admin.volmgr.*

これらの承認は、auth_attr データベースに定義されています。

# auth_attr - authorization definitions
solaris.admin.fsmgr.:::Mounts and Shares::help=AuthFsmgrHeader.html
solaris.admin.fsmgr.read:::View Mounts and Shares::help=AuthFsmgrRead.html
solaris.admin.fsmgr.write:::Mount and Share Files::help=AuthFsmgrWrite.html

File System Management 権利プロファイルには、exec_attr データベースでセキュリティー属性を指定したコマンドが割り当てられます。

# exec_attr - rights profile names with secured commands
File System Management:suser:cmd:::/usr/sbin/mount:uid=0
File System Management:suser:cmd:::/usr/sbin/dfshares:euid=0
…
File System Management:solaris:cmd:::/usr/sbin/mount:privs=sys_mount
…

RBAC データベースとネームサービス

RBAC データベースのネームサービスの適用範囲は、ローカルホストにのみ適用することができます。また、適用範囲には、 NIS、NIS+、LDAP などのネームサービスによってサービスが提供されるすべてのホストが含まれます。どのネームサービスが優先されるかは、/etc/nsswitch.conf ファイルでデータベースごとに設定されます。

auth_attr エントリ – auth_attr データベースにネームサービスの優先順位が設定されます。
passwd エントリ – user_attr データベースにネームサービスの優先順位が設定されます。
prof_attr エントリ – prof_attr データベースにネームサービスの優先順位が設定されます。また、exec_attr データベースにもネームサービスの優先順位が設定されます。

たとえば、セキュリティー属性を指定したコマンドを特定の権利プロファイルに割り当てた場合に、そのプロファイルが 2 つのネームサービスの適用範囲に存在するときは、最初のネームサービスの適用範囲のエントリだけが使用されます。

`user_attr` データベース

user_attr データベースには、ユーザーと役割の情報が格納されます。これらの情報は、passwd および shadow データベースによって利用されます。user_attr データベースには、承認、権利プロファイル、割り当てられた役割など、さまざまなユーザー属性が格納されます。user_attr データベースの各フィールドは次のようにコロンで区切ります。

user:qualifier:res1:res2:attr

フィールドの意味は次のとおりです。

user

passwd データベースに指定されているユーザー名または役割名。

qualifier:res1:res2

これらのフィールドは、将来的な使用のために予約されています。

attr

セミコロン (;) で区切られた、鍵と値のペアからなるリスト (省略可能)。ユーザーがコマンドを実行したときに適用されるセキュリティー属性を表します。有効な鍵は、type、auths、profiles、roles の 4 つです。

type キーワードには、アカウントが通常ユーザーの場合は normal を設定します。役割の場合 type は role になります。
auths キーワードには、auth_attr データベースの定義名から選択した承認名をコンマで区切って指定します。承認名には、ワイルドカードとしてアスタリスク (*) を使用できます。たとえば、solaris.device.* はすべての Solaris デバイスの承認を意味します。
profiles キーワードには、prof_attr データベースに定義されている権利プロファイル名をコンマで区切って指定します。権利プロファイルの順序は、UNIX 検索パスと同様に動作します。実行するコマンドにどのセキュリティー属性が適用されるかは、そのコマンドが含まれているリストの最初のプロファイルによって決まります (属性を使用する場合)。
roles キーワードには、ユーザーに割り当てる役割名をコンマで区切って指定します。役割も同じ user_attr データベースに定義されます。役割の場合は、type 値に role が設定されます。役割を他の役割に割り当てることはできません。

次の例では、Operator 役割を標準的な user_attr データベースに定義する方法を示しています。また、Operator 役割をユーザー jdoe に割り当てる方法も示しています。役割とユーザーは、type キーワードによって識別されます。

% grep operator /etc/user_attr 
jdoe::::type=normal;roles=operator
operator::::profiles=Operator;type=role

`auth_attr` データベース

承認はすべて auth_attr データベースに格納されます。承認は、ユーザー、役割、権利プロファイルに割り当てることができます。承認を権利プロファイルに配置し、権利プロファイルを役割のプロファイルリストに含めたあと、その役割をユーザーに割り当てることをお勧めします。

auth_attr データベースのフィールドは次のようにコロンで区切ります。

authname:res1:res2:short_desc:long_desc:attr

フィールドの意味は次のとおりです。

authname

承認を識別する一意の文字列。書式は prefix.[suffix]。Solaris OS では、承認の接頭辞として solaris を使用します。ほかのすべての承認には、承認を作成する組織のインターネットドメインを逆にしたもので始まる接頭辞を使用します (たとえば、com.xyzcompany)。接尾辞は、一般には機能領域と操作、およびどのように承認されるかを示します。

authname が接頭辞と機能領域で構成され、ピリオドで終わるときは、GUI 内でアプリケーションによって使用されるヘッダーとして機能します。2 つの部分からなる authname は実際の承認ではありません。たとえば、authname は solaris.printmgr. ではヘッダーです。

authname が「grant」で終わるときは、認可承認として機能します。認可承認を持つユーザーは、同じ接頭辞と機能領域で構成される承認をほかのユーザーに委託できます。たとえば、solaris.printmgr.grant が authname の場合は、認可承認として使用されます。solaris.printmgr.grant が許可されたユーザーは、solaris.printmgr.admin や solaris.printmgr.nobanner などの承認をほかのユーザーに委託する権利を持ちます。

res1:res2

これらのフィールドは、将来的な使用のために予約されています。

short_desc

承認の簡略名。この簡略名は、GUI のスクロールリストの中など、ユーザーインタフェースでの表示に適しています。

long_desc

詳しい記述。このフィールドには、承認の目的、承認が使用されるアプリケーション、承認を使用するユーザーの種類などを記述します。詳しい記述は、アプリケーションのヘルプテキストに表示できます。

attr

承認の属性を記述する鍵と値のペアをセミコロン (;) で区切ったリスト (オプション)。0 または 1 つ以上の鍵を指定できます。

キーワード help には HTML 形式のヘルプファイルを指定します。ヘルプファイルは、/usr/lib/help/auths/locale/C ディレクトリの index.html ファイルからアクセスできます。

次の例は、標準的な値がいくつか設定された auth_attr データベースを示します。

% grep printer /etc/security/auth_attr 
solaris.admin.printer.:::Printer Information::help=AuthPrinterHeader.html
solaris.admin.printer.delete:::Delete Printer Information::help=AuthPrinterDelete.html
solaris.admin.printer.modify:::Update Printer Information::help=AuthPrinterModify.html
solaris.admin.printer.read:::View Printer Information::help=AuthPrinterRead.html

solaris.admin.printer. はドット (.) で終わっているため、ヘッダーとして定義されます。ヘッダーは、承認の集合を作成するために、GUI によって使用されます。

`prof_attr` データベース

prof_attr データベースには、権利プロファイルに割り当てる名前、説明、ヘルプファイルの場所、および承認が格納されます。権利プロファイルに割り当てられたコマンドとセキュリティー属性は、exec_attr データベースに格納されます。詳細については、「exec_attr データベース」を参照してください。prof_attr データベースのフィールドは次のようにコロンで区切ります。

profname:res1:res2:desc:attr

フィールドの意味は次のとおりです。

profname

権利プロファイルの名前。権利プロファイル名では大文字と小文字が区別されます。この名前は、役割とユーザーにプロファイルを指定するために、user_attr データベースでも使用されます。

res1:res2

これらのフィールドは、将来的な使用のために予約されています。

desc

詳しい記述。このフィールドでは、権利プロファイルの使用に適したユーザーの種類など、権利プロファイルの目的を説明します。詳しい記述は、アプリケーションのヘルプテキストとして適している内容である必要があります。

attr

実行時にそのオブジェクトに適用するセキュリティー属性を記述する鍵と値のペアをセミコロン (;) で区切ったリスト (オプション)。0 または 1 つ以上の鍵を指定できます。有効な鍵は、help と auths の 2 つです。

キーワード help には HTML 形式のヘルプファイルを指定します。ヘルプファイルは、/usr/lib/help/profiles/locale/C ディレクトリの index.html ファイルからアクセスできます。

キーワード auths には、auth_attr データベースから選択した承認名をコンマで区切って指定します。承認名には、ワイルドカードとしてアスタリスク (*) を使用できます。

次の例では、標準的な 2 つの prof_attr データベースエントリを示します。Printer Management 権利プロファイルは、Operator 権利プロファイルの補助権利プロファイルです。この例は、表示の都合上、折り返して記載されています。

% grep 'Printer Management' /etc/security/prof_attr
Printer Management:::         Name of rights profile
Manage printers, daemons, spooling: Description
help=RtPrntAdmin.html;              Help file
auths=solaris.admin.printer.read, Authorizations
solaris.admin.printer.modify,solaris.admin.printer.delete
...
Operator:::                         Name of rights profile
Can perform simple administrative tasks: Description
profiles=Printer Management,  Supplementary rights profiles
Media Backup,All;
help=RtOperator.html               Help file

`exec_attr` データベース

exec_attr データベースでは、成功するためにセキュリティー属性を必要とするコマンドが定義されます。このコマンドは、権利プロファイルの一部です。セキュリティー属性を指定したコマンドは、プロファイルが割り当てられている役割が実行できます。

exec_attr データベースのフィールドは次のようにコロンで区切って指定します。

name:policy:type:res1:res2:id:attr

フィールドの意味は次のとおりです。

profname

権利プロファイルの名前。権利プロファイル名では大文字と小文字が区別されます。この名前は、prof_attr データベースのプロファイルを参照します。

policy

このエントリに関連付けるセキュリティーポリシー。現時点では、suser と solaris が有効なエントリです。solaris ポリシーでは、特権が認識されます。suser ポリシーでは、認識されません。

type

指定するエンティティーの種類。現在は、cmd (コマンド) が唯一の有効なエンティティーです。

res1:res2

これらのフィールドは、将来的な使用のために予約されています。

id

エンティティーを識別する文字列。コマンドには、完全パスかワイルドカード (*) をもつパスを指定します。引数を指定する場合は、引数をもつスクリプトを作成し、そのスクリプトを id に指定します。

attr

実行時にそのエンティティーに適用するセキュリティー属性を記述する鍵と値のペアをセミコロン (;) で区切ったリスト (オプション)。 0 または 1 つ以上の鍵を指定できます。有効なキーワードのリストは、適用するポリシーによって異なります。

suser ポリシーに対して有効な鍵は、euid、uid、egid、gid の 4 つです。

euid および uid キーワードには、1 つのユーザー名またはユーザー ID (UID) の数値が含まれます。euid を使用すると、コマンドは指定された UID で動作します。これは、実行可能ファイルに setuid ビットを設定することと同じです。uid を使用すると、コマンドは指定された実 UID と実効 UID で動作します。
egid および gid キーワードには、1 つのグループ名またはグループ ID (GID) の数値が含まれます。egid を使用すると、コマンドは指定された GID で動作します。これは、実行可能ファイルに setgid ビットを設定することと同じです。gid を使用すると、コマンドは指定された実 GID と実効 GID で動作します。

solaris ポリシーに対して、有効なキーワードは privs です。値は、コンマで区切られた特権のリストから構成されます。

次の例に、exec_attr データベースの標準的な値をいくつか示します。

% grep 'File System Management' /etc/security/exec_attr
File System Management:suser:cmd:::/usr/sbin/ff:euid=0
File System Management:solaris:cmd:::/usr/sbin/mount:privs=sys_mount
…

`policy.conf` ファイル

policy.conf ファイルは、特定の権利プロファイル、特定の承認、および特定の特権をすべてのユーザーに与える方法を定義します。ファイル内の関連するエントリは、key=value のペアから構成されます。

AUTHS_GRANTED=authorizations – 1 つまたは複数の承認を示します。
PROFS_GRANTED=rights profiles – 1 つまたは複数の権利プロファイルを示します。
PRIV_DEFAULT=privileges – 1 つまたは複数の特権を示します。
PRIV_LIMIT=privileges – すべての特権を示します。

次の例では、policy.conf データベースの標準的な値をいくつか示します。

# grep AUTHS /etc/security/policy
AUTHS_GRANTED=solaris.device.cdrw

# grep PROFS /etc/security/policy
PROFS_GRANTED=Basic Solaris User

# grep PRIV /etc/security/policy

#PRIV_DEFAULT=basic
#PRIV_LIMIT=all

権限の詳細は、「特権 (概要)」を参照してください。

RBAC コマンド

この節では、RBAC の管理に使用するコマンドを一覧します。承認を使用してアクセス権を制御できるコマンドについても説明します。

RBAC を管理するコマンド

ローカルの RBAC データベースは手動で編集できますが、そのような編集はできるだけ避けてください。RBAC を使用したタスクへのアクセスを管理するために、次のコマンドが使用できます。

表 10–7 RBAC 管理コマンド


コマンドのマニュアルページ	説明
auths(1)	ユーザーに対する承認を表示します。
makedbm(1M)	`dbm` ファイルを作成します。
nscd(1M)	ネームサービスキャッシュデーモン。`user_attr`、 `prof_attr`、および`exec_attr` データベースをキャッシュするときに使用します。`svcadm` コマンドを使用してデーモンを再起動します。
pam_roles(5)	PAM 用の役割アカウント管理モジュール。役割になる承認があるかを検査します。
pfexec(1)	プロファイルシェルによって使用されます。`exec_attr` データベースに指定されているセキュリティー属性を使用してコマンドを実行します。
policy.conf(4)	システムのセキュリティーポリシーの構成ファイル。与えられている承認、与えられている特権、およびその他のセキュリティー情報を一覧表示します。
profiles(1)	指定したユーザーの権利プロファイルを表示します。
roles(1)	指定したユーザーが引き受けられる役割を表示します。
roleadd(1M)	役割をローカルシステムに追加します。
roledel(1M)	役割をローカルシステムから削除します。
rolemod(1M)	ローカルシステム上の役割のプロパティーを変更します。
smattrpop(1M)	2 つのセキュリティー属性データベースをマージします。ローカルデータベースをネームサービスにマージするときに使用します。変換スクリプトを使用しないでアップグレードするときも使用します。
smexec(1M)	`exec_attr` データベースのエントリを管理します。認証を必要とします。
smmultiuser(1M)	ユーザーアカウントの一括操作を管理します。認証を必要とします。
smprofile(1M)	`prof_attr` および `exec_attr` データベースの権利プロファイルを管理します。認証を必要とします。
smrole(1M)	役割アカウントの役割とユーザーを管理します。認証を必要とします。
smuser(1M)	ユーザーのエントリを管理します。認証を必要とします。
useradd(1M)	ユーザーアカウントをシステムに追加します。ユーザーのアカウントに役割を割り当てるには、`-P` オプションを使用します。
userdel(1M)	ユーザーのログインをシステムから削除します。
usermod(1M)	システム上のユーザーのアカウントプロパティーを変更します。

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

次の表では、承認を使用して Solaris システムのコマンドオプションを制限する方法を示します。承認の詳細については、「承認の命名と委託」を参照してください。

表 10–8 コマンドおよび関連する承認


コマンドのマニュアルページ	承認の要件
at(1)	`solaris.jobs.user` がすべてのオプションで必要です (`at.allow` ファイルおよび `at.deny` ファイルがない場合)
atq(1)	`solaris.jobs.admin` がすべてのオプションで必要です
cdrw(1)	`solaris.device.cdrw` がすべてのオプションで必要です。`policy.conf` ファイルにデフォルトで与えられます
crontab(1)	ジョブを送信するオプションの場合は、`solaris.jobs.user` が必要です (`crontab.allow` および `crontab.deny`ファイルがない場合) ほかのユーザーの `crontab` ファイルを一覧表示または変更する場合は、`solaris.jobs.admin` が必要です
allocate(1)	デバイスを割り当てる場合は、`solaris.device.allocate` (または、 `device_allocate` ファイルに指定されている別承認) が必要ですほかのユーザーにデバイスを割り当てる場合 (`F` オプション) は、 `solaris.device.revoke` (または、 `-device_allocate` ファイルに指定されている別承認) が必要です
deallocate(1)	ほかのユーザーのデバイスの割り当てを解除する場合は、 `solaris.device.allocate` (または、`device_allocate` ファイルに指定されている別承認) が必要です指定したデバイス (`-F` オプション) またはすべてのデバイス (`-I` オプション) の割り当てを強制的に解除する場合は、`solaris.device.revoke` (または、 `device_allocate` に指定されている別承認) が必要です
list_devices(1)	ほかのユーザーのデバイスを一覧表示する場合 (`U` オプション) は、`-solaris.device.revoke` が必要です
sendmail(1M)	メールサブシステム機能にアクセスする場合は、`solaris.mail` が必要。メールキューを表示する場合は、`solaris.mail.mailq` が必要です

第 11 章特権 (手順)

この章では、ご使用のシステムでの特権の管理と使用の手順について説明します。この章の内容は次のとおりです。

特権の概要については、「特権 (概要)」を参照してください。参照情報については、第 12 章特権 (参照)を参照してください。

特権の管理と使用 (作業マップ)

次の作業マップは、特権を管理および使用するための作業マップです。

作業	説明	参照先
サイトで特権を使用します	特権の使用の割り当て、削除、追加、デバッグを含みます。	「特権の管理 (作業マップ)」
コマンド実行時に特権を使用します	割り当てられた特権の使用を含みます。	「特権の判断 (作業マップ)」

特権の管理 (作業マップ)

次の作業マップでは、特権の表示、特権の割り当て、および特権コマンドを含むスクリプトの実行の手順を示します。

作業	説明	参照先
プロセスに含まれる特権を判断します	プロセスに対する、有効な特権、継承可能な特権、許可された特権、および制限付きの特権のセットを一覧表示します。	「プロセスの特権を判断する方法」
プロセスから漏れている特権を判断します	失敗したプロセスが必要とする特権を一覧表示します。	「プログラムが必要とする特権を判断する方法」
特権をコマンドに追加します	特権を権利プロファイルのコマンドに追加します。ユーザーまたは役割を権利プロファイルに割り当てることができます。ユーザーは、プロファイルシェルで割り当てられた特権でコマンドを実行できるようになります。	「特権をコマンドに追加する方法」
特権をユーザーに割り当てます	ユーザーまたは役割の継承可能な一連の特権を拡張します。この手順は、十分注意して実行してください。	「特権をユーザーまたは役割に割り当てる方法」
ユーザーの特権を制限します	ユーザーの特権の基本セットを制限します。この手順は、十分注意して実行してください。	「ユーザーまたは役割の特権を制限する方法」
特権付きのシェルスクリプトを実行します	特権をシェルスクリプトおよびシェルスクリプトのコマンドに追加します。その後、プロファイルシェルのスクリプトを実行します。	「特権付きのコマンドを含むシェルスクリプトの実行方法」

特権の管理

ユーザーおよび役割の特権を管理する最も安全な方法として、権利プロファイルのコマンドに対して特権の使用を制限します。その後、権利プロファイルを役割に含めます。その役割をユーザーに割り当てます。ユーザーは、割り当てられた役割を引き受けると、特権付きコマンドをプロファイルシェルで実行できるようになります。次の手順は、特権の割り当て、特権の削除、および特権の使用のデバッグの方法を示したものです。

プロセスの特権を判断する方法

この手順は、プロセスで使用可能な特権を判断する方法です。一覧には、特定のコマンドに割り当てられている特権は含まれません。

シェルのプロセスで使用可能な特権を一覧表示します。
% ppriv pid $ ppriv -v pid
pid

プロセス番号です。二重ドル記号 ($$) を使用して親シェルのプロセス番号をコマンドに渡します。

-v

特権名の詳細な一覧表示を行います。

例 11–1 現在のシェルでの特権の判断

次の例では、ユーザーのシェルプロセスの親プロセスでの特権を一覧表示します。2 つ目の例では、特権の正式名を一覧表示します。出力の最初の文字は、次の特権セットを指しています。

E: 有効な特権セットです。
I: 継承可能な特権セットです。
P: 許可された特権セットです。
L: 制限付きの特権セットです。

% ppriv $$
1200:   -csh
flags = <none>
        E: basic
        I: basic
        P: basic
        L: all
% ppriv -v $$
1200:   -csh
flags = <none>
        E: file_link_any,net_access,proc_exec,proc_fork,proc_info,proc_session
        I: file_link_any,net_access,proc_exec,proc_fork,proc_info,proc_session
        P: file_link_any,net_access,proc_exec,proc_fork,proc_info,proc_session
        L: cpc_cpu,dtrace_kernel,dtrace_proc,dtrace_user,…,sys_time

例 11–2 引き受けることができる役割の特権の判断

役割では、管理シェルまたはプロファイルシェルが使用されます。役割に直接割り当てられている特権を一覧表示するには、役割を引き受け、役割のシェルを使用する必要があります。次の例では、役割 sysadmin に直接割り当てられている特権はありません。

% su - sysadmin
Password: <Type sysadmin password>
$ /usr/ucb/whoami
sysadmin
$ ppriv -v $$
1400:   pfksh
flags = <none>
        E: file_link_any,net_access,proc_exec,proc_fork,proc_info,proc_session
        I: file_link_any,net_access,proc_exec,proc_fork,proc_info,proc_session
        P: file_link_any,net_access,proc_exec,proc_fork,proc_info,proc_session
        L: cpc_cpu,dtrace_kernel,dtrace_proc,dtrace_user,…,sys_time

プログラムが必要とする特権を判断する方法

この手順では、コマンドまたはプロセスが必要とする特権を判断します。

始める前に

この手順は、コマンドまたはプロセスが失敗している場合に有効です。

ppriv デバッグコマンドに対する引数として失敗しているコマンドを入力します。

% ppriv -eD touch /etc/acct/yearly
touch[11365]: missing privilege "file_dac_write" 
     (euid = 130, syscall = 224) needed at ufs_direnter_cm+0x27c
touch: /etc/acct/yearly cannot create

/etc/name_to_sysnum ファイルの syscall 番号を見つけ、失敗しているシステムコールを突き止めます。
% grep 224 /etc/name_to_sysnum creat64 224

例 11–3 特権の使用を検査するための `truss` コマンドの使用

truss コマンドは、通常のシェルで特権の使用をデバッグすることができます。たとえば、次のコマンドは、失敗した touch プロセスをデバッグします。

% truss -t creat touch /etc/acct/yearly
creat64("/etc/acct/yearly", 0666)            
                       Err#13 EACCES [file_dac_write]
touch: /etc/acct/yearly cannot create

拡張された /proc インタフェースで、truss 出力のエラーコードのあとに欠如している特権がレポートされます。

例 11–4 プロファイルシェルで特権の使用を検査するための `ppriv` コマンドの使用

ppriv コマンドは、プロファイルシェルで特権の使用をデバッグすることができます。権利プロファイルをユーザーに割り当て、割り当てた権利プロファイルに特権付きのコマンドを含める場合、そのコマンドはプロファイルシェルで入力する必要があります。特権付きのコマンドを通常のシェルで入力すると、そのコマンドは特権では実行されません。

次の例で、jdoe ユーザーは、役割 objadminを引き受けることができます。objadmin 役割には、Object Access Management 権利プロファイルが含まれます。この権利プロファイルによって、objadmin 役割は objadmin が所有しないファイルに関するアクセス権を変更することができます。

次の例で、jdoe は、useful.script ファイルに関するアクセス権を変更することができません。

jdoe% ls -l useful.script
-rw-r--r--  1 aloe  staff  2303 Apr 10 10:10 useful.script
jdoe% chown objadmin useful.script
chown: useful.script: Not owner
jdoe% ppriv -eD chown objadmin useful.script
chown[11444]: missing privilege "file_chown" 
            (euid = 130, syscall = 16) needed at ufs_setattr+0x258
chown: useful.script: Not owner

jdoe が objadmin 役割を引き受けると、ファイルに関するアクセス権が変更されます。

jdoe% su - objadmin
Password: <Type objadmin password>
$ ls -l useful.script
-rw-r--r--  1 aloe  staff  2303 Apr 10 10:10 useful.script
$ chown objadmin useful.script
$ ls -l useful.script
-rw-r--r--  1 objadmin  staff  2303 Apr 10 10:10 useful.script
$ chgrp admin useful.script
$ ls -l objadmin.script
-rw-r--r--  1 objadmin  admin  2303 Apr 10 10:11 useful.script

例 11–5 `root` ユーザーが所有するファイルの変更

この例では、特権エスカレーションに対する保護について説明します。詳細については、「特権エスカレーションの防止」を参照してください。ファイルは、root ユーザーが所有します。権限の弱い objadmin 役割ではファイルの所有を変更するためにはすべての特権が必要なので、処理は失敗します。

jdoe% su - objadmin
Password: <Type objadmin password>
$ cd /etc; ls -l system
-rw-r--r--  1 root  sys   1883 Oct 10 10:20 system
$ chown objadmin system
chown: system: Not owner
$ ppriv -eD chown objadmin system
chown[11481]: missing privilege "ALL" 
     (euid = 101, syscall = 16) needed at ufs_setattr+0x258
chown: system: Not owner

特権をコマンドに追加する方法

コマンドを権利プロファイルに追加するときは、特権をコマンドに追加します。特権によって権利プロファイルを含む役割は管理コマンドを実行することができるようになりますが、ほかのスーパーユーザー機能は与えられません。

始める前に

コマンドまたはプログラムは、特権を認識できる必要があります。詳細については、「プロセスが特権を取得する方法」を参照してください。

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、「RBAC の構成 (作業マップ)」を参照してください。

Solaris 管理コンソールの GUI を開きます。

手順については、「Solaris 管理コンソールで役割を引き受ける方法」を参照してください。

権利ツールを使用して、該当するプロファイルを更新します。

含めるコマンドを選択します。含めるコマンドごとに、コマンドが必要とする特権を追加します。

注意 –
権利プロファイルにコマンドを含め、含めたコマンドに特権を追加すると、コマンドは、プロファイルシェルで実行されたときに、それらの特権で実行されます。

プロファイルの順序は重要です。プロファイルシェルで、コマンドまたはアクションは、アカウントのプロファイルリストの最初のプロファイルで指定されたセキュリティー属性で実行されます。たとえば、chgrp コマンドが特権付きの Object Access Management 権利プロファイルに含まれていて、Object Access Management が chgrp が検出される最初のプロファイルである場合、chgrp コマンドは Object Access Management プロファイルで指定された特権で実行されます。

特権をユーザーまたは役割に割り当てる方法

特定の特権を持つ何人かのユーザーを常に信頼する場合があります。システムのごく一部に影響を与える非常に限定的な特権をユーザーに割り当てることをお勧めします。特権を直接割り当てることによる影響の詳細については、「セキュリティー属性を直接割り当てる場合に考慮すべきセキュリティー事項」を参照してください。

次の手順により、ユーザー jdoe は高分解能タイマーを使用できるようになります。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

高分解能時間に影響を与える特権を、ユーザーの最初の継承可能な特権セットに追加します。
$ usermod -K defaultpriv=basic,proc_clock_highres jdoe
既存の値が defaultpriv キーワードの値で置き換えられます。このため、ユーザーが basic 特権を保持するために、値 basic を指定する必要があります。デフォルトの構成では、すべてのユーザーが基本特権を保持します。

結果として生じる user_attr エントリを確認します。

$ grep jdoe /etc/user_attr
jdoe::::type=normal;defaultpriv=basic,proc_clock_highres

例 11–6 システム時間を構成するための特権付き役割の作成

この例では、システム上の時間の処理を唯一のタスクとする役割を作成します。

$ /usr/sadm/bin/smrole -D nisplus:/examplehost/example.domain \
-r primaryadm -l <Type primaryadm password> \
add -- -n clockmgr \
-c "Role that sets system time" \
-F "Clock Manager" \
-s /bin/pfksh \
-u 108 \
-P <Type clockmgr password> \
-K defaultpriv=basic,proc_priocntl,sys_cpu_config,
proc_clock_highres,sys_time

-K 行は、表示の都合上、折り返して記載されています。

役割がローカルに作成される場合、その役割に対する user_attr エントリは次のようになります。

clockmgr:::Role that sets system time:
type=role;defaultpriv=basic,proc_priocntl,sys_cpu_config,
proc_clock_highres,sys_time

ユーザーまたは役割の特権を制限する方法

基本セットを削減するか、制限セットを削減することにより、ユーザーまたは役割が使用可能な特権を制限することができます。このような制限は意図しない面に影響を与える可能性があるため、この方法でユーザーの特権を制限するにはそれ相応の理由が必要です。

注意 –

ユーザーに対して基本セットまたは制限セットが変更されたユーザーの機能を入念にテストしてください。

基本セットがデフォルトより少ないと、ユーザーはシステムを使用できない可能性があります。
制限セットがすべての特権より少ないと、実効 UID=0 で実行する必要があるプロセスが失敗する可能性があります。

ユーザーの基本セットおよび制限セットの特権を判断します。

手順については、「プロセスの特権を判断する方法」を参照してください。

(省略可能) 基本セットから特権の 1 つを削除します。
$ usermod -K defaultpriv=basic,!priv-name username
proc_session 特権を削除することにより、ユーザーは現在のセッション外のプロセスを検査できなくなります。file_link_any 特権を削除することにより、ユーザーは所有していないファイルへのハードリンクを作成できなくなります。

注意 –
proc_fork 特権または proc_exec 特権は削除しないでください。これらの特権がないと、ユーザーはシステムを使用することができません。実際のところ、これらの 2 つの特権は、ほかのプロセスに対してfork() または exec() すべきでないデーモンからそれ相応の理由がある場合にのみ削除されます。

(省略可能) 制限セットから特権の 1 つを削除します。
$ usermod -K limitpriv=all,!priv-name username

username の機能をテストします。

username としてログインし、username がシステム上で実行する必要のあるタスクを実行してみます。

例 11–7 ユーザーの制限セットからの特権の削除

次の例では、jdoe の最初のログインから開始されるすべてのセッションで sys_linkdir 特権を使用できないようにします。すなわち、ユーザーは、su コマンドを実行したあとでも、ディレクトリへのハードリンクを作成することやディレクトリへのリンクを解除することができません。

$ usermod -K limitpriv=all,!sys_linkdir jdoe
$ grep jdoe /etc/user_attr
jdoe::::type=normal;defaultpriv=basic;limitpriv=all,!sys_linkdir

例 11–8 ユーザーの基本セットからの特権の削除

次の例では、jdoe の最初のログインから開始されるすべてのセッションで proc_session 特権を使用できないようにします。すなわち、ユーザーは、su コマンドを実行したあとでも、ユーザーのセッション外のいずれのプロセスも検査できません。

$ usermod -K defaultpriv=basic,!proc_session jdoe

$ grep jdoe /etc/user_attr
jdoe::::type=normal;defaultpriv=basic,!proc_session;limitpriv=all

特権付きのコマンドを含むシェルスクリプトの実行方法

注 –

継承された特権を持つコマンドを実行するシェルスクリプトを作成するときは、割り当てる特権付きのコマンドを該当する権利プロファイルに含める必要があります。

1 行目は、スクリプトを /bin/pfsh またはほかのプロファイルシェルで開始します。
#!/bin/pfsh # Copyright (c) 2009 by Sun Microsystems, Inc.

スクリプトのコマンドが必要とする特権を判断します。
% ppriv -eD script-full-path

Solaris 管理コンソールの GUI を開きます。

手順については、「Solaris 管理コンソールで役割を引き受ける方法」を参照してください。Primary Administrator など、権利プロファイルを作成することができる役割を選択します。

権利ツールを使用して、該当するプロファイルを作成または更新します。

スクリプトを選択し、実行に特権が必要なシェルスクリプトのコマンドをそれぞれ権利プロファイルに含めます。含めるコマンドごとに、コマンドが必要とする特権を追加します。

注意 –
権利プロファイルの順序は重要です。プロファイルシェルは、プロファイルリストのコマンドの最初のインスタンスを実行します。たとえば、chgrp コマンドが Object Access Management 権利プロファイルに含まれていて、Object Access Management が chgrp が検出される最初のプロファイルである場合、chgrp コマンドは Object Access Management プロファイルで指定された特権で実行されます。

権利プロファイルを役割に追加し、その役割をユーザーに割り当てます。

ユーザーは、プロファイルを実行するために、その役割を引き受け、役割のプロファイルシェルでスクリプトを実行します。

特権の判断 (作業マップ)

次の作業マップでは、割り当てられた特権を使用する手順を示します。

作業	説明	参照先
任意のシェルでユーザーとしての特権を表示します	直接割り当てられた特権を示します。プロセスのすべてはこれらの特権で実行されます。	「直接割り当てられた特権を判断する方法」
特権で実行できるコマンドを判断します	権利プロファイルで特権が実行可能プログラムに割り当てられているとき、その実行可能プログラムはプロファイルシェルで入力する必要があります。	「実行可能な特権付きコマンドを判断する方法」
役割が特権で実行できるコマンドを判断します	役割が特権で実行できるコマンドを判断する役割を引き受けます。	「役割が実行可能な特権付きコマンドを判断する方法」

割り当てられた特権の判断

ユーザーに特権が直接割り当てられるとき、その特権はすべてのシェルで有効になります。ユーザーに特権が直接割り当てられないとき、ユーザーはプロファイルシェルを開く必要があります。たとえば、特権が割り当てられているコマンドがユーザーの権利プロファイルのリスト内の権利プロファイルに含まれるとき、ユーザーはプロファイルシェルでコマンドを実行する必要があります。

直接割り当てられた特権を判断する方法

次の手順は、特権が直接割り当てられたかどうかを判断する方法です。

注意 –

直接割り当てられた特権を不適切に使用すると、無意識のうちにセキュリティーを侵害する可能性があります。詳細については、「セキュリティー属性を直接割り当てる場合に考慮すべきセキュリティー事項」を参照してください。

プロセスが使用可能な特権を一覧表示します。

手順については、「プロセスの特権を判断する方法」を参照してください。

任意のシェルでアクションを起動し、コマンドを実行します。

有効なセットに一覧表示されている特権は、セッション全体を通して有効です。基本セットに加えて特権を直接割り当てた場合、その特権は有効なセットに一覧表示されます。

例 11–9 直接割り当てられた特権の判断

直接特権が割り当てられた場合、基本セットにはデフォルトの基本セットより多くの特権が含まれます。この例では、ユーザーは常時 proc_clock_highres 特権にアクセスできます。

% /usr/ucb/whoami
jdoe
% ppriv -v $$
1800:   pfksh
flags = <none>
        E: file_link_any,…,proc_clock_highres,proc_session
        I: file_link_any,…,proc_clock_highres,proc_session
        P: file_link_any,…,proc_clock_highres,proc_session
        L: cpc_cpu,dtrace_kernel,dtrace_proc,dtrace_user,…,sys_time
% ppriv -vl proc_clock_highres
        Allows a process to use high resolution timers.

例 11–10 役割に直接割り当てられた特権の判断

役割では、管理シェルまたはプロファイルシェルが使用されます。役割を引き受けるユーザーは、役割のシェルを使用して、役割に直接割り当てられている特権を一覧表示することができます。次の例では、役割 realtime に日時のプログラムを処理する特権が直接割り当てられます。

% su - realtime
Password: <Type realtime password>
$ /usr/ucb/whoami
realtime
$ ppriv -v $$
1600:   pfksh
flags = <none>
        E: file_link_any,…,proc_clock_highres,proc_session,sys_time
        I: file_link_any,…,proc_clock_highres,proc_session,sys_time
        P: file_link_any,…,proc_clock_highres,proc_session,sys_time
        L: cpc_cpu,dtrace_kernel,dtrace_proc,dtrace_user,…,sys_time

実行可能な特権付きコマンドを判断する方法

ユーザーに直接特権が割り当てられていないとき、ユーザーは権利プロファイルによって特権付きコマンドにアクセスすることができます。権利プロファイルのコマンドは、プロファイルシェルで実行する必要があります。

始める前に

Solaris 管理コンソールに対して認証を行うユーザーまたは役割は、solaris.admin.usermgr.read 承認を得る必要があります。Basic Solaris User 権利プロファイルには、この承認が含まれます。

割り当てられている権利プロファイルを判断します。

$ /usr/sadm/bin/smuser list -- -n username -l

Authenticating as user: admin
… Please enter a string value for: password :: 
…
User name:      username
User ID (UID):  130
Primary group:  staff
Secondary groups: 
Comment: object mgt jobs
Login Shell: /bin/sh
Home dir server: system
Home directory: /export/home/username
AutoHome setup: True
Mail server: system
Rights: Object Access Management
Assigned Roles:

「Rights:」で始まる行を探します。

「Rights」行には、直接割り当てた権利プロファイルの名前が一覧表示されます。

exec_attr データベースの権利プロファイルの名前を見つけます。

$ cd /etc/security
$ grep "Object Access Management" exec_attr 
Object Access Management:solaris:cmd:::/usr/bin/chgrp:privs=file_chown
Object Access Management:solaris:cmd:::/usr/bin/chown:privs=file_chown
Object Access Management:suser:cmd:::/usr/bin/chgrp:euid=0
Object Access Management:suser:cmd:::/usr/bin/chmod:euid=0
…

特権が追加されたコマンドは、solaris ポリシーエントリの最後に一覧表示されます。

プロファイルシェルで、特権を必要とするコマンドを入力します。

コマンドを通常のシェルで入力すると、そのコマンドは特権で実行されず、失敗します。
% pfsh $

例 11–11 プロファイルシェルでの特権付きコマンドの実行

次の例で、ユーザー jdoe は、通常のシェルからはファイルに関するグループアクセス権を変更できません。しかし、jdoe は、プロファイルシェルでコマンドを入力すると、グループアクセス権を変更できます。

% whoami
jdoe
% ls -l useful.script
-rwxr-xr-- 1 nodoe eng 262 Apr 2 10:52 useful.script
chgrp staff useful.script
chgrp: useful.script: Not owner
% pfksh
$ /usr/ucb/whoami
jdoe
$ chgrp staff useful.script
$ chown jdoe useful.script
$ ls -l useful.script
-rwxr-xr-- 1 jdoe staff 262 Apr 2 10:53 useful.script

役割が実行可能な特権付きコマンドを判断する方法

役割は、特権が割り当てられたコマンドを含む権利プロファイルによって、特権付きコマンドにアクセスすることができます。特権付きコマンドに対するアクセス権をユーザーに与える最も安全な方法は、役割をコマンドに割り当てることです。ユーザーは、役割を引き受けると、その役割の権利プロファイルに含まれるすべての特権付きコマンドを実行することができます。

始める前に

引き受けることができる役割を判断します。

$ /usr/sadm/bin/smuser list -- -n username -l
Authenticating as user: primadmin
…
User name:      username
User ID (UID):  110
Primary group:  staff
Secondary groups: 
Comment: Has admin roles
Login Shell: /bin/sh
…
Rights: 
Assigned Roles: primadmin, admin

「Assigned Roles:」で始まる行を探します。

「Assigned Roles」行には、引き受けることができる役割が一覧表示されます。

役割の 1 つに含まれる権利プロファイルを判断します。

$ /usr/sadm/bin/smuser list -- -n admin -l
Authenticating as user: primadmin
…
User name:      admin
User ID (UID):  101
Primary group:  sysadmin
Secondary groups:
Comment: system administrator
Login Shell: /bin/pfksh
…
Rights: System Administrator
Assigned Roles:

「Rights:」行で役割の権利プロファイルの名前を探します。

prof_attr データベースの権利プロファイルを見つけます。

System Administrator プロファイルはプロファイルの集合なので、System Administrator プロファイルのプロファイルを一覧表示する必要があります。

$ cd /etc/security
$ grep "System Administrator" prof_attr 
System Administrator:::Can perform most non-security administrative
tasks:profiles=Audit Review,Printer Management,Cron Management,
Device Management,File System Management,Mail Management,Maintenance
and Repair,Media Backup,Media Restore,Name Service Management,Network
Management,Object Access Management,Process Management,Software
Installation,User Management,All;help=RtSysAdmin.html

権利プロファイルごとに、exec_attr データベースの権利プロファイルを見つけます。

たとえば、Network Management プロファイルは、System Administrator プロファイルの補助プロファイルです。Network Management プロファイルには、多数の特権付きコマンドが含まれます。

$ cd /etc/security
$ grep "Network Management" exec_attr 
Network Management:solaris:cmd:::/usr/sbin/ifconfig:privs=sys_net_config
Network Management:solaris:cmd:::/usr/sbin/route:privs=sys_net_config
…

コマンドおよびそれらに割り当てられた特権は、solaris ポリシーエントリの最後の 2 つのフィールドです。役割のプロファイルシェルで、これらのコマンドを実行することができます。

例 11–12 役割での特権付きコマンドの実行

ユーザーが役割を引き受けると、シェルはプロファイルシェルになります。したがって、コマンドは、コマンドに割り当てられた特権で実行されます。次の例で、admin 役割は、 useful.script ファイルに関する権利を変更することができます。

% whoami
jdoe
% ls -l useful.script
-rwxr-xr-- 1 elsee eng 262 Apr 2 10:52 useful.script
chgrp admin useful.script
chgrp: useful.script: Not owner
% su - admin
Password: <Type admin password>
$ /usr/ucb/whoami
admin
$ chgrp admin useful.script
$ chown admin useful.script
$ ls -l useful.script
-rwxr-xr-- 1 admin admin 262 Apr 2 10:53 useful.script

第 12 章特権 (参照)

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

特権の使用方法については、第 11 章特権 (手順)を参照してください。概要については、「特権 (概要)」を参照してください。

特権を扱うための管理コマンド

次の表では、特権を扱うために使用可能なコマンドを一覧表示します。

表 12–1 特権を扱うためのコマンド


目的	コマンド	マニュアルページ
プロセスの特権を検査します	`ppriv -v` `pid`	ppriv(1)
プロセスの特権を設定します	`ppriv -s` `spec`
システム上の特権を一覧表示します	`ppriv -l`
特権とその説明を一覧表示します	`ppriv -lv` `priv`
特権の障害をデバッグします	`ppriv -eD` `failed-operation`
特権を新しいローカルユーザーに割り当てます	`useradd`	useradd(1M)
特権を既存のローカルユーザーに追加します	`usermod`	usermod(1M)
特権をネームサービスのユーザーに割り当てます	`smuser`	smuser(1M)
特権を新しいローカル役割に割り当てます	`roleadd`	roleadd(1M)
特権を既存のローカル役割に追加します	`rolemod`	rolemod(1M)
特権をネームサービスの役割に割り当てます	`smrole`	smrole(1M)
デバイスポリシーを表示します	`getdevpolicy`	getdevpolicy(1M)
デバイスポリシーを設定します	`devfsadm`	devfsadm(1M)
オープンデバイスでのデバイスポリシーを更新します	`update_drv -p` `policy driver`	update_drv(1M)
デバイスポリシーをデバイスに追加します	`add_drv -p` `policy driver`	add_drv(1M)

コマンド、ユーザー、および役割への特権の割り当ては、Solaris 管理コンソールの GUI で行うことをお勧めします。詳細については、「Solaris 管理コンソールで役割を引き受ける方法」を参照してください。

特権情報が含まれるファイル

次のファイルには、特権に関する情報が含まれます。

表 12–2 特権情報が含まれるファイル


ファイルおよびマニュアルページ	キーワード	説明
`/etc/security/policy.conf` policy.conf(4)	`PRIV_DEFAULT`	システムに対する特権の継承可能なセット
`/etc/security/policy.conf` policy.conf(4)	`PRIV_LIMIT`	システムに対する特権の制限セット
`/etc/user_attr` user_attr(4)	ユーザーまたは役割のエントリでの `defaultpriv` キーワード値は通常、Solaris 管理コンソールの GUI で設定します	ユーザーまたは役割に対する特権の継承可能なセット
`/etc/user_attr` user_attr(4)	ユーザーまたは役割のエントリでの `limitpriv` キーワード値は通常、Solaris 管理コンソールの GUI で設定します	ユーザーまたは役割に対する特権の制限セット
`/etc/security/exec_attr` exec_attr(4)	プロファイルのコマンドに対するエントリでの `privs` キーワードコマンドに対するポリシーは `solaris` である必要があります	権利プロファイルのコマンドに割り当てられた特権の一覧
`syslog.conf` syslog.conf(4)	デバッグメッセージ用のシステムログファイル `priv.debug` エントリで設定されるパス	特権デバッグログ

注 –

exec_attr および user_attr データベースは直接編集しないでください。特権を管理するには、Solaris 管理コンソールまたは smuser などのコマンドを使用します。詳細は、smc(1M) および smuser(1M) のマニュアルページを参照してください。手順については、「特権の管理 (作業マップ)」を参照してください。

特権と監査

特権の使用は監査することができます。プロセスで特権が使用される場合は常に、upriv 監査トークン内の監査トレールに特権の使用が記録されます。特権の名前がレコードに含まれる場合、テキスト形式が使用されます。次の監査イベントにより、特権の使用が記録されます。

AUE_SETPPRIV 監査イベント – 特権セットが変更されたときに監査記録を生成します。AUE_SETPPRIV 監査イベントは pm クラスにあります。
AUE_MODALLOCPRIV 監査イベント – カーネル外から特権が追加されたときに監査記録を生成します。AUE_MODALLOCPRIV 監査イベントは ad クラスにあります。
AUE_MODDEVPLCY 監査イベント – デバイスポリシーが変更されたときに監査記録を生成します。AUE_MODDEVPLCY 監査イベントは ad クラスにあります。
AUE_prof_cmd 監査イベント – コマンドがプロファイルシェルで実行されたときに監査記録を生成します。AUE_prof_cmd 監査イベントは as および ua 監査クラスにあります。特権の名前は、監査レコードに含まれます。

基本セットに含まれる特権が正常に使用される場合は、監査されません。ユーザーの基本セットから削除された基本特権の使用を試みる場合、監査されます。

特権エスカレーションの防止

Solaris カーネルは特権エスカレーションを防ぎます。特権エスカレーションとは、特権によってプロセスがその範囲を越えたことを行えるようになることです。プロセスが特権の範囲を越えることを防ぐために、一定のシステム変更を行うには特権の完全セットが必要です。たとえば、root (UID=0) が所有するファイルまたはプロセスは、特権の完全セットを備えたプロセスによってのみ変更できます。root ユーザーは、特権がなくても root が所有するファイルを変更することができます。しかし、root ユーザー以外は、root が所有するファイルを変更するにはすべての特権が必要です。

同様に、デバイスへのアクセスを提供する操作には、有効なセットのすべての特権が必要です。

file_chown_self および proc_owner は、特権エスカレーションが生じやすい特権です。file_chown_self は、プロセスがそのファイルを渡せるようにする特権です。proc_owner は、プロセス自身が所有しないプロセスを調査できるようにする特権です。

file_chown_self 特権は、rstchown システム変数によって制限されます。rstchown 変数が 0 に設定されると、file_chown_self 特権は、システムおよび全ユーザーの初期の継承可能セットから削除されます。rstchown システム変数の詳細については、chown(1) のマニュアルページを参照してください。

file_chown_self 特権のコマンドへの割り当て、プロファイルへの配置、およびプロファイルシェルで使用するための役割への割り当ては最も安全に行います。

proc_owner 特権は、プロセス UID を 0 にするには十分ではありません。任意の UID のプロセスを UID=0 にするには、すべての特権が必要です。proc_owner 特権はシステム上のすべてのファイルに無制限の読み取りアクセス権を与えるので、この特権のコマンドへの割り当て、プロファイルへの配置、およびプロファイルシェルで使用するための役割への割り当ては最も安全に行います。

注意 –

file_chown_self 特権または proc_owner 特権がユーザーの初期の継承可能セットに含まれるようにユーザーのアカウントを変更することができます。これらの強力な特権を任意のユーザー、役割、またはシステムに対する特権の継承可能セットに配置するには、セキュリティー上の相応の理由がなければなりません。

デバイスに対する特権エスカレーションを防ぐ方法の詳細については、「特権とデバイス」を参照してください。

レガシーアプリケーションと特権モデル

レガシーアプリケーションに対応するために、特権の実装はスーパーユーザーモデルと特権モデルで動作します。カーネルは、プログラムが特権で動作するように設計されていること示す PRIV_AWARE フラグを自動的に追跡します。特権を認識しない子プロセスについて検討してください。親プロセスから継承された特権はどれも、子の許可されたセットおよび有効なセットで使用可能です。子プロセスで UID が 0 に設定されていると、子プロセスが完全なスーパーユーザー機能を持たない場合があります。プロセスの有効なセットおよび許可されたセットは、子の制限セットの特権に限定されます。このように、特権を認識するプロセスの制限セットによって、特権を認識しない子プロセス root 特権が制限されます。

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

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

RBAC の新機能

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

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

Solaris RBAC の要素と基本概念

図 8–1 Solaris RBAC 要素の動作

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

RBAC の承認

承認と特権

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

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

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

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

RBAC の権利プロファイル

RBAC の役割

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

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

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

特権 (概要)

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

特権の種類

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

特権とシステム資源

特権の実装方法

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

特権の割り当て

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

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

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

特権とデバイス

特権とデバッグ

第 9 章 役割によるアクセス制御の使用 (手順)

RBAC の使用 (作業マップ)

RBAC の構成 (作業マップ)

RBAC の構成

RBAC の実装を計画する方法

GUI を使用して役割の作成および割り当てを行う方法

始める前に

例 9–1 System Administrator 権利プロファイルの役割の作成

例 9–2 Operator 権利プロファイルの役割の作成

例 9–3 セキュリティー関連の権利プロファイルの役割の作成

例 9–4 適用範囲が制限された権利プロファイルの役割の作成

例 9–5 ユーザーの役割の割り当ての変更

注意事項

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

始める前に

例 9–6 smrole コマンドを使用してカスタムの Operator 役割を作成する

役割をローカルユーザーに割り当てる方法

始める前に

例 9–7 コマンド行からのローカル役割の作成と割り当て

役割を監査する方法

root ユーザーを役割にする方法

始める前に

例 9–8 root 役割がシステムの構成に使用されることを防ぐ

例 9–9 root 役割を変更して root ユーザーに戻す

注意事項

役割の使用 (作業マップ)

役割の使用

端末ウィンドウで役割を引き受ける方法

始める前に

例 9–10 Primary Administrator 役割を引き受ける

例 9–11 root 役割を引き受ける

例 9–12 System Administrator 役割を引き受ける

Solaris 管理コンソールで役割を引き受ける方法

始める前に

RBAC の管理(作業マップ)

RBAC の管理

役割のパスワードを変更する方法

始める前に

例 9–13 passwd コマンドによるローカル役割のパスワードの変更

例 9–14 LDAP リポジトリ内の役割のパスワードを変更する

例 9–15 smrole modify コマンドによる役割のパスワードの変更

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

始める前に

例 9–16 rolemod コマンドによるローカル役割のプロパティーの変更

例 9–17 smrole modify コマンドによるローカル役割のプロパティーの変更

例 9–18 smrole modify コマンドによるドメインの役割の変更

権利プロファイルを作成または変更する方法

始める前に

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

第 9 章役割によるアクセス制御の使用 (手順)

例 9–6 `smrole` コマンドを使用してカスタムの Operator 役割を作成する

`root` ユーザーを役割にする方法

例 9–8 `root` 役割がシステムの構成に使用されることを防ぐ

例 9–9 `root` 役割を変更して `root` ユーザーに戻す

例 9–11 `root` 役割を引き受ける

例 9–13 `passwd` コマンドによるローカル役割のパスワードの変更

例 9–15 `smrole modify` コマンドによる役割のパスワードの変更

例 9–16 `rolemod` コマンドによるローカル役割のプロパティーの変更

例 9–17 `smrole modify` コマンドによるローカル役割のプロパティーの変更

例 9–18 `smrole modify` コマンドによるドメインの役割の変更

例 9–22 `smuser` コマンドを使用したユーザーの RBAC プロパティーの変更

第 10 章役割によるアクセス制御 (参照)

`user_attr` データベース

`auth_attr` データベース

`prof_attr` データベース

`exec_attr` データベース

`policy.conf` ファイル

第 11 章特権 (手順)

例 11–3 特権の使用を検査するための `truss` コマンドの使用

例 11–4 プロファイルシェルで特権の使用を検査するための `ppriv` コマンドの使用

例 11–5 `root` ユーザーが所有するファイルの変更

第 12 章特権 (参照)