test

Trusted Solaris 管理の手順

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

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

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

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

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

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

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

以下の事項の中には、標準の 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 の処理」および 「ユーザーの最下位ラベルよりも低いラベルのメールに関するメール配送オプションを設定するには」を参照してください。

以下の情報の収集

    作成予定のユーザーアカウントには、ネットワーク上のどことも重複しない一意のユーザー名と 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)」オプションを使う場合も、承認は必要ありません。

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

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

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

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

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

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

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

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

管理者役割の責任

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

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

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

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

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

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

注 -

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

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

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

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

Graphic

各ボタンを使用するには、それぞれ承認が必要となります。これらの承認は、デフォルトの管理者とセキュリティ管理者の間で分割して割り当てられています。ここでも、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 システムが次の特徴を持つためです。

この節では、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 にコピーされます。

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

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

Graphic

デフォルトの /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 は読まれない

Graphic

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

標準 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 ユーザーマネージャ: ホームディレクトリを作成するダイアログボックス

Graphic

上の図に示したように、デフォルトのスケルトンパスディレクトリは、/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 を指定する必要があります。

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

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

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) を実行します。

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 を使って実行されます。

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

at または 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 の場合、使用を許可または禁止するユーザー名を次のファイルに定義します。


daemon
bin
smtp
nuucp
listen
nobody
noaccess

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

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

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 を作成 (またはそれを使用) するためには、次の条件を満たすことが必要です。

  1. 指定されたユーザー名、または指定された at_job の所有者のユーザー名が、at.admin ファイルに登録されている特殊なシステムアカウント名の 1 つであること。かつ条件 3 が満たされていること。

  2. 指定された at_job の所有者のユーザー名が、役割アカウント名であること。かつ条件 3 が満たされていること。

  3. アカウントの、実行プロファイル内に「at admin を変更」承認があること。

  4. 条件 1 および 2 のどちらも満たされない場合、呼び出しを行うアカウントの実行プロファイル内に「at user を変更」承認がなければならない。

crontab コマンドの場合の条件

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

  1. 指定されたユーザー名が、cron.admin ファイルに登録されている特殊なシステムアカウント名の 1 つであること。かつ条件 3 が満たされていること。

  2. 指定されたユーザー名が、役割アカウント名であること。かつ条件 3 が満たされていること。

  3. 呼び出しを行うアカウントが「 cron admin を変更」承認を持っていること。

  4. 条件 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) のオプション
 オプション コメント
-lat_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 ファイルが添付された状態で出荷されます。

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

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

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

注 -

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

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

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

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

    相手先のディレクトリが存在しないときは、それを作成します。


    $ cp sys.dtprofile /etc/dt/configcd /usr/dt/config

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

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

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

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


    DTSOURCEPROFILE=true

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


    :wq

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

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

  1. ホームディレクトリに移動します。


    trusted% cd

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

  3. 次のように入力します。


    Dtterm*LoginShell: true

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


    :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 にファイルがある場合、ファイルを変更することができます。この手順は、複数ユーザーの設定を自動化する管理者役割向けです。

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

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

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

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


    $ cd /etc/skel/skelC

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

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


    $ ls
.cm.rc
.cshrc 
.login 
.mailrc 
.netscape

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

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

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

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

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