Trusted Solaris 管理の手順

パート II ユーザー、役割、プロファイル、メールの管理

このパートでは、ユーザーアカウントや役割アカウントの管理、メール管理、実行プロファイル管理に関する概要と、それらの操作手順を説明します。以下の 6 つの章があります。

第 3 章「ユーザーアカウントの管理」には次の項目があります。

第 4 章「役割の管理」には次の項目があります。

第 5 章「ユーザーマネージャを使ったアカウントの設定」には次の項目があります。

第 6 章「メール管理」には次の項目があります。

第 7 章「ユーザーマネージャ用データ収集ワークシート」では、ユーザーアカウントや役割アカウントの設定に必要なデータを収集するためのワークシートを紹介します

第 8 章「ユーザーおよび役割のための実行プロファイルの管理」には次の項目があります。

第 3 章ユーザーアカウントの管理

Trusted Solaris システムの設定時には、2 つのユーザーアカウントが設定されており、これらのアカウントは 2 つの管理的役割になり「インストールチーム」として共同作業を行います。この章では、これ以外のすべてのユーザーアカウントの設定に必要なタスクの実行方法のうち、マニュアル『Trusted Solaris のインストールと構成』では述べられていないものを説明します。また、ユーザーアカウントの管理に必要となる前提知識も紹介します。この章には次の項目があります。

この章では次の操作手順を説明します。

アカウント設定のための前提条件

ユーザーアカウントを設定する場合、以下の前提条件が満たされていることを確認してください。

以下のものが設定されていること
- NIS+ マスター
- 分散システム用のインストールサーバー、ブートサーバー
- 各ユーザーの主ワークステーション
- 各ユーザーのホームディレクトリサーバー
- 各ユーザーの監査サーバー
- ユーザーの主ワークステーションに任意のサービスを提供する他のワークステーションやサーバー (メールサーバーなど)

ユーザーアカウント設定の前に決定すべきこと

アカウント設定を始める前に、以下の事項を決定するようにしてください。これらはアカウント設定に影響を及ぼします。

以下の事項の中には、標準の Solaris や他の UNIX マシンのネットワークをインストールする場合に決定しなければならない事項と同じものがあります。しかし、ここでは Trusted Solaris 環境を構成することが目的であるため、以下の事項については、自サイトのセキュリティ要件やその他の特殊な要件を十分考慮に入れて決定してください。

ユーザーのログイン名に関する規則の決定

Trusted Solaris では、ユーザーのログイン名は 8 文字と決められています。ログイン名の命名規則の例としては、ファーストネームの後にラストネームのイニシャルを付ける、またはラストネームの後にファーストネームのイニシャルを付けるようにすることなどが挙げられます。

デフォルトのグループの確認、グループを追加するかどうかの決定

新しいグループを定義するには、管理者役割はアプリケーションマネージャの「Solstice 管理 (Solstice_Admin)」フォルダにあるグループマネージャを使います。 Trusted Solaris 版のグループ管理で新しく追加されたフィールドはありませんので、必要に応じて、マニュアル『Solstice AdminSuite 2.1 ユーザーズガイド』を参照してください。

自サイトのセキュリティポリシーに応じて以下の事項を決定し、Trusted Solaris ユーザー管理に必要な情報を収集してください。

パスワード生成の基本的な方法 (自動または手動) の選択

自サイトで、受信者の最下位機密ラベルよりも低い機密ラベルでメールが送られて来た場合の処理方法の決定

sendmail(1M) の設定ファイルである sendmail.cf 内に指定する Trusted Solaris 特有の機密性オプションとして、自サイトのセキュリティポリシーに合った適切な値が設定されるようにしてください。詳細は、第 6 章「メール管理」の「受信者の最下位ラベルよりも低いラベルのメールに関する Sendmail の処理」および「ユーザーの最下位ラベルよりも低いラベルのメールに関するメール配送オプションを設定するには」を参照してください。

以下の情報の収集

使用可能な実行プロファイルの一覧

システムに添付されている実行プロファイルは、ユーザーがその変更や拡張を行わないことを前提に設計されています。実行プロファイルの各役割への割り当てとその目的、すべてのコマンド、アクション、各プロファイルに割り当てられている承認の一覧については、付録 A 「プロファイル概要テーブル」を参照してください。

特殊な要件を持つサイトでは、セキュリティ管理者役割が追加のプロファイルを新規作成できます。自サイトに別の実行プロファイルが存在する場合は、それに関する内部文書を参照してください。
使用可能な管理役割および非管理役割の一覧

システムに設定されているデフォルトの役割は、ユーザーがその変更や拡張を行わないことを前提に設計されています。セキュリティ管理者が役割の追加や再設定を行えます。ユーザー用に定義された役割の説明については、自サイトの内部文書を参照してください。
アカウントを必要とする自サイトの社員の名前の一覧。および、各アカウントに割り当てる責任、役割、認可上限、最下位ラベルの一覧。

上記の情報を得るには、自サイトの社員の実施する業務データの収集と、社員に割り当てる認可上限、最下位ラベル、プロファイルについての決定が必要になります。さらに、どの社員が管理役割になれるようにするかの決定も必要です。政府機関の場合、各職員に与えられている職務上の認可上限を検討し、各職員がなることのできる役割と、作業時に使用するラベルを決定することも必要となるでしょう。

作成予定のユーザーアカウントには、ネットワーク上のどことも重複しない一意のユーザー名と UID を割り当てる。

作成予定の各グループには、ネットワーク上のどのグループとも重複しない一意の GID を割り当てる。

ユーザーのログイン時に自動的にシステムがシェル初期化ファイルを読み取るようにするかどうか、これらのファイルの初期内容を変更するかどうかを決定

詳細は、「Trusted Solaris システムにおけるスタートアップファイルの管理」を参照してください。

特定のユーザー用に作成された $HOME ディレクトリ内で最初に作成された SLD 内にあるファイルのうち、どのファイルを 2 番目以降に作成される SLD にコピーまたはリンクするかを決定し、必要なら、/etc/skel (またはその他のスケルトンディレクトリ) 内の .copy_files および .link_files を変更する。

詳細は、「ホームディレクトリ内の複数の SLD にスタートアップファイルを配置するには」を参照してください。

アカウントを閉じる前の 1 回のログイン試行の間、パスワードの入力ミスを許す最大回数をそのままにしておくか、変更するかの決定。

1 回のログイン試行の間、ある一定回数以上のパスワードの入力ミスを続けるとユーザーアカウントを閉じてしまう Trusted Solaris の機能の説明に関しては、第 2 章「その他の作業と操作手順」を参照してください。「パスワード入力ミス許容回数の最大値の変更」には、アカウントの閉鎖につながる入力失敗回数の最大値の設定変更をセキュリティ管理者がどのようにして行うかの説明があります。

リモートログインの管理

Trusted Solaris と Solaris の両方において、rlogin コマンドの使用が許可されている任意のユーザーは、リモートホスト上のそのユーザーのホームディレクトリにある /etc/hosts.equiv ファイルまたは .rhosts ファイルのどちらかにユーザー名またはリモートログインを行おうとしているホストが存在している場合、パスワードを指定せずにリモートホストにアクセスできます。必要であれば、デフォルトシステムのセキュリティ管理者役割は「管理エディタ (Admin Editor)」アクションを使って rhosts ファイルにエントリを作成し、ユーザーがパスワードなしにログインできるように設定できます。テキストエディタを使うことができる任意のユーザーは、そのユーザーのホームディレクトリにある hosts.equiv ファイルに同様なエントリを作成できます。

2 つの Trusted Solaris ホスト間でリモートログインが上記の状態で許可されている場合、リモートログインは現在のログインセッションの拡張であると考えられるため、承認は必要ありません。

また、ユーザーが CDE の「ログイン (Login)」ダイアログボックスから「リモートログイン (Remote Login)」オプションを使う場合も、承認は必要ありません。

その他のすべてのリモートログインでは、「リモートログイン」承認が必要です。

hosts.equiv ファイルまたは .rhosts ファイルにユーザー名またはユーザーのホストが指定されていない場合、rlogin を使うと、ユーザーはパスワードの入力を求められます。
telnet や ftp などのリモートアクセスコマンドを使うとき、ユーザーはパスワードの入力を求められます。

「リモートログイン」承認を含む既存のプロファイルを割り当てたり、新しいプロファイルを作成する方法については、「プロファイルを指定または変更するには」を参照してください。

ユーザー管理に関する責任の分割

この章では、ユーザーアカウントの管理に必要な前提知識を紹介します。この章には次のトピックがあります。

ユーザー管理 : 2 つの管理役割間での分割

デフォルトの Trusted Solaris システムでは、ユーザー管理作業は 2 人の人間が責任を持つものとして設定されているため、1 人の管理者がシステムに関する全体的な管理を受け持つことありません。しかし、このことは、複数の人間が任意の管理役割になれることを意味するため、管理者となるユーザーは、「2 人の人間」が責任を持つのではなく、あくまで「 2 つの役割」が責任を持つことを正確に理解しておく必要があります。

ユーザーアカウントを管理するための各種作業は、次の 2 つのデフォルト役割間で分割されます。

システム管理者 (admin)
セキュリティ管理者 (secadmin)

これら 2 つの管理的役割が持つデフォルトの実行プロファイルで、承認がどのように設定されているかにより、各役割が指定できるアカウントマネージャ内のフィールドの種類が決定されます。ユーザーマネージャに適用される承認については、「アカウント管理作業を行うための承認」を参照してください。

管理者役割の責任

管理者役割は、ユーザーアカウントに関するセキュリティ関係を除くすべての事項を指定することが認められています。これには次の事項が含まれます。

ユーザー ID
グループ ID
ホームディレクトリの場所
ユーザーのデフォルトのシェル

管理者役割に割り当てられる作業は、標準の UNIX システムにおけるシステム管理者 (スーパーユーザー) が行うタスクと同じものです。

セキュリティ管理者役割の責任

セキュリティ管理者は、ユーザーアカウントのセキュリティに関係するすべての事項を指定することが認められています。これには次の事項が含まれます。

パスワードの生成方法
パスワードの有効期間 (パスワードの変更が必要となる最小または最大経過日数、最長非使用日数、有効期限、警告の表示など)
ユーザーの最下位ラベル
ユーザーの認可上限
ユーザーのラベル表示(内部または外部)
ユーザーが機密ラベルを見ることができるようにするか
特定のユーザーを、分散システム上の他のユーザーよりも高い／低い度合いで監査するかどうか
ユーザーが持つ実行プロファイル
ユーザーがなれる役割
ワークステーションが指定の期間アイドル状態となった場合に取るべき処理

2 つの役割による分割管理を取らない場合

サイトによっては、ユーザー管理を 2 つの役割間で分割せず、必要に応じて管理役割を再設定したい場合もあるでしょう。このような場合については、第 4 章「役割の管理」の「2 つの役割による分割管理を取らない場合」を参照してください。

注 -

管理的役割を自サイトで再設定している場合、そのサイトのセキュリティ管理者は、各管理的役割にどのような責任や機能を割り当てているかを、管理者に通達しなければなりません。

アカウント管理作業を行うための承認

図 3-1 に、ユーザーアカウントや役割アカウントの追加に使用するユーザーマネージャの「ナビゲータ (追加)」メニューを示します。まだ、何の情報も指定されていないため、「ユーザー (User)」、「UID」、「コメント (Comment)」の各フィールドは空になっています。「コメント (Comment)」の下には 8 つのボタンがあり、各ボタンには、アカウントごとに指定する情報の種類を示すラベルが付けられています。各ボタンを押すと、それぞれに対応するダイアログボックスが表示され、そこで指定の情報を入力できます。これらのボタンを使って、ユーザーアカウントの追加または変更を行います。

図 3-1 ユーザーマネージャの「ナビゲータ」ダイアログボックス

各ボタンを使用するには、それぞれ承認が必要となります。これらの承認は、デフォルトの管理者とセキュリティ管理者の間で分割して割り当てられています。ここでも、2 人の人間によるアカウント管理が前提とする責務分割の原則が守られています。

注 -

管理役割がユーザーマネージャを起動した時に、グレー表示のボタンがあった場合、そのボタンを使用するのに必要となる承認が、現在の役割の持つ実行プロファイルに割り当てられていないことを意味します。

各ボタンの使用に必要となる承認と、各ボタンに対応するダイアログボックスをまとめたものを次の表に示します。

表 3-1 ユーザーマネージャの各ボタンに必要となる承認と、そのボタンを使って指定できる情報の種類


ボタン	承認名	デフォルトの役割	指定できる情報
`識別情報 (Identity)`	ユーザーの識別情報を設定 (set user identity)	`admin`	アカウント名、UID、主および追加 GID、コメント、シェル、アカウントの種類(一般ユーザー、管理役割、非管理役割) の設定
`パスワード(Password )`	ユーザーのパスワードを設定 (set user password)	`secadmin`	アカウント用のパスワードの設定、またはパスワードなしでアカウントを設定パスワードの有効期間(パスワードの変更が必要となる最小または最大経過日数、最長非使用、有効期限、警告の表示など) アカウントの状態(オープンまたはクローズ) NIS+ 資格テーブルを更新するかどうかの選択
`ホーム (Home)`	ホームディレクトリの属性を設定 (set home directory attributes)	`admin`	サーバー上のパス名にホームディレクトリを作成するかどうかの指定シェル初期化ファイルのパスの指定ホームディレクトリへのアクセス権の設定メールサーバーの指定ホームディレクトリを自動マウントするかどうかの選択
`ラベル (Labels)`	ユーザーのラベルを設定 (set user labels)	`secadmin`	認可上限と最下位ラベルの設定外部または内部ラベル表示の設定(管理ラベルの名前を表示する／表示しない) SLの表示／非表示の設定
`プロファイル (Profiles)`	ユーザーのプロファイルを設定 (set user profiles)	`secadmin`	ユーザープロファイルの選択 (ユーザーアカウントのみ)
`役割 (Roles)`	役割リストを設定 (set roles list)	`secadmin`	1つ以上の役割の選択(ユーザーアカウントのみ)
`アイドル (Idle)`	アイドル時間を設定 (set idle time)	`admin`	スクリーンがリスト上より選択された一定期間アイドル状態となった場合に取るべき処理の指定

Trusted Solaris システムにおけるスタートアップファイルの管理

Trusted Solaris システムでは、管理者はスタートアップファイルを設定する場合に、標準の UNIX システムでは問題にならないか、あてはまらないような点に関して考慮する必要があります。これは Trusted Solaris システムが次の特徴を持つためです。

ホームディレクトリが通常マルチレベルディレクトリ (MLD) となっている
コマンドへのアクセスを制限する目的でアカウントにプロファイルシェルを割り当てることができる
ワークスペース作成時に役割の代わりに .profile(4) ファイルから実行されるコマンドがプロファイルシェル機構により制限されない。

この節では、Trusted Solaris 環境におけるスタートアップファイルの管理方法の概要を説明し、実際のスタートアップファイルを設定するための操作手順を紹介します。csh(1)、pfsh(1M)、sh(1) のマニュアルページも参照してください。

スタートアップファイルのコマンドを読み込む、あるいは実行する、という意味合いで「読み取る (ソース)」という表現を使うことがよくあります (csh もドットスクリプトのコマンドを実行するのに内蔵のソースコマンドを持っています)。スタートアップファイルのセットは、起動されたときウィンドウシステムからソースされます。どのスタートアップファイルが読み込まれるかは、ユーザーアカウントが作成されたときにユーザーに割り当てられるログインシェルによって異なります。次の表を参照してください。

表 3-2 ログインシェルのタイプ別に、ウィンドウシステムによって読み込まれるスタートアップファイル


ログインシェル	スタートアップファイル
C シェル	`/etc/.login` と `$HOME/.login`
Bourne シェルまたは Korn シェル	`/etc/.profile` と `$HOME/.profile`
プロファイルシェル (Trusted Solaris システム内のみ)	`/etc/.profile` と `$HOME/.profile`

このほかに、cmdtool、shelltool、または dtterm のように端末エミュレータのシェルを起動するたびに読み込まれる別の一連のスタートアップファイルもあります (「シェル起動時にどのスタートアップファイルを読み込むかの制御」を参照してください)。

ウィンドウシステムにどのスタートアップファイルを読み取らせるかの制御

標準 CDE ウィンドウシステムと同様に、拡張 Trsuted Solaris CDE ウィンドウシステムでは、アカウントには、編集可能な $HOME/.dtprofile ファイルが用意されています。このファイルの基本的な機能は、アカウントがログインし、セッションを開始するときに .login ファイルあるいは .profile ファイルをデスクトップで読み取るかどうかを管理するものです (login(1) と profile(4) のマニュアルページも参照)。ただし、アカウントがログインシェルとしてプロファイルシェルの pfsh(1M) を持っていると、.dtprofile ファイルの処理は異なります。これについては、「スタートアップファイル読み取りの制御：プロファイルシェルユーザーの場合」を参照してください。

dtprofile ファイル

Trusted Solaris システムでは、デフォルトとして .login または .profile ファイルは、ウィンドウシステムでは読み取られません。これらのファイルの読み取りは、いくつかある dtprofile ファイルの 1 つによって制御されています。

次のファイルのどちらかがそのアカウントの $HOME/.dtprofile にコピーされます。

サイトのセキュリティ管理者役割によって作成された /etc/dt/config/sys.dtprofile ファイル (存在する場合)
デフォルトの /usr/dt/config/sys.dtprofile ファイル

上記のファイルのどちらかを $HOME/.dtprofile にコピーするまでの流れを次の図に示します。

図 3-2 ファイルを $HOME/.dtprofile にコピーするまでの流れ

デフォルトの /usr/dt/config/sys.dtprofile では、これらのファイルの読み取りを有効にする変数がコメント行になっています。

# DTSOURCEPROFILE=true

sys.dtprofile ファイルのコピーの DTSOURCEPROFILE 定義の前にある # を削除すると、該当するスタートアップファイルをウィンドウシステムに読み取らせることができます。その他の *.dtprofile ファイルを変更して、他のスタートアップファイルでも行えるようなこと、たとえば、環境変数の設定、コマンドやアクションの検索パスの設定、標準エラーや標準出力がどこに書き込まれるかの変更、コマンドや機能の呼び出しなどを行うようにすることができます。

デフォルトの *.dtprofile ファイルのコメントにも記述されているように、サイトの管理者や各ユーザーは、スタートアップファイルで次のようなアクションを行わないように注意してください。

端末エミュレータで処理が必要になる
ウィンドウシステムが起動している最中に、ユーザーによる処理が必要になる

詳細は、ファイル /etc/dt/config/sys.dtprofile 内のコメントや、「ログイン時に .login および .profile ファイルを自動的に読み取らせるには」を参照してください。なお、デフォルト設定を変更する場合は、それが自サイトのセキュリティポリシーに合致していることを確認してください。

注 -

.login または .profile を変更したためにユーザーが作業を行えなくなった場合、そのユーザーは「ログイン (login)」で「復旧セッション」オプションを指定することで問題を解決できます。「復旧セッション」オプションを使うと、スタートアップファイルを読み取ることなくログインできるため、ログイン後、ユーザーは問題のあるファイルを修正できます。

スタートアップファイル読み取りの制御：プロファイルシェルユーザーの場合

プロファイルシェルのスタートアップファイル読み取りに使われるアルゴリズムは、セキュリティ上の理由から、他のシェルに適用されるものとは異なっています。

ユーザーのログインシェルとして pfsh(1M) が指定されている場合、他のシェルと同様に、pfsh が有効になる前に、.profile ファイルがログイン中に読み込まれます。しかし、アカウントの$HOME ディレクトリ内の .dtprofile ファイルのバージョンは読み込まれません。デフォルトシェルが pfsh であるユーザーが $HOME/.dtprofile を作成しても、個人的に作成した .dtprofile は無視されるので、そのファイルは有効にはなりません。このように、個人のユーザーあるいは役割は、アカウントのプロファイルで指定されていない .dtprofile でコマンドを指定することができないようになっています。 $HOME/.dtprofile の代わりに、デフォルトの /usr/dt/config/sys.dtprofile、またはセキュリティ管理者役割によって変更された /etc/dt/config/sys.dtprofile が使用されます。

図 3-3 デフォルトが pfsh(1M) であるユーザーの場合、$HOME/.dtprofile は読まれない

シェル起動時にどのスタートアップファイルを読み込むかの制御

標準 Solaris システムと同様に、シェル初期化ファイルを使用して、検索パスやその他の環境変数の設定を行なったり、便利なコマンドや関数の実行を行なったりします。各シェルが起動したときに、どのスタートアップファイルが読み込まれるかを次の表に示します。

表 3-3 シェル初期化時に読み込まれるスタートアップファイル


シェル	スタートアップファイル
C シェル	`$HOME/.cshrc` `$HOME/.login`
Bourne シェル	`$HOME/.profile`
Korn シェル	`$HOME/.profile` ENV 変数で指定したファイル
プロファイルシェル (Trusted Solaris システムのみ）	`$HOME/.profile`

シェルがアカウントのログインシェルと認識されたときにのみ .profile あるいは .login ファイルが呼び出されます。シェルは、- の接頭辞付きで (- csh のように) 呼び出されますが、これは、ログインシェルであることを示しています。このことは、たとえば、C シェルが csh を使用して (- の接頭辞なしで) 起動した場合、.login ファイルは実行されないことを意味します。

dtterm による $HOME/.login または .profile の強制読み込み

dtterm(1) で起動したシェルは、ログインシェルとして起動しないため、$HOME/.login や $HOME/.profile は読み込まれません。dtterm にログインシェルを起動させるには、どのアカウント、ユーザー、役割も $HOME/.Xdefaults-hostname ファイルに次のようなエントリを作成することによってそれを行うことができます。

Dtterm*LoginShell: true

このように追加された変更を有効にするには、いったんログアウトすることが必要です。「dtterm により新規シェルをログインシェルとして起動させるには」を参照してください。同じエントリが、そのアカウントが作業をしているラベルのホームディレクトリである SLD の .Xdefaults-hostname になければいけません。.Xdefaults-hostname をすべての SLD にコピーしたりリンクを張ったりする設定方法に関しては、「.copy_files および .link_files の使い方」を参照してください。

注 -

すべての役割向けのデフォルトの .profile ファイルには、adminvi(1M) コマンドに別名をつけて vi(1) とする機能がありますが、この別名機能は、Dtterm*LoginShell: true のエントリを $HOME/.Xdefaults-hostname ファイルに作らないと、有効にはなりません。「adminvi から vi への名前の変更」を参照してください。

その他のシェルスタートアップファイル

ホームディレクトリにあると便利なスタートアップファイルに .mailrc があります。これは、次の図に示すように、特にユーザーのメールフォルダ、受信箱、メールエイリアスを指定するのによく使われるものです。

例 3-1 `.mailrc` の例

set folder=/home/roseanne/.mailrc
set MBOX=$HOME/Mail/inbox
alias pubs janer@think monicap@owl jstearns@auburn

もう 1 つの例として、ニュースビューアの起動のたびにどのニュースグループを起動するかを決めるのに使用する .newsrc ファイルがあります。.Xdefaults ファイルと .Xdefaults-hostname ファイルもウィンドウの動作を制御するために頻繁に変更されます。

スケルトンディレクトリの管理

管理者役割は、次の図に示すようなユーザーマネージャの「ホーム (Home)」ダイアログボックスを使用して、アカウント用にスケルトンパスディレクトリを定義します。

図 3-4 ユーザーマネージャ: ホームディレクトリを作成するダイアログボックス

上の図に示したように、デフォルトのスケルトンパスディレクトリは、/etc/skel です。管理者役割によってこのデフォルト値を承認されると、それぞれのシェルのデフォルトの初期化ファイルが /etc/skel からアカウントの $HOME ディレクトリにコピーされ、リネームされます。

次の図に示すように /etc/skel ディレクトリの一覧にある local.cshrc、 local.login、local.profile ファイルは、一般ユーザーアカウント向けにコピーされます。

例 3-2 デフォルトの /etc/skel ディレクトリ内容

trusted1% cd /etc/skel
trusted2% ls -R
local.cshrc local.login local.profile tsol/
 
tsol:role.link_files role.profile

(Trusted Solaris に固有の /etc/skel/tsol ディレクトリについては、「/etc/skel/tsol の役割スタートアップファイル」を参照してください。)

管理者役割がユーザーマネージャで自動ホームディレクトリ作成オプションを選択している場合、/etc/skel ファイルはアカウントの最下位ラベルに対応する SLD にコピーされます。

/etc/skel/tsol の役割スタートアップファイル

役割およびインストールユーザーのホームディレクトリは、次の図に示すように /etc/security/tsol/home/rolename に作成されます。

trusted1% ls /etc/security/tsol
admin/    install/    oper/     secadmin/

/etc/skel/tsol の role.link_files と role.profile ファイルはデフォルトのスタートアップファイルで、役割のホームディレクトリだけで使用されます。

trusted% cd /etc/skel/tsol
trusted% ls 
role.link_files role.profile

新たに別の管理役割を設定するときは、セキュリティ管理者役割は、ユーザーマネージャの「スケルトンパス (Skeleton Path)」フィールドに /etc/skel/tsol を指定する必要があります。

スケルトンファイルの変更

管理者役割は、次のようなことを行うことがあります。

/etc/skel あるいは /etc/skel/tsol ディレクトリにコピーすべき他のファイルの追加
/etc/skel あるいは /etc/skel/tsol ディレクトリのデフォルトファイルの変更あるいはリネーム
サイト特有のスケルトンファイルのある代替スケルトンディレクトリの作成

代替のスケルトンディレクトリを使用する際は、管理者役割は、ユーザーマネージャを使用してユーザーアカウントを作成するときに「ホーム (Home)」ダイアログボックスに代替ディレクトリのパス名を指定することができます。
各シェル用にシェルスタートアップファイルのマスターコピーをスケルトンサブディレクトリに設定し、各ユーザーのデフォルトのシェルにあわせてスケルトンディレクトリをユーザーマネージャで指定する

これにより、アカウントの最下位の機密ラベルで最初にワークスペースが作成されたときに、スケルトンファイルのディレクトリから SLD に、ユーザーのデフォルト (ログイン) の SHELL 用の正しいスタートアップファイルだけがコピーされます。各シェルに別々の設定を実行する方法と、pfsh については、この章の「各シェル用にシェル初期化ファイルを分離するには」を参照してください。

Trusted Solaris システムでは、スケルトンディレクトリ内のファイルは、アカウントの持つ最下位ラベルで作成された、そのアカウント用の最初の SLD だけに自動的にコピーされます。

この後、アカウントはいくつかの設定を行う義務があります。ユーザーアカウントは、スケルトンディレクトリからコピーされたファイルを自分のデフォルトのシェルに合わせてリネームし、必要に応じてその内容を変更する必要があります。たとえば、ユーザーのデフォルトシェルが C シェルでその最下位機密ラベルが PUBLIC である場合、最初のログインの後、ユーザーはホームディレクトリ内の PUBLIC ラベルを持つ SLD に移り、そこで local.cshrc (/etc/skel から自動的にコピーされたもの)をリネームし、必要に応じてその内容を変更することになります。

これらの初期化ファイルはアカウントの持つ最下位ラベルで作成されたホームディレクトリ内の最初の SLD にロードされるだけなので、その他のラベルで作成された SLD にこれらのファイルを配置するにはさらに追加作業が必要となります。ホームディレクトリ内の SLD にファイルをコピーする場合やリンクを作成する場合には、ユーザーまたは管理者は、.copy_files か .link_files ファイルあるいはその両方のファイルを作成する必要があります。詳細は、「.copy_files および .link_files の使い方」を参照してください。

すべてのプロダクトのマニュアルページにアクセスするには

man(1) コマンドが Trusted Solaris パッケージに含まれているすべての Trusted Solaris プロダクト (CDE、X ウィンドウ、Solstice AdminSuite) のマニュアルページを見つけることができるようにするには、MANPATH 環境変数に次の表に示すディレクトリ名をすべて指定する必要があります。

表 3-4 Trusted Solaris パッケージプロダクトのマニュアルページのディレクトリ


マニュアルページのディレクトリ
`/usr/man`
`/usr/openwin/man`
`/usr/dt/man`

注 -

Solstice AdminSuite のマニュアルページは独立したマニュアルディレクトリを持っておらず、/usr/man にあります。

MANPATH 環境変数を設定するには、ユーザーは、以下の行を自分のシェル初期化ファイルに追加します。または、管理者が /etc/skel (または他のスケルトンディレクトリ)内にサイト全体のシェル初期化ファイルを作成し、そのファイルに以下の行を追加します。

setenv MANPATH="/usr/dt/man:/usr/openwin/man:/usr/man:$MANPATH"

自分の MANPATH 環境変数の現在の設定を調べるには、次のコマンドを使います。

$ echo $MANPATH

MANPATH 環境変数には少なくとも次の値が設定されている必要があります。

/usr/dt/man:/usr/man:/usr/openwin/share/man

.copy_files および .link_files の使い方

.copy_files および .link_files は Trusted Solaris に導入された新しいシステムファイルです。これらのファイルを使うと、ユーザーや管理者は、各アカウントのホームディレクトリの MLD に作成された SLD 間でのスタートアップファイルのコピーやリンクの作成を自動化できます。これらのファイルはアカウントの最下位の機密ラベルの SLD に作成されます。ユーザーまたは管理者は、最下位機密ラベルの SLD から他のラベルの SLD にコピーまたはリンクされるファイルをそれぞれ .copy-files または.link-files にリストすることができます。どのファイルのコピーやリンクを作成するかは、設定を行うユーザーの判断に任されます。

新しいラベルにワークスペースが作成されるといつも dtsession(1) が updatehome(1M) コマンドを実行して、アカウントの最下位ラベルの SLD の .copy_files と .link_files を読み込み、一覧表示されたファイルを新しいワークスペースにコピーあるいはリンクします。

updatehome コマンドは、コピーおよびリンク制御ファイルを読み、次の表に示すような処理を行います。

表 3-5 updatehome の動作とそのタイミング


タイミング	処理
ログインセッションの間に新しい機密ラベルで新しいワークスペースが作成された時	アカウントの最下位機密ラベルの SLD から新規ラベルの SLD に、`.copy_files` のファイルをコピーし、`.link_files` のファイルをリンク
ログインセッションの開始時	アカウントの最下位機密ラベルの SLD から既存のホームディレクトリの全 SLD に `.copy_files` のファイルをコピーし、`.link_files` のファイルをリンク

.copy_files を使った SLD 間のファイルのコピー

最下位機密ラベルの SLD から他のラベルで作成された 2 番目以降の SLD に任意のファイルがコピーされると、そのファイルがユーザーにより編集され、異なる SLD 内に異なるバージョンのファイルが存在することになります。SLD 間のファイルのコピーが必要となるのは、たとえば異なる機密ラベルで作業しているユーザーが、ラベルごとに異なるメールエイリアスを使いたいという場合などです。各 SLD に .Xdefaults-hostname のコピーを配置するには .copy_files ファイルの一覧に.Xdefaults-hostname を加えます。詳細は、「ホームディレクトリ内の複数の SLD にスタートアップファイルを配置するには」を参照してください。

上記の手順において、管理者役割は任意のスケルトンディレクトリを作成し (またはデフォルトの /etc/skel を使用して)、そのスケルトンディレクトリにスタートアップファイルの汎用コピーを配置します。さらに、管理者はこのスケルトンディレクトリ内に、マスターの .copy_files (すべてのホーム SLD にコピーしたいスタートアップファイルの一覧を記述したもの) ならびにマスターの .link_files (すべてのホーム SLD にリンクしたいファイルの一覧を記述したもの) を作成します。その後、ユーザーアカウントの設定時に、管理者役割がこの変更されたスケルトンディレクトリのパス名を指定すると、スケルトンディレクトリ内のすべてのファイル (.link_files や .copy_files を含む) が指定のユーザーのホームディレクトリ内の最下位の機密ラベルの SLD にコピーされます。続いて .link_files ならびに .copy_files 内の情報に基づいて、最初の SLD 内の指定されたファイルが、2 番目以降に作成された各 SLD にコピーまたはリンクされることになります。

.link_files を使った SLD 間でのファイルのリンク

ある SLD 内の 1 つの初期化ファイルが変更されると、そのファイルがリンクされているすべての SLD 内の、あらゆるラベルのファイルすべてが、同じように変更されます。

たとえば、Confidential ワークスペース内にリンクされている .cshrc を変更した場合、その変更はファイルがリンクされているすべての他のラベルの SLD 内の .cshrc ファイルに適用されます。詳細は、「ホームディレクトリ内の複数の SLD にスタートアップファイルを配置するには」を参照してください。

SLD 間でのファイルのコピーやリンクを行うためのワークシート

よく使われるファイルのうち、どのファイルをコピーまたはリンクするかを決めるためのワークシートの例を以下に示します。

表 3-6 SLD 間でのスタートアップファイルのコピーやリンクを行うためのワークシート


よく使われるスタートアップファイル	コピーするもの (`.copy_files` に記述)	コピーするもの (`.link_files` に記述)
`.bugtraqrc`
`.cshrc`
`.dtprofile`
`.login`
`.Xdefaults`
`.Xdefaults-hostname`
`.mailrc`
`.newsrc`
`.profile`

cron、at、batch を使ったジョブの自動実行の管理

cron(1M) は、指定の時刻にコマンドを実行するクロックデーモンです。この節では、cron の動作の概要を説明し、Trusted Solaris における cron の管理と、cron に関連するコマンド群の特徴を説明します。cron に関する基本的な事項については『Solaris のシステム管理 (第 2 巻)』を参照してください。Trusted Solaris における変更点については、at(1)、atq(1)、atrm(1)、cron(1M)、crontab(1) の各マニュアルページを参照してください。

バッチジョブの概念の説明

cron は、すべてのスケジュール化されたジョブを実行するために、各イベントを時間順に並べたリストを保持しています。各イベントは、特定のジョブとそれを実行するのに必要な情報を表しています。cron は次の 2 種類のジョブ (cron_job および at_job) を実行します。

at によってスケジュール化される、将来の指定された時間に1度だけ実行される単一の実行ジョブ (at_job)
batch によってスケジュール化される単一の実行ジョブ (at_job)。batch は at(1) のフロントエンドスクリプトであり、システム負荷レベルが許すと即座にジョブ実行を依頼する。
crontab によってスケジュール化される、指定された時間間隔で繰り返し実行される周期的実行ジョブ (cron_jobs)。

cron_job および at_job は、それぞれ対応するスプールディレクトリに格納されている crontab または atjob ファイルを cron が読み込むことによりスケジュール化されます。これらのファイルを cron が読み込むタイミングは次のどちらかです。
cron 自身のプロセスの初期化時
crontab または atjob ファイルに変更が行われた後

crontab ファイル

crontab ファイルは、ユーザーアカウントまたは役割アカウントが crontab(1) コマンドを使うことにより生成されます (Trusted Solaris システムでは、crontab コマンドがアカウントの実行プロファイルにの 1 つに含まれていなければなりません)。crontab ファイルは、1 行ごとに書かれたコマンドから構成されており、これらのコマンドは各コマンド行の先頭部分に指定された時刻に自動的に実行されます。crontab ファイル内の各コマンド行を「cron_job」と呼びます。crontab ファイルは複数の cron_job を含むことができます。crontab ファイルのスプール空間は、/var/spool/cron/crontabs です。

atjob ファイル

atjob ファイルは、ユーザーアカウントまたは役割アカウントが at(1) または batch コマンドを使うことにより生成されます (これらのコマンドがアカウントの実行プロファイルの 1 つに含まれていなければなりません)。コマンドが実行された時のユーザーの現在のプロセス環境もファイルに保存されます。これらの各ファイルは「at_job」として参照されます。atjob ファイルのスプール空間は /var/spool/cron/atjobs です。

スプールディレクトリにおける異なるラベルを持つジョブのサポート

Trusted Solaris システムでは、crontab および atjob ファイルのスプールディレクトリは MLD として実装されているため、これらのスプールディレクトリには異なる機密ラベルを持つジョブファイルが保持されることになります。スプールディレクトリが MLD であるため、1 人のユーザーは、crontab ディレクトリ内に異なる機密ラベルを持つ複数の crontab ファイルを持つことができます。同様に、1 人のユーザーは、atjobs ディレクトリ内に異なる機密ラベルを持つ複数の atjob ファイルを持つことができます。

ジョブの実行にプロファイルシェルを使うには

注意 -

ジョブの実行にプロファイルシェルを指定する場合、セキュリティ管理者役割は、そのジョブの実行に必要なすべてのコマンドが、それを呼び出すユーザーに割り当てられている実行プロファイル内に存在することを確認しておかなければなりません。

cron_job は次の条件のどちらかが満たされている場合、pfsh を使って実行されます。

アカウントの passwd(1) エントリに登録されているログインシェルが pfsh である
$SHELL 環境変数の値が /bin/pfsh である

上記のどちらの条件も満たされない場合、cron は cron_job の実行にデフォルトの Bourne シェルである sh(1) を使います。

at コマンドの場合、ユーザーは -c(csh)、-k(ksh)、-s(sh)、-p(pfsh) の各オプションを使って、ジョブの実行に使うシェルを指定できます。このため、at_job の場合、その実行にプロファイルシェルが使われる条件として、3 つ目の場合があります。
アカウントの passwd エントリに登録されているログインシェルが pfsh である
$SHELL 環境変数の値が pfsh である
at コマンドが -p オプション付きで指定された場合

上記のどの条件も満たされない場合、at は次のどちらかのシェルを使います。
-c、-k、-s オプションのいずれかで指定されたシェル
デフォルトのシェル (sh)

at または cron ジョブで特権付きのコマンドを実行するには

at または cron ジョブ内のコマンドを実行するのに特権が必要となる場合、強制された特権または継承可能な特権のどちらかが使用されます。

しかし、コマンドを実行するのが誰であるかにかかわらず強制された特権を使ってそのコマンドを実行することは、通常、サイトのセキュリティポリシーには適合しません。このため、通常、セキュリティ管理者役割は、継承可能な特権を使用できるようにするために、次の操作を行う必要があります。

プロファイルマネージャを使って、コマンドとその実行に必要となる特権を、それを呼び出すユーザーの実行プロファイル内に指定すること。
そのジョブの実行にプロファイルシェルを使用するよう指定すること (「ジョブの実行にプロファイルシェルを使うには」を参照のこと)。

詳細は、「特権がコマンドとアクションに割り当てられる方法」、「コマンドに強制された特権を付与するには」、「コマンドやアクションに「継承可能な特権」を付与する」などを参照してください。また、cron ジョブの使用例については、「特権コマンドを実行するプロファイルシェルスクリプトを作成するには」を参照してください。

UNIX ドメインソケットを使った通信

Trusted Solaris システムでは、crontab(1)、at(1)、atrm(1)、cron(1M) の間の通信機構として、UNIX ドメインソケットが使用されます。UNIX ドメインソケットを使うことで、トラステッドセキュリティ情報交換ライブラリ (TSIX) の提供するトラステッドネットワーキングインタフェースにより、cron のクライアントから cron へのメッセージやセキュリティ属性の通信を信頼できる方法で実施することが可能となっています。詳細は libt6(3N) のマニュアルページを参照してください。

cron(1M) は、UNIX ドメインソケットの作成とバインド (割り当て) に /etc/cron.d/CRON を使うように変更されています。/etc/cron.d/CRON ファイルは、クロックデーモンによる複数の実行を防ぐためのロックファイルとしても使われます。

クロックデーモンは、有効セット内の net_mac_read 特権を有効にすることでマルチレベルポートを作成します。これにより、クロックデーモンは異なる機密ラベルを持つメッセージを受信できます。

ユーザーが crontab または atjob ファイルを作成、変更、削除すると、 crontab、at、atrm の各コマンドは、適切なデータを含むメッセージと、そのコマンドのプロセスが持つ機密ラベル情報をクロックデーモンに送信します。クロックデーモンは、このメッセージと機密ラベル情報を受け取ると、そのメッセージを解釈して必要な処理を行います。送信された機密ラベル情報は、対応する SLD 内での crontab または atjob ファイルの作成や削除を行うのに使用されます。

補助ファイル

各 crontabs ファイル用の crontabs MLD、および各 atjob ファイル用の atjobs MLD には、補助ファイルが作成されます。crontab ファイルや atjob ファイルを変更すると、対応する補助ファイルのデータも変更されます。補助ファイルの名前は、crontab ファイルの場合は username (ユーザー名).ad になり、atjob ファイルの場合は jobname (ジョブ名).ad になります。補助ファイルには、cron がジョブの設定に使用する情報が格納されます。

at および cron の使用を制限するには

管理者は、/etc/cron.d ディレクトリ内の *.allow および *.deny ファイルを使うことで、at および cron の使用を制限できます。

at の場合、使用を許可または禁止するユーザー名を次のファイルに定義します。

at.allow
at.deny

cron の場合、使用を許可または禁止するユーザー名を次のファイルに定義します。
cron.allow
cron.deny

*.allow ファイルが存在する場合、対応する *.deny ファイルは検査されません。*.allow ファイルが存在しない場合、*.deny ファイルが検査されますが、この場合、*.deny ファイルが空であると、どのユーザーでもジョブの実行を依頼できるようになります。Trusted Solaris 環境では、*.allow ファイルと *.deny ファイルの両方が存在しない場合、どのユーザーもジョブの実行を依頼できなくなります。Trusted Solaris システムは cron.allow および at.allow ファイルなしで出荷されます。デフォルトの cron.deny および at.deny には、次のアカウント名が含まれています。

daemon
bin
smtp
nuucp
listen
nobody
noaccess

他のユーザーが所有するジョブの使用

デフォルトの Trusted Solaris のセキュリティポリシーでは、ユーザーが他のユーザーの所有するジョブを使用することは禁じられています。ただし、セキュリティ管理者役割は、ユーザー設定を変更することにより、この制限を無効にすることができます。特定のユーザーが他のユーザーの所有するジョブを使用できるようにするには、セキュリティ管理者役割は次の操作を実行する必要があります。

/etc/cron.d ディレクトリにある at.admin および cron.admin を編集する
at および cron 関連の特権を割り当てる

at.admin および cron.admin ファイル

出荷時の状態では、/etc/cron.d にある at.admin および cron.admin ファイルには、システムプロセスが使用する特殊なシステムアカウント名のみが記述されています。このデフォルトの内容を以下に示します。2 つのファイルの内容は同じです

bin
adm
lp
smtp
uucp
nuucp
listen

出荷時の状態では、デフォルトの crontabs SLD (ADMIN_LOW ラベル付き) には、adm、sys、uucp 用の crontab ファイルが含まれています。crontabs MLD にはこれ以外のデフォルトの crontab ファイルは存在せず、また atjobs MLD にはデフォルトの at_job は存在しません。各サイトでは、必要に応じて、特殊なシステムアカウント用に実行する別の crontab や at_job を作成できます。これらのシステムアカウントにはパスワードが割り当てられていないため、これらのアカウントには誰もログインできません。したがって、この機能がなければ、これらのアカウント用の cron_job や at_job に対するいかなる変更も行えないことになります。

他のユーザーの所有するジョブを使用するための条件

at、atq、atrm、crontab を呼び出すアカウントは、以下の条件を満たす場合にのみ、他のユーザーの所有するジョブの表示、編集、削除が行えます。

at 関連のコマンドの場合の条件

特定のアカウントが、at、atq、atrm を使って、他のユーザーの所有する at_job を作成 (またはそれを使用) するためには、次の条件を満たすことが必要です。

指定されたユーザー名、または指定された at_job の所有者のユーザー名が、at.admin ファイルに登録されている特殊なシステムアカウント名の 1 つであること。かつ条件 3 が満たされていること。
指定された at_job の所有者のユーザー名が、役割アカウント名であること。かつ条件 3 が満たされていること。
アカウントの、実行プロファイル内に「at admin を変更」承認があること。
条件 1 および 2 のどちらも満たされない場合、呼び出しを行うアカウントの実行プロファイル内に「at user を変更」承認がなければならない。

crontab コマンドの場合の条件

特定のアカウントが、crontab を使って、他のユーザーの所有する crontab ファイルを作成 (またはそれを使用) するためには、次の条件を満たすことが必要です。

指定されたユーザー名が、cron.admin ファイルに登録されている特殊なシステムアカウント名の 1 つであること。かつ条件 3 が満たされていること。
指定されたユーザー名が、役割アカウント名であること。かつ条件 3 が満たされていること。
呼び出しを行うアカウントが「 cron admin を変更」承認を持っていること。
条件 1 および 2 のどちらも満たされない場合、呼び出しを行うアカウントの実行プロファイル内に「cron users を変更」承認がなければならない。

crontab(1) に対する変更点

crontab(1) コマンドのオプションのうち、Trusted Solaris 環境で変更されているものを表 3-7 に示します。

表 3-7 crontab(1) のオプション


オプション	コメント
`-e`	呼び出し元のプロセスのラベルと同じラベルで `crontab` ファイルの作成または変更を行う。「他のユーザーが所有するジョブの使用」に述べた条件を満たす場合にのみ、ユーザーは、他のユーザーの所有する `crontab` ファイルを編集できる。ユーザーの passwd エントリに `/bin/pfsh` が指定されていない場合、`crontab -e` コマンドは `VISUAL` 環境変数に定義されているエディタを呼び出す。`VISUAL` 環境変数がヌルの場合、`EDITOR` 環境変数に定義されているエディタを呼び出す。どちらの環境変数も定義されていない場合、`cron` はデフォルトのエディタである `ed`(1) を使用する。ユーザーの passwd エントリに `/bin/pfsh` が指定されている場合、環境変数が vi に設定されているならば adminvi が使用される。環境変数が `dtpad` に設定されているならば `TSOLdtpad` が使用される。どちらの環境変数も定義されていない場合、`cron` はデフォルトのエディタである adminvi を使用する。
`-l`	呼び出し元のプロセスの機密ラベルで、現在のユーザーが持つ `crontab` ファイルの内容を表示する。「他のユーザーが所有するジョブの使用」に述べた条件を満たす場合にのみ、ユーザーは、他のユーザーの所有する `crontab` ファイルの内容を表示できる。
`-r`	呼び出し元のプロセスの機密ラベルで、ユーザーの `crontab` ファイルを `crontabs` ディレクトリから削除する。「他のユーザーが所有するジョブの使用」に述べた条件を満たす場合にのみ、ユーザーは、他のユーザーの所有する `crontab` ファイルを削除できる。

アクセス制御は変更されていません。ただし、例外として、cron.allow および cron.deny の両方が存在しない場合、すべてのユーザーがジョブ実行を依頼できなくなります。

at コマンドに対する変更点

at(1) コマンドのオプションのうち、Trusted Solaris 環境で変更されているものを次の表に示します。-p オプションは新しく追加されたものです。

表 3-8 Trusted Solaris 版 at(1) のオプション


オプション	コメント
`-l`	at_job 番号がオペランドに指定されていない場合、現在のユーザーが所有しているすべての at_job に関する情報を、呼び出し元プロセスのラベルで表示する。at_job 番号がオペランドに指定されている場合、そのジョブに関する情報だけが表示される。その at_job が現在のユーザーの所有するものでないならば、「他のユーザーが所有するジョブの使用」に述べた条件を満たす場合にのみ、そのジョブに関する情報が表示される。
`-r`	オペランドに指定された at_job 番号(それ以前にスケジュール化されていたもの)を持つ at_jobs を削除する。その at_job が現在のユーザーの所有するものでないならば、「他のユーザーが所有するジョブの使用」に述べた条件を満たす場合にのみ、そのジョブが削除される。
`-p`	ジョブの実行にプロファイルシェルを使用する。

アクセス制御は変更されていません。ただし、例外として、at.allow および at.deny の両方が存在しない場合、すべてのユーザーがジョブ実行を依頼できなくなります。

atq コマンドに対する変更点

atq(1) コマンドに対する変更点を下の表に示します。

表 3-9 Trusted Solaris における atq(1) の変更点


引数	説明
なし	呼び出したユーザーが所有している atjob を、呼び出し元プロセスの機密ラベルで表示する。その atjob が現在のユーザーの所有するものでないならば、「他のユーザーが所有するジョブの使用」に述べた条件を満たす場合にのみ、そのジョブに関する情報が表示される。
`user`	引数に指定したユーザーが、このコマンドを呼び出したユーザーである場合、指定のユーザーが所有しているすべての atjob を表示する。引数に指定したユーザーが、このコマンドを呼び出したユーザーでない場合、「他のユーザーが所有するジョブの使用」に述べた条件を満たす場合にのみ、そのジョブに関する情報が表示される。

atrm コマンドに対する変更点

atrm(1) コマンドに対する変更点を下の表に示します。

表 3-10 Trusted Solaris における atrm(1) の変更点


引数	説明
`user`	引数に指定したユーザー (`user`) が、このコマンドを呼び出したユーザーである場合、指定のユーザーが所有しているすべての atjob を削除する。引数に指定したユーザーが、このコマンドを呼び出したユーザーでない場合、「他のユーザーが所有するジョブの使用」に述べた条件を満たす場合にのみ、そのジョブが削除される。
at_job #	オペランドに指定された at_job 番号を持つジョブで、呼び出し元プロセスの機密ラベルを持つものを削除する。
option `-a`	このコマンドを呼び出したユーザーが所有するすべての atjob で、呼び出し元プロセスの機密ラベルを持つものを削除する。

その他の注意点

cron(1M) はブートプロファイルによって、ADMIN_LOW 機密ラベルで起動されます。その後、cron(1M) が UNIX ドメインソケットを ADMIN_LOW で作成してから以降は、ADMIN_HIGH 機密ラベルで動作するよう変更されます。

Trusted Solaris は、次の crontab ファイルが添付された状態で出荷されます。

ADMIN_HIGH 機能ラベルを持つ、root、uucp、adm、sys 用の crontab ファイルと補助ファイルの組み合わせ
ADMIN_HIGH 機密ラベルを持つ、root および lp 用の crontab ファイルと補助ファイルの組み合わせ

/var/cron/log ファイルは、クロックデーモンにより ADMIN_HIGH 機密ラベルで作成されます。このログファイルには、クロックデーモンの内部メッセージが記録されます。

ユーザー設定のための操作手順

ログイン時に .login および .profile ファイルを自動的に読み取らせるには

注 -

ここで手順を実行すると、変更が加えられたホスト上の全ユーザーのデフォルト値を変更します。

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

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

ファイルマネージャあるいは端末エミュレータからコマンドを使用して、 sys.dtprofile を /usr/dt/config から /etc/dt/config にコピーします。

相手先のディレクトリが存在しないときは、それを作成します。
$ cp sys.dtprofile /etc/dt/configcd /usr/dt/config

管理用エディタを使用して、sys.dtprofile ファイルを開き、編集を行います。

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

このファイルの末尾にある、DTSOURCEPROFILE 変数の行の先頭にあるポンド記号 (#)を削除します。

編集後の行は、次のようになります。
DTSOURCEPROFILE=true

ファイルの内容を保存し、ファイルを閉じます。
:wq

dtterm により新規シェルをログインシェルとして起動させるには

この手順をアカウントが作業を行なっているホームディレクトリの SLD ごとに行なってください。あるいは、アカウントの最下位機密ラベルのホームディレクトリの SLD で一度この手順を行なって、「.copy_files および .link_files の使い方」で説明したように .copy_files あるいは .link_files の一覧に .Xdefaults-hostname ファイルを加えてください。詳細については、マニュアルページの updatehome(1M) を参照してください。

ホームディレクトリに移動します。
trusted% cd

テキストエディタを使用して、.Xdefaults-hostname ファイルを作成あるいは変更します。

次のように入力します。
Dtterm*LoginShell: true

ファイルへの書き込みを行い、ファイルを閉じます。
:wq

各シェル用にシェル初期化ファイルを分離するには

管理者役割になった状態で、Solaris 用のマニュアル『Solaris のシステム管理 (第 1 巻)』の「ユーザーアカウントとグループの管理の概要」にあるユーザー初期ファイルの設定手順を実行します。

この手順には、3 つのシェルに特有のスケルトンディレクトリ名を生成する方法が述べられています。ここで生成したディレクトリ名を、ユーザーマネージャの「スケルトンパス (Skeleton path)」フィールドに入力することになります。また、上記の手順には、local.login ファイルをskelC サブディレクトリにコピーする方法、local.profile ファイルを skelK サブディレクトリにコピーする方法、local.login ファイルを skelB サブディレクトリにコピーする方法も述べられています。

管理者役割になり、skelP サブディレクトリを作成します。このディレクトリは、デフォルトシェルが pfsh であるユーザーのホームディレクトリにインストールされる .profile の特殊なバージョン用のディレクトリです。

ユーザーのデフォルトシェルに応じて、正しい skelX サブディレクトリ名をユーザーマネージャの「スケルトンパス (Skeleton path)」フィールドに入力します。

ホームディレクトリ内の複数の SLD にスタートアップファイルを配置するには

注 -

どのユーザーも .copy_files や link_files を自己のホームディレクトリの MLD内の最下位機密ラベルの SLD にコピーすることができます。また、すでに最下位ラベルの SLD にファイルがある場合、ファイルを変更することができます。この手順は、複数ユーザーの設定を自動化する管理者役割向けです。

管理者役割になり、 ADMIN_LOW のワークスペースに移動します。

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

/etc/skel あるいは自分が使用したい任意のスケルトンディレクトリに移動します。

下の例に、C シェル用スタートアップファイルのためのスケルトンディレクトリ /etc/skel/skelC に移る例を示します(このディレクトリは、「各シェル用にシェル初期化ファイルを分離するには」の手順で作成したものです)。
$ cd /etc/skel/skelC

スタートアップファイルの汎用コピーをこのスケルトンディレクトリに配置します。

たとえば、下の例に示すような、C シェル、メーラー、dtterm 用のスタートアップファイルなどを配置します。
$ ls .cm.rc .cshrc .login .mailrc .netscape

.copy_files を作成するか、(すでに存在する場合は)このファイルを編集し、すべてのホームディレクトリ内の SLD にコピーしたいファイルの一覧をここに記述します。

コピーされたファイルの内容は、ユーザーにより、各 SLD で変更される場合があります。

.link_files を作成するか、(すでに存在する場合は)このファイルを編集し、すべてのホームディレクトリ SLD にリンクしたいファイルの一覧をここに記述します。

リンクされたファイルの内容は、すべての SLD で同一となります。

ユーザーアカウントの設定時に、ユーザーマネージャの「ホーム (Home)」ダイアログボックスで、変更したスケルトンディレクトリのパス名を入力します。

第 4 章役割の管理

この章では、役割の作成と変更に関する前提知識と、実際の操作方法を紹介します。この章には次の項目があります。

この章では次の操作手続きを示します。

役割アカウントとユーザーアカウントの違い

役割アカウントはユーザーアカウントの特性をすべて保持していますが、以下の点が異なっています。

役割アカウントはログインできません。

管理作業は、事前にログインとパスワードの認証を受けたユーザーが行わなければなりません。これは、ユーザーと管理者が自分の行う処理に対して責任を持たなければならないという必要性があるからです。ログイン認証が不明なユーザーによって行われた管理作業は、監査機構による把握が不可能です。
特定の役割でログインするのではなく、ログイン済みユーザーがトラステッドパスメニューを使ってその役割になります。
役割は他の役割になることはできません。

ユーザーマネージャの「識別情報 (Identity)」ダイアログボックスを使って、特定の役割アカウントになると、「ナビゲータ」ダイアログボックスの「役割 (Role)」ボタンはグレー表示になります。この場合、「役割 (Role)」ボタンをクリックするとエラーメッセージが表示されます。
各役割は役割ワークスペースを持ちます。役割ワークスペースは、ユーザーがその役割になった時点でフロントパネルに追加されます。

管理役割と非管理役割の違い

役割には次の 2 つの種類があります。

非管理役割
管理役割

非管理役割

オペレータ (oper) はデフォルトのシステムでは、次の非管理役割だけが存在します。

オペレータ役割はバックアップ作業とプリンタ管理を行うための役割です。オペレータ役割の行う機能は、トラステッドパス属性をはじめ、「管理役割」に述べる「管理役割」の持ついかなる特性も必要としません。

非管理役割を作成する場合

非管理役割は、複数ユーザーに同じプロファイルを割り当てる上で、次のような利点を持っています。

役割が作成したファイルはすべて、その役割により所有されます。このため、その役割になれるユーザーはすべて、そのファイルの所有者となることで、そのファイルに関して同じアクセス許可を持つことができます。
(非管理) 役割になったユーザーはすべて、/etc/security/tsol/home 下にある同じホームディレクトリを共有し、(非管理) 役割のワークスペース内の同じ環境で作業します。

たとえば、複数のユーザーを help というサポート役割になるように設定します。この場合、help 役割から出されるメールはすべて単一の名前で出されます。したがって、help 役割内で作業しているユーザーはカスタマからは識別できません。

管理役割

デフォルトの Trusted Solaris システムでは、次の 2 つの主要な管理役割があります。

セキュリティ管理者 (secadmin)
システム管理者 (admin)

上記以外に、第 3 の任意の管理役割として、root 役割が存在します。root 役割は、ソフトウェアのインストールのように番号 0 の実 UID (root の UID) を必要とする作業を行うものです。root 役割は、通常、セキュリティ管理役割を持つアカウントに割り当てられます。これは、root の機能が制限されている一方で root 役割の主な機能であるソフトウェアの追加は、セキュリティに直接かかわってくるからです

管理役割には次のような特徴があります。

管理役割には、その追加グループ ID の 1 つとして sysadmin (GID 番号 14) が自動的に割り当てられます。このグループ ID を持たない場合、役割は管理ツールを実行できません。
管理役割ワークスペースは、トラステッドパス属性を持ちます。この属性は管理ツールを使用する場合に必要となるものです。
root 役割のホームディレクトリは / です。secadmin と admin のホームディレクトリは /etc/security/tsol/home の下にあります。

新しい管理役割を作成する場合

各サイトでは、トラステッドパス属性を検査するようなコマンドやアクションを使用する役割が必要となった場合、新しい管理役割を作成できます。たとえば、3 つのデフォルトの管理役割を 1 つの役割にまとめたい場合、そのような機能を持つ新しい管理的役割を作成できます。詳しくは「2 つの役割による分割管理を取らない場合」を参照してください。

トラステッドパス属性

トラステッドパス属性は、ブート時、あるいはプログラムが管理役割ワークスペースで動作しているときに取得できます。プログラムがトラステッドパス属性を取得できるのは、そのプログラムがブートプロファイルまたは管理役割に割り当てられているプロファイルに指定されているときだけです。

多くの管理コマンドやアクションにはトラステッドパス属性が必要です。たとえば、プロファイルシェルが管理役割の代わりに起動されるとき (たとえば、デフォルトのプロファイルシェルで端末エミュレータを起動するときや、(管理) 役割がプロファイルシェルのスクリプトを実行するとき)、プロファイルシェルはトラステッドパス属性を検査します。管理役割ワークスペースにウィンドウを作成するコマンドやスクリプト (多くのインストールスクリプトなど) にはトラステッドパス属性が必要です。次の表に、これ以外のコマンドやツールの一覧を示します。

表 4-1 トラステッドパスを必要とするコマンド、オプションおよびアプリケーション


コマンドまたはアプリケーション	オプション
`audit(1M)`
`auditd(1M)`
`login(1)`	`-d` および `-f`
`lpsched(1M)`
`runpd(1M)`
`sendmail(1M)`	`-ba`, `-bd`, `-bi`, `-bs`, `-bt`, `-bv`, `-M`, `-X`, `-d`, `-q`
Database Manager (dbmgr)
Group Manager (groupmgr)
Host Manager (hostmgr)
Printer Manager (printermgr)
Profile Manager (profilemgr)
Serial Manager (serialmgr)
User Manager (usermgr)

トラステッドパスの警告

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

WARNING: Command operating outside of the Trusted Path!

このメッセージは、実行しようとしているコマンドにセキュリティ制限を回避する権利が与えられていないことを役割に知らせます。コマンドが成功したとしても、警告は表示されます。エラー警告を抑制するには、-Q オプションを使います。つまり、管理役割はプロファイルシェルのコマンド行で set -Q と入力するか、$HOME/.profile ファイルに set -Q を入力します。

プログラムが失敗したとき、プログラムにトラステッドパス属性が欠如していることを示す警告が表示されます。このエラーは、インストールプログラムが管理役割ワークスペースでウィンドウを起動しようとして失敗したときに表示されます。また、トラステッドパス属性を持たない管理役割はプロファイルシェルを起動できないため、シェルスクリプトがプロファイルシェルを使ったときにもこのエラーが表示されます。どちらの場合でも、修正するには、役割に割り当てられているプロファイルにインストールプログラムまたはシェルスクリプトを追加します。

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

ユーザーアカウントおよび管理アカウントを管理する作業の分割

次の図で説明するように、デフォルトの Trusted Solaris システムでは、管理者役割とセキュリティ管理者役割は、一連のユーザーアカウントの規定された特性をそれぞれ設定します。図 4-1 に示すように、セキュリティ管理者は、一般ユーザーアカウントおよびすべての役割アカウントの持つ特性のうち、セキュリティ関連のものの設定を受け持ちます。一方、管理者は、一般ユーザーアカウントの特性の設定と同時に、セキュリティ管理者の特性の設定を受け持ちます。これは、いかなる役割も自分自身を設定することはできないためです。

図 4-1 アカウントやプロファイル設定に関してセキュリティ管理者と管理者役割間で行われる責任の分担

アカウント管理作業を使用するための承認

図 4-2 に、ユーザーアカウントや役割アカウントの追加に使用するユーザーマネージャの「ナビゲータ (追加)」メニューを示します。「コメント (Comment)」の下には 8 つのボタンがあり、各ボタンには、アカウントごとに指定する情報の種類を示すラベルが付けられています。各ボタンを押すと、それぞれに対応するダイアログボックスが表示され、そこで指定の情報を入力できます。これらのボタンは、ユーザーマネージャの「ナビゲータ」ダイアログボックスを使って、ユーザーアカウントの追加または変更を行う場合にのみ表示されます。

図 4-2 ユーザーマネージャの「ナビゲータ」ダイアログボックス

どちらのボタンにも承認が必要です。デフォルトでは、これらの承認はセキュリティ管理者役割と管理者役割に分割され、アカウント管理を 2 人で保守するように構成されています。

注 -

管理役割がユーザーマネージャを起動した時に、これらのボタンのうちのどれかがグレー表示されていた場合、そのボタンを使用するのに必要となる承認が、現在の役割の持つ実行プロファイルに割り当てられていないことを意味します。

各ボタンの使用に必要となる承認と、各ボタンに対応するダイアログボックスをまとめたものを表 4-2 に示します。詳細は、auth_desc(4) のマニュアルページを参照してください。

表 4-2 各種ユーザー情報の指定に必要となる承認


ユーザーマネージャのボタン	承認名	承認番号	承認の内容
識別情報 (Identity)	`ユーザーの識別情報を設定 (set user identity)`	`17`	ユーザーの持つ ID に関するセキュリティ情報 (ユーザー名、主グループ、補助グループ、コメント、ログイン) を、ユーザーマネージャを使用して管理者が設定できるようにする。ユーザーの追加、コピー、削除に必要となる。
パスワード (Password)	`ユーザーのパスワードを設定 (set user password)`	`18`	ユーザーの持つパスワード関連の情報 (パスワード、パスワードの種類、有効期間、有効期限、警告の表示、資格テーブル設定の許可) を、ユーザーマネージャを使用して管理者が設定できるようにする。
ホーム (Home)	`ホームディレクトリの属性を設定 (set home directory attributes)`	`25`	ユーザーのホームディレクトリに関する事項(場所、アクセス権、初期内容)を、ユーザーマネージャを使用して管理者が設定できるようにする。
ラベル (Labels)	`ユーザーのラベルを設定 (set user labels)`	`20`	ユーザーに割り当てられている各種ラベル関連の情報 (ユーザーの最下位ログインラベル、認可上限、ラベル表示、ラベル変換属性) を、ユーザーマネージャを使用して管理者が設定できるようにする。
プロファイル (Profiles)	`ユーザーのプロファイルを設定 (set user profiles)`	`22`	ユーザーへのプロファイルの割り当てを、ユーザーマネージャを使用して管理者が設定できるようにする。
役割 (Roles)	`役割リストを設定 (set roles list)`	`24`	ユーザーがなることができる役割を、ユーザーマネージャを使用して管理者が選択できるようにする。
アイドル (Idle)	`アイドル時間を設定 (set idle time)`	`23`	アイドル時間の設定、およびワークステーションが指定の期間アイドル状態となった場合に実行するコマンドを、ユーザーマネージャを使用して管理者が設定できるようにする。

注 -

上の表に示したデフォルトの承認を使うと、特定の役割が、自分自身を除く、他のすべてのユーザーアカウントおよび役割アカウントの情報を変更できます。たとえば、「ユーザーのパスワードを設定」承認を使うことにより、セキュリティ管理者は、自分自身を除く他のすべてのアカウントのパスワードのオプションを設定できます。

自分自身の役割に関する情報を指定するための承認

「自分を変更することを許可」承認を特定の役割に与えると、その役割は自分自身の役割アカウントの承認情報を指定できるようになります。デフォルトでは、どちらの管理役割のプロファイルもこの承認を持ちません。

「自分を変更することを許可」承認を持つ役割は、自分自身のために、すでに必要な承認を持っている属性だけを構成できます。たとえば、管理者役割が「自分を変更することを許可」特権をセキュリティ管理者役割に割り当てられている実行プロファイルに追加した場合、セキュリティ管理者役割は自分のアカウントのセキュリティ関連の事項だけを指定でき、その役割に承認されていない事項 (「識別 (Identify)」ダイアログボックスの設定など) は指定できません。

注 -

「自分を変更することを許可」承認を許可しても、役割がその役割アカウント自身に割り当てられたプロファイルを編集することはできません。

2 つの役割による分割管理を取らない場合

サイトのセキュリティポリシーが許すならば、セキュリティ管理者役割は、管理作業を 2 つの役割に分割するのではなく、単一の結合された管理役割を作成できます。

セキュリティポリシーがデフォルトのセキュリティ管理者役割と管理者役割の能力を結合することを許す場合、新しい役割を作成して、root 役割の能力を拡張することをお勧めします。

注意 -

サイトのセキュリティポリシーが許すならば、NIS+ クライアントから NIS+ 管理を行うことができるように root の能力を拡張することも可能ですが、お勧めできません。これを行うには、nisgrpadm(1) コマンドを使って、root が使うすべての NIS+ クライアントの名前を NIS+ グループ admin に追加します。「スーパーユーザーまたは新しい役割が NIS+ を管理できるように設定するには」を参照してください。

注 -

単一の結合された管理役割を作成する場合、この役割には、両方の役割のプロファイル内に指定されているすべての承認とともに、「自分を変更することを許可」承認を与えるようにしてください。また、デフォルトの oper 役割に割り当てられているプロファイル内に指定されている承認を与えることも可能です。

管理役割によるリモートログインの許可

Trusted Solaris と Solaris の両方において、ある条件下では任意のアカウントがリモートログインでき、別の条件下では「リモートログイン」承認を持つアカウントだけがリモートログインできる場合もあります (承認が必要な条件とログインの種類については、「リモートログインの管理」を参照してください)。デフォルトの管理役割は「リモートログイン」承認を持っていますが、管理役割によるリモートログインには追加の手順が必要です。セキュリティ管理者役割は、管理役割がログインできるホストごとに、その /etc/default/login ファイルの設定を変更する必要があります。「任意の役割がリモートログインできるように設定するには」を参照してください。

新しい役割の作成

管理者役割とセキュリティ管理者役割は、一緒に実行して新しい役割のアカウントを設定します。また、セキュリティ管理者役割は管理者役割とともに新しいアカウントを構成する前に、新しい役割のプロファイルを作成する必要があります。作成方法については、後述の手順を参照してください。

役割のための新しいプロファイルを作成する前に、セキュリティ管理者はその役割が作業の実行に使用するコマンドがどのような特権を必要とするかを分析しなければなりません。詳細は、第 16 章「ソフトウェアの追加」および priv_desc(4) のマニュアルページを参照してください。このマニュアルページには、そのようなコマンドに必要となる必須特権および無効化特権を決定する方法が述べてあります。

必須特権

あるコマンドまたはそのオプションの実行には特権が必要となる場合、そのような特権を「必須特権」(または「操作特権」)と呼びます。必須特権は、Trusted Solaris のマニュアルページでは「なければなりません (must have)」という説明付きで示されています。たとえば、「ifconfig(1M) コマンドはネットワークインタフェースを変更するための sys_net_config privilege 特権を持っていなければなりません」という具合です。

必須特権がコマンドに強制されていない場合、あるいは、secadmin がユーザーの実行プロファイル内のコマンドに必須特権を指定していない場合、そのコマンドまたはオプションは動作しません。

無効化特権

「1 つまたは複数の DAC または MAC 検査にパスしなかった場合には、そのコマンドは失敗する」には、「無効化特権」が必要となります。必須特権と同じように、無効化特権は、それを与えることによりユーザーの権限がユーザーの信頼レベルを超過しないこと、およびそのプロファイルに指定されている作業の範囲を超えた動作を可能にしないことを確認の上、セキュリティ管理者の指示により割り当てられます。マニュアルページでは、このようなアクセス制限を無効化するのに使われる特権の名前は ERRORS セクションに記述されています。ファイルやディレクトリに関する DAC または MAC 検査を無効化するのに使われる無効化特権を次に説明します。

DAC 無効化特権

DAC 無効化特権には、file_dac_read と file_dac_write があります。ユーザーがファイルに対する DAC アクセスを持たない場合、セキュリティ管理者は、そのファイルに対するアクセスの種類 (読み取り、書き込み、またはその両方) に合わせて、どちらかの特権を対応するコマンドに割り当てます。

MAC 無効化特権

MAC 無効化特権には、file_mac_read と file_mac_write があります。ユーザーがファイルに対する MAC アクセスを持たない場合、セキュリティ管理者は、そのファイルに対するアクセスの種類 (読み取り、書き込み、またはその両方) に合わせて、どちらかの特権を対応するコマンドに割り当てます。

無効化特権を使わない方法

プロファイル機構を使うと、セキュリティ管理者役割は、プログラムが代替 UID または GID、あるいは特定のラベルを使って、無効化特権を使わずに動作できることを指定できます。たとえば、DAC 特権の必要性をなくすには、セキュリティ管理者は、コマンドが別のユーザー ID (通常は、root ID 0) または別のグループ ID を使って、そのアクセス権または ACL に基づいてファイルまたはディレクトリにアクセスできることを実行プロファイルに指定します。

また、たとえば、あるプログラムがあるラベルのファイルを書き込みまたは読み取る必要があるとき、MAC 特権の必要性をなくすには、セキュリティ管理者は、そのプログラムが指定されている実行プロファイルにそのラベルを指定します。

セキュリティポリシーの範囲内でのセキュリティ属性の使用

コマンドがその作業の実行に必要とする特権や他のセキュリティ属性を確認した後、セキュリティ管理者役割は、そのコマンドおよび役割が、サイトのセキュリティポリシーに違反することなく、特権やその他のセキュリティ属性を使用できるだけの信頼性があることを確認する必要があります。

マニュアルページを参照してプロファイルに mount コマンド用の設定を行う例

mount(1M) コマンドは、管理者役割に割り当てられている System Maintenance プロファイルに指定されています。ここでは、セキュリティ属性の指定がどのように行われるかを示す非常に簡単な例を示すことにします。Solaris および他の UNIX オペレーティングシステムでは、一般ユーザーがオプションなしの mount コマンドを実行すると、現在マウントされているファイルシステムの名前が表示されます。ただし、root になって実行するとき、mount コマンドは、管理者 (スーパーユーザー) によって、そのコマンド行や vfstab(4) に指定したファイルシステムをマウントするのに使われる場合もあります。この場合、mount コマンドはそれを呼び出したユーザーの UID が 0 であるかどうかを検査します。

Trusted Solaris では、一般ユーザーが使用する mount コマンドの動作は Solaris の場合と同じです。しかし、管理作業を行うとき、mount は root の UID だけではなく特権も検査します。

mount(1M) のマニュアルページには、ファイルシステムをマウントするときに使われるコマンドには sys_mount 特権が必須特権であると記述されています。また、mount コマンドは、マウントポイントとマウントされるデバイスの両方に DAC と MAC の両方のアクセス権を持っている必要があります。これらのアクセス権を持っていない場合は、DAC または MAC 無効化特権が必要です (Intro(2) のマニュアルページを参照)。マウントされるファイルシステムにマウント時間セキュリティ属性が (-S オプションで) 指定されている場合、追加の無効化特権が必要になる可能性もあります。

mount (1M) のマニュアルページには、mount がファイルシステムを任意のラベルでマウントする場合、あるいは、すべてのマウント時間属性を指定する場合、セキュリティ管理者はプロファイルにおいて、次のすべての操作特権および必須特権 (file_mac_read、file_dac_read、file_mac_write、file_dac_write、 file_mac_search、file_dac_search、net_privaddr、proc_setsl、 proc_setil、sys_mount、および sys_trans_label) を mount コマンドに割り当てる必要があると記述されています。

デフォルトの役割向けに実行プロファイルをカスタマイズ

実行プロファイルを役割ごとにカスタマイズするために 4 つのカスタム役割実行プロファイルが用意されていますが、それを次の表に示します。

表 4-3 カスタム役割プロファイル


Custom Admin Role
Custom Root Role
Custom Secadmin Role
Custom Oper Role

これらのプロファイルを使うことによって、役割プロファイルにどのような変更が行われたかが常に記録されます。各役割の (単一の) プロファイルにまとめて変更を行うことによって、デバッグが簡単になり、サービス要求を行うときにもシステムの状態を伝えやすくなります。どのプロファイルに対して、どの役割が変更を加えるかに関して、次のような制約があります。

セキュリティ管理者の役割を持った者は、セキュリティ管理者役割以外のすべての役割のカスタム役割プロファイルをカスタマイズすることができる
セキュリティ管理者役割をカスタマイズすることができるのは、root 役割 (スーパーユーザー) だけである

そのサイトのセキュリティポリシーに抵触しない限り、root 役割は、Custom Secadmin Roleに「自分を変更することを許可」承認を加えることができるので、セキュリティ管理者は、セキュリティ管理役割をカスタマイズすることができます。

「管理役割をカスタマイズするには」を参照してください。

adminvi から vi への名前の変更

デフォルトでは、すべての役割に、vi(1) ではなく、制限付きエディタ adminvi(1M) が割り当てられています。また、デフォルトでは、dtterm(1) 端末もすべての役割に割り当てられています。役割が adminvi ではなく vi と間違って入力した場合、次のエラーメッセージが表示されます。

vi: command not in profile

/etc/security/tsol/home/role_name ディレクトリにあるすべての役割用のデフォルトの profile(4) ファイルには、次のような adminvi を vi に変更する別名機能があります。

vi() { adminvi $1 ; }

この別名は、役割が使う各ホストの $HOME/.Xdefaults-hostname ファイルに次のようなエントリを入力するまで機能しません。役割が作業する SLD ごとに、このファイルのコピーが存在する必要があります。

Dtterm*LoginShell: true

どのスタートアップファイルが読み込まれるかの詳細は、第 3 章「ユーザーアカウントの管理」「Trusted Solaris システムにおけるスタートアップファイルの管理」を参照してください。.Xdefaults-hostname にそれをサポートするエントリを入力するための手順については、「dtterm により新規シェルをログインシェルとして起動させるには」を参照してください。

役割のデフォルトエディタとしての trusted_edit の割り当て

/usr/dt/bin/trusted_edit スクリプトは、$EDITOR 環境変数を使用した編集ウィンドウを起動するラッパー (wrapper) です。これは、すべての変更内容を監査します。trusted_edit を役割用のエディタとして使用するには、セキュリティ管理者は、trusted_edit スクリプトをアカウントの有効な実行プロファイルに追加し、proc_audit_tcb 特権をスクリプトに割り当てます。

必要に応じて、セキュリティ管理者あるいはそれの影響を受ける役割担当者は、trusted_edit を vi として使用することができます。その手順については、「trusted_edit エディタを役割に割り当てるには」を参照してください。

役割を管理する手順

スーパーユーザーまたは新しい役割が NIS+ を管理できるように設定するには

NIS+ マスターにログインし、セキュリティ管理者役割になります。

NIS+ マスターにログインし、nisgrpadm(1) コマンドを使って、NIS+ グループ admin にエントリを追加します。
1. スーパーユーザーが NIS+ クライアントから NIS+ を管理できるように設定するには、nsgrpadmin -a、管理グループ名、およびスーパーユーザー役割が NIS+ をリモート管理したいすべての NIS+ クライアントの完全修飾名を (この順番で) 入力します。
  $ nisgrpadm -a admin fully_qualified_hostname . . .
  たとえば、次の行は、sun.com の security ドメインに 2 つのホスト (trusted と trustworthy) を追加します。
  $ nisgrpadm -a admin trusted.security.sun.com. trustworthy.security.sun.com.
2. 新しい役割が NIS+ クライアントから NIS+ を管理できるように設定するには、nsgrpadmin -a、管理グループ名、および新しい役割の完全修飾名を (この順番で) 入力します。
  $ nisgrpadm -a admin role's_principal_name . . .
  たとえば、次の行は、sun.com の security ドメインに新しい役割を追加します。
  $ nisgrpadm -a admin newrole.security.sun.com.

任意の役割がリモートログインできるように設定するには

注 -

他のリモートログインの前提条件については、「リモートログインの管理」と「管理役割によるリモートログインの許可」を参照してください。

次の手順は、役割がリモートログインするホストごとに行います。

ログインし、セキュリティ管理者役割になります。

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

「管理用エディタ (Admin Editor)」アクションを使って、/etc/default/login ファイルを開いて編集します。

CONSOLE 行をコメントアウトします。
#CONSOLE=/dev/console

新しい役割を設定するには

新しい役割の責任を定義します。また、その役割が作業を行うのに必要とするコマンド、アクション、承認を定義します。

コマンドがその作業に特権や他のセキュリティ属性を必要とするかどうか、役割とコマンドがそのセキュリティ属性を信頼できる方法で使用できるかどうかを決定します。

役割が新しい実行プロファイルを必要とするかどうかを決定します。必要とする場合はそれを作成します。

「プロファイルマネージャ (Profile Manager)」を使って新しいプロファイルを作成する方法については、第 8 章「ユーザーおよび役割のための実行プロファイルの管理」を参照してください。既存のプロファイルとそのコマンド、アクション、承認の一覧については、付録 A 「プロファイル概要テーブル」を参照してください。

新しい役割のためのアカウントを作成します。

役割アカウントを作成するための前提知識と手順については、第 5 章「ユーザーマネージャを使ったアカウントの設定」を参照してください。

NIS+ グループ admin に新しい役割用のエントリを作成します。

必要であれば、「スーパーユーザーまたは新しい役割が NIS+ を管理できるように設定するには」を参照してください。

trusted_edit エディタを役割に割り当てるには

trusted_edit コマンドが役割の実行プロファイルに含まれていないときは、次のことを行なってください。

ログインし、セキュリティ管理者役割になります。

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

trusted_edit コマンドをアカウントの実行プロファイルの 1 つに追加します。

必要に応じて、「管理役割をカスタマイズするには」を参照してください。

/usr/dt/bin/trusted_edit スクリプトを追加します。

スクリプトに proc_audit_tcb 特権を与えます。

注 -
残りの手順は、プロファイル内で「管理用エディタ (Admin Editor)」アクションが割り当てられている secadmin などの役割だけが実行できます。

下記の手順で、別名で trusted_edit を vi コマンドに変更します。
1. /etc/security/tsol/home/role_name のホームディレクトリ内で .profile ファイル内の vi 機能を検索します。
  vi() {adminvi $1;}
2. adminvi を trusted_edit と置き換えます。
  vi() {trusted_edit $1;}
3. 次のエントリがユーザーが作業する各 SLD の $HOME/.Xdefaults-hostname ファイルにもあることを確認します。
  Dtterm*LoginShell: true
  注 -
  このファイルは、役割が使うホストごとに作成します。たとえば、役割が trusted と trustworthy というホストで作業する場合、SLD ごとに、$HOME/.Xdefaults-trusted と $HOME/.Xdefaults-trustworthy のファイルを作成します。
注意 -
trusted_edit はウィンドウを起動するため、コマンド行編集用には使うことができません。リモートログインセッションでは、コマンド行編集が唯一の選択肢である可能性もあります。したがって、役割がリモートでコマンド行編集を行わないことが判明している場合以外には、役割が利用できるエディタとして trusted_edit だけを割り当てることは避けてください。

第 5 章ユーザーマネージャを使ったアカウントの設定

この章では、ユーザーアカウントや役割アカウントを指定する際に必要となる情報の種類を詳しく説明し、ユーザーマネージャを使用したアカウントの追加手順および変更手順を示します。この章には、次の項目があります。

注 -

ユーザーマネージャ、ユーザー名、およびユーザー ID という用語は、Solstice 版のユーザーマネージャとの互換性を保つために使われています。Trusted Solaris 版のユーザーマネージャは、ユーザーのアカウントだけでなく、役割アカウントの設定も行います。この章での「ユーザー名」とは実際にはアカウント名のことであり、これは、ユーザーまたは役割がシステムによる ID 認証を得るために使用する文字列を意味します。また、この章での「ユーザー ID」とは、実際にはユーザーアカウントか役割アカウントのどちらかに適用される ID を意味します。

ユーザーマネージャの各種ダイアログボックスに入力する情報の概要

セキュリティ管理役割およびシステム管理役割は、ユーザーマネージャに表示されているボタンを押すと表示される各種のダイアログボックスを使って、ユーザーや役割のアカウント情報を入力します。責任の分割や、各ボタンにアクセスするのに必要となる承認については、第 3 章「ユーザーアカウントの管理」および第 4 章「役割の管理」を参照してください。

各種のダイアログボックスを起動するボタンを次の図に示します。

図 5-1 ユーザーマネージャの「ナビゲータ (Navigator)」ダイアログボックス

識別情報

管理者役割は、「識別情報 (Identity)」ダイアログボックスで次のようなアカウント情報を入力します。

ユーザーまたは役割を「識別」するための名前と番号
ユーザーまたは役割の一次グループおよび (オプションの) 二次グループ
コメント
デフォルトのシェル (コマンドインタプリタ)
作成するアカウントの種類 (一般、非管理役割、管理役割)

ユーザー名、ユーザー番号、グループ名、グループ ID 番号

アカウント名には一意の名前 (ユーザー名) と一意の番号 (ユーザー ID または UID) が必要です。

注意 -

システムが同一である限り、ユーザー名およびユーザー ID は決して再利用しないようにしてください。ユーザー名や UID を再使用しないことによって、アーカイブファイルを復元したり、監査記録を分析したりするときにどのユーザーが何をし、どのファイルを所有していたかについての混乱を防ぐことができます。

作成するアカウントがユーザー用か役割用かに応じて、アカウントのユーザー名、ユーザー ID、グループ名、グループ ID 番号を以下の要領で入力します。

これらの情報はすべて、アカウントのためにコマンドを実行する個々のプロセスに関連付けられます。
これらの情報はすべて、アカウントにより作成されたファイルやディレクトリに関連付けられます。
これらの情報はすべて DAC 判定に使用され、標準の UNIX のファイルまたはディレクトリのアクセス権およびアクセス制御リスト (ACL) に基づいて、ユーザーが特定のファイルやディレクトリに対するアクセス許可を持つかどうかが判定されます。
一般ユーザーアカウントの場合、ログインの際にユーザー識別と承認のために、ユーザー名の入力を求められます。
役割アカウントの場合、トラステッドパスを通じてユーザーがその役割になる際にユーザー名の入力を求められます。
一般ユーザーアカウントの場合、UID は監査 ID になります。監査 ID は、ユーザーが行なった監査可能なアクションにより生成される監査レコード内に格納されます。ユーザーがログインセッション中に特定の役割になり、その役割の UID で作業を始める場合でも、同ログインセッション中の監査 ID は同じままになります。監査 ID を使うと、管理者は監査アクションをどのユーザーが実行したかをトレースできます。

入力前に決定すべき事項

自サイトの規定に応じてアカウントのユーザー名を決定すること。
- アカウント名の長さは 8 文字です。
- アカウント名は、ネットワーク内で重複しないこと。
- アカウント名は、そのシステムが同一である限り、再使用はしないこと。
アカウントのユーザー ID (UID) を決定すること。UID はユーザー名とともに、システムでのアカウントの識別に使用される。
- UID は、ネットワーク内で重複しないこと。
- UID は、システムが同一である限り、再使用はしないこと。
ユーザーが所属する一次グループまたは二次グループを決定すること (二次グループはオプション)。
- 新しいアカウントに割り当てるための、利用可能なグループ名および GID 番号が必要です。

ユーザーマネージャ内の入力場所

「識別情報を指定または変更するには」、手順 3、手順 4、手順 5 を参照のこと。

ユーザーアカウントの場合、「コメント (Comment)」には、ユーザーの氏名、役職、電話番号などを入力します。ここに入力した情報は passwd(1) エントリの GCOS フィールドに格納されます。「コメント (Comment)」フィールドに入力したテキストは、そのユーザーが送信する電子メールの「From:」フィールドとして、また finger(1) コマンドの出力の一部として使用されます。このフィールドが使用された例を以下に示します。

From: Roseanne Sullivan -- Manual Laborer

役割アカウントの場合、任意のコメントを入力します。

入力前に決定すべき事項

サイトの使用に応じたコメントを入力すること。

ユーザーマネージャ内の入力場所

「識別情報を指定または変更するには」、特に手順 6 を参照のこと。

シェル

管理者役割は、ユーザーまたは役割アカウントが使用するデフォルトのシェルを選択できます。指定できるシェルには、Bourne シェル、Korn シェル、C シェル、プロファイルシェルなどがあります。Bourne シェル、Korn シェル、C シェルを使用すると、アカウントは特権を継承する必要のないコマンドをすべて実行することができます。それに対して、プロファイルシェル上で作業する場合は、アカウントが実行できるのはそのアカウントのプロファイルにあるコマンドだけになります。

プロファイルシェルは、同シェル内でユーザーがコマンドを実行するたびに、プロファイルデータベースを調べ、そのコマンドがユーザーの実行プロファイルに存在するかどうか、そして何らかの特権がそのコマンドに継承されるかまたは他の特別な属性がそのコマンドに適用されるかどうかを判断します。そのコマンドの実行時に、データベースに指定されているそのコマンド用の継承可能な特権または他の属性や、アカウントの実行プロファイルに指定されている承認が利用可能となります。

プロファイルシェルを使ったアカウントへの制限付与

プロファイルシェルを使うとユーザーの機能を制限できます。プロファイルシェルは、他のシェルとは異なり、ユーザーが使えるコマンドを指定のコマンド集合に制限できます。

プロファイルシェルを使ったアカウントへの特権付与

プロファイルの機能を使うと、一部のユーザーにしか使用できない特権付きのコマンドが使用できる承認を特定のアカウントに与えることができます。

注 -

プロファイルシェルは、コマンドを実行するプロセスに特権を継承させる、あるいは、拡張された属性で実行させることができる唯一のシェルです。アカウントにどんなデフォルトシェルが割り当てられていても、すべてのアカウントは、別のシェルのコマンド行からプロファイルシェルを呼び出すことができます。

入力前に決定すべき事項

アカウントのシェルを識別すること。

ユーザーマネージャ内の入力場所

「識別情報を指定または変更するには」、特に手順 7、手順 8 を参照のこと。

アカウントの種類

管理役割は、アカウントを一般ユーザーとして作成するか、それとも非管理役割や管理役割として作成するかを決定します。新しい役割アカウントを作成する場合にのみ、非管理役割または管理役割のいずれかを選択してください (詳細は、第 8 章「ユーザーおよび役割のための実行プロファイルの管理」を参照のこと)。

入力前に決定すべき事項

一般のユーザーアカウントを設定する場合には「一般ユーザー」を選択する。

これを選択した後でも、「役割」ダイアログボックスを使えば、特定のユーザーが既存の役割になれるように設定できます。
新しい管理役割を設定する場合には「管理役割」を選択する。
新しい非管理役割を設定する場合には「非管理役割」を選択する。

ユーザーマネージャ内の入力場所

「識別情報を指定または変更するには」、特に手順 9 を参照のこと。

パスワード

セキュリティ管理者役割は、「パスワード (Password)」ダイアログボックスで次のことを行います。

アカウント用のパスワードを生成するか、または 3 つのオプションから選択する。
ユーザーがパスワードを変更できるようになるまでの期間を指定する。
ユーザーがパスワードを変更しなければならなくなるまでの期間を指定する。
パスワードの有効期限よりもどれくらい前に警告を送信するかの指定
ユーザーがトラステッドパス経由でパスワードを変更する場合に表示されるパスワード生成方法の選択
アカウントを「開く」、「閉じる」、または「常に開く」に指定する。
NIS+ 資格を使用するかどうかを指定。

パスワード作成や他のパスワードオプションに関する前提知識

アカウントを設定する際、セキュリティ管理者役割は、ユーザーまたは役割用にパスワードを生成します。その後、セキュリティ管理者は、生成したパスワードを新しいユーザーに渡し、最初のログインで使用できるようにします。これ以降、ユーザーが自分のアカウント用のパスワードをいつ変更できるようにするか (またはいつ変更しなければならないようにするか) は、セキュリティ管理者役割の判断に任されます。パスワードの文字数は、8 文字でなければなりません。セキュリティ管理者役割のアカウントや、その役割になることが許可されているユーザーは、「常に開く」に指定する必要があります。役割アカウントのパスワードは、パスワードの使用期限に左右されないようにすべきです。

ユーザーが管理役割になることが許可された場合、セキュリティ管理役割は、役割用のパスワードをそのユーザーに渡します。役割用のパスワードは、役割アカウントに直接ログインするためには使用できません。ログイン後トラステッドパスメニューの役割になるためのオプションを使って特定の役割になろうとするユーザーの認証を行うために使われます。

一般のユーザーであれ役割であれ、指定のアイドル時間が経過したため画面が自動的にロックされた場合には、自分のパスワードを使って再認証を行う必要があります。ユーザーが自分のパスワードを忘れた場合などには、セキュリティ管理者役割は、そのユーザーのための新しいパスワードを生成します。セキュリティ管理者役割は、自分自身を除くすべてのアカウント用のパスワードを変更できます。

注 -

Trusted Solaris 環境では、ユーザーや管理役割は、passwd(1)、 yppasswd(1)、nispasswd(1) のいずれのコマンドも使用できません。セキュリティ管理者は、ユーザーマネージャを使ってアカウントのパスワードを変更できます。各アカウントのパスワードを変更するには、いったんログインしてシステムの認証を受けた後、トラステッドパスメニューの「パスワード変更 (Change Password)」オプションを使わなければなりません。一般ユーザーは、ユーザーのワークスペース内でトラステッドパスメニューを使ってパスワードを変更します。特定の役割になっているユーザーは、役割ワークスペース内でトラステッドパスメニューを使ってパスワードを変更します。

「パスワード」メニューからどちらかが選択された場合、セキュリティ管理者は、選択された方法を使って、そのユーザー用のパスワードを直ちに生成するよう求められます。

注 -

「パスワード」メニューでは「パスワードの入力」オプションおよび「リストから選択」オプションだけを使うようにしてください。これは、両オプションだけが Trusted Solaris のセキュリティポリシー (ユーザーのログインとパスワードの認証、信頼性) に合致しているためです。その他のオプションは、熟練したセキュリティ管理者が、そのオプションを使用することがサイトのセキュリティポリシーの範囲内で必要かつ妥当であると判断した場合にのみ使うようにしてください。推奨以外のオプションを使用すると、システムがより脆弱になり、しかもシステムの保守が困難になることを十分考慮してください。

表 5-1 パスワード生成オプションに関する説明と推奨事項


パスワード生成オプション	説明
`アカウントを凍結`	このオプションを選択すると、無効なパスワードが入力された場合にアカウントがロックされます。このロックは、新しいパスワードが割り当てられるまで解除されません。ロックが解除されない限り、アカウントはファイルは所有できますが、ログインはできません。注 - このオプションは、Trusted Solaris 1.x で使われていたものとは、セキュリティ属性が指定されるまでアカウントを凍結するという点で異なっています。Trusted Solaris 2.x および 7 では、その目的には「状態」メニューの「閉じる」オプションが使われます。詳しくは表 5-3 を参照してください。
`パスワードなし -- setuid 処理のみ有効`	このオプションは、ファイルは所有できるがログインはできないという特殊なアカウントを設定します。ユーザーまたは役割アカウント用には、このオプションは選択されません。このオプション付きで設定されたアカウントは、 `setuid` 機能を使って自分の ID をアカウントの ID に変更するプログラムによって使用されます。このようにすると、指定のプログラムが、そのアカウントが所有するファイルにアクセスできるようになります。デフォルトシステムに存在するこのタイプのアカウントには、`lp` および `uucp` があります。パスワードを持たないアカウントを作成することにより、システム侵入を目的としてこれらのアカウントのパスワードが推測されるリスクを回避できます。
`パスワードの入力`	このオプションを選択すると「パスワードを設定」ダイアログボックスが表示されます。このダイアログボックスを使って、管理役割はアカウントのパスワードを入力できます。
`リストから選択`	このオプションを選択すると「パスワードの生成」ダイアログボックスが表示されます。セキュリティ管理者役割は、このダイアログボックスに表示される自動生成されたパスワードの一覧から、指定のアカウント用のパスワードを選択できます。

入力前に決定すべき事項

選択したパスワードをキーボードから入力するか、それとも自動生成されたリストから選択するかを決定すること。

ユーザーマネージャ内の入力場所

「パスワード情報を指定または更新するには」、特に手順 1 を参照のこと。

パスワードの期間および警告のフィールドに関する前提知識

パスワード変更に関するオプションを設定することで、侵入者がパスワードの推測または盗むことに成功したとしても、システムへのアクセスを試みる期間を制限できます。パスワードの変更が可能となるまでの最小経過時間を設定すると、新しいパスワードを与えられたユーザーがそれを直ちに古いパスワードに戻すことを抑止できます。役割アカウントのパスワードは、パスワードの使用期限に左右されないようにすべきです。

入力前に決定すべき事項

ユーザーが自分のパスワードを変更できるようになるまでの経過時間を決定すること。
ユーザーが自分のパスワードを変更しなければならなくなるまでの経過時間を決定すること。これには次の指定方法がある。
- 「最長有効日数」フィールドに何日、何週間、何か月のいずれかを入力する。
- 「有効期限」フィールドのメニューで年月日を選択する。
パスワードの期限失効日の何日前、何週間前、何か月前、あるいは何月何日にユーザーに警告を送信するかを決定すること。

ユーザーマネージャ内の入力場所

「パスワード情報を指定または更新するには」、特に手順 4、手順 5 を参照のこと。

パスワード生成方法の選択に関する前提知識

「変更方法」メニューで選択されたパスワード生成方法に応じて、アカウントがトラステッドパスメニューを使ってパスワードを生成する時に表示されるダイアログボックス (手動生成または自動生成) が決定されます。

次の表に示した規則が有効になるのは、アカウントがトラステッドパスメニューから「パスワードを変更 (Change Password)」オプションを選択し、パスワードを手動で変更することが許可されたときです。

表 5-2 手動生成パスワードに関する規則


規則
最大文字数は 8 であること。
パスワードは少なくとも 2 つのアルファベットを含んでいなければならない。
パスワードは少なくとも 1 つの数字または特殊記号を含んでいなければならない。
パスワードはユーザーのログイン名 (ログイン名の文字順を逆にしたもの、文字を循環シフトしたものも含む) とは異なっていなければならない。(この場合、大文字小文字の区別は無視される)
新しいパスワードは、古いパスワードとは異なる文字を少なくとも 3 文字含んでいなければならない (この場合、大文字小文字の区別は無視される)。

注 -

ユーザーマネージャを使って生成されたパスワード、およびパスワード生成ソフトウェアにより生成されたパスワードに関する規則は、表 5-2 に示したものとは若干異なっています。たとえば、自動生成されたパスワードは数字を含みません。ユーザーマネージャが生成したパスワードは、手動生成したパスワードの規則を完全には満足していませんが、これらのパスワードもシステムにより受け入れられます。セキュリティ管理者役割としては、表 5-2 に示した条件を満たすパスワードを作成することを推奨します。「セキュリティの条件」も参照してください。

入力前に決定すべき事項

アカウントが自分のパスワードを選択できるようにするか、それとも自動生成されたリストからパスワードを選択しなければならないようにするかを決定すること。

ユーザーマネージャ内の入力場所

「パスワード情報を指定または更新するには」、特に手順 6 を参照のこと。

アカウント用の「状態」メニューのオプションに関する前提知識

「状態」メニューのオプションは、Trusted Solaris 版のユーザーマネージャに新しく追加されたものです。これらのオプションに関する説明と推奨設定を下の表に示します。

表 5-3 「状態 (Status)」メニューのオプションの説明と推奨設定


オプション	説明と推奨設定
`閉じる`	アカウントが完全に指定されるまで有効です。アカウントの凍結 (「パスワード (`Password`)」ダイアログボックスの最上部にある「パスワード (`Password`)」メニューで指定するもの) とは異なり、このオプションはアカウントのパスワードには影響しません。デフォルトでは、同じセッション内で不正なパスワードが 5 回入力された場合、アカウントの状態は自動的に「閉じる (Closed)」になります。この場合、`tsoluser(4)` パスワードファイルのこのユーザー用のエントリの lock フィールドに値 locked が指定されます。この場合、セキュリティ管理者は、ユーザーマネージャを使って、この値を「開く」にリセットしなければなりません。
`開く`	アカウントが完全に指定された後に、あるいは、自動的にロックされたアカウントを開き直すときに使います。セキュリティ管理役割は、ユーザーアカウントのセキュリティ関連特性を設定した後、このオプションを選択します。またログイン試行に 5 回失敗しアカウントがロックされた場合、システムの信頼性が脅かされていないことを確認してから、この値にリセットします。アカウントが完全に指定されるまで、ユーザーマネージャはこの値を受け入れません。
`常に開く`	不正なパスワードの入力が制限数まで到達した場合でも、アカウントを閉じない場合に使います。このオプションは、使用不能攻撃 (悪意のあるユーザーがログイン試行を繰り返すことで、特定のアカウントをクローズさせてしまう攻撃) を封じる必要性が、繰り返しのパスワード推測によるシステム侵入を防ぐ必要性よりも大きいと判断した場合にも使用できます。

注 -

デフォルトでは、ローカルホストに対して、ログインの試行に 5 回失敗すると、アカウントが閉じられてしまいます。必要に応じて、「パスワード入力ミス許容回数の最大値の変更」を参照。セキュリティ管理者役割は、アカウントのオプションとして「常に開く」を選択すると、トラステッドアカウントをこの制約から免除することができます。

入力前に決定すべき事項

アカウントのステータスを決定すること。

ユーザーマネージャ内の入力場所

「パスワード情報を指定または更新するには」、特に手順 7 を参照のこと。

NIS+ 用の「認証テーブルの設定」フィールドを選択する場合の注意点

「認証テーブルの設定 (Cred. Table Setup)」フィールドの隣にあるトグルボタンをクリックすると、NIS+ 主体の公開鍵および非公開鍵が cred テーブルに追加されます。これにより、アカウントは NIS+ 主体として設定され、そのアカウントのパスワードが NIS+ データベースに追加されます。詳細は、『Solaris ネーミングの管理』の第 5 章「NIS+ 資格の管理」を参照してください。

入力前に決定すべき事項

「認証テーブルの設定 (Cred. Table Setup)」ボックスを選択して、NIS+ 資格を設定するかどうかを決定すること。

ユーザーマネージャ内の入力場所

「パスワード情報を指定または更新するには」、特に手順 8 を参照のこと。

ホームディレクトリ

「ホーム (Home)」ダイアログボックスでは、管理者役割は次のことを設定します。

ホームディレクトリを自動作成するかどうか
ホームディレクトリのパス名
ホームディレクトリを提供するサーバーの名前
シェル初期化ファイルを含むスケルトンパスの名前
望ましいホームディレクトリの DAC アクセス権
アカウントのメールサーバーの名前
ホームディレクトリを自動マウントするかどうか

注 -

アカウントを作成する前にアカウントのホームディレクトリを提供するサーバーを設定しておく必要があります。

ホームディレクトリの自動作成を選ぶ理由

管理者役割がホームディレクトリの自動作成をシステムに指示しなかった場合、管理者役割は、ユーザーがログインする前に、MLD としてのホームディレクトリを手動で作成しなければなりません。この方法では、アカウントが初めてログインしたときにスタートアップファイルも自動的に初期 SLD にコピーされるため、ホームディレクトリを自動作成することをお勧めします。

スケルトンパスに関する注意点

シェルのスタートアップファイル用のスケルトンパスを指定するよう求められた場合、デフォルトのスケルトンパスである /etc/skel を指定すると、あらかじめ提供されているすべてのシェル用のスタートアップファイル (local.cshrc、local.login、local.profile) が、アカウントのホームディレクトリにコピーされます。その後、各アカウントは、それらのコピーされたファイルのうち適切なものを選んでリネームし、自分のシェルで使用しないファイルは削除しなければなりません。たとえば、ユーザーのログインシェルが C シェルの場合、そのユーザーは local.profile を削除します。さらに、local.cshrc および local.login を適切に変更した後、これを .cshrc および .login にリネームします。

注 -

管理者が設定を特に変更しなければ、アカウントのデフォルトシェルが pfsh(1M) でないならば、ウィンドウシステムの起動時には .login および .profile のどちらも参照されません。また、スケルトンディレクトリ内のファイルは、ホームディレクトリ内のアカウントの初期機密ラベルで作成された最初の SLD にコピーされますが、その後、管理者またはユーザーは、他の機密ラベルで 2 番目以降に作成されたすべての SLD にも、これらのスタートアップファイルが確実にコピーされるようにする必要があります。スタートアップファイルに関する詳細は、第 3 章「ユーザーアカウントの管理」「Trusted Solaris システムにおけるスタートアップファイルの管理」を参照してください。

シェル初期化ファイルの使用を制御するには

ユーザーのログインシェルが Bourne シェル、Korn シェル、C シェルのいずれかに指定されている場合、デフォルトでは、ログイン時にシェル初期化ファイルは参照されないことに注意してください。これは、デフォルトでは、*.dtprofile ファイル内の対応する変数がコメントになっているからです。*.dtprofile ファイル内の他のコメントにも書かれていますが、ログイン時にシェル初期化ファイルが参照されるようにするには、初期化ファイルを正しく設定した後、このコメントをはずすようにしてください。なお、初期化ファイルのデフォルト設定を変更する場合には、その初期化ファイルがウィンドウシステムの起動中に、端末エミュレータやユーザーによる応答を必要とする処理を一切行わないように注意してください。

各ユーザーは自分の $HOME/.dtprofile ファイルを変更して、ウィンドウシステムの起動中、ユーザーのプロファイルが有効になる前に各種のコマンドが実行されるように設定することもできます。しかし、プロファイルシェルの持つ特殊な目的をサポートするために、ユーザーは自分のシェルが有効になる前に実行されるコマンドを指定することは許されません。このため、ユーザーのログインシェルがプロファイルシェルに指定されている場合、ログイン時に .profile ファイルは参照されますが、そのユーザーの $HOME/.dtprofile ファイルは参照されません。

詳しくは、第 3 章「ユーザーアカウントの管理」の「ログイン時に .login および .profile ファイルを自動的に読み取らせるには」および「Trusted Solaris システムにおけるスタートアップファイルの管理」を参照してください。

入力前に決定すべき事項

アカウントのホームディレクトリを提供するサーバーを決定すること。
アカウント用のマルチレベルホームディレクトリ (MLD) を自動生成するかどうかを決定すること。
/etc/skel または別のスケルトンディレクトリのどちらを使うか、さらに、その中にどのようなファイルを配置するかを決定すること。

シェル初期化ファイルをユーザーが独自に変更できるようにするか、それともサイト独自の管理者が管理するシェル初期化ファイルを提供するかを決定すること。後者を選択する場合、第 3 章「ユーザーアカウントの管理」の「各シェル用にシェル初期化ファイルを分離するには」の手順を実行する必要があります。
管理者が /etc/skel に各シェルごとにサブディレクトリを作成した場合、ユーザーのデフォルトシェルに応じて、ユーザーマネージャの「スケルトンパス (Skeleton path)」フィールドに正しい skelX サブディレクトリ名を入力する必要がある。
ユーザーが作成するファイルのデフォルトのアクセス権 (umask の設定) を決定すること。
アカウント用のメールサーバーを決定すること。
ホームディレクトリを自動マウントするかどうかを決定すること。

ユーザーマネージャ内の入力場所

「ホームディレクトリ情報を指定または変更するには」、特に手順 3、手順 4、手順 5、手順 6、手順 7、手順 8 を参照のこと。

ラベル

「ラベル (Labels)」ダイアログボックスでは、管理者役割は次のことを設定します。

認可上限
最下位機密ラベル
アカウントが管理ラベルを見ることを許可するかどうか、またはユーザーの認可範囲内で異なるラベルを見せるようにするか。
ユーザーが機密ラベルを見ることを許可するかどうか

認可上限と最下位ラベルに関する前提知識

認可上限とは、アカウントが作業を行える機密ラベル範囲のうちの最上位ラベルを定義するものです。管理役割は、認可上限として ADMIN_HIGH を持ちます。

アカウントの最下位機密ラベルとは、アカウントが作業を行える最も低いラベルのことです。管理役割は、最下位機密ラベルとして ADMIN_LOW を持ちます。初めてログインしたとき、最初のワークスペースは最下位ラベルで起動します。

最初のワークスペースのラベルは以降のセッションで変更してもかまいません。アカウントは次のような方法を使って、別のワークスペースが異なるラベルで起動するように指定できます。

(トラステッドパスメニューから「ワークスペースの機密ラベルを変更 (Change Workspace SL)」オプションを選択して) ワークスペースのラベルを変更し、次のうちの 1 つを行います。
「トラステッドデスクトップ (Trusted Desktop)」サブパネルの「デスクトップスタイル (Desktop Style)」ダイアログボックスを使って、次のうちのどちらかを行います。
- 「ホームセッションを設定 (Set Home Session)」オプションを使って、ワークスペースのラベルをホームセッションと同じ高いラベルに設定し、「ホームセッションに戻る (Return to Home Session)」を指定します。
- 「このセッションを再開 (Resume Current Session)」を指定し、現在のワークスペースのラベルが高いままログアウトします。

注 -

アカウントの持つ認可上限と最下位ラベルはどちらも、label_encodings(4) ファイル内の最上位機密ラベルよりも劣位でなければならず、かつ、そのユーザー認可範囲に定義されている最下位認可上限より優位でなければなりません。

入力前に決定すべき事項

アカウントの認可上限を決定すること。これは、label_encodings ファイルに定義されている最下位認可上限よりも優位であること。
このアカウントが作業することを許される最下位機密ラベルを決定すること。

ユーザーマネージャ内の入力場所

「ラベル情報を指定または変更するには」、特に手順 3、手順 4 を参照のこと。

ラベル表示に関する前提知識

「ラベル (Labels)」ダイアログボックスを使うことで、管理者役割は、ラベルがどのように表示されるかを指定できます。以下の説明では、「CMWラベル」という用語は、以下に示すような標準の形式で両者が表示される場合の情報ラベルおよび機密ラベルを指すものとします。これは、情報ラベルの長形式名 (INFORMATION LABEL) と任意の語の後に、機密ラベルの短形式名 (SL) と任意の語が表示されるものです。

INFORMATION LABEL [SL]

注 -

Trusted Solaris 7 以降では情報ラベルは使われません。ADMIN_LOW の固定された情報ラベルは各 CMW ラベルの一部ですが、情報ラベルセクションは無視されます。

ラベル表示

サイトによっては、管理ラベルの名前を機密情報扱いとする場合もあります。ラベル表示のダイアログボックスを使うと、セキュリティ管理者役割は、管理ラベルの ASCII 名を表示するかどうかを決定できます。管理ラベルのデフォルトの ASCII 名は ADMIN_HIGH および ADMIN_LOW です。セキュリティ管理者役割は、 label_encodings(4) ファイルに別の管理ラベル名を指定できるため、実際に表示されるラベル名はサイトによって異なる場合があります。管理ラベルは機密ラベル、認可上限内に表示されます。

注 -

セキュリティ管理者役割が別の名前を管理ラベルに割り当てる方法については、『Trusted Solaris のラベル管理』を参照してください。

システム全体のデフォルトのラベル表示は、label_encodings ファイルに設定されます。この場合、セキュリティ管理者役割は、インストール時にデフォルトの設定 INTERNAL を変更するかどうかを選択できます。ユーザーまたは役割アカウント用のラベル表示の場合、それぞれのアカウントを設定する際に、セキュリティ管理者役割は、以下のどれかを選択できます。

Internal (内部用)
External (外部用)
Sys Default (Sys デフォルト)

内部表示

「内部用」オプションを設定すると、アカウントは管理ラベルの名前を見ることができるようになります。管理ラベルの名前は、ADMIN_HIGH および ADMIN_LOW または各サイトの管理者が設定した名前になります。

外部表示

「外部用」オプションを設定されたアカウントは、管理ラベルの ASCII 名を見ることはできません。アカウントのラベル表示が「外部用」である場合、そのアカウントに対しては、ADMIN_LOW (または各サイトの管理者が設定した名前) の代わりに、ユーザー認可範囲内の同じ種類の有効な最下位ラベルが表示されます。また、アカウントのラベル表示が「外部用」に設定されると、ADMIN-LOW (または各サイトの管理者が設定した名前) の代わりに、ユーザー認可範囲内の同じ種類の有効な最上位ラベルが表示されます。

注 -

ラベル表示が「外部用」に設定された場合でも、バイナリラベルは変化しないことに注意してください。「内部用」との唯一の違いは、ラベルの持つ本当の名前ではなく、ラベルに別の名前が与えられて表示されるということです。

Sys デフォルト

アカウントに対して「Sys デフォルト」オプションを設定した場合、 label_encodings(4) ファイルに指定されている値のうち DEFAULT LABEL VIEW キーワードに対応するもの (EXTERNAL または INTERNAL のいずれか) がこのアカウント対して適用されます。

入力前に決定すべき事項

ユーザーが管理ラベルの名前を見ることを許すかどうかを決定すること。または、ユーザーに対して、ADMIN_LOW ラベルの代わりにユーザー認可範囲内の有効な最下位ラベルを表示するかどうか、ADMIN_HIGH ラベルの代わりにユーザー認可範囲内の有効な最上位ラベルを表示するかどうかを決定すること。

ユーザーマネージャ内の入力場所

「ラベル情報を指定または変更するには」、特に手順 5 を参照のこと。

SL の表示／非表示に関する前提知識

機密ラベルは、他の要素とともに次のような場所に表示されます。

画面の最下行にあるトラステッドパスインジケータ
ウィンドウ枠の上部
ウィンドウアイコンのタイトルバー

機密ラベルは角括弧 [ ] の内部に長形式名で表示されます。

入力前に決定すべき事項

機密ラベルを表示するかを決定すること。

ユーザーマネージャ内の入力場所

「ラベル情報を指定または変更するには」、特に手順 6 を参照のこと。

プロファイル

セキュリティ管理者役割は、アカウントに対して実行プロファイルを割り当てます。「プロファイル」ダイアログボックスでは、スクロール可能なリスト内に使用可能な実行プロファイルのリストが説明付きで表示されます。各プロファイルに定義されているアクション、承認、コマンドのリストについては、付録 A 「プロファイル概要テーブル」を参照してください。

注 -

デフォルトの管理役割には、必要な実行プロファイルがすでに割り当てられています。新しい役割を作成した場合、その役割のために新しいプロファイルを作成する必要があります。この場合、新しいプロファイルは新しい役割アカウントを作成する前に設定しておいてください。このようにすると、ユーザーマネージャを使ってその役割アカウントにプロファイルを割り当てることができます。

ユーザーアカウントを設定して、このユーザーに役割を割り当てようとする場合、このユーザーアカウントには対応する役割プロファイルを割り当ててはいけません。役割アカウントはそれ自身の実行プロファイルを持っており、このプロファイルは、ユーザーがその役割になって、そのユーザーの ID が役割の ID となった場合にのみ有効となります。

注 -

役割プロファイルを一般のユーザーアカウントに割り当ててはいけません。もしそのようにした場合、リスクや混乱が発生することになります。この場合、ユーザーが役割になっていない時でも、ユーザーアカウントに割り当てた役割プロファイルが有効となってしまいます。これは起こってはならないことです。さらに、この場合、作業が正しく行えなくなる場合がでてきます。なぜなら、管理役割のコマンドやアプリケーションの多くはトラステッドパス属性を必要とするため、管理役割ワークスペースの外では動作しないからです。

プロファイルの順番も重要です。アカウントがコマンドやアクションを起動すると、プロファイルの仕組みにより、そのアカウントの持つプロファイル集合のうち任意のプロファイル内で最初にその名前が見つかったコマンドまたはアクションが使用されます。この場合、最初に名前が見つかったプロファイル中に定義されているコマンドやアクションのための属性がそのまま使われることになります。これはユーザーが特定のコマンドを呼び出した場合、システムはそのユーザーの PATH 環境変数に指定されているディレクトリで最初に見つかったコマンドのインスタンスを使用するのに似ています。たとえば、ユーザーがコマンド行から ps コマンドを呼び出した場合、/usr/bin/ps (ps(1) を参照) と /usr/ucb/ps (ps(1B) を参照) のうちどちらが実行されるかは、そのユーザーの PATH がどう設定されているかによって決まります (これら 2 つのバージョンの ps はそれぞれオプションが異なっています)。

これと同様に、1 つのコマンドまたはアクションが、複数の実行プロファイル内に異なる属性を持つもの (たとえば、異なる特権を持つものや、setuid 属性のオン／オフが異なるもの) として定義されている場合、そのコマンドやアクションは、最初にその名前が見つかったプロファイルに定義されているように実行されます。

複数の実行プロファイルの整列順を利用すると次のようなこともできます。あるコマンドを実行するのに、既存の実行プロファイルに定義されている特権とは別の特権を使用したい場合、その特権を割り当てられた同じコマンドを持つ新しい実行プロファイルを作成し、この新しい実行プロファイルを挿入します。このようにすれば、同コマンドが呼び出された場合、プロファイルの仕組みにより新しいプロファイルが最初に見つけられます。

プロファイルの順番を利用すると、特定のアカウントが特定のコマンドやアクションだけを特権付き (または有効な UID や GID 付きや特定の機密ラベル付き) で実行できるようにし、その他のコマンドやアクションについてはすべてそのような特別なセキュリティ属性なしで実行するように設定できます。これを行うには、アカウントが特定のセキュリティ属性付きで実行する必要のあるコマンドやアクションを明示的に指定したプロファイル集合を、このアカウントに対して割り当てた後、これらのプロファイルのリストの一番最後に、アカウントが特権なしで任意のコマンドやアクションを実行できるような「All」プロファイルを割り当てます。このようにすると、アカウントは明示的に指定されたコマンドやアクションだけを指定された属性付きで実行でき、その他のコマンドはすべて特別な属性なしで実行できるようになります。

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

入力前に決定すべき事項

アカウントに対して少なくとも 1 つの実行プロファイルを割り当てるよう決定すること。
実行プロファイルを登録する順番を決定すること。

ユーザーマネージャ内の入力場所

「プロファイルを指定または変更するには」、特に手順 3 を参照のこと。

役割

セキュリティ管理役割は、一般のユーザーアカウントに対して役割を割り当てます。「役割」ダイアログボックスでは、スクロール可能なリスト内に使用可能な役割のリストが説明付きで表示されます。

役割アカウントは他の役割になることはできません。ユーザーマネージャでは、役割アカウントの設定中は、「役割」ダイアログボックスにはアクセスできないようになっています。ただし、サイトのセキュリティポリシーが許すならば、単一のユーザーに対して複数の役割を割り当てることはできます。

入力前に決定すべき事項

アカウントがなる役割 (もしあれば) を決定すること。

ユーザーマネージャ内の入力場所

「役割を指定または変更するには」、特に手順 3 を参照のこと。

アイドル

セキュリティ管理者は、ワークステーションが役割によって指定される一定の期間アイドル状態となった場合に何らかのアクションを実行するかどうかを指定できます。この場合、次の表のように、実行できるアクションとしては、ユーザーをログアウトするか、画面をロックするかのどちらかを選択できます。

表 5-4 アイドル時の選択


画面ロック	指定の期間アイドル状態となった場合に画面をロックします。この場合、アカウントが元のセッションに戻るには、パスワードを入力する必要があります。マウスを移動するか任意のキーを押すと、ダイアログボックスが表示されるので、ユーザーはここで自分のパスワードを入力します。
ログアウト	指定の期間アイドル状態となった場合にユーザーをシステムから完全にログアウトします。この場合、ユーザーは再度ログインする必要があります。

図 5-2 画面ロック時のパスワード入力のダイアログボックス

セキュリティ管理役割は、これらのアクションを実行するまでの時間量を「アイドル時間」メニューから選択できます。1、2、3、4、5 分、10、15、30、60、120 分、または「制限なし」のいずれかを選択できます。「制限なし (Forever)」メニューオプションを使うと、ワークスペースは無制限にアイドル状態になり、何のアクションも実行されなくなります。

入力前に決定すべき事項

ユーザーはログオンしているが活動していないため、ワークステーションがアイドル状態になった場合の措置を決定すること。画面をロックする／ユーザーのセッションを終了させユーザーをログアウトさせる／何もしない、のうちから選択する。
ワークステーション上での活動がない状態で、どのくらいの時間が経過した場合に指定のアクションを取るかを決定すること。

ユーザーマネージャ内の入力場所

「アイドル制限を指定または変更するには」、特に手順 2 を参照のこと。

ユーザーアカウントや役割アカウントの設定または変更手順

ユーザーマネージャの各種オプションを使ってアカウント情報を指定するための操作手順を以下に示します。

ユーザーマネージャを起動するには

管理者役割は、新しくアカウントを追加し、識別情報とホームディレクトリ情報を指定します。セキュリティ管理者役割はそのアカウントを開き、セキュリティ関連の情報を指定します。

該当する役割になることのできるユーザーとしてログインし、その役割になります。

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

アプリケーションマネージャの「Solstice アプリケーション (Solstice_Apps)」フォルダ内のユーザーマネージャのアイコンをクリックします。

次の図に示すような「読み込み (Load)」ダイアログボックスとユーザーマネージャのウィンドウが表示されます。後者にはユーザーが表示されていません。

「読み込み (Load)」ダイアログボックスを使ってユーザーと役割アカウントの一覧を読み込むには

「ネームサービス (Naming Service)」メニューから「NIS+」オプションを選択します。

注 -
「NIS+」オプションを選択することをお勧めします。これを使うと、すべてのユーザー、ホスト、およびネットワーク情報で集中管理できるからです。これはユーザーの責任および信頼できる管理という点からも重要です。「なし (None)」オプションは、熟練したセキュリティ管理者によってローカルなアカウントサイトのセキュリティポリシーの範囲内で必要かつ妥当であると判断された場合にのみ使うようにしてください。ただし、このオプションを使用すると、システムが攻撃を受けやすくなり、システムの保守が困難になることに注意してください。

「なし (None)」を選択した場合、「ホスト (Host)」フィールドに表示されたローカルホスト名を受け入れるか、構成ファイルを変更したい別のホスト名を入力します。

「ユーザーの表示対象 (Filter Users)」メニューから「すべて (All)」または「なし (None)」のどちらかを選択します。
1. 「すべて (All)」を選択すると、すでに設定されているアカウント名とそれに関連付けられているユーザー ID およびコメントのリストが表示されます。
2. 「指定したものを表示 (Specify)」を選択すると、ユーザー ( 1 人または複数) を指定できます。
  
  次のどちらかの手順を実行します。
  1. 特定のユーザー名を入力します。
  2. ユーザー名をフィルタ処理するための正規表現を入力します。
3. 「なし (None)」を選択すると、アカウント名を1つも含まない、メインのユーザーマネージャの「読み込み (Load)」ダイアログボックスが表示されます。

「了解 (OK)」をクリックします。

ユーザーの読み込みまたは終了(オプション)

「ファイル (File)」メニューから「読み込み (Load)」オプションを選択し、「読み込み (Load)」ダイアログボックスを表示させます。

「読み込み (Load)」ダイアログボックスの使い方については、「「読み込み (Load)」ダイアログボックスを使ってユーザーと役割アカウントの一覧を読み込むには」を参照してください。

Exit を選択すると、すべてのユーザーマネージャウィンドウを終了します。

アカウントの検索やソートを行うには

「表示 (View)」メニューからオプションを選択します。
1. リストから特定のユーザーを見つけるには、「検索 (Find)」を選択し、探したい文字列 (0 個以上のワイルドカードを含む) を入力します。
  1. 検索したいユーザー名、ユーザー ID、コメントのいずれか 1 つを入力します。
    
    1 度に検索できるターゲットの種類は 1 つだけです。
  2. 「適用 (Apply)」または「了解 (OK)」をクリックします。
    
    「了解 (OK)」をクリックすると、ユーザーマネージャのリスト内で次に一致したユーザーがあれば、そのユーザーが強調表示され、「ユーザーマネージャ: 検索 (User Manager: Find)」ダイアログボックスは閉じられます。同様に「適用 (Apply)」をクリックすると、ユーザーマネージャのリスト内で次に一致したユーザーがあれば、そのユーザーが強調表示され、「ユーザーマネージャ: 検索 (User Manager: Find)」ダイアログボックスは表示されたままになります。ここで「適用 (Apply)」を再度クリックすると、次に一致したユーザーが強調表示されます。
2. 「ソート条件 (Sort By)」を選択するとサブメニューが表示されますので、ここで「ユーザー名 (Name)」、「ID」、「コメント (Comment)」の 3 つのフィールドのいずれかを選択します。
3. 「最新の内容を表示 (Rebuild List)」を選択すると、前回リストが表示された後に行われた追加、削除、変更を反映した現在のアカウントのリストが表示されます。

ユーザーマネージャから追加、変更、コピー、デフォルトの設定、または削除を選択するには

ユーザーマネージャの「編集 (Edit)」メニューから、「追加 (Add)」、「変更 (Modify)」、「コピー (Copy)」、「デフォルトの設定 (Set Defaults)」、「削除 (Delete)」のいずれかを選択します。

admin 役割は、「編集 (Edit)」メニューの任意のオプションを使用することができます。admin 役割によってアカウントが作成されると、secadmin 役割は、「変更 (Modify)」を使用することができます。secadmin は、「デフォルトの設定 (Set Defaults)」を使用することもできます。

「編集 (Edit)」メニューから任意のオプションを選択すると、「ナビゲータ (Navigator)」ダイアログボックスが表示されます。ナビゲータのボタンを使用して、さらに他のダイアログボックスを表示させてそこに挙げられた情報を入力することができます。次の図に、「ユーザーマネージャ: ナビゲータ (追加) (User Manager: Navigator (Add))」ダイアログボックスと、「ユーザーマネージャ: ナビゲータ (変更) (User Manager: Navigator (Modify))」ダイアログボックスを示します。

注 -
管理役割がユーザーマネージャを起動した時に、これらのボタンのうちのどれかがグレー表示になっていた場合、そのボタンを使用するのに必要となる承認が、現在の役割の持つ実行プロファイルに割り当てられていないことを意味します。

注 -
ナビゲータから起動するどのダイアログボックスでも「適用 (Apply)」ボタンをクリックすると、データを保存し、ダイアログボックスを表示したままにします。それに対して、「了解 (OK)」ボタンをクリックすると、データを登録し、ナビゲータの上に重ねて表示されていたダイアログボックスを閉じます。

注 -
「監査 (Audit)」ボタンは、有効にはなっていません。個々のユーザー向けに監査機能を設定する方法については、マニュアル『Trusted Solaris の監査管理』を参照してください。

すべての新しいアカウントに対してデフォルト値を適用するには、「デフォルトの設定 (Set Defaults)」を選択し、各ボタンをクリックすると、指定の種類の情報をデフォルト値で更新できます (オプション)。

次の表に、各ダイアログボックスの設定可能なデフォルトを示します。現在の役割が設定できないデフォルトはグレー表示されます。

表 5-5 ユーザーマネージャのダイアログボックスで設定可能なデフォルト値


ダイアログボックス	デフォルト値が設定可能な事項	設定手順
「識別情報 (`Identity`)」	一次グループ	「識別情報」と「識別情報を指定または変更するには」を参照のこと。
	`二次グループ`
	`ログインシェル`
	`ユーザータイプ`
「パスワード (`Password`)」	`すべて`	「パスワード」と「パスワード情報を指定または更新するには」を参照のこと。
「ホーム (`Home`)」	`パス以外のすべて`	「ホームディレクトリ」と「ホームディレクトリ情報を指定または変更するには」を参照のこと。
「ラベル (`Labels`)」	`すべて`	「ラベル」と「ラベル情報を指定または変更するには」を参照のこと。
「プロファイル (`Profiles`)」	`すべて`	「プロファイル」と「プロファイルを指定または変更するには」を参照のこと。
「役割 (`Roles`)」	`すべて`	「役割」と「役割を指定または変更するには」を参照のこと。
「アイドル (`Idle`)」	`すべて`	「アイドル」と「アイドル制限を指定または変更するには」を参照のこと。

新しいアカウントを追加する場合は、「追加 (Add)」または「コピー (Copy)」を選択し、「識別情報を指定または変更するには」に移ります。

「コピー (Copy)」を選択すると、既存のアカウント用の指定済みのフィールドを編集することで新しいアカウントを作成できます。このオプションを使うと、他のユーザーアカウントのエントリのうち使いたいものを保持しながら、新しいアカウント用の異なる情報だけを変更できます。

既存のアカウントを変更するには、「変更 (Modify)」を選択し、「識別情報を指定または変更するには」、「パスワード情報を指定または更新するには」、「ホームディレクトリ情報を指定または変更するには」、「ラベル情報を指定または変更するには」、「プロファイルを指定または変更するには」、「役割を指定または変更するには」、または「アイドル制限を指定または変更するには」に移ります。

アカウントを削除するには「削除 (Delete)」を選択し、「ユーザーの読み込みまたは終了(オプション)」に移ります。

識別情報を指定または変更するには

「識別情報 (Identity)」ダイアログボックスで指定する情報については、「識別情報」を参照してください。

ユーザーマネージャを起動し、アカウント名と変更の種類 (「追加 (Add)」、「変更 (Modify)」、または「デフォルトの設定 (Set Defaults)」) を指定します。

必要であれば、「ユーザーマネージャを起動するには」、「「読み込み (Load)」ダイアログボックスを使ってユーザーと役割アカウントの一覧を読み込むには」ダイアログボックスを使ってユーザーと役割アカウントの一覧を読み込むには」、「ユーザーの読み込みまたは終了(オプション)」、「アカウントの検索やソートを行うには」、または「ユーザーマネージャから追加、変更、コピー、デフォルトの設定、または削除を選択するには」を参照してください。

ユーザーマネージャの「ナビゲート (Navigate)」ダイアログボックス内の「識別情報 (Identity)」ボタンをクリックします。

「識別情報 (Identity)」ダイアログボックスが表示されます。

ユーザーまたは役割を識別するための名前を入力します。

ユーザー名の長さは最大で 8 文字です。名前は、ネットワーク全体で、重複しないようにし、過去に使用した名前は使用しないようにしてください。

ユーザーまたは役割の ID 番号を入力します。

IDは、ネットワーク全体で、重複しないようにし、過去に使用した ID は使用しないようにしてください。

ユーザーまたは役割の一次グループ (およびオプションで二次グループ) を入力します。

コメントを入力します。

「ログインシェル (Login Shell)」メニューからデフォルトのシェルを選択します。プロファイル、Bourne、Korn、C、またはその他のシェルを指定できます。

「ログインシェル (Login Shell)」メニューから「その他 (Other)」を選択した場合には、そのシェルのパス名を入力します。

注 -
役割アカウントのログインシェルには必ずプロファイルシェル、pfsh(1M) を選択してください。pfsh を通常のユーザーに割り当てることは任意です。

「ユーザータイプ (User Type)」メニューからアカウントの種類を選択します。

「一般 (Normal)」、「管理役割 (Admin. Role)」、「非管理役割 (Non-Admin Role)」のいずれかを選択します。

「識別情報 (Identity)」ダイアログボックスの「適用 (Apply)」または「了解 (OK)」をクリックし、変更を保存します。

「適用 (Apply)」ボタンをクリックすると、指定のデータを保存した後、ダイアログボックスは表示されたままになります。一方、「了解 (OK)」ボタンをクリックすると、指定のデータを保存した後、ダイアログボックスが閉じられます。

新しいアカウント用の情報の入力、または (必要に応じて) 既存アカウントの更新が終了したら、変更を保存して終了します。

必要に応じて、「ユーザーの読み込みまたは終了(オプション)」を参照してください。

パスワード情報を指定または更新するには

「パスワード (Password)」ダイアログボックスで指定する情報については、「パスワード」を参照してください。

ユーザーマネージャを起動し、アカウント名と変更の種類 (「追加 (Add)」、「変更 (Modify)」、または「デフォルトの設定 (Set Defaults)」) を指定します。

必要であれば、「ユーザーマネージャを起動するには」、「「読み込み (Load)」ダイアログボックスを使ってユーザーと役割アカウントの一覧を読み込むには」、「ユーザーの読み込みまたは終了(オプション)」、「アカウントの検索やソートを行うには」、または「ユーザーマネージャから追加、変更、コピー、デフォルトの設定、または削除を選択するには」を参照してください。

ユーザーマネージャの「ナビゲータ (Navigator)」ダイアログボックスの「パスワード (Password)」ボタンをクリックします。

「パスワード (Password)」ダイアログボックスが表示されます。

新しいパスワードを入力するか、既存のパスワードを変更します。
1. 上図の「パスワード (Password)」メニューから「パスワードの入力 (Type in)」または「リストから選択 (Choose from list)」のどちらかを選択します。
  
  注意 -
  パスワードを保護し、パスワードを本人以外に知られないようにするのは、セキュリティ管理者役割の責任です。
2. 「パスワードの入力 (Type in)」を選択して、パスワードを入力します。
  1. 「パスワードを入力 (Enter Password)」テキスト入力フィールドにパスワードを入力します。
  2. タブキーを押して「パスワードを確認 (Verify Password)」テキストフィールドに移ります。
  3. 再度パスワードを入力します。
  4. 「了解 (OK)」をクリックするか、Enter キーを押してパスワードを保存します。
3. 「リストから選択 (Choose from list)」オプションを選択した場合、パスワード生成用のダイアログボックスに表示される生成されたパスワードのリストからパスワードを選択します。
  
  パスワード生成用のダイアログボックスは、システムが生成した 5 つのパスワードを選択肢として表示します。各パスワードの右側には、そのパスワードを音節に分割した発音用のニーモニックが ( ) 内に表示されます (これはパスワードを覚えやすくするための措置です)。
  1. 生成されたパスワード中に好みのパスワードが見つからない場合は、「生成 (Gen)」をクリックして再度 5 つの新しいパスワードを生成させます。
  2. リストからパスワードを選択するには、希望のパスワードの左にある丸をクリックします。
  3. 下にあるテキスト入力フィールドに選択したパスワードを入力して確認します。
  4. 「了解 (OK)」をクリックするか、Enter キーを押してパスワードを保存します。

パスワードの有効期間に関する情報を指定します (オプション)。
1. 「最短有効日数 (Min Change)」フィールドには、いったんパスワードが変更された後、ユーザーが再度そのアカウントでパスワードを変更できるようになるまでに経過しなければならない最小日数を入力します。
2. パスワードの前回変更時から一定の日数後にそのパスワードを期限切れにしたい場合は、その日数を「最長有効日数 (Max Change)」フィールドに入力します。
3. 「最長非使用日数 (Max Inactive)」フィールドには、ユーザーアカウントが閉じられる前に、そのアカウントが非活動状態のままでいられる最大日数を入力します。
4. 特定の日付でパスワードを期限切れにするには、「有効期限 (Expiration Date)」フィールドにその日付を入力します。

手順 4 でパスワードの有効期間や有効期限を設定した場合、「警告 (Warning)」テキスト入力フィールドに、パスワードが期限切れとなる何日前にユーザーに警告を送るかを入力します。

ユーザー用のパスワードの生成方法を指定します。

「パスワード (Password)」ダイアログボックスの「生成 (Generation)」メニューを使うと、パスワードの提供をユーザーが行うかそれともシステムが行うかを指定できます。

「リストから選択 (Choose from list)」を選択すると、ユーザーがトラステッドパスメニューの「パスワード変更 (Change password)」オプションを選択した場合には必ずパスワード生成用のダイアログボックスが表示されるようになります。

「状態 (Status)」メニューから、アカウントの「開く (Open)」、「閉じる (Closed)」、「常に開く (Always Open)」のいずれかを選択します。

新しいアカウントは、セキュリティ管理者がそれを開くまでは閉じられたままになります。同じログインセッション内で不正なパスワードが 3 回入力された場合、アカウントの状態は自動的に「開く (Open)」から「閉じる (Closed)」になります。状態が「常に開く (Always Open)」のアカウントは常にアクセス可能で、不正なパスワードが何回入力されても閉じることはありません。

注 -
ログイン試行が 3 回失敗したために既存のアカウントが閉じられた場合、セキュリティ管理者は、そのアカウントを再度開く前に、ログイン失敗の状況を調査する必要があります。

「認証テーブルの設定 (Cred. Table Setup)」の右にあるトグルをチェックすると、NIS+ 主体の公開鍵および非公開鍵が資格テーブルに追加されます。

注 -
新しいアカウントを作成した場合、「認証テーブルの設定」チェックボックスにチェックマークを付けることをお勧めします。これにより、そのアカウントは NIS+ の資格テーブルに追加され、そのアカウントのパスワードは NIS+ データベースに追加されます。アカウントを変更するときは、パスワードを変更しない限り、このトグルをそのままにしておくことを一般的にはお勧めします。

「パスワード (Password)」ダイアログボックスの「適用 (Apply)」または「了解 (OK)」をクリックし、変更を保存します。

「適用 (Apply)」ボタンをクリックすると、指定のデータを保存した後、ダイアログボックスは表示されたままになります。一方、「了解 (OK)」ボタンをクリックすると、指定のデータを保存した後、ダイアログボックスが閉じられます。

新しいアカウント用の情報の入力、または既存アカウントの更新が終了します。

必要に応じて、「ユーザーの読み込みまたは終了(オプション)」を参照してください。

ホームディレクトリ情報を指定または変更するには

「ホーム (Home)」ダイアログボックスで指定する情報については、「ホームディレクトリ」を参照してください。

ユーザーマネージャを起動し、アカウント名と変更の種類 (「追加 (Add)」、「変更 ( Modify)」、または「デフォルトの設定 (Set Defaults)」) を指定します。

必要であれば、「ユーザーマネージャを起動するには」、「「読み込み (Load)」ダイアログボックスを使ってユーザーと役割アカウントの一覧を読み込むには」、「ユーザーの読み込みまたは終了(オプション)」、「アカウントの検索やソートを行うには」、または「ユーザーマネージャから追加、変更、コピー、デフォルトの設定、または削除を選択するには」を参照してください。

ユーザーマネージャの「ナビゲータ (Navigator)」ダイアログボックス内の「ホーム (Home)」ボタンをクリックします。

「ホ−ム (Home)」ダイアログボックスが表示されます。

「ホ−ムディレクトリの作成 (Create Home Dir)」チェックボックスにチェックマークを付けて、アカウントのホームディレクトリを MLD として自動作成します (オプション)。

「パス (Path)」フィールドに、ホームディレクトリのパス名を入力します。

「サーバー (Server)」フィールドに、ホームディレクトリを提供するサーバーの名前を入力します。

ホームディレクトリがアカウントの主ワークステーションのローカルパーティション上にマウントされている場合、その主ワークステーションの名前を入力します。それ以外の場合、アカウントのホームディレクトリを提供している NFS サーバーの名前を入力します。

注 -
サーバーはユーザーアカウントの作成前に設定されていなければなりません。

「アクセス権 (Permissions)」の下の適当なアクセス権ボックスにチェックマークを付けて、ホームディレクトリに対する読み取り、書き込み、実行アクセス権を、所有者、グループ、その他のユーザーごとに設定します。

メールサーバーを指定します (オプション)。

「AutoHome の設定 (AutoHome Setup)」ボックスにチェックマークを付けて、ホームディレクトリを自動的にマウントさせます。

「ホーム (Home)」ダイアログボックスの「適用 (Apply)」または「了解 (OK)」をクリックし、変更を保存します。

「適用 (Apply)」ボタンをクリックすると、指定のデータを保存した後、ダイアログボックスは表示されたままになります。一方、「了解 (OK)」ボタンをクリックすると、指定のデータを保存した後、ダイアログボックスが閉じられます。

新しいアカウント用の情報の入力、または既存アカウントの更新が終了したら、変更を保存して終了します。

必要に応じて、「変更を保存してユーザーマネージャを終了するには」を参照してください。

ラベル情報を指定または変更するには

「ラベル (Labels)」ダイアログボックスで指定する情報については、「ラベル」を参照してください。

ユーザーマネージャを起動し、アカウント名と変更の種類 (「追加 (Add)」、「変更 (Modify)」、または「デフォルトの設定 (Set Defaults)」) を指定します。

必要であれば、「ユーザーマネージャを起動するには」、「「読み込み (Load)」ダイアログボックスを使ってユーザーと役割アカウントの一覧を読み込むには」、「ユーザーの読み込みまたは終了(オプション)」、「アカウントの検索やソートを行うには」、または「ユーザーマネージャから追加、変更、コピー、デフォルトの設定、または削除を選択するには」を参照してください。

ユーザーマネージャの「ナビゲータ (Navigator)」ダイアログボックス内の「ラベル (Labels)」ボタンをクリックします。

「ラベル (Labels)」ダイアログボックスが表示されます。

「認可上限 (Clearance)」ボタンをクリックすると認可上限ビルダーのダイアログボックスが起動されるので、ここでアカウントの認可上限を入力します。

ユーザーマネージャの認可上限ラベルビルダーダイアログボックスが表示されます。
1. 認可上限をキーボードから入力するには、「更新後のラベル (Update With)」の下のテキスト入力フィールドを使用します。入力が終ったら「更新 (update)」ボタンをクリックします。
2. マウスを使って認可上限を設定するには、格付けのメニューから希望の分類を選択した後、コンパートメントのメニューから、もしあれば、希望のコンパートメントを選択します。
3. 「了解 (OK)」をクリックしてラベルビルダーのダイアログボックスを閉じます。
  
  選択した認可上限が、「ラベル (Labels)」ダイアログボックスの「認可上限 (Clearance)」フィールドに表示されます。
  
  注 -
  アカウントの認可上限は、label_encodings(4) ファイルに指定されている最上位機密ラベルよりも劣位でなければならず、かつ、同ファイルに指定されている最下位認可上限よりも優位でなければなりません。

「最下位 SL (Minimum SL)」をクリックして、最下位機密ラベルを入力します。

最下位機密ラベルビルダーダイアログボックスが表示されます。
1. 最下位機密ラベルをキーボードから入力するには、「更新後のラベル (Update With)」の下のテキスト入力フィールドを使用します。入力が終わったら「更新 (Update)」ボタンをクリックします。
2. マウスを使って最下位機密ラベルを設定するには、格付けのメニューから希望の分類を選択した後、コンパートメントのメニューから、もしあれば、希望のコンパートメントを選択します。
3. 「了解 (OK)」をクリックしてラベルビルダーのダイアログボックスを閉じます。
  
  選択した最下位機密ラベルが、「ラベル (Labels)」ダイアログボックスの「最下位 SL (Minimum SL)」フィールドに表示されます。
  
  注 -
  アカウントの持つ最下位機密ラベルは、label_encodings ファイルに指定されている最上位機密ラベルよりも劣位でなければならず、かつ、同ファイルに指定されている最下位機密ラベルよりも優位でなければなりません。

「表示 (View)」メニューのオプションから、アカウント用の管理ラベル表示を選択します。
1. ADMIN_HIGH および ADMIN_LOW 管理ラベルの代わりに、ユーザー認可範囲内の有効な最上位および最下位ラベルを表示する場合は、「外部用 (External)」を選択します。
2. ユーザーが ADMIN_HIGH および ADMIN_LOW または各サイトの管理者が設定した管理ラベルの ASCII 名を見ることができるようにするには、「内部用 (Internal)」を選択します。
3. label_encodings(4) ファイルに指定されているラベル表示のデフォルト値を使用する場合は、「Sys デフォルト (Sys default)」を選択します。
  
  注 -
  アカウントが機密ラベルを見ることができるように設定されていない場合、「表示 (View)」メニューのラベル表示オプションは機密ラベルに関しては無効です。.

SL メニューで機密ラベルをアカウントに対して表示するかどうかを選択します。
1. 機密ラベルを表示する場合には「表示 (Show)」を選択します。
2. 機密ラベルを表示しない場合には「非表示 (Hide)」を選択します。

「ラベル (Labels)」ダイアログボックスの「適用 (Apply)」または「了解 (OK)」をクリックし、変更を保存します。

「適用 (Apply)」ボタンをクリックすると、指定のデータを保存した後、ダイアログボックスは表示されたままになります。一方、「了解 (OK)」ボタンをクリックすると、指定のデータを保存した後、ダイアログボックスが閉じられます。

新しいアカウント用の情報の入力、または既存アカウントの更新が終了したら、変更を保存して終了します。

必要に応じて、「変更を保存してユーザーマネージャを終了するには」を参照してください。

プロファイルを指定または変更するには

「プロファイル (Profiles)」ダイアログボックスで指定する情報については、「プロファイル」を参照してください。

ユーザーマネージャを起動し、アカウント名と変更の種類 (「追加 (Add)」、「変更 (Modify)」、または「デフォルトの設定 (Set Defaults)」) を指定します。

必要であれば、「ユーザーマネージャを起動するには」、「「読み込み (Load)」ダイアログボックスを使ってユーザーと役割アカウントの一覧を読み込むには」、「ユーザーの読み込みまたは終了(オプション)」、「アカウントの検索やソートを行うには」、または「ユーザーマネージャから追加、変更、コピー、デフォルトの設定、または削除を選択するには」を参照してください。

ユーザーマネージャの「ナビゲータ (Navigator)」ダイアログボックス内の「プロファイル (Profiles)」ボタンをクリックします。

「プロファイル (Profiles)」ダイアログボックスが表示されます。

上記の図の左側には、選択されていない実行プロファイルの「利用可能 (Available)」リストが表示されます。右側には、現在のアカウント用に選択された実行プロファイルの「含める (Included)」リストが表示されます。

実行プロファイルを割り当てるには、「利用可能 (Available)」リスト内にある割り当てたいプロファイル名をダブルクリックします。または、その名前をシングルクリックした後、右矢印ボタンをクリックして、そのプロファイル名を「選択 (Selected)」リストに移動します。

「選択 (Selected)」リストから実行プロファイルを削除するには、削除したいプロファイルの名前をダブルクリックします。または、その名前をシングルクリックした後、左矢印ボタンをクリックして、そのプロファイル名を「利用可能 (Available)」リストに移動します。

「選択 (Selected)」リスト内の実行プロファイルの並び順を変更するには、その名前をシングルクリックした後、上または下矢印ボタンをクリックして、そのプロファイル名の位置を「選択 (Selected)」リスト内で移動させます。

注 -
「プロファイル」で述べたように、プロファイルの順番はどのコマンド定義が使用されるかに影響します。このため、プロファイルの順番を決定する場合には、ユーザーにコマンドを使用させる目的を考慮した上で注意深く設定してください。

「プロファイル (Profiles)」ダイアログボックスの「適用 (Apply)」または「了解 (OK)」をクリックし、変更を保存します。

「適用 (Apply)」ボタンをクリックすると、指定のデータを保存した後、ダイアログボックスは表示されたままになります。一方、「了解 (OK)」ボタンをクリックすると、指定のデータを保存した後、ダイアログボックスが閉じられます。

新しいアカウント用の情報の入力、または既存アカウントの更新が終了したら、変更を保存して終了します。

必要に応じて、「変更を保存してユーザーマネージャを終了するには」を参照します。

役割を指定または変更するには

「役割 (Roles)」ダイアログボックスで指定する情報については、「役割」を参照してください。

ユーザーマネージャを起動し、アカウント名と変更の種類 (「追加 (Add)」、「変更 (Modify)」、または「デフォルトの設定 (Set Defaults)」) を指定します。

必要であれば、「ユーザーマネージャを起動するには」、「「読み込み (Load)」ダイアログボックスを使ってユーザーと役割アカウントの一覧を読み込むには」、「ユーザーの読み込みまたは終了(オプション)」、「アカウントの検索やソートを行うには」、または「ユーザーマネージャから追加、変更、コピー、デフォルトの設定、または削除を選択するには」を参照してください。

ユーザーマネージャの「ナビゲータ (Navigator)」ダイアログボックス内の「役割 (Roles)」ボタンをクリックします。

「役割 (Roles)」ダイアログボックスが表示されます。

注 -
役割は別の役割になることができません。このため、「識別情報 (Identity)」ダイアログボックスの「ユーザータイプ (Account Type)」フィールドに現在のアカウントが役割アカウントとして示されている場合、「役割 (Roles)」ボタンはグレー表示されます。

上記の図の左側には、選択されていない役割の「禁止された役割 (Prohibited)」リストが表示されます。右側には、選択された役割のリストが「就任可能な役割 (Assumable)」の下に表示されます。

アカウントに対して役割を割り当てるには、「禁止された役割 (Prohibited)」リスト内にある割り当てたい役割の名前をダブルクリックします。または、その名前をシングルクリックした後、右矢印ボタンをクリックして、そのプロファイル名を「就任可能な役割 (Assumable)」リストに移動します。

「就任可能な役割 (Assumable)」リストから役割を削除するには、削除したい役割の名前をダブルクリックします。または、その名前をシングルクリックした後、左矢印ボタンをクリックして、そのプロファイル名を「禁止された役割 (Prohibited)」リストに移動します。

「役割 (Roles)」ダイアログボックスの「適用 (Apply)」または「了解 (OK)」をクリックし、変更を保存します。

「適用 (Apply)」ボタンをクリックすると、指定のデータを保存した後、ダイアログボックスは表示されたままになります。一方、「了解 (OK)」ボタンをクリックすると、指定のデータを保存した後、ダイアログボックスが閉じられます。

新しいアカウント用の情報の入力、または既存アカウントの更新が終了したら、変更を保存して終了します。

必要に応じて、「変更を保存してユーザーマネージャを終了するには」を参照してください。

アイドル制限を指定または変更するには

「アイドル (Idle)」ダイアログボックスで指定する情報については、「アイドル」を参照してください。

「ユーザーマネージャ: ナビゲータ (User Manager: Navigator)」の「アイドル (Idle)」ボタンをクリックします。

必要であれば、「ユーザーマネージャを起動するには」、「「読み込み (Load)」ダイアログボックスを使ってユーザーと役割アカウントの一覧を読み込むには」、「ユーザーの読み込みまたは終了(オプション)」、「アカウントの検索やソートを行うには」、または「ユーザーマネージャから追加、変更、コピー、デフォルトの設定、または削除を選択するには」を参照してください。

「アイドル (Idle)」ダイアログボックスが表示されます。

「アイドル (Idle)」ダイアログボックスでは、アカウントのアイドル状態を制限するための情報およびアクションを指定します (オプション)。
1. ユーザーマネージャの「ナビゲータ ( Navigator)」ダイアログボックス内の「アイドル (Idle)」ボタンをクリックします。
  
  「アイドル (Idle)」ダイアログボックスが表示されます。
2. アイドル時間の設定メニューから、ワークステーションがアイドル状態となった時点から何らかのアクションを実行するまでの時間の長さを選択します。
3. 「画面をロック (Lock Screen)」または「ログアウト (Logout)」のどちらかをクリックします。
  
  注意 -
  アクションとしてログアウトを選択した場合、ユーザーのセッションで実行されていたプロセスはすべて kill されます。
4. 「アイドル (Idle)」ダイアログボックスの「適用 (Apply)」または「了解 (OK)」をクリックし、変更を保存します。
  
  「適用 (Apply)」ボタンをクリックすると、指定のデータを保存した後、ダイアログボックスは表示されたままになります。一方、「了解 (OK)」ボタンをクリックすると、指定のデータを保存した後、ダイアログボックスが閉じられます。
5. 新しいアカウント用の情報の入力、または既存アカウントの更新が終了したら、変更を保存して終了します。
  
  必要に応じて、「変更を保存してユーザーマネージャを終了するには」を参照してください。

変更を保存してユーザーマネージャを終了するには

ユーザーマネージャの「ナビゲータ (Navigator)」ダイアログボックスの「完了 (Done)」または「保存 (Save)」をクリックします。

「ナビゲータ (Navigator)」の「完了 (Done)」をクリックすると、このダイアログボックスに行われたすべての変更が保存され、「ナビゲータ (Navigator)」が閉じます。「保存 (Save)」をクリックすると、変更は保存されますが、「ナビゲータ (Navigator)」は閉じません。

注 -
パスワード情報が指定されていない場合、アカウントは閉じられたままになります。

ユーザーマネージャの「ファイル (File)」メニューから「終了 (Exit)」オプションを選択し、すべてのユーザーマネージャウィンドウを終了します。

第 6 章メール管理

Trusted Solaris 環境と Solaris 環境では、メールは本質的に同じです。したがって、管理者役割がメールサーバーを設定および管理するときは、基本的に『メールシステムの管理』の指示に従ってください。ただし、この章や sendmail(1M) のマニュアルページで説明されている若干の違いには注意してください＝

この章では次の操作手続きを示します。

Trusted Solaris におけるメール機能の概要

Trusted Solaris 環境では、メールの送受信は複数の機密ラベル付きで実施され、メールの持つ機密ラベルが保存されます。Trusted Solaris 環境におけるメールの取り扱いを以下に示します。

配送用のキューに入れられたメールの格納、および未読メールメッセージの格納にはマルチラベルディレクトリ (MLD) が使用されます。

詳しくは、「送信および着信メール用マルチラベルディレクトリ」および「マルチラベルディレクトリ内のメールボックス」を参照してください。
Sendmail(1M) は、機密ラベルの運用をサポートするよう変更されています。さらに、Sendmail は、着信メールの持つ機密ラベルがユーザーの認可上限と最下位機密ラベルの範囲内にある場合にのみ、そのユーザーに対するメールのルーティングを行うよう変更されています。
他のユーザーが送ったメールが入っているメールキューの内容をユーザーが表示できるのは望ましくないため、デフォルトで sendmail.cf ファイル内に -restrictmailq オプションが設定されています。これにより、メールキュー内のジョブのリストを表示できるのは、メールキューと同じグループに所属するユーザーだけになります。

詳しくは、「メール待ち行列の内容を表示するには」を参照してください。
sendmail.cf ファイル内の -p オプションを拡張したものとして、「-Optsol..」機密オプションが提供されています。このオプションを設定すると、管理者は、ユーザーの持つ最下位機密ラベルよりも低い機密ラベルで到着したメールを sendmail がどう処理するかを指定できます。

詳しくは、「受信者の最下位ラベルよりも低いラベルのメールに関する Sendmail の処理」および「ユーザーの最下位ラベルよりも低いラベルのメールに関するメール配送オプションを設定するには」を参照してください。

フロントパネルの「メール (Mail)」サブパネル内にあるデフォルトの dtmail アクションの代わりに、別のメールアプリケーション用の CDE アクションを使うことができます。

詳しくは、「他のメールアプリケーションを代用するには」を参照してください。

送信および着信メール用マルチラベルディレクトリ

/var/spool/mqueue はマルチラベルディレクトリ (MLD) として実装されており、ここには異なる機密ラベルを持つメールが格納され、実際の配送を待つことになります。次の例に、ユーザーが /var/spool/mqueue ディレクトリに移動した時の例を示します。この場合、ユーザーは現在のプロセスと同じ機密ラベルを持つ SLD である「.SLD.2」に自動的にリダイレクトされています。.SLD.2 の内容として表示されているメールメッセージは、現在の機密ラベル付きで送信されるのを待機しているものです。

例 6-1 `/var/spool/mqueue` MLD とその内容 (異なる機密ラベルを持つ SLD)

trustworthy% cd /var/spool/mqueue
trustworthy% mldpwd
/var/spool/.MLD.mqueue/.SLD.2
trustworthy% ls
dfNAA00212
dfNAB00212
dfNAC00212
trustworthy% cd /var/spool/.MLD.mqueue
trustworthy% ls -R .SLD.*
ls: .SLD.1: Permission denied
.SLD.0:
.SLD.2:
dfNAA00212
dfNAB00212
dfNAC00212

mqueue MLD 内にあるすべての SLD の内容の表示は、次のことを意味しています。

「.SLD.1: パーミッションが与えられていません。」は、「.SLD.1」が現在の機密ラベルよりも完全に優位なラベルを持つことを意味します。
「.SLD.0」は空です。
「.SLD.2」には、現在の機密ラベル付きでの送信を待機しているメッセージがあります。

Trusted Solaris オペレーティング環境は、/var/mail も MLD として作成し、このディレクトリ内にすべてのアカウント用のラベルを格納します。詳細は、「マルチラベルディレクトリ内のメールボックス」を参照してください。

マルチラベルディレクトリ内のメールボックス

sendmail プログラムは、/var/mail MLD 内にメールボックスファイルを作成し、このファイルに受信したメールを格納します。

各アカウントに対し、受信したメールのそれぞれの機密ラベルに別々のメールボックスが作成されます。この結果、各アカウントは複数のメールボックスを持つことになります。

たとえば、ユーザー roseanne が PUBLIC、NEED TO KNOW ENGINEERING、NEED TO KNOW MARKETING という 3 種類の機密ラベル付きのメールを受信した場合、roseanne はこれらの各ラベルに対応する 3 つの独立したメールボックスを、それぞれ独立した SLD 内に 1 つずつ持つことになります。メールボックスにはアカウントと同じ名前が付けられるため、roseanne の持つメールボックスの名前はすべて「roseanne」になります。
役割アカウントもユーザーアカウントと同様に、自分自身のメールボックスを持ちますが、この場合も、メールボックスには役割と同じ名前が付けられます。たとえば、secadmin という役割アカウントの作成したメールボックスの名前はすべて「secadmin」になります。

ホスト上のユーザーまたは役割に対して特定の機密ラベルを持つメールが初めて送られた場合、sendmail プログラムは、そのメールの持つ機密ラベルで /var/mail 内に新しいSLD を 1 つ作成し、この SLD 内のメールボックスにそのメールを格納します。
同じ機密ラベルを持つメールがこのユーザーまたはそれ以外のユーザーに対して送付された場合、それらのメールはこの同じ SLD に格納されます。
ユーザーが特定の機密ラベルでメールボックスからすべてのメールを削除すると、対応するメールボックス (/var/.MLD.mail/.SLD.?/username) が削除されます。

以下の例を参照して、たとえば、NEED TO KNOW ENGINEERING という機密ラベルを持つユーザー roseanne 宛てのメールをシステムが初めて受信した場合、NEED TO KNOW ENGINEERING という機密ラベルで /var/.MLD.mail/.SLD.0 が作成され、そのメールは .SLD.0 内の roseanne という名前のメールボックスに格納されます。この後、NEED TO KNOW ENGINEERING という機密ラベルを持つ別のユーザー jhoman 宛てのメールをシステムが受信した場合、そのメールは .SLD.0 内の新規に作成された jhoman という名前のメールボックスに格納されます。続いて、PUBLIC ラベルを持つ roseanne 宛てのメールをシステムが受信した場合、今度は .SLD.1 が作成され、そのメールは .SLD.1 内の roseanne という名前のメールボックスに格納されます。NEED TO KNOW ENGINEERING ラベルを持つユーザー roseanne および jhoman 宛てのメールがそれぞれ .SLD.0 内のメールボックス roseanne および jhoman に格納され、PUBLIC ラベルを持つ roseanne 宛てのメールが .SLD.1 内の別の roseanne メールボックスに格納されている様子を次の図に示します。

例 6-2 異なる機密ラベルを持つ SLD 内のメールボックス群

$ cd /var/.MLD.mail/
$ ls -R .SLD.*
.SLD.0
roseanne
jhoman
.SLD.1
roseanne

メールの通知

フロントパネルの「メール (Mail)」サブパネルを通じてメールの到着を通知されます。図 6-1 に示すように、「メール (Mail)」サブパネルは、次の各機密ラベルごとに 1 つのメールアイコンを表示します。

ユーザーがメールを受け取った時の機密ラベル
ユーザーがなっている役割がメールを受け取った時の機密ラベル

図 6-1 メールの複数のラベルを表示する「メール (Mail)」サブパネル

「メール (Mail)」サブパネルの最上行に表示されているメールアイコンには、特定の機密ラベル名が付けられていません。このアイコンをクリックすると、フロントパネル内のメールアイコンをクリックした時と同じように、現在のワークスペースの機密ラベルで受け取られたメールが表示されます。

異なる機密ラベルを持つメールへのアクセスは、現在のワークスペースの持つ機密ラベルによっては制限されません。いかなるユーザーも、自分が許可された範囲内の機密ラベルでメールの読み込みや送信を行えることは、Trusted Solaris のセキュリティポリシーに違反していないからです。したがって、メールリーダーは、現在のワークスペースの機密ラベルやアイコンの機密ラベルにかかわらず、「メール (Mail)」サブパネルに表示されているどのアイコンからでも起動できます。

メールの読み込み

受信者がメールアイコンをクリックすると、メールリーダーが着信メールの持つ機密ラベルで表示されます。

機密ラベル名は長形式名で [ ] 内に表示されます。この場合、次の図に示すように、メールリーダーの表示する機密ラベル名は [INTERNAL_USE_ONLY] となります。

図 6-2 メールリーダーのウィンドウラベル

メールの持つ機密ラベルの決定

メールの持つ機密ラベルは次のいずれかの方法により決定されます。

Trusted Solaris ホストまたはそれ以外のラベル付きホスト (トラステッドネットワークデータベースのラベル付きホストオプションで設定されているもの) からの着信メールの場合、その機密ラベルはメール作成プロセスの持つ機密ラベル (そのメールを送信したメーラーの持つ機密ラベル) になります。
ラベルなしホスト (ラベルを認識せず、トラステッドネットワークデータベース内でラベルなしホストとして設定されているもの) からの着信メールの場合、その機密ラベルはトラステッドネットワークデータベース内でそのホストに割り当てられているデフォルトの機密ラベルになります。

メールエイリアスの変更

メールエイリアスの管理方法については、Solaris のマニュアル『メールシステムの管理』に書かれています。以下の節では、Trusted Solaris 環境に特有の事項だけを説明します。

ホームディレクトリ MLD で .mailrc を利用する

各ユーザーは自分のホームディレクトリに .mailrc ファイルのローカルコピーを配置することで、個人的なメールエイリアスを作成できます。ホームディレクトリが常に MLD であるため、Trusted Solaris と Solaris では .mailrc ファイルの使い方が異なります。管理者やユーザーは .mailrc ファイル (その他のスタートアップファイル) を各 SLD (それぞれ異なる機密ラベルで作成されたもの)にコピーまたはリンクするために設定を行う必要があります。

新しいローカルエイリアスおよび NIS+ で管理されるエイリアスの作成と初期化

エイリアスは NIS+ マップで指定するか、または各ホストの /etc/aliases ファイルで指定します。データベースマネージャの「ネームサービス (Naming Service)」メニューを使うと、システム管理者は aliases を含むデータベースの編集時に、「NIS+」または「なし (none)」を選べます。

エイリアスを編集するには

管理役割になり、ADMIN_LOW ワークスペースに移動します。

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

データベースマネージャの「Aliases データベース」ウィンドウを起動します。

必要に応じて、「管理アプリケーションを起動するには」を参照してください。
1. 「データベース名」スクロールリスト上の「別名」を強調表示させます。
2. NIS+ エイリアスマップを編集する場合は、「ネームサービス」メニューから「NIS+」を選びます。ローカルな /etc/aliases ファイルを編集する場合は「なし (None)」を選びます。
3. 「了解 (OK)」をクリックします。
  
  データベースマネージャ「Aliases データベース」ウィンドウが表示されます。

エイリアスを変更するには、既存のエイリアスを選択し、それを変更します。
1. 特定のエイリアス名を強調表示させます。
2. 「編集」メニューから「変更」を選択します。
  
  データベースマネージャの「変更」ダイアログボックスが表示されます。
3. 「登録内容」テキスト入力フィールド内のテキストを必要に応じて変更します。
4. 終了したら、「了解」ボタンをクリックします。

エイリアスを追加するには、「編集」メニューから「追加」を選択します。
1. 「エイリアス名」テキスト入力フィールドにエイリアスの名前を入力します。
2. 「登録内容」テキスト入力フィールドに、そのエイリアスが表すアドレスをすべて入力します。
3. 終了したら、「了解」ボタンをクリックします。

データベースマネージャの「ファイル」メニューから「終了」を選択します。

ユーザーがメール待ち行列全体の内容を表示できるようにするには

Solaris オペレーティング環境の /etc/mail/sendmail.cf ファイルでは、restrictmailq オプションが利用可能ですが、このオプションはデフォルトではセットされていません。Trusted Solaris 環境の sendmail.cf ファイルでは、restrictmailq オプションがデフォルトでセットされているため、特定のメール待ち行列内のジョブのリストを表示できるのは、そのメール待ち行列と同じグループに属しているユーザーだけに限られます。このオプションを設定すると、他のユーザーから送信された待ち行列内のメールの一覧を通常のユーザーが表示できません。

注 -

メール待ち行列の一覧を表示するには、mailq コマンドまたは sendmail -bp コマンドを入力します。管理者が次の操作を実行したとしても、メール待ち行列の内容を表示できるのは、自分のプロファイル内に mailq または sendmail コマンドを持つユーザーだけに限られます。これらのコマンドは、そのユーザーのプロセスの持つ機密ラベルよりも劣位のラベルを持つメールだけを表示します。

メール待ち行列の内容を表示するには

すべてのユーザーがメール待ち行列の内容を表示できるようにするには、/etc/mail/sendmail.cf ファイル内の -restrictmailq オプションを削除します。

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

特定のグループに属すユーザーだけがメール待ち行列の内容を表示できるようにするには
1. 新しいグループを作成します。
2. そのグループに必要なユーザーを追加します。
3. chgrp(1) を使って、/var/spool/mqueue のグループを上記のグループに変更します。

mailq および sendmail -bp コマンドをプロファイルに追加し、/var/spool/mqueue のグループをこれらのコマンドに割り当てます。

sendmail の活動をトレースするには

ローカルおよびリモートのメール配送には、複数の sendmail のインスタンスが関係します。図 6-3 に、sendmail プロセスの処理におけるデータの流れを示します。

sendmail の第 1 のインスタンスは、いくつかのメール送信に使われる任意のメーラー (デフォルトでは dtmail) によって開始されます。このインスタンスにより、現在のホストから発信されたメールの配送が試行されます。メールの内容は、実際に配送されるまで /var/spool/mqueue MLD 内に格納されます。システムクラッシュなどが発生した場合には、これらのメールメッセージは配送されません (図 6-3 の (1))。通常、メッセージは直ちに配送されるため、メッセージがメール待ち行列に存在する時間はほんの数秒です。ただし、リモートホストがダウンしている場合などには、メッセージはメール待ち行列に永久に存在することになります。

sendmail の第 2 のインスタンスは、ワークステーションまたはサーバーのブート時に開始されます。このインスタンスは 25 番ポートを監視することで、リモートホストから受信するメールの配送に備えています。各メッセージは、実際に配送されるまで /var/spool/mqueue MLD 内に格納されます(例の (3) と (5))。

sendmail の第 3 のインスタンスは、メール待ち行列を定期的にスキャンして、待ち行列にメールが存在する場合はその配送を試みます(例の (2) と (4))。次の図は、cascade、trustworthy、juggle という 3 つのホスト上のメール送信プロセスを示しており、ホスト trustworrthy はホスト juggle のメール中継ホストとして動作します。

図 6-3 sendmail が扱うデータの流れの例

ユーザーが「username@hostname 」にメールを送る場合、「hostname」がリモートホストならば、sendmail はそのメッセージをそのホストの 25 番ポートに転送します。例に示すように、「homan@cascade 」宛てのメールがホスト cascade 上の homan 以外のアカウントから送信された場合、sendmail (1) はそのメールを cascade 上の /var/spool/.MLD.mqueue 内の SLD に格納し、このメールはローカルメーラーによって配送されます。cascade 上の sendmail (2) は、定期的にメール待ち行列のポーリングを行い、待ち行列にたまったメールの配送を行います。ホスト trustworthy および juggle 上の sendmail (3) および (5) は、着信メールに備えて 25 番ポートを監視しています。cascade から出された trustworthy および juggle 宛てのメッセージはどちらもローカルの /var/spool/.MLD.mqueue に入れられた後、trustworthy の 25 番ポートに送信されます (この例では trustworthy はメール中継ホストとして動作しています)。trustworthy 上の sendmail (3) がこれら両方のメッセージをローカルな /var/spool/.MLD.mqueue 内の SLD に入れると、「roseanne@trustworthy」宛てのメッセージはローカルメーラーによって配送され、「ahart@juggle」宛てのメッセージは、juggle 上の 25 番ポートを監視している sendmail (5) に転送されます。

-d オプションを使った sendmail のデバッグに関しては、O'Reilly & Associates, Inc 発行の『sendmail Nutshell Handbook』に詳しく説明されています。簡単な使い方としては、-d オプションの後に X を指定することで、デバッグ情報を見ることができます。sendmail -d の出力を特定のものだけに制限するには、カテゴリを指定し、オプションでそれに続けてピリオド (.) の後に 0〜9 のレベルを指定します (9 は情報の最大レベルを示します)。新しいカテゴリである 75 を指定すると、sendmail の Trusted Solaris 版独自のデバッグ情報を表示できます。

sendmail の Trusted Solaris 情報をトレースするには

管理役割になり、ADMIN_LOW ワークスペースに移動します。

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

プロファイルシェルにて /etc/init.d ディレクトリに移動し、sendmail を停止します。
$ cd /etc/rc2.d $ sendmail stop

sendmail -d に続いてカテゴリ番号 75、続いて必要であればピリオド (.) の後にレベル番号を指定します。さらにその後に、1 つスペースを入れ宛先とメッセージを指定します。

次に示すように、メッセージはファイルの内容を宛先にリダイレクトすることでも指定できます。またはメッセージを指定せずに行末で return キーを押します。この場合、「Subject:」というプロンプトが表示されたらメールの件名を入力し、その後は mail(1) の構文に則ってメッセージの内容を記述できます。
$ /usr/lib/sendmail -d75.9 roseanne@trusted < /etc/motd

エラーメッセージを確認します。

ADMIN_LOW のプロファイルシェルにて /etc/init.d ディレクトリに移動し、sendmail を再スタートさせます。
$ cd /etc/init.d $ sendmail start

メール配送に関するトラブルシューティング

sendmail は、メールの送信や転送を行う前に、宛先に指定された受け手や受信ホストに関して多くのチェックを行います。メールがアカウントによって受け取り可能となるのは、そのメールがアカウントの認可上限と最下位機密ラベルの間にある場合に限られます。アカウントの持つ機密ラベル範囲については、第 5 章「ユーザーマネージャを使ったアカウントの設定」を参照してください。また、メールが特定のホスト上で受け取り可能となるのは、以下に示すように、そのメールがホストの持つ認可範囲内にある場合に限られます (詳しくは、第 10 章「トラステッドネットワークデータベースにおけるセキュリティ属性の指定とルーティング設定」も参照のこと)。

認可範囲が ADMIN_LOW と ADMIN_HIGH の間であるマルチレベルホストは、すべての機密ラベルのメールを受信できます。
制限された認可範囲を持つマルチレベルホストは、その最上位から最下位機密ラベル間にあるメールだけを受信できます。
シングルレベル (ラベルなし) ホストは、そのホスト用に設定されている単一機密ラベルを持つメールだけを受信できます。

ユーザーによるメール送信に問題が起こった場合は、次のガイドラインに従って、問題を調査してください。

メールエイリアスをチェックすること。

sendmail はメールの配送先を決定するのに、/etc/aliases ファイルと NIS+ テーブルである mail_aliases を参照します。たとえば、xxx という名前の Trusted Solaris ワークステーション上のプロセスがユーザー fred に対してメールを送信した場合、sendmail が mail_aliases テーブルを参照した結果 fred のエイリアスとして fred@yyy を見つけた場合、そのメールは fred@xxx には送信されません。

送信ホストと受信ホスト間のネットワーク接続が正しく設定されていることを確認すること。

ここで、「メール送信用にネットワーク接続が正しく設定されていることをチェックするには」に示されている手順を実行してください。

メール送信用にネットワーク接続が正しく設定されていることをチェックするには

mailx を使ってメールを送信します。
# mailx -v somebody@somehost Subject: test1 testl .
mailx が出力するメッセージを調べます。メッセージが受け付けられたことを示す行が表示されていれば手順 4 に移ります。

送信元のホストにログインし (またはメールサーバーが送信元ホストでない場合には、メールサーバーにログインし)、ユーザーのメール送信に必要となる機密ラベルにログインします。

telnet(1) コマンドを発行し、受信側ホストの 25 番ポートに接続します。
trustworthy% telnet hostname 25
送信元のホストと受信側ホスト間のトラステッドネットワークデータベース内で、正しいラベルで接続が設定されている場合は、宛先ホストの sendmail が次のようなメッセージを出力します。
220 hostname Sendmail version ready at date
接続を終了するには quit と入力します。
quit
telnet からエラーメッセージが出力された場合は、接続が設定されていません。この場合、手順 6 以降に移り、デバッグしたいホストの種類に適合した手順を実行してください。接続が正しく設定された場合には次の手順に移ります。

送信メールの機密ラベルで、送信元ホスト上のメール待ち行列の内容を表示します。メールサーバーが送信元ホストでない場合には、メールサーバー上のメール待ち行列の内容を表示します。

表示内容を調べ、送信したメールがメールサーバー上の待ち行列に入っているかどうかを調べます。
# mailq | more

「sendmail の Trusted Solaris 情報をトレースするには」に示されている手順を実行します。

宛先ホストが Trusted Solaris 2.x または 7 システムである場合、次の手順で宛先ユーザーがTrusted Solaris のセキュリティポリシーに基づくメールを受け取れるかどうかを確認します。
1. (必要に応じてユーザーマネージャを使って)、受信者が有効なユーザーアカウントを持っていることを確認します。
2. ユーザーマネージャの「ラベル (Labels)」ダイアログボックスを使って、そのアカウントの最下位ラベルと認可上限を調べます。
3. 送信されたメールの持つ機密ラベルが、受信者の最上位ラベルよりも劣位で、かつ、受信者の最下位ラベルよりも優位であることを確認します。
  1. 送信されたメールの持つ機密ラベルが受信者のアカウントの持つラベル範囲にない場合、送信者と受信者の相互に受け入れ可能な機密ラベルが見つかるならば、そのラベルを使って再度送信を試みます。
  2. メールが届いた場合は、今後この受信者に対しては、上記の相互に受け入れ可能な機密ラベルを使うよう送信者に指示します。
4. メールの持つ機密ラベルが、label_encodings(4) ファイルに定義されて、宛先ホストのユーザー認可範囲およびシステム認可範囲内にあることを確認します。
  
  sendmail は、メールの持つ機密ラベルがシステム認可範囲外にある場合、そのメールを配送しません。
  
  たとえば、ADMIN_LOW や ADMIN_HIGH ラベルで送信されたメールのように、メールの持つ機密ラベルがシステム認可範囲内にはあるが、ユーザー認可範囲内にはない場合、一般ユーザーはデフォルトではそのメールを受け取れません。このような場合は、次の手順に移ります。
5. 宛先ユーザーの最下位ラベルよりも低いラベルを持つメールの場合、自サイトのセキュリティポリシーが許すならば、次の手順を実行します。
  
  詳細は、「受信者の最下位ラベルよりも低いラベルのメールに関する Sendmail の処理」および「ユーザーの最下位ラベルよりも低いラベルのメールに関するメール配送オプションを設定するには」を参照してください。
  1. システム上のすべてのユーザーが自分の最下位ラベルよりも低いラベルのメールを受け取れるようにするには、tsoluserlowupgrade (デフォルト) の指定により sendmail がメールを自動的に昇格していることを確認します。または、tsoluserlowaccept を指定することで、メールリーダーがメールを着信ラベルで生成していることを確認します (これが行われている場合、アカウントが必要な承認を持っていれば、昇格が可能になります)。
  2. 管理役割に移行可能なすべての一般ユーザーアカウントだけが、ユーザー認可範囲外にあるシステムプロセスからのメールを受け取れるようにするには、sendmail の設定ファイルで tsoladminlowupgrade または tsoladminlowaccept オプションを設定してください。
  3. ある特定の管理役割が、ユーザー認可範囲外にあるシステムプロセスからのメールを受け取れるようにするには、プロファイルマネージャを使って、その管理役割に「すべての定義済みラベルを使用」承認を指定してください。
    
    (デフォルトの管理役割は、この承認をプロファイルに持っています)

Trusted Solaris 2.x または 7 オペレーティング環境を実行している宛先ホストの場合、送信側ホスト上で、受信側ホスト用の tnrhdb(4)/tnrhtp(4) エントリが正しく設定されており、他のホストとの通信ができるようにしてください。

注 -
tninfo(1M) コマンドを使うと、各ホストに割り当てられているテンプレートの種類、およびそのテンプレート内に指定されているホストのタイプや属性を調べることができます。-h hostname オプションは指定のホストに割り当てられているテンプレートの名前を表示し、-t template_name オプションはそのテンプレートに指定されているエントリ (ホストのタイプを含む) を表示します。
1. 宛先ホストが、tnrhdb(4) データベース内でそのホストに割り当てられている正しいテンプレート名を持つことを確認します。また、tnrhtp(4) ファイル内のテンプレートにそのホストのタイプが sun_tsol として正しく定義されていることを確認します。
2. tnrhtp ファイル内のテンプレートに記述されている最下位および最上位機密ラベルセットが、配送されなかったメールの持つ機密ラベルでの通信を許すかどうかを調べます。
3. これらの検査をパスした場合、ネットワーク接続は正しく動作するはずです。手順 3 に戻り、確認のために telnet(1) を再度実行してください。

Trusted Solaris 1.x オペレーティング環境を実行している宛先ホストの場合、送信側ホスト上で、受信側ホスト用の tnrhdb/tnrhtp エントリが正しく設定されており、他のホストとの通信ができるようになっていることを確認してください。
1. 宛先ホストが、tnrhdb データベース内でそのホストに割り当てられている正しいテンプレート名を持つことを確認します。また、tnrhtp ファイル内のテンプレートにそのホストのタイプが msix として正しく定義されていることを確認します。
2. tnrhtp ファイル内のテンプレートに記述されている最下位および最上位機密ラベルセットが、配送されなかったメールの持つ機密ラベルでの通信を許すかどうかを調べます。
3. これらの検査をパスした場合、ネットワーク接続は正しく動作するはずです。手順 3 に戻り、確認のために telnet を再度実行してください。

Trusted Solaris 以外のラベル付きオペレーティングシステムを実行している宛先ホストの場合、送信側ホスト上で、受信側ホスト用の tnrhdb ならびに tnrhtp エントリが正しく設定されており、Trusted Solaris システムがネットワークを介して他のホストとの通信ができるようになっていることを確認してください。
1. 必要であれば tnrhtp(4) のマニュアルページを読み、このホストに割り当てるテンプレート内で指定するホストタイプやその他のオプションを確認します。
  
  たとえば、CIPSO タイプのホストと RIPSO タイプのホストでは、それぞれ必要とするオプションが異なります。詳細は、第 10 章「トラステッドネットワークデータベースにおけるセキュリティ属性の指定とルーティング設定」を参照してください。
2. テンプレートを作成するかまたは tnrhtp 内にコピーを作成し、tnrhdb データベース内でそのホストに正しいテンプレートが割り当てられており、適切なホストタイプでそのホストが識別できることを確認します。
3. tnrhtp ファイル内のテンプレートに記述されている最下位および最上位機密ラベルセットが、配送されなかったメールの持つ機密ラベルでの通信を許すかどうかを調べます。
4. これらの検査をパスした場合、ネットワーク接続は正しく動作するはずです。手順 3 に戻り、確認のために telnet を再度実行してください。

ラベルを認識可能なオペレーティングシステムを実行していない宛先ホストの場合、送信側ホスト上で、受信側ホスト用の tnrhdb ならびに tnrhtp エントリが正しく設定されており、他のホストとの通信ができるようになっていることを確認してください。
1. 宛先ホストが、tnrhdb データベース内でそのホストに割り当てられている正しいテンプレート名を持つことを確認します。また、tnrhtp ファイル内のテンプレートにそのホストのタイプが「unlabeled」として正しく定義されていることを確認します。
2. tnrhtp ファイル内のテンプレートに記述されているラベルなしホスト用のデフォルトの機密ラベルが、配送されなかったメールの持つ機密ラベルでの通信を許すかどうかを調べます。
3. これらの検査をパスした場合、ネットワーク接続は正しく動作するはずです。手順 3 に戻り、確認のために telnet を再度実行してください。

ユーザーの再下位ラベルよりも低いラベルのメールに関する Trusted Solaris メール配送オプションの設定

セキュリティ管理者役割は、sendmail の設定ファイルである sendmail.cf に、Trusted Solaris に特有の機密性オプションとして、自サイトのセキュリティポリシーに合った値が設定されていることを確認する必要があります。詳細は、sendmail(1M) のマニュアルページの「Trusted Solaris での変更点」セクションを参照してください。以下の節ではこれらのオプションについて説明します。

受信者の最下位ラベルよりも低いラベルのメールに関する Sendmail の処理

受信者の最下位機密ラベルよりも低い機密ラベルのメールを受信した場合に sendmail が実行する処理には 2 つの種類を指定することができます。sendmail の設定ファイル内に「-Optsol...」機密性オプションを設定することで、メールが ADMIN_LOW ラベルを持つかそれとも受信者の最下位機密ラベルよりも低い他のラベルを持つかに応じて、どのような処理を実行するかを指定できます。ADMIN_LOWラベルのメールは他のラベルのメールとは違った扱いを受けます。これは、ADMIN_LOW ラベルのメールは常にシステムプロセスから特定のアカウント (通常は、管理役割アカウント) へと送信されるものであり、同アカウントはそのメールを読む必要があるからです。一方、ユーザー認可範囲内の特定のラベル (CONFIDENTIAL や INTERNAL USE ONLY など) を持つことを許可されたユーザーの場合、その最下位ラベルが SECRET または NEED TO KNOW であるようなユーザーにメールを送れるようにする必要はおそらくないでしょう。

このようなオプションを使用するかどうかは、各サイトのセキュリティポリシーに任されています。/etc/mail/sendmail.cf のデフォルト設定では、ADMIN_LOW ラベルで送信されたメールは自動的に昇格されますが、受信者の最下位ラベルよりも低いラベルを持つメールは送信者に戻されるようになっています。

メール処理オプション

上記の処理を行うために、-tsoladminlow という接頭辞を持つ互いに排他的な 3 つのオプションと、-tsolotherlow という接頭辞を持つ互いに排他的な 3 つのオプションが提供されています。これらはいずれも同じ接頭辞を持つ 3 つのうちのどれか 1 つだけを指定するタイプのオプションです。各オプション名には、ADMIN_LOW ラベルのメールを受け取った時に sendmail が実行する処理、または受信者の最下位機密ラベルよりも低いその他の機密ラベルのメールを受け取った時に sendmail が実行する処理の名前が含まれています。-upgrade は受信者の最下位機密ラベルでそのメッセージを配送することを意味します。-accept はそのメッセージ自身が持つ機密ラベルでメッセージを配送することを意味します。-return はそのメッセージを送信者に戻すことを意味します。

表 6-1 Trusted Solaris のメール処理オプション


オプション名	意味
`-tsoladminlowupgrade`	デフォルトの設定。`ADMIN_LOW` ラベルのメールを受け入れ、それをユーザーの最下位 SL で配送する。
`-tsoladminlowaccept`	`ADMIN_LOW` ラベルのメールを受け入れ、それを `ADMIN_LOW` ラベルで配送する。ユーザーの実行プロファイルに「すべての定義済みラベルを使用」承認が存在する場合にのみ、そのユーザーはこのメールを昇格し、読むことができる。
`-tsoladminlowreturn`	`ADMIN_LOW` ラベルのメールを送信者に戻す
`-tsolotherlowupgrade`	受信者の最下位 SL よりも低い SL で受け取ったメールを受信者の最下位 SL まで昇格する。このメールは `sendmail` によりアップグレードされるため、これを受け取るユーザーに「すべての定義済みラベルを使用」承認は必要ない。
`-tsolotherlowaccept`	受信者の最下位 SL よりも低い SL のメールを受け入れ配送する。ユーザーの実行プロファイルに「すべての定義済みラベルを使用」承認が存在する場合にのみ、そのユーザーはこのメールを昇格し、読むことができる。
`-tsolotherrlowreturn`	デフォルトの設定。受信者の最下位 SL よりも低い SL のメールを送信者に戻す。

ユーザーの最下位ラベルよりも低いラベルのメールに関するメール配送オプションを設定するには

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

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

「メール・オプションの設定 (Set Mail Options)」アクションを使用して sendmail.cf ファイルを開き、編集を行います。

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

「-Optsol」で始まる行を検索し、2 つのデフォルト設定を変更します。

tsol 機密性オプションの名前と意味については、表 6-1を参照してください。

# TSOL actions for mail received below recipient min label
#    options are:
#         tsoladminlowupgrade - upgrade to user min label (default)
#        tsoladminlowaccept  - accept at delivered label
#        tsoladminlowreturn  - return to sender
#        tsolotherlowupgrade - upgrade to user min label
#        tsolotherlowaccept  - accept at delivered label
#        tsolotherlowreturn  - return to sender (default)
 
Optsoladminlowupgrade    
Optsolotherlowreturn

他のメールアプリケーションを代用するには

デフォルトでは、Trusted Solaris のフロントパネルのメールパネルから起動されるメールアプリケーションは dtmail になります。Trusted Solaris システムでは、これを別のメールアプリケーションに置き換えることが可能です。ただし、そのメーラーが完全なマルチレベル対応のメール機能を提供できるようにするための、置き換えに必要な設定作業を行えるのは管理者役割だけです。

管理者による処理がなくても、各ユーザーは代替メールアプリケーションのアクションをフロントパネルにドラッグ＆ドロップすることで、新しくインストールされたメーラーを現在のワークスペースの機密ラベルで使用することができます。しかし、このような方式でアクションをインストールした場合、複数の機密ラベルによるメールの監視が行えなくなります。したがって、このような方式は、単一機密ラベルを使っているサイトでのみ有効です。

管理者役割は次のことが行えます。

フロントパネル制御ファイルを変更し、代替メールアクションをすべてのユーザーが使えるようにすること (「フロントパネルの代替メールアクションをすべてのユーザーが使えるようにするには」を参照のこと)。
代替メールアクションの制御ファイルを各ユーザーに配布し、代替の制御ファイルを各ユーザーのフロントパネルの「メール (Mail)」サブパネルにドラッグ＆ドロップする方法を指示すること (「代替メールアプリケーション用のマルチレベルアクションを作成するには」を参照のこと)。

代替メールアクションをフロントパネルにインストールする場合、そのメールアプリケーションに対応するアプリケーションを定義しなければなりません。「フロントパネルの代替メールアクションをすべてのユーザーが使えるようにするには」では、Dtmail の代わりに OpenWindows の mailtool を使用する例を示します。/usr/dt/appconfig/types/localename/sunOW.dt に定義されている OpenWindows の mailtool アクションを次の例に示します (localename はロケール名を示しています)。

例 6-3 sunOW.dt 内の OpenWindows の mailtool アクションの定義

ACTION OWmailtool
{
        LABEL           OW Mail Tool
        ICON            OWmailtool
        TYPE            COMMAND
        WINDOW_TYPE     NO_STDIO
        EXEC_STRING     /usr/openwin/bin/mailtool
}

デフォルトのメールアイコンを変更するときの注意

代替メールアイコンをインストール中に、またはデフォルトのメールアイコンを削除中にメールが到着した場合には問題が起こる場合があります。このため、これらの作業を行う場合は前もって sendmail を停止させ、作業が終了してから sendmail を最起動するとよいでしょう。

すべてのメールアイコンがフロントパネルから消えた場合、アカウントのホームディレクトリの /.dt/fp.dynamics ディレクトリを調査してください。システムの運用中は、フロントパネルに対するすべての変更は、そのセッションの認可上限で各アカウントの $HOME/.dt/fp.dynamics に保存されています。fp.dynamics の内容をバックアップディレクトリにコピーし、フロントパネルの設定が復旧するまでそのファイルをひとつずつ戻します。

フロントパネルの代替メールアクションをすべてのユーザーが使えるようにするには

注意 -

次の操作は、アカウントがシステムでメールの受け取りを開始する前に行なってください。そうしない場合、ウィンドウシステムが各ホームディレクトリ MLD の各 SLD にある .dt/fp.dynamics に作成したディレクトリの内容をきれいにすることが必要となることがあります。

管理者役割になり、ADMIN_LOW ワークスペースにいることを確認します。

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

dtterm(1) などの端末エミュレータにおいて、/etc/init.d ディレクトリに移動し、sendmail を停止します。
$ cd /etc/init.d $ sendmail stop

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

代替メールアクションにアクションが定義されていることを確認します。

必要に応じて、「他のメールアプリケーションを代用するには」を参照してください。

アプリケーションマネージャの「システム管理 (System_Admin)」フォルダの「管理用エディタ (Admin Editor)」アクションを使用して、/usr/dt/appconfig/types/locale_name/dtwm.fp を開き、編集を行います (locale_name はロケール名を示しています)。

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

次に示すようなメールの制御を行うセクションを検索します。

CONTROL Mail
{
  TYPE                      icon
  CONTAINER_NAME            Top
  CONTAINER_TYPE            BOX
  POSITION_HINTS            5
  ICON                      DTmail
  LABEL                     Mail
  ALTERNATE_ICON            DtMnew
  MONITOR_TYPE              mail
  DROP_ACTION               Compose
  PUSH_ACTION               DTWmail
  PUSH_RECALL               true
  CLIENT_NAME               dtmail
  HELP_TOPIC                FPOnItemMail
  HELP_VOLUME               FPanel
}

TYPE、CONTAINER_NAME、CONTAINER_TYPE、POSITION_HINTS は、以下に示すようにそのままにしておきます。

TYPE                            icon
CONTAINER_NAME                  Top
CONTAINER_TYPE                  BOX
POSITION_HINTS                  5

ICON フィールドの値を、代替アプリケーションのアイコンを表す値に変更します。
ICON OWmailtool

LABEL フィールドの値を、「メール (Mail)」サブパネル内の代替アプリケーションのアイコンと一緒に表示されるアイコンラベルに変更します。
LABEL OW Mail Tool

ALTERNATE_ICON および MONITOR_TYPE は変更しません。

ALTERNATE_ICON                   DtMnew
MONITOR_TYPE                     mail

DROP_ACTION を変更するか、またはそのままにしておきます。
DROP_ACTION Compose
メールプログラムには「メール作成」アクションを持つものと持たないものがあります。OpenWindows のメールツール (mailtool) は「メール作成」アクションを持ちません。このため、DROP_ACTION を「メール作成」のままにしておくと、誰かがメールをメールアイコンにドラッグした場合、dtmail の「メール作成」アクションが起動されます。DROP_ACTION を削除すると、メールがメールアイコンにドラッグされても何も起こりません。

PUSH_ACTION フィールドの値を、ユーザーが新しいメールアイコンをクリックした時に実行する代替アクションを表す値に変更します。
PUSH_ACTION OWmailtool
ここで指定するアクション名は、アプリケーション検索パスのどれかに定義されている必要があります。上記の OWmailtool アクションは /usr/dt/appconfig/types/localename ディレクトリの sunOW.dt に定義されています (localename はロケール名を示しています)。

PUSH_RECALL は変更しません。
PUSH_RECALL true
この値が「true」の場合、アプリケーションを 2 度立ち上げようとしても、新しいアプリケーションは起動しません。アプリケーションウィンドウがワークスペースで隠されている場合には、代わりにアプリケーションウィンドウが最前面に移動します。

CLIENT_NAME フィールドの値を、代替アプリケーションの実行可能ファイルを表すものに変更します。
CLIENT_NAME mailtool
CLIENT_NAME に指定するアクションのパス名は、そのアクション定義の EXEC_STRING に指定されているものである必要があります。たとえば、OWmailtool アクションの EXEC_STRING は /usr/openwin/bin/mailtool として定義されています。

エントリ HELP_* は変更しません。

 
HELP_TOPIC                    FPOnItemMail
HELP_VOLUME                   FPanel

変更を保存し、ファイルを閉じます。
:wq
注 -
次の手順 8 は、この作業をシステムの稼動後に行なった場合にのみ必要となります。

$HOME/.dt/fp.dynamics ディレクトリの内容をすべて削除します。

ワークスペースのメニューを使ってワークスペースマネージャを再起動し、dtwm.fp に対する変更がフロントパネル上に反映されていることを確認します。

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

dtterm(1) などの端末エミュレータにおいて、/etc/init.d ディレクトリに移動し、sendmail を再スタートさせます。
$ cd /etc/init.d $ sendmail start

代替メールアプリケーション用のマルチレベルアクションを作成するには

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

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

「管理用エディタ (Admin Editor)」アクションを使って、/usr/dt/appconfig/types/localename/dtwm.fp ファイルを編集用に開きます (localename はロケール名を示しています)。

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

以下に示すようなメールの制御を行うセクションを検索します。

CONTROL Mail
{
  TYPE                      icon
  CONTAINER_NAME            Top
  CONTAINER_TYPE            BOX
  POSITION_HINTS            5
  ICON                      DTmail
  LABEL                     Mail
  ALTERNATE_ICON            DtMnew
  MONITOR_TYPE              mail
  DROP_ACTION               Compose
  PUSH_ACTION               DTWmail
  PUSH_RECALL               true
  CLIENT_NAME               dtmail
  HELP_TOPIC                FPOnItemMail
  HELP_VOLUME               FPanel
}

上記の制御テキストを拡張子 .fp を持つファイル (たとえば mail.fp) にコピーし、dtwm.fp を閉じます。

注 -
新しいファイル mail.fp は、/etc または /usr/bin のように、すべてのユーザーのパスにあるようなディレクトリに作成します。
:wq

「システム管理 (System_Admin)」フォルダから「管理用エディタ (Admin Editor)」アクションを起動し、新ファイル mail.fp を編集用に開きます。

CONTROL OW_Mail セクションを以下のように変更します。

CONTROL OW_Mail
{
  TYPE                      icon
  CONTAINER_NAME            Top
  CONTAINER_TYPE            BOX
  POSITION_HINTS            5
  ICON                      DTmail
  LABEL                     Mail
  ALTERNATE_ICON            DtMnew
  MONITOR_TYPE              mail
  DROP_ACTION               Compose
  PUSH_ACTION               DTWmail
  PUSH_RECALL               true
  CLIENT_NAME               dtmail
  HELP_TOPIC                FPOnItemMail
  HELP_VOLUME               FPanel
}

TYPE、CONTAINER_NAME、CONTAINER_TYPE、POSITION_HINTS は変更しません。

TYPE                       icon
CONTAINER_NAME             Top
CONTAINER_TYPE             BOX
POSITION_HINTS             5

ICON フィールドの値を、代替アプリケーションのアイコンを表す値に変更します。
ICON OWmailtool

LABEL フィールドの値を、「メール (Mail)」サブパネル内の代替アプリケーションのアイコンと一緒に表示されるアイコンラベルに変更します。
LABEL OW Mail Tool

ALTERNATE_ICON および MONITOR_TYPE は変更しません。

 
ALTERNATE_ICON                    DtMnew
MONITOR_TYPE                      mail

DROP_ACTION を変更するか、またはそのままにしておきます。
DROP_ACTION Compose
メールプログラムには「メール作成」アクションを持つものと持たないものがあります。たとえば OpenWindows のメールツール (mailtool) は「メール作成」アクションを持ちません。このため、DROP_ACTION を「メール作成」のままにしておくと、誰かがメールをメールアイコンにドラッグした場合、dtmail の「メール作成」アクションが起動されます。DROP_ACTION を削除すると、メールがメールアイコンにドラッグされても何も起こりません。

PUSH_ACTION フィールドの値を、ユーザーが新しいメールアイコンをクリックした時に実行する代替アクションを表す値に変更します。
PUSH_ACTION OWmailtool
ここで指定するアクション名は、アプリケーション検索パスのどれかに定義されている必要があります。上記の OWmailtool アクションは /usr/dt/appconfig/types/localename ディレクトリの sunOW.dt に定義されています (localename はロケール名を示しています)。

PUSH_RECALL は変更しません。
PUSH_RECALL true
この値が「true」の場合、アプリケーションを 2 度立ち上げようとしても、新しいアプリケーションは起動しません。アプリケーションウィンドウがワークスペースで隠されている場合には、代わりにアプリケーションウィンドウが最前面に移動します。

CLIENT_NAME フィールドの値を、代替アプリケーションの実行可能ファイルを表すものに変更します。
CLIENT_NAME mailtool
CLIENT_NAME に指定するパス名は、そのアクション定義の EXEC_STRING に指定されているものである必要があります。たとえば、OWmailtool アクションの EXEC_STRING は /usr/openwin/bin/mailtool として定義されています。

エントリ HELP_* は変更しません。

HELP_TOPIC                   FPOnItemMail
HELP_VOLUME                  FPanel

変更を保存し、ファイルを閉じます。
:wq

事前にこの手順をテストし、メーラーが表示され正しく動作することを確認した後、「フロントパネルに別のメールプログラムをインストールするには」の手順をユーザーに指示します。

フロントパネルに別のメールプログラムをインストールするには

管理者から、正しいメールアプリケーションの制御ファイルのパス名を入手します。

管理者役割は、ユーザーの認可範囲内にあるすべてのラベルのメールを監視または通知するようにメーラーを設定する必要があります。詳細は、「代替メールアプリケーション用のマルチレベルアクションを作成するには」を参照してください。

注意 -
自サイトのセキュリティ管理者の承認を得ない限り、次を厳守してください。
- アプリケーションマネージャのフォルダから別のメールプログラムをインストールしない。
- 接尾辞 .fp が付かない制御ファイルを持つ別のメールプログラムはインストールしない。

セキュリティ管理者役割に sendmail を停止するよう依頼します。

ファイルマネージャを使って、インストールするメールプログラム (新しいメールプログラムと呼びます) の制御ファイルが置かれているディレクトリに移動します。

「メールプログラム」サブパネル呼び出しボタンをクリックし、同サブパネルを起動します。

新しいメールプログラムのフロントパネル制御ファイルのアイコンをドラッグし、「メール」サブパネルの「アイコンのインストール」ドロップサイト上にドロップします。

新しいメールアプリケーション用のアイコンが「メール」スライダに表示されます。

ポインタを新しいメールアプリケーション用のアイコンに置いた状態で、マウスの右ボタンをクリックし、「メインパネルに表示」を選択します。

ポインタを「メール」サブパネル内の古いメールアプリケーション用のアイコンに置いた状態で、マウスの右ボタンをクリックし、「削除」を選択します。

古いメールアプリケーション用のアイコンをすべて削除するまで、上記の操作を繰り返します。古いメールアプリケーションと新しいメールアプリケーションを同時に使用することはできません。

ワークスペースのメニューから「ワークスペース・マネージャの再起動」を選択します。

サブパネルのサイズは、ウィンドウマネージャを再起動するまで補正されません。

管理者役割に sendmail を再起動するよう依頼します。

第 7 章ユーザーマネージャ用データ収集ワークシート

注 -

ユーザーと役割アカウント用ワークシートの第 1 列に示した名前は、ユーザーマネージャの「ナビゲータ」ダイアログボックスのボタンのラベル名に対応しています。

ユーザーアカウント／役割アカウント用ワークシート

ユーザーまたは役割のフルネームおよび機能
主ホスト名
ドメイン名

識別情報	ログイン名: UID:
	一次 GID: 二次 GID:
	コメント:
	シェル: [ ] Bourne [ ] C [ ] プロファイル [ ] その他:
	ユーザータイプ: [ ] 一般ユーザー [ ] 管理役割 [ ] 非管理役割
ホーム	ホームディレクトリを自動作成するか
	ホームディレクトリのパス:
	スケルトンパス:
	デフォルトのアクセス権:
	メールサーバー:
	AutoHome の設定:
パスワード	[ ] アカウントを凍結 [ ] パスワードなし (setuid のみ有効) [ ] パスワードの入力 [ ] リストから選択
	パスワードの再変更が可能となるまでの最短日数:
	パスワードの再変更が必要となるまでの最長日数:
	有効期限: 警告 (有効期限日までの日数):
	変更方法 (アカウントが使用するパスワードの生成方法)：[ ] リストから選択 [ ] パスワードの入力
	アカウントのステータス [ ] 開く [ ] 閉じる [ ] 常に開く
	NIS+ 資格テーブルの設定
アイドル	アイドル時間：[ ] アクション実行までの時間 [ ] 設定しない
	アクション：[ ] ログアウト [ ] 画面ロック
ラベル	認可上限:
	最下位機密ラベル:
	表示：[ ] 内部用 (管理ラベルの名前をユーザー認可範囲内にある同等ラベルで置き換える) [ ] 外部用 (実際の管理ラベルを表示) [ ] Sys デフォルト
	機密ラベル：[ ] 表示 [ ] 非表示
	情報ラベル：[ ] 表示 [ ] 非表示
プロファイル	プロファイル名とそれが含むツールについては付録 A 「プロファイル概要テーブル」を参照のこと


役割	[ ] セキュリティ管理者 [ ] システム管理者 [ ] オペレータ [ ] スーパーユーザー

第 8 章ユーザーおよび役割のための実行プロファイルの管理

この章では、実行プロファイルの変更や追加を行う方法について説明します。実行プロファイルは個々のユーザーや管理役割の持つ機能を定義するのに使われます。この章の主な項目には次のものがあります。

この章では次の操作手順を示します。

プロファイルに関係する用語について

この節では、実行プロファイルに関係する Trusted Solaris 独自の概念や用語について再度説明します。また新しい概念や情報も説明します。ここで再度説明する項目は、『Trusted Solaris ユーザーズガイド』で紹介され、『Trusted Solaris 管理の概要』でより詳しく説明されたもので、便宜上、このマニュアルにも含まれています。

実行プロファイル

実行プロファイルとは、個々のユーザーや管理役割の持つ機能を定義する仕組みです。各実行プロファイルには、UNIX コマンド、CDE アクション、承認のリストを含めることができ、また実行プロファイルではこれらの各コマンドやアクションに特定のセキュリティ属性 (実効 UID、実効 GID、継承可能な特権、ラベル制限)を関連付けることもできます。各ユーザーまたは役割には 1 つ以上の実効プロファイルを割り当てることができます。実効プロファイルを指定する順番には意味があります。ユーザーまたは役割に複数の実効プロファイルが割り当てられている場合、それらの一連の承認は結合されることになります。また、何らかのコマンドやアクションが発行されると、そのコマンドやアクションに関する属性記述を見つけるために、そのアカウントの持つすべてのプロファイルのリストが検索されます。この結果、そのコマンドやアクションは、それらが最初に現れたプロファイルに指定されている特権、UID、GID を使って実行されることになります。また、実行プロファイルを使うと、ユーザーの使用するアプリケーションやコマンドを特定のものだけに制限することや、役割の仕組みと組み合わせて使うことで特定のアカウントの機能を拡張することもできます。詳細は、「有効化属性」および「制限属性」の項を参照してください。

実効 UID および GID

コマンドを実行するプロセスは、実効ユーザー ID (EUID) および実効グループ ID (EGID) を持ちます。これらは、プロセスが、セットユーザー ID (setuid) ビットまたはセットグループ ID (setgid) ビットがセットされたコマンドを実行しない限り、それぞれそのプロセスの実 UID および実 GID に等しくなります。setuid ビットや setgid ビットをセットすることにより実効ユーザー ID または実効グループ ID (またはその両方) を設定することは、通常、コマンドの実行時にそのコマンド自身が root (UID が 0) によって実行されていることを検査するようなコマンドに対して行われます。あるコマンドやアクションの setuid ビットや setgid ビットをセットすると、標準 UNIX システム内ではスーパーユーザーしか実行できない作業を、管理者でないユーザーが実行できるようになります。Trusted Solaris 環境で同様の操作を実施するには、セキュリティ管理者は、コマンドやアクションが特定のユーザーやグループによって実行される必要がある場合、実効ユーザー ID および実効グループ ID を実行プロファイル内のそのコマンドやアクションに対して割り当てます。多くの場合、実効ユーザー ID および実効グループ ID の割り当ては、root として実行する必要のあるコマンドに対して行われます。

アクション

アクションとは、1 つ以上のコマンドを特定のタスクとしてまとめることで、そのタスクを 1 人以上のユーザーに割り当てられるようにする仕組みです。アクションは各コマンドと共に指定された一連のオプションや引数を持ちます。また、ユーザーに追加の引数の入力を求めるダイアログボックスを使用することもあります。

NIS+ によって管理されないファイルの編集を行うために、これまで一連の管理アクションが作成されて来ました。たとえば、vfstab_adjunct ファイルを編集する場合、セキュリティ管理者役割は「マウント属性の設定」というアクションを使います。「マウント属性の設定」アクションは、コマンド (adminvi)、引数 (vfstab_adjunct)、ラベル範囲 (ADMIN_LOW から ADMIN_HIGH)、root の実効 UID および sys の実効 GID を含んでいます。ラベルの範囲を制限すれば、vfstab_adjunct ファイルが特定の範囲のラベル内だけで、またはシングルラベルだけで編集されることを保証できます。実効 UID および実効 GID はこのファイルへのアクセスを保証し、編集プロセス中にこのファイルの所有者やグループが変更されないようにするために使われます。

各アクションは通常それ自身のアイコンを持ちます。また、各アクションはそれ自身のセキュリティ属性を割り当てられており、実効プロファイル内に指定できます。アプリケーションマネージャ内のアイコンやほとんどのフロントパネル内のアイコンは、何らかのアクションに対応しています。

アクションの追加方法については『共通デスクトップ環境ユーザーズ・ガイド』および『共通デスクトップ環境上級ユーザー及びシステム管理者ガイド』に説明されています。ただし、Trusted Solaris のセキュリティポリシーにより、誰がアクションを追加でき、誰がアクションを使用できるのかに関しては、これらの説明とは異なっています。

単一機密ラベルで実行する場合、一般ユーザーはアプリケーションマネージャを使ってアクションをフロントパネルにドラッグ＆ドロップできます。
システム管理者役割はアクションを登録し、それらを /etc/dt/appconfig/types/localename ディレクトリに置くことで、そのアクションをすべてのユーザーにとって利用可能とすることができます (localename はロケール名を示しています)。

アクションの追加方法に関しては、第 16 章「ソフトウェアの追加」の「アクション」を参照してください。

有効化属性

実行プロファイル内で、コマンドやアクションに対してオプションとして一連の無効化特権、実効ユーザー ID、実効グループ ID を割り当てることで、そのコマンドやアクションの機能を拡張できます。このようなコマンドやアクションを呼び出すことで、アカウントは次のことが可能となります。

Trusted Solaris のセキュリティポリシーの範囲外で作業すること
制御された方法で作業すること
厳密に定義された目的で作業すること

このような UID、GID、特権をまとめて「有効化属性」と呼びます。

制限属性

ラベル属性は「制限属性」と呼ばれます。これは、ラベル属性がコマンドやアクションを呼び出すことのできるラベルの範囲を制限するものだからです。デフォルトのラベル範囲は ADMIN_LOW から ADMIN_HIGH まで、システム認可範囲のすべての範囲となります。

プロファイル内の特権

実行プロファイル内で、コマンドやアクションに 1 つ以上の特権を割り当てると、その特権は、「特権の継承」を通じて利用可能となります。特権は「有効化属性」であると見なされます。コマンドは、プロファイルシェル (pfsh(1M)) から呼び出された場合にのみ特権を継承します。アクションは、ウィンドウシステム経由でプロファイルシェルが使用するデータベースルックアップにより、特権を継承します。

特権の継承を使うと、特権を利用するアカウントに対してさらに細かい制御が行えます。コマンドに関する継承された特権の使用と強制された特権の使用を比べてみると、強制された特権は実行プロファイルに関連付けられているため、そのコマンドを誰が呼び出したか、またはどのシェルが使われたかに関係なく、この特権は有効となります。一方、継承された特権は、ユーザーまたは役割がそのコマンドをプロファイルシェルで実行した場合、かつそのアカウントの実行プロファイルにそのコマンドを特権付きで実行するよう指定されている場合にのみ利用可能となります。

実行プロファイルに関する前提知識

プロファイルの追加や変更は、デフォルトのシステムに提供されている管理方法の範囲を超えて、さらにユーザーの活動を制御し管理者の機能を拡張したいと考えるサイトを対象とする上級者向けのトピックです。

Trusted Solaris 環境の提供するデフォルトの実行プロファイルセットには次のものがあります。

一般ユーザーのための基本的なプロファイル
3 つの管理役割プロファイルと 1 つの非管理役割プロファイル

これらのデフォルトの役割プロファイル間では、通常の UNIX システム管理者 (root／スーパーユーザー) の管理責任に加えて、Trusted Solaris システムに特化した管理責任を満たすのに必要なすべてのコマンド、アクション、承認、特権が分割されています。

デフォルトの実行プロファイルは、管理者が完全に信頼して義務を実行できるように定義されています。しかし、各サイトのセキュリティ管理者が実行プロファイルとその動作原理に精通したならば、そのセキュリティ管理者は次の問いに対する自サイトの答えに基づいて、新しいプロファイルを作成する場合があるでしょう。

システム全体で実施する必要のあるタスクと各個人で実施すべきタスクはそれぞれ何か
各個人が持つ必要のある機能とは何か
各個人について信頼できる情報や責任とは何か

注 -

Trusted Solaris のマニュアルでは、「プロファイル」のことを「実行プロファイル」と呼ぶことがあります。「実行」という語は、「インストールプロファイル (インストール時に作成され、システムの jumpstart の一部として使われるもの)」という別の種類のプロファイルとの混乱を避けるための強調表現として使われています。

実行プロファイルを変更する前に、特に新しい管理役割プロファイルを作成 (または既存の管理役割プロファイルを変更) する前に、現在の役割がどのように設定されているか、また現在行おうとしている変更や追加によってどのようなセキュリティ関連の影響が発生するかを完全に理解するようにしてください。これらの理解には、付録 A 「プロファイル概要テーブル」に示されている表が役立ちます。この表には、各プロファイルに割り当てられているコマンド、アクション、承認、および各アクションやコマンドに適用されるセキュリティ属性 (UID、GID、ラベル範囲) の一覧が示されています。

プロファイルマネージャを使った実行プロファイルの作成または変更

デフォルトの設定では、プロファイルマネージャはセキュリティ管理役割にのみ割り当てられます。プロファイルマネージャは ADMIN_LOW ラベルで使用されます。

プロファイルマネージャを起動すると (起動方法については、「プロファイルマネージャを起動するには」を参照のこと)、プロファイルマネージャの「読み込み (Load)」ダイアログボックスが表示されます (次の図を参照)。このダイアログボックスには、ネームサービスやプロファイルのフィルタ処理を選択できるメニューがあります。プロファイルをフィルタ処理すると、起動時に既存のプロファイルを読み込むか、それとも空のプロファイルマネージャを起動するかを選択できます。

図 8-1 プロファイルマネージャの「読み込み (Load)」ダイアログボックス

プロファイルマネージャの「読み込み (Load)」ダイアログボックスのコントロールボタンの使い方

上の図に示したコントロールボタンは、「特権を設定 (Set Privileges)」ダイアログボックスや「UID/GID を設定 (Set UID/GID)」ダイアログボックスに表示されるボタンと同じものです。

了解

「了解 (OK)」をクリックすると、変更が保存され、ダイアログボックスが閉じます。

リセット

「リセット (Reset)」をクリックすると、各フィールドを前回保存時の状態に戻します。ダイアログボックスは開いたままです。

取消し

「取消し (Cancel)」をクリックすると、変更は保存されずにダイアログボックスが閉じます。

ヘルプ

「ヘルプ (Help)」をクリックすると、文脈に応じたヘルプメッセージが表示されます。

ネームサービスの選択

他の Trusted Solaris の AdminSuite ツールと同様に、プロファイルマネージャはユーザーにネームサービスの指定を求めます。デフォルトは「NIS+」であり、これは分散したユーザーおよびホスト情報を集中管理するのに優れた仕組みです。「なし (None)」オプションは、熟練したセキュリティ管理者が、個々のホスト上でのローカルなプロファイルの作成は、自サイトのセキュリティポリシーに照らして必要かつ許容可能であると判断した場合にのみ使用してください。スタンドアロンの Trusted Solaris ホストでもこれらのネームサービスを利用できます。スタンドアロンで NIS+ を使うことができるのは、スタンドアロンが独自の NIS+ マスターとして構成されている場合だけです。

「ネームサービス (Naming Service)」メニューで「NIS+」を選択した場合、実行プロファイルに対して行った変更は、指定のドメイン用の NIS+ tsolprof テーブル内に格納されます。現在のドメイン名は NIS+ オプションの隣に表示されます (次の図を参照)。セキュリティ管理者役割が他のドメインでも認証される場合、現在のドメイン名をその NIS+ ドメイン名で置き換えることで、他のドメインの NIS+ プロファイルテーブルを更新できます。

図 8-2 プロファイルマネージャの「読み込み (Load)」ダイアログボックスの「ネームサービス (Naming Service)」メニューと「NIS+」オプション

「ネームサービス (Naming Service)」メニューで「なし (None)」を選択すると、次の図に示すようなローカルホスト名が表示されます。「ホスト名 (Host)」フィールドの名前は変更可能です。これを選択した場合、実行プロファイルに対して行った変更は、指定のホスト上の /etc/security/tsol/tsolprof ファイルに格納されます。

図 8-3 プロファイルマネージャの「読み込み(Load)」ダイアログボックスの「ネームサービス (Naming Service)」メニューと「なし (None)」オプション

入力前に決定すべき事項

NIS+ を使用するか、それともネームサービスを使用しないかを決定すること

プロファイルのフィルタ処理

「プロファイルの表示対象 (Filter Profiles)」メニュー (図 8-4 を参照) を使うと、プロファイルマネージャを空のまま起動するか、それとも指定のプロファイルを読み込んだ状態で起動するかを指定できます。「プロファイルの表示対象 (Filter Profiles)」メニューのどのオプションを選ぶかは、新しいプロファイルを追加するか、それとも既存のプロファイルを変更するかによって決まります。詳細は、「新しいプロファイルを追加する場合」または「既存のプロファイルを変更する場合」を参照してください。

注 -

どちらのオプションを選択した場合でも、いったんプロファイルマネージャが起動した後で「プロファイル (Profiles)」メニューを使うことにより、他のプロファイルを表示することや画面を空にすることができます。詳細は、「プロファイルマネージャ内で空のプロファイル定義の表示、既存プロファイルの読み込み、変更の保存を行うには」を参照してください。

図 8-4 プロファイルマネージャの「読み込み (Load)」ダイアログボックスの「プロファイルの表示対象 (Filter Profiles)」メニュー

注 -

プロファイルマネージャは起動時にはアクションモードで表示され、「含まない　 (Excluded)」および「含む (Included)」リストが表示されます (アクションモードのプロファイルマネージャについては図 8-6 を参照のこと)。プロファイルマネージャの「表示 (View)」メニューを使うと、アクションモード、コマンドモード、承認モードの切替えを行えます。詳細は、「実行プロファイル中内にコマンドを指定するには」を参照してください。

入力前に決定すべき事項

新しいプロファイルを追加する場合は「新しいプロファイルを追加する場合」に進み、既存のプロファイルを変更する場合は「既存のプロファイルを変更する場合」に進むこと。

新しいプロファイルを追加する場合

新しいプロファイルを追加する場合、プロファイルマネージャを次のどちらかの状態で起動します。

空の状態 (「空のプロファイルマネージャを起動するには」を参照のこと
変更またはリネームすることになる既存のプロファイルを読み込んだ状態 (「既存のプロファイルを読み込んだプロファイルマネージャを起動するには」を参照のこと

入力前に決定すべき事項

既存のプロファイルのコピーや変更を行うか、それとも空のプロファイルマネージャを起動するかを選択すること

既存のプロファイルを変更する場合

既存のプロファイルを変更する場合、既存のプロファイルを読み込んだプロファイルマネージャを起動します (「既存のプロファイルを読み込んだプロファイルマネージャを起動するには」を参照のこと)。その後、プロファイルに対する変更を行い、そのプロファイルと同じ名前で保存します。

空のプロファイルマネージャを起動するには

「プロファイルの表示対象 (Filter Profiles)」メニュー (図 8-5 を参照) で「なし (None)」を選択すると、空のプロファイルマネージャを起動できます (図 8-6 を参照)。

図 8-5 プロファイルマネージャの「読み込み (Load)」ダイアログボックスの「プロファイルの表示対象 (Filter Profiles)」メニューから「なし (None)」を選択

図 8-6 アクションモードで起動した空のプロファイルマネージャ

既存のプロファイルを読み込んだプロファイルマネージャを起動するには

「プロファイルの表示対象 (Filter Profiles)」メニューから「すべて (All)」または「指定したものを表示 (Specify)」を選択すると、プロファイルの名前を選べるリストが表示されます。プロファイル名を選択した後「読み込み (Load)」をクリックすると、既存のプロファイルを読み込んだプロファイルマネージャが起動されます。

すべての既存のプロファイル名から1つを選択したい場合は、「既存のプロファイル名を選択するには」を参照のこと。
正規表現を使って特定の既存のプロファイル名を検索したい場合は、「既存のプロファイル名を指定するには」を参照のこと。

既存のプロファイル名を選択するには

「プロファイルの表示対象 (Filter Profiles)」メニューから「すべて (All)」を選択する (次の図を参照) か、または OK をクリックすると、すべてのプロファイルのリストから 1 つのプロファイル名を選択できます。

特定のプロファイル名を強調表示させ「読み込み (Load)」をクリックすると (次の図を参照)、そのプロファイルを読み込んだ状態でプロファイルマネージャが開きます。

既存のプロファイル名を指定するには

「プロファイルの表示対象 (Filter Profiles)」メニューから「指定したものを表示 (Specify)」を選択すると、テキスト入力フィールド内に次のいずれかの方法でプロファイル名を指定できます。

正規表現を入力して、該当するプロファイル名の一覧を生成します。

上図の例では、文字 P で始まるプロファイルを検索するために、「P*」を入力しています。次の図にこの検索結果を示します。プロファイルマネージャの「開く (Open)」ダイアログボックスに「Privileged Shells」プロファイルが表示されます。このプロファイル名を強調表示させ「読み込み (Load)」をクリックすると、「Privileged Shells」プロファイルを読み込んだプロファイルマネージャが開きます (次の図を参照)。
既知のプロファイル名を入力して、そのプロファイル名を表示します。

プロファイルマネージャ内で空のプロファイル定義の表示、既存プロファイルの読み込み、変更の保存を行うには

次の図に「プロファイル (Profile)」メニューのオプションを示します。

図 8-7 プロファイルマネージャの「プロファイル (Profile)」メニュー

「プロファイル (Profile)」メニューの各オプションを使うと次のことができます。

「新規プロファイル (New Profile)」は既存のプロファイルの記述をクリアします。
「プロファイルを開く (Open Profile)」を使うと、すべてのプロファイルのリストから別のプロファイルを選んで読み込むことがきます (図 8-8 に示すように、すべてのプロファイルのリストを持つプロファイルマネージャの「開く (Open)」が表示されます)。
「プロファイルを保存 (Save Profile)」は現在のプロファイルに対する変更を保存します。
「読み込み (Load)」は新しい実行プロファイルを読み込みます。
「閉じる (Close)」はプロファイルマネージャを閉じます。保存していない変更を保存するかどうかのプロンプトは表示されません。

図 8-8 プロファイルマネージャの「開く (Open)」ダイアログボックスでプロファイル名を強調表示

プロファイル名またはプロファイル記述の入力と変更

特定のプロファイルを読み込まずにプロファイルマネージャを起動した場合、空のテキスト入力フィールドに新しいプロファイルの名前とプロファイルの記述を入力できます。それらを入力した後、「プロファイル (Profiles)」メニューから「保存 (Save)」を選択すると、指定した名前の新しいプロファイルが作成されます。

特定のプロファイルを読み込んだ状態でプロファイルマネージャを起動した場合、次の図に示すように既存のプロファイルの名前と記述を変更できます。既存のプロファイル名を変更した後、「プロファイル (Profiles)」メニューから「保存 (Save)」を選択すると、指定した名前の新しいプロファイルが作成されます。

図 8-9 プロファイルマネージャの「プロファイル名 (Profile Name)」と「説明 (Description)」フィールド

アクションモード、コマンドモード、承認モード間での切替え

プロファイルマネージャの「読み込み (Load)」ダイアログボックスで「了解 (OK)」をクリックすると (前出の図を参照)、プロファイルマネージャはまずアクションモードで起動されます。次の図は、アクションモード、コマンドモード、承認モード間での切替えを行うための「表示 (View)」メニューです。

図 8-10 アクションモード、コマンドモード、承認モード間での切替えを行うプロファイルマネージャの「表示 (View)」メニュー

詳細は、「コマンドモードでの作業」、「承認モードでの作業」、「アクションモードでの作業」を参照してください。

「含まない (Excluded)」および「含む (Included)」リストを使った作業

次の図に、プロファイルマネージャの「含まない (Excluded)」および「含む (Included)」リストの例を示します。このリストは、アクション、コマンド、承認、特権に関して使用できます。この例ではアクションが表示されていますが、これらのリストの使い方は、「含まない (Excluded)」および「含む (Included)」リストを表示するすべてのプロファイルマネージャダイアログボックス間で共通です。

図 8-11 「Privileged Shells」プロファイルを読み込んだプロファイルマネージャ

リスト間で項目を移動するには

リスト間で項目 (承認、特権、コマンド、完全なディレクトリ、個々のアクション、アプリケーショングループ内の一連のアクションなど) を移動するには、項目名を強調表示させ、矢印ボタンを使ってどちらかのリストへ移動します。

「含む (Included)」リストに対するドラッグ＆ドロップ操作

プロファイルマネージャの最下行に注記してあるように、現在のモードに該当している項目をファイルマネージャから「含む (Included)」リストにドラッグ＆ドロップできます。たとえば、コマンドモードの場合、/etc フォルダ内の mount コマンドの実行可能ファイルをドラッグし、それを「含む (Included)」リストにドロップできます。

「すべてを選択 (Select All)」と「すべてを消去 (Clear All)」ボタンを使ったすべてのリスト項目の移動と消去

すべてのモードのプロファイルマネージャと「特権を設定 (Set Privilege)」ダイアログボックスには、「すべてを選択 (Select All)」および「すべてを消去 (Clear All)」ボタンがあります。

すべてを選択

「すべてを選択 (Select All)」は「含まない (Excluded)」リスト内の項目すべてを「含む (Included)」リストに移動します。

すべてを消去

「すべてを消去 (Clear All)」は「含む (Included)」リスト内の項目すべてを「含まない (Excluded)」リストに移動します。

コマンドモードとアクションモードに共通の機能

この節では、プロファイルマネージャのコマンドモードとアクションモードに共通の機能について説明します。以下の項目があります。

コマンドモードとアクションモードにおけるアプリケーショングループやディレクトリのリストの展開と収縮

デフォルトの「含まない (Excluded)」リスト内の見出しは、それぞれ同一グループに属するアクション (アクションモードの場合) および同一グループに属するコマンド (コマンドモードの場合) を表しています。この見出し (または存在する場合にはそのアイコン) をダブルクリックすると、そのグループに含まれているすべての項目 (アクションまたはコマンド) を見ることができます。たとえば、強調表示されている Desktop Apps というアクション見出しをダブルクリックすると、このグループが展開され、次の図に示すようなこの見出しの下にグループ化されていたすべてのアクションがリスト表示されます。

図 8-12 グループ名を展開してその内容をリスト表示する

逆に、展開されているコマンド見出しをダブルクリックすると、リストはその見出し (またはディレクトリ名) へと収縮します。「含まない (Excluded)」リストと「含む (Included)」リスト間での項目の移動は 1 つずつ行うこともできますが、見出しやディレクトリ名によりグループごと移動することもできます。

コマンドおよびアクションに関するセキュリティ属性を設定するボタン

図 8-14 に示すボタン群は、「含む (Included)」リスト内の項目が強調表示されており、かつその項目にセキュリティ属性が設定できる場合にだけ表示されます。

図 8-13 特権、ラベル範囲、UID および GID を設定するボタン

図 8-14では、format コマンドが強調表示されています。コマンドに対しては、特権、機密ラベル範囲、UID および GID が設定できるため、これらの属性を設定するためのボタンが表示されています。一方、Tool Talk メッセージにはセキュリティ属性を設定できないため、Tool Talk メッセージを起動するアクション (TT_MSG が定義フィールドに表示されるもの) を強調表示した場合、これらのボタンはグレー表示となります。

図 8-14 特権、ラベル範囲、UID および GID を設定するボタン

コマンドおよびアクションに特権を設定するには

プロファイルマネージャ内でコマンドまたはアクションを強調表示させた後、「特権を設定 (Set Privileges)」ボタンをクリックすると、「特権を設定 (Set Privileges)」ダイアログボックスが表示されます (図 8-15 を参照)。多くの特権が「含まない (Excluded)」リスト内に表示されています。「含む (Included)」リストが空であるかどうかは、このコマンドに対して以前特権が割り当てられたことがあるかどうかによります。

定義

「説明 (Description)」フィールドには、この特権により、指定のコマンドを実行するプロセスが、セキュリティポリシーを迂回した上で何ができるのかを説明したテキストが表示されます。

図 8-15 プロファイルマネージャの「特権を設定 (Set Privileges)」ダイアログボックス

コマンドおよびアクションにラベル範囲を設定するには

プロファイルマネージャ内でコマンドまたはアクションを強調表示させた後、最下位および最上位機密ラベルを指定することにより、そのコマンドまたはアクションに対してラベル範囲を設定できます。「最下位 SL を設定 (Set Minimum SL)」ボタンまたは「最上位 SL を設定 (Set Maximum SL)」をクリックすると、ラベルビルダーが起動されます (「最下位 SL を設定 (Set Minimum SL)」ダイアログボックスを次の図に示します)。これらのダイアログボックスを使ってコマンドまたはアクションに対する最下位および最上位機密ラベルを指定する方法は、他の Trusted Solaris のラベルビルダーの場合と同じです。

図 8-16 プロファイルマネージャの「最下位 SL を設定 (Set Minimum SL)」ダイアログボックス

コマンドモードでの作業

この節では、承認モードやアクションモード用のダイアログボックスにはない、コマンドモードに特有の機能の使い方を説明します。ただし、以下のトピックに関する説明は重複するために省きます。

プロファイルマネージャの「表示 (View)」メニューから「コマンド (Commands)」を選択すると、コマンドモードが起動します (次の図を参照)。いくつかのディレクトリが「含まない (Excluded)」リスト内に表示されています。「含む (Included)」リストが空であるかどうかは、以前このプロファイルがコマンドを割り当てたことがあるかどうかによります。

図 8-17 プロファイルマネージャのコマンドモード

新しいディレクトリの読み込み

「含まない (Excluded)」リストに他のディレクトリを追加するには、「読み込み (Load)」ボタンの隣にあるテキスト入力フィールドにディレクトリのパス名を指定した後、「読み込み (Load)」ボタンをクリックします。次の図は、/etc ディレクトリを「パス名 (Pathname:)」フィールドに入力し、このディレクトリを「含まない (Excluded)」リストに追加した様子を示しています。

図 8-18 /etc ディレクトリのパス名を入力し、そこに含まれるコマンドを選択する

コマンドのマニュアルページを表示するには

「含む (Included)」リスト内でコマンドが強調表示されている場合、「マニュアルページ (Man Page)」ボタンをクリックすることで、「機能説明 (DESCRIPTION)」セクションで始まるそのコマンドのマニュアルページを見ることができます。

承認モードでの作業

承認モードには、アクションモードやコマンドモード用のダイアログボックスにはない、承認モード特有の機能はありません。承認モードでの作業については、以下の節ですでに説明してあります。

プロファイルマネージャの「表示 (View)」メニューから「承認 (Authorizations)」を選択すると、承認モードが起動します (次の図を参照)。多くの承認が「含まない (Excluded)」リスト内に表示されています。「含む (Included)」リストが空であるかどうかは、以前このプロファイルが承認を割り当てたことがあるかどうかによります。

図 8-19 プロファイルマネージャの承認モード

アクションモードでの作業

この節では、コマンドモードや承認モード用のダイアログボックスにはない、アクションモードに特有の機能の使い方を説明します。ただし、以下の項目に関する説明は重複するために省きます。

プロファイルマネージャの「表示 (View)」メニューから「アクション (Actions)」を選択すると、アクションモードが起動します (次の図を参照)。いくつかのアクションが「含まない (Excluded)」リスト内に表示されています。「含む (Included)」リストが空であるかどうかは、以前このプロファイルがアクションを割り当てたことがあるかどうかにより変化します。

図 8-20 プロファイルマネージャのアクションモード

アイコン

次の図に示したアイコンは、強調表示されているアクションまたはアプリケーショングループに割り当てられています。図の「説明 (Description)」セクションに記述されているように、アプリケーショングループのアイコンをクリックすると、そのグループに含まれているすべてのアクション項目のリストが表示されます。

図 8-21 アクションモードのアイコンと「タイプ (Type)」

タイプ

「タイプ (Type)」フィールドは強調表示されている項目のタイプを示します。アプリケーショングループとは複数のアクションを含む見出しのことです。見出しは展開して、それが含むすべてのアクションを表示させることができます。アクションが強調表示されている場合、そのタイプは次のどちらかになります。

COMMAND TT_MSG

新しいプロファイルの指定

はじめに「プロファイルマネージャを起動するには」を実行します。

新しい実行プロファイルを作成する場合、既存のプロファイルの名前を変えて内容を変更するか、またはすべてのフィールドが空である状態から始めます。「ネームサービスおよびプロファイル用のフィルタを選択するには」または「新しいプロファイルの名前と説明を入力するには」を参照してください。

必要に応じて、以下の手順に従って、新しいプロファイルのアクション、コマンド、承認を定義します。

既存のプロファイルの変更

既存のプロファイルを変更するには、まず、「プロファイルマネージャを起動するには」、次に「ネームサービスおよびプロファイル用のフィルタを選択するには」を実行します。

必要に応じて、以下の節の手順に従って、プロファイルの持つアクション、コマンド、承認を再定義します。

実行プロファイルの操作手順

プロファイルマネージャを起動するには

セキュリティ管理者役割になります。

ADMIN_LOW ラベルのワークスペースで、アプリケーションマネージャ内のプロファイルマネージャ (Profile Manager) アイコンをダブルクリックして起動します。

プロファイルマネージャの「読み込み (Load)」ウィンドウが表示され、「ドメイン名 (Domain)」フィールドには現在のドメイン名が表示されます。

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

ネームサービスおよびプロファイル用のフィルタを選択するには

プロファイルマネージャを起動します。

必要に応じて「プロファイルマネージャを起動するには」を参照してください。プロファイルマネージャの「読み込み (Load)」ダイアログボックスが表示されます。

「ネームサービス (Naming Service)」メニューから「NIS+」または「なし (None)」のどちらかを選択します。
1. 「NIS+」を選択した場合、「NIS+」メニュー項目の隣に表示されるテキスト入力フィールドに表示されるドメイン名を受け入れるか、または変更します。
2. 「なし (None)」を選択した場合、「なし (None)」メニュー項目の隣に表示されるテキスト入力フィールドに表示されるローカルホスト名を受け入れるか、または変更します。

「プロファイルの表示対象 (Filter Profiles)」メニューから「すべて (All)」、「指定したものを表示 (Specify)」、「なし (None)」のいずれかを選択します。
1. 「すべて (All)」を選択した場合、すべてのプロファイルのリストから 1 つのプロファイルを指定します。
  1. 「了解 (OK)」をクリックします。
    
    既存のすべての実行プロファイルを表示したプロファイルマネージャの「読み込み (Load)」ダイアログボックスが表示されます。
  2. リストからプロファイルを 1 つ選択します。
  3. 「読み込み (Load)」をクリックします。
    
    1 つ以上のプロファイルが読み込まれた状態でプロファイルマネージャが表示されます。
2. 「指定したものを表示 (Specify)」を選択した場合、読み込むプロファイルの名前を指定します。
  
  「指定したものを表示 (Specify)」を選択すると、同メニュー項目の隣に次の図に示すようなテキスト入力フィールドが表示されます。
  1. テキスト入力フィールドに既存の実行プロファイル名か、または正規表現を入力する。
  2. 「了解 (OK)」をクリックするか、または Return キーを押します。
  3. 読み込みたいプロファイル名を強調表示させます。
  4. 「読み込み (Load)」をクリックします。
    
    1 つ以上のプロファイルが読み込まれた状態でプロファイルマネージャが表示されます。
3. 「なし (None)」を選択した場合、「新しいプロファイルの名前と説明を入力するには」に進みます。
  
  プロファイルマネージャはプロファイルを読み込まずに、使用可能なアクションのリストを表示します。

新しいプロファイルの名前と説明を入力するには

プロファイルマネージャが実行されていない場合、「プロファイルマネージャを起動するには」および「ネームサービスおよびプロファイル用のフィルタを選択するには」に従ってプロファイルマネージャを起動します。

「プロファイル名 (Profile Name:)」フィールドにプロファイル名を入力します。

「説明 (Description:)」フィールドにそのプロファイルの説明を入力します。

「プロファイル (Profiles)」メニューから「保存 (Save)」を選択します。

実行プロファイル中内にコマンドを指定するには

プロファイルマネージャが実行されていない場合、「プロファイルマネージャを起動するには」および「ネームサービスおよびプロファイル用のフィルタを選択するには」に従ってプロファイルマネージャを起動します。

「表示 (View)」メニューから「コマンド (Commands)」を選択します。

「含む (Included)」リストにコマンドの名前を入力します。

コマンドが存在するディレクトリがデフォルトのリストにない場合、次の手順を実行します。
1. コマンドが存在するディレクトリ名を「パス名 (Pathname)」フィールドに入力し、「読み込み (Load)」ボタンをクリックし、次の手順に進みます。
2. コマンドが存在するディレクトリ名を展開し、そのコマンド名を強調表示させ、それを「含む (Included)」リストに移動します。または、そのコマンド用のアイコンをフォルダからドラッグし、「含む (Included)」にドロップします。

セキュリティ属性を指定するには、「含む (Included)」リスト内のコマンド名を強調表示させ、指定したい属性に対応するボタンをクリックします。
1. 必要ならば特権を指定します。
  1. 「特権を設定 (Set Privileges)」ボタンをクリックします。
  2. 「特権を設定 (Set Privileges)」ダイアログボックスで、指定したい特権を「含む (Included)」リストに移動します。
  3. 「了解 (OK)」をクリックします。
2. 必要ならばラベル範囲を指定します。
  1. 「最下位 SL を設定 (Set Minimum SL)」ボタンをクリックします。
  2. 「最下位 SL を設定 (Set Minimum SL)」ダイアログボックスで、最下位 SL を指定します。
  3. 「了解 (OK)」をクリックします。
  4. 「最上位 SL を設定 (Set Maximum SL)」ボタンをクリックします。
  5. 「最上位 SL を設定 (Set Maximum SL)」ダイアログボックスで、最上位 SL を指定します。
  6. 「了解 (OK)」をクリックします。
3. 必要ならば実行 UID/GID を指定します。
  1. 「UID/GID を設定 (Set UID/GID)」ボタンをクリックします。
  2. 「UID/GID を設定 (Set UID/GID)」ダイアログボックスで、設定したいユーザー名を「含む (Included)」リストに移動します。
  3. 設定したいグループ名を「含む (Included)」リストに移動します。
  4. 「了解 (OK)」をクリックします。

プロファイルマネージャで「プロファイル (Profiles)」メニューから「保存 (Save)」を選択します。

作業を終了する場合は、「プロファイル (Profiles)」メニューから「閉じる (Close)」を選択します。

作業を続ける場合は、「実行プロファイル内にアクションを指定するには」または「実行プロファイル内に承認を指定するには」へ進みます。

実行プロファイル内にアクションを指定するには

プロファイルマネージャが実行されていない場合、「プロファイルマネージャを起動するには」および「ネームサービスおよびプロファイル用のフィルタを選択するには」に従ってプロファイルマネージャを起動します。

「表示 (View)」メニューから「アクション (Actions)」を選択します。

「含む (Included)」リストにアクションの名前を入力します。

アクションが属するアプリケーショングループがデフォルトのリストにない場合、そのアクションのアイコンをフォルダからドラッグし、「含む (Included)」リストにドロップします。

「含む (Included)」リスト内にあるそのアクションの名前を強調表示させます。

必要ならば、適切な種類のアクションに対してセキュリティ属性を指定します。

アクションの種類が「TT_MSG」の場合、セキュリティ属性を指定するためのボタン群はグレー表示され、セキュリティ属性を指定できません。アクションの種類が「COMMAND」の場合、以降の手順で特権、ラベル範囲、および実効 UID/GID を指定します。

必要ならば特権を指定します。
1. 「特権を設定 (Set Privileges)」ボタンをクリックします。
2. 「特権を設定 (Set Privileges)」ダイアログボックスで、指定したい特権を「含む (Included)」リストに移動します。
3. 「了解 (OK)」をクリックします。

必要ならばラベル範囲を指定します。
1. 「最下位 SL を設定 (Set Minimum SL)」ボタンをクリックします。
2. 「最下位 SLを設定 (Set Minimum SL)」ダイアログボックスで、最下位 SL を指定します。
3. 「了解 (OK)」をクリックします。
4. 「最上位 SL を設定 (Set Maximum SL)」ボタンをクリックします。
5. 「最上位 SL を設定 (Set Maximum SL)」ダイアログボックスで、最上位 SL を指定します。
6. 「了解 (OK)」をクリックします。

必要ならば実効 UID/GID を指定します。
1. 「UID/GID を設定 (Set UID/GID)」ボタンをクリックします。
2. 「UID/GID を設定 (Set UID/GID)」ダイアログボックスで、設定したいユーザー名を「含む (Included)」リストに移動します。
3. 設定したいグループ名を「含む (Included)」リストに移動します。
4. 「了解 (OK)」をクリックします。

「プロファイル (Profiles)」メニューから「保存 (Save)」を選択します。

作業を終了する場合は、「プロファイル (Profiles)」メニューから「閉じる (Close)」を選択します。

作業を続ける場合は、「表示 (View)」メニューから「コマンド (Commands)」または「承認 (Authorizations)」を選択します。

実行プロファイル内に承認を指定するには

プロファイルマネージャが実行されていない場合、「プロファイルマネージャを起動するには」および「ネームサービスおよびプロファイル用のフィルタを選択するには」に従ってプロファイルマネージャを起動します。

「表示 (View)」メニューから「承認 (Authorizations)」を選択します。

「含む (Included)」リストに加えたい承認の名前を強調表示させ、それを「含む (Included)」リストに移動します。

「プロファイル (Profiles)」メニューから「保存 (Save)」を選択します。

作業を終了する場合は、「プロファイル (Profiles)」メニューから「閉じる (Close)」を選択します。

作業を続ける場合は、「表示 (View)」メニューから「コマンド (Commands)」または「アクション (Actions)」を選択します。

管理役割をカスタマイズするには

カスタム役割プロファイルを管理者、root、あるいはオペレータ役割用に変更するには、セキュリティ管理者役割になる必要があります。カスタムセキュリティ管理者役割プロファイルを変更するには、root 役割になる必要があります。

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

注 -
secadmin 役割に「自分を変更することを許可」承認が与えられているときのみセキュリティ管理者は、自分のカスタムプロファイルの変更を行うことができます。必要な承認を割り当てたり、セキュリティ管理者役割のその他の部分を変更することができるのは、root 役割だけです。

ADMIN_LOW ワークスペースに移動し、プロファイルマネージャを開きます。

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

プロファイルマネージャの「読み込み (Load)」ダイアログボックスで、変更対象となるネームサービスとカスタム役割プロファイルを選択します。

必要に応じて、「ネームサービスおよびプロファイル用のフィルタを選択するには」を参照してください。
1. すべての NIS+ クライアントに対する役割プロファイルに変更を加えるには、「ネームサービス (Naming Service)」メニューから「NIS+」を選択します。ローカルホスト上の役割プロファイルに変更を加えるときは、ネームサービスとして「なし (None)」を選択します。
2. 変更したいカスタム役割プロファイルの名前を指定し、「変更 (Modify)」ボタンをクリックします。

必要に応じて、1 つまたは複数のコマンドをセキュリティ属性を使用して指定します。

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

必要に応じて、1 つまたは複数のアクションをセキュリティ属性を使用して指定します。

必要に応じて、「実行プロファイル内にアクションを指定するには」を参照してください。

必要に応じて、1 つまたは複数の承認を指定します。

「実行プロファイル内に承認を指定するには」を参照してください。

「プロファイル (Profiles)」メニューから「保存 (Save)」を選択して、プロファイルを保存します。

ネームサービスに「なし (None)」を選択したときは、管理役割が「ネーム・サービス・スイッチ (Name Service Switch)」アクションを使用して files が nisplus の前に来るように tsolprof エントリに変更を加えたかどうかを必要に応じて確認してください。

「ネーム・サービス・スイッチ (Name Service Switch)」アクションの使用方法に関しては、必要に応じて、「管理アクションを起動するには」を参照してください。tsolprof エントリは、次の例のようになっています。
tsolprof: files nisplus

パート II ユーザー、役割、プロファイル、メールの管理

第 3 章 ユーザーアカウントの管理

アカウント設定のための前提条件

ユーザーアカウント設定の前に決定すべきこと

リモートログインの管理

ユーザー管理に関する責任の分割

ユーザー管理 : 2 つの管理役割間での分割

管理者役割の責任

セキュリティ管理者役割の責任

2 つの役割による分割管理を取らない場合

アカウント管理作業を行うための承認

図 3-1 ユーザーマネージャの「ナビゲータ」ダイアログボックス

Trusted Solaris システムにおけるスタートアップファイルの管理

ウィンドウシステムにどのスタートアップファイルを読み取らせるかの制御

dtprofile ファイル

図 3-2 ファイルを $HOME/.dtprofile にコピーするまでの流れ

スタートアップファイル読み取りの制御：プロファイルシェルユーザーの場合

図 3-3 デフォルトが pfsh(1M) であるユーザーの場合、$HOME/.dtprofile は読まれない

シェル起動時にどのスタートアップファイルを読み込むかの制御

dtterm による $HOME/.login または .profile の強制読み込み

その他のシェルスタートアップファイル

例 3-1 .mailrc の例

スケルトンディレクトリの管理

図 3-4 ユーザーマネージャ: ホームディレクトリを作成するダイアログボックス

例 3-2 デフォルトの /etc/skel ディレクトリ内容

/etc/skel/tsol の役割スタートアップファイル

スケルトンファイルの変更

すべてのプロダクトのマニュアルページにアクセスするには

.copy_files および .link_files の使い方

.copy_files を使った SLD 間のファイルのコピー

.link_files を使った SLD 間でのファイルのリンク

SLD 間でのファイルのコピーやリンクを行うためのワークシート

cron、at、batch を使ったジョブの自動実行の管理

バッチジョブの概念の説明

crontab ファイル

atjob ファイル

スプールディレクトリにおける異なるラベルを持つジョブのサポート

ジョブの実行にプロファイルシェルを使うには

at または cron ジョブで特権付きのコマンドを実行するには

UNIX ドメインソケットを使った通信

補助ファイル

at および cron の使用を制限するには

他のユーザーが所有するジョブの使用

at.admin および cron.admin ファイル

他のユーザーの所有するジョブを使用するための条件

at 関連のコマンドの場合の条件

crontab コマンドの場合の条件

crontab(1) に対する変更点

at コマンドに対する変更点

atq コマンドに対する変更点

atrm コマンドに対する変更点

その他の注意点

ユーザー設定のための操作手順

ログイン時に .login および .profile ファイルを自動的に読み取らせるには

dtterm により新規シェルをログインシェルとして起動させるには

各シェル用にシェル初期化ファイルを分離するには

ホームディレクトリ内の複数の SLD にスタートアップファイルを配置するには

第 4 章 役割の管理

役割アカウントとユーザーアカウントの違い

管理役割と非管理役割の違い

非管理役割

非管理役割を作成する場合

管理役割

新しい管理役割を作成する場合

トラステッドパス属性

トラステッドパスの警告

ユーザーアカウントおよび管理アカウントを管理する作業の分割

図 4-1 アカウントやプロファイル設定に関してセキュリティ管理者と管理者役割間で行われる責任の分担

アカウント管理作業を使用するための承認

図 4-2 ユーザーマネージャの「ナビゲータ」ダイアログボックス

自分自身の役割に関する情報を指定するための承認

2 つの役割による分割管理を取らない場合

管理役割によるリモートログインの許可

新しい役割の作成

必須特権

無効化特権

DAC 無効化特権

MAC 無効化特権

無効化特権を使わない方法

セキュリティポリシーの範囲内でのセキュリティ属性の使用

第 3 章ユーザーアカウントの管理

例 3-1 `.mailrc` の例

第 4 章役割の管理

第 5 章ユーザーマネージャを使ったアカウントの設定