Trusted Solaris 管理の手順

パート I すべての作業と管理役割に共通の操作手順

このパートでは、すべての役割に共通の作業と操作手順について説明します。以下の 2 つの章があります。

第 1 章「特定の役割への移行と役割ワークスペースでの作業」では次の項目を扱います。

第 1 章特定の役割への移行と役割ワークスペースでの作業

『Trusted Solaris 管理の概要』に述べられているように、管理作業は、複数の管理役割によって行われます。この章では、特定の役割になる際の手順を説明し、管理役割ワークスペースでの作業方法を示します。この章には次の主要項目があります。

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

管理役割と非管理役割の概念

以下の節では、ログイン後に管理的な作業を行う人物の立場からログインの過程を完全に把握できるようにするために『Trusted Solaris ユーザーズガイド』に紹介してあるいくつかの概念をおさらいします。Trusted Solaris には「管理役割」と「非管理役割」という 2 種類の役割があります。

管理役割

ほとんどの管理作業は管理役割により実行されます。管理役割は多くの点に関して非管理役割と似通っていますが、以下の点だけが異なります。

管理役割は sysadmin グループ (GID は 14) に属す。これは NIS+ 関連の作業を実行するために必要となる GID である。
管理役割は特殊な「管理役割ワークスペース」で作業を行う。管理役割ワークスペース内のプロセスは、多くの管理プログラムに使われる必須のトラステッドパス属性を持つ。

詳細については、「管理役割ワークスペースでの作業」を参照してください。

デフォルトでは多くの管理作業はセキュリティ管理者 (secadmin) と管理者 (admin) 役割のどちらかに分類されます。第 3 の管理役割としてスーパーユーザー役割があります。スーパーユーザー役割はソフトウェアのインストールのように、その遂行に実際のスーパーユーザーの UID が必要となる作業を行う場合に使用されます。

非管理役割

デフォルトでは、非管理役割のうち唯一オペレータ (oper) 役割だけになります。この役割はファイルシステムのバックアップを行う場合に割り当てられます。

ログインと役割への移行

Trusted Solaris 環境では、管理役割を担うユーザーであっても最初から直接ログインしてはいけません。管理役割であれ非管理役割であれ、特定の役割を担うユーザーは次の手順で、ウィンドウシステム内で作業を開始しなければなりません (管理役割と非管理役割の違いは、下記の手順において最後の 2 項目だけです)。

セキュリティ管理者の役割は User Manager Roles ダイアログを使って特定のユーザーアカウントに管理役割または非管理役割を割り当てます。
セキュリティ管理者の役割はユーザーに対して、そのユーザーアカウント用のパスワードとそのユーザーアカウントが果たす特定の役割用のパスワードを付与します。
特定の役割になれるよう設定されたユーザーは、自分自身のユーザー名とパスワードを使ってログインします。

通常のユーザーワークスペースが生成されます。ユーザーワークスペースは、多くのプログラムによって検査されるトラステッドパス属性を持ちません。
ユーザーはトラステッドパスメニューから「役割になる (assume role)」オプションを選択し、役割用パスワードのダイアログボックスにパスワードを入力します。
管理役割ワークスペースがトラステッドパス属性でアクティブになり、そのユーザーは管理役割に割り当てられた管理作業を実行できるようになります。

管理的アクションの監査

ログイン時点で、ログインしたユーザーの生成するすべてのプロセスには特定の UID (これは監査 ID としても使われます) が関連付けられるようになります。ユーザーが特定の役割へ移行した場合、そのユーザーの実効 ID は変化しますが監査 ID は変化しません。同様のことは、実効 UID によって動作するプログラムに対してもいえます。このプログラムを実行するプロセスの監査 ID は、実際のユーザーを識別し続けることができます。監査 ID により、ユーザーが役割になっているときに実行した処理から、そのユーザーがログイン時に認証されたユーザーアカウントを導きだすことができます。

このように、まずユーザーとしてログインし認証を経た後でなければ特定の役割に移行できないようにすることには、通常の UNIX システムで発生しがちなセキュリティホールを塞ぐ意味があります。通常の UNIX システムではスーパーユーザーのパスワードを知っている者なら誰でも直接ログインしてシステム上のすべての情報に制限なしに匿名でアクセスすることが可能となります。

ログインを有効にするには

デフォルトでは、システムをリブートするたびにログインは無効となります。ログインが無効のとき、「ログインを有効化」承認を持つユーザーアカウントだけがログインしたり、ログインを有効にすることができます。このようなログイン無効化の目的は、システム管理者や信頼できる他の社員がシステムセキュリティを検証した後でなければその他のユーザーの再ログインを許さないようにすることにあります。

システムがリブートされてまだログインが有効になっていない場合、ユーザーが自分のパスワードを入力すると次の 2 つのダイアログボックスのうちのどちらかが表示されます。

現在のユーザーアカウントが「ログインを有効化」承認を持たない場合、次のようなダイアログボックスが表示されます。

図 1-1 承認を持たないユーザーに表示される無効なログインを通知するダイアログボックス

現在のユーザーアカウントが「ログインを有効化」承認を持つ場合、次のようなダイアログボックスが表示されます。

図 1-2 「ログインを有効化」承認を持つユーザーに表示される無効なログインを通知するダイアログボックス

リブート後のログイン無効化を防ぐには

Trusted Solaris と Solaris の両方のオペレーティング環境において、システムのシャットダウン中には、ログインを防ぐために /etc/nologin ファイルが作成されます。このファイルはブートが完了すると削除されます。Trusted Solaris システムでは、このファイルの使い方が拡張されています。デフォルトでは、/etc/nologin ファイルは作成し直され、認証されたユーザーがログインを有効にするまで削除されません (「管理的アクションの監査」を参照)。

この機能を削除してもサイトのセキュリティポリシーに矛盾しない場合、セキュリティ管理者役割は、/etc/init.d 中の RMTMPFILES スクリプトを編集し、/etc/nologin ファイルを作成し直す行をコメントアウトできます。これを行うには、このような変更がご自分のサイトのセキュリティポリシーに合致しているかどうか確認した上で「リブート後のログイン無効化を防ぐには」に示してある手順を実行してください。

リモート管理オプション

管理者がリモートホスト上で管理するには、いくつかの方法があります。

管理者は管理役割になり、rlogin(1) または telnet(1) を使ってリモートホストにログインし、管理役割の実行プロファイルに割り当てられている任意のコマンドを使って、コマンド行から変更を行います。
ローカルホスト上で Solstice ツールを使うとき、管理者は NIS+ マスター上の NIS+ テーブルか、リモートホスト上にある構成ファイルのどちらかを変更できます。

「「Solstice アプリケーション (Solstice_Apps)」アプリケーションフォルダ内の管理ツールの使用」を参照してください。
任意のユーザーは、ローカルホストの CDE ログイン画面からリモートホスト上の CDE ウィンドウシステムに直接ログインできます。

リモートホストにログインした後、管理者は管理役割になり、ローカルホスト上で実行できるのと同じ作業を行うことができます。「リモートホスト上での CDE ログインセッションの起動」を参照してください。
管理者は、ローカルホスト上のワークスペースからリモートホストにログインできます。そして、アプリケーションマネージャを起動して、ローカルホストで表示しながら、リモートホストを管理できます。

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

リモートホスト上での CDE ログインセッションの起動

リモートホスト上でログインセッションを起動するには、管理者はローカルホストの CDE ログイン画面から「リモートログイン (Remote Login)」オプションを使い、リモートホストにログインした後で管理役割になります。次の図に、「オプション (Options)」ボタンのプルダウンメニューを引き出したときのログイン画面を示します。

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

管理役割の実行

ログインしたユーザーは、次のことを行うことによって管理役割を実行します。

右 (メニュー) マウスボタンをワークスペースのスイッチ領域上でクリックしたままトラステッドパスメニューまでドラッグする。
または、ワークスペースボタン上でメニューボタンをクリックしたままワークスペースボタン名のメニューまでドラッグする。
「役割になる: [役割名] 役割 (Assume role_name Role)」を選択する。

Workspace One のメニューと Assume admin Role オプションが含まれる TP Menu を次の図に示します。

図 1-3 ワークスペースのメニューまたは `TP Menu` からの役割になるためのオプションの選択

注 -

ユーザーにシャットダウン権限があるときのみ「シャットダウン (Shut Down)」オプションが表示されます。デフォルトでは、すべての管理役割がシャットダウン権限を持ちます。

管理役割ワークスペースでの作業

ユーザーが特定の役割になると直ちに管理役割ワークスペースがアクティブになります。管理役割ワークスペースのデフォルトのラベルは、その役割の最下位ラベル (通常は、ADMIN_LOW) です。ワークスペースのスイッチ領域には、その役割の新しいワークスペースボタンが (上端と左端が強調表示されて) 表示されます。このボタンには、管理役割アカウントの名前が表示されます (図 1-4 を参照)。

図 1-4 管理役割 admin 用のボタンがあるワークスペースのスイッチ領域

管理役割は、任意のユーザーが他のワークスペースの名前を変更できるように、そのワークスペースの名前を変更できます。

管理役割は、管理役割になったときに管理ワークスペースに希望のラベルが表示されるようにデフォルトを変更できます。フロントパネルの「トラステッドデスクトップ (Trusted Desktop)」サブパネルから「デスクトップスタイル (Desktop Style)」を選択し、スタイルマネージャが表示されたら、「スタートアップ (Startup)」オプションを選択します。現在のラベルで現在のワークスペースに戻るには、「ホームセッションを設定 (Set Home Session)」ボタンをクリックし、プロンプトに応答します。

「ワークスペースを追加 (Add Workspace)」オプションを選択したとき、カーソルが通常のワークスペースボタン上にあった場合、通常のワークスペースが作成されます。「ワークスペースを追加 (Add Workspace)」オプションを選択したとき、カーソルが管理的なワークスペースボタン上にあった場合、新しい管理役割ワークスペースが作成されます。「管理役割になっている間に、複数ラベルで作業するには」と次の図を参照してください。

図 1-5 管理用のワークスペースのメニューからの役割ワークスペースの新規作成

ユーザーはワークスペースのボタンをクリックすると非管理役割ワークスペースにいつでも戻ることができます。必要に応じて、「管理役割ワークスペースと通常のユーザーワークスペース間の切り替えを行うには」を参照してください。

管理役割は、多くの場合、ADMIN_LOW および ADMIN_HIGH 管理ラベルで作業します。最初のワークスペースが役割の最下位のラベルで表示された後、管理者は最初のワークスペースのラベルを変更することも、新しい管理役割ワークスペースを作成し、そのワークスペースのラベルを変更することもできます。詳細については、「管理役割になっている間に、複数ラベルで作業するには」を参照してください。

注 -

管理役割ワークスペースを削除するには、そのワークスペースが空である必要があります。

新規ワークスペースのボタンは、管理者がログアウトするときに名前を付けて保存されます。管理者が一般ユーザーとして再度ログインし、管理ワークスペースのボタンをクリックして役割パスワードを入力すれば、その管理ワークスペースを使用することができます。

アプリケーションマネージャ内のフォルダとアクションのアイコン

管理役割によって実行される管理作業の多くは、アプリケーションマネージャ内のフォルダに収められている管理プログラムを起動することにより遂行されます。最少特権の原則を維持するために一連の管理プログラムは 2 つの主要な管理役割に分割されます。役割にアプリケーションの使用が許されていない場合はそのアプリケーションのアイコンは表示されません。

「Solstice アプリケーション (Solstice_Apps)」アプリケーションフォルダ内の管理ツールの使用

管理役割ではアプリケーションマネージャ内の「Solstice アプリケーション (Solstice_Apps)」フォルダに収められている管理アプリケーションを起動することでユーザー、役割、プロファイル、ホスト、およびネットワークの構成を遂行できます。詳細は、「管理アプリケーションを起動するには」を参照してください。NIS+ マップとして管理されるすべての設定ファイルは「Solstice アプリケーション (Solstice_Apps)」フォルダ内のアプリケーションを通じて編集されます。

次の図は「Solstice アプリケーション (Solstics_Apps)」アイコンを示します。

次の図に、「Solstice アプリケーション (Solstice_Apps)」アイコンをダブルクリックしたときに表示される「Solstice アプリケーション (Solstice_Apps)」フォルダを示します。

「Solstice アプリケーション (Solstice_Apps)」フォルダに表示されるアイコンは役割ごとに異なります。表示されるアイコンは、現在の役割に割り当てられたプロファイルに指定されているアクションによって制御されます。

「読み込み (Load)」ダイアログの使用

任意のアイコンを起動すると、次のような「読み込み (Load)」ダイアログボックスが表示されます。

役割は、「読み込み (Load)」メニューから次の 1 つを選択します。

NIS+

デフォルトでは、NIS+ ネーミングサービスが選択され、NIS+ ドメイン名が「ドメイン名 (Domain)」テキスト入力フィールドに表示されます。
なし

管理者が「なし (None)」を選択した場合、現在のホスト名が「ホスト名」テキスト入力フィールドに表示されます。別のホストのローカルファイルを管理するには、管理者は別のホスト名を入力します。このツールの任意のダイアログボックスで行った変更は、指定したホストの構成ファイルに保存されます。「なし (None)」を選択するのは、ワークステーションが NIS+ ネーミングサービスを使っていない場合、あるいは、構成情報をローカルファイルに保存しなければならない特別な理由がある場合だけです。

「システム管理 (System_Admin)」アプリケーションフォルダ内の管理アクションの使用

NIS+ マップとして管理されない設定ファイルの編集のように、管理役割により実行されるその他の作業は、アプリケーションマネージャ内の「システム管理 (System_Admin)」フォルダに収められている管理アクションを使って行われます。

アプリケーションマネージャの呼び出し

アプリケーションマネージャアイコンは、フロントパネルのアプリケーションメニューにあります。アプリケーションメニューでアプリケーションマネージャアイコンを選択した時の様子とフロントパネルの上に表示されるアプリケーションマネージャフォルダを図 1-6 に示します。

図 1-6 「アプリケーションマネージャ (Application Manager)」アイコンと「アプリケーションマネージャ (Application Manager)」フォルダ

アプリケーションメニューのフロントパネルにあるデフォルトのアイコンは「テキストノート (Text Note)」アプリケーションです。管理者は、アプリケーションメニューにある「フロントパネルに昇格 (Promote to Front Panel)」オプションを使って、「テキストノート (Text Note)」アイコンを「アプリケーションマネージャ (Application Manager)」アイコンで置き換えることができます。必要であれば、『Solaris 共通デスクトップ環境ユーザーズ・ガイド』の「フロントパネルの使い方」を参照してください。

リモートホストからのアプリケーションマネージャの起動

dtappsession(1) スクリプトは、リモートホストで動作しながらローカルホストに表示される CDE アプリケーションマネージャの独立したインスタンスを起動します。「リモートホスト上での CDE ログインセッションの起動」で説明した CDE リモートログインとは異なり、dtappsession を使う場合、管理者はローカルログインセッション内にいながらリモートで作業できます。対照的に、CDE リモートログインを使う場合、管理者はリモートセッションを開始する前に完全にログアウトする必要があります。

リモートホスト上で dtappsession を呼び出すと、「リモート管理 (Remote Administration)」ダイアログボックスが表示されます。このダイアログボックスには、リモートホスト名と (その後に続いて)「Remote Administration」という言葉、さらに「終了 (Exit)」ボタンが表示されます。次の例では、リモートホスト名は「bunster」です。

bunster: Remote Administration Press Exit to logout of bunster

Exit

「リモート管理 (Remote Administration)」ダイアログが表示された後、アプリケーションマネージャがリモートで実行され、ローカルホストに表示されます。

注 -

ローカルホスト名は、dtappsession コマンド行に指定するか、リモートホスト上の DISPLAY 環境変数に設定する必要があります。

アプリケーションマネージャを閉じるだけでは、リモートホストからログアウトしません。アプリケーションマネージャを閉じて、リモートセッションからログアウトするには、「終了 (Exit)」ボタンをクリックしてください。

dtappsession は、リモートホストにモニターがないときに便利です。たとえば、巨大なサーバー (E10000 など) 上にあるドメインを管理するために Solstice アプリケーションなどのウィンドウツールが必要なときは、CDE リモートログインよりも dtappsession の方が便利です。

リモートのアプリケーションマネージャによって管理されるリモートホストは、CDE が動作している Trusted Solaris ホストまたは通常の Solaris ホストのどちらでもかまいません。Trusted Solaris のアプリケーションマネージャにはすべての Solstice ツールと CDE アクション (この章で説明) が含まれていますが、Solaris 環境のアプリケーションマネージャの内容は異なることがあります。たとえば、Solaris AdminSuite 製品は Solaris 環境には同梱されていません。Solstice AdminSuite がインストールされていない場合、リモートホストのアプリケーションマネージャには「Solstice アプリケーション (Solstice_Apps)」フォルダはありません。

dtappsession を使うための前提条件

管理者はホストにリモートログインできる必要があります。「管理役割によるリモートログインの許可」を参照してください。
任意の NIS+ クライアントから Solstice ツールを使って NIS+ を管理するには、すべての NIS+ クライアント名を、Solstice ドメインの NIS+ マスター上にある NIS+ admin グループに入力する必要があります。「スーパーユーザーまたは新しい役割が NIS+ を管理できるように設定するには」を参照してください。
リモートホストにおいて、/etc/default/login ファイル内の CONSOLE=/dev/console 行をコメントアウトする必要があります。「任意の役割がリモートログインできるように設定するには」を参照してください。

注意 -
リモートとローカルの CDE アプリケーションを混同しないようにするために、dtappsession が動作するための専用のワークスペースを別に作成することを強くお勧めします。

dtappsession によるリモートの Trusted Solaris ホストの管理

管理者は管理役割になり、次の作業を行います。

新しい専用の管理役割ワークスペースを起動します。
rlogin(1) でリモートホストにログインします。
コマンド行に dtappsession(1) と (その後に続いて) ローカルホスト名を入力します。

「リモート管理 (Remote Administration)」ダイアログボックスが表示され、次にアプリケーションマネージャが表示されます。
セッションを終了するには、「リモート管理 (Remote Administration)」ダイアログ上の「終了 (Exit)」ボタンをクリックします。

必要であれば、「dtappsession で Trusted Solaris ホストをリモート管理するには」を参照してください。

「システム管理 (System_Admin)」フォルダ内の管理アクション

次の表に、「システム管理 (System_Admin)」フォルダの中で、Trusted Solaris 環境だけにあるアクションの目的を示します。また、各アクションが割り当てられているデフォルトの役割も示します。

表 1-1 管理アクションとその目的、デフォルトの役割


アクション名	アクションの目的	デフォルトの役割
`割り当て可能なデバイスの追加`	`device_allocate(4)` と `device_maps(4)` にエントリを作成し、新規の割り当て可能または割り当て可能ではないデバイス用に補助ファイルを作成する。ユーザーは、デバイス名と種類を指定し、デバイスに関連するデバイス特殊ファイルを一覧にする。`add_allocatable(1M)` を参照	`secadmin`
`管理用エディタ`	指定のファイルの編集	`secadmin`
`監査クラス`	`audit_class(4)` の編集	`secadmin`
`監査制御`	`audit_control(4)` の編集	`secadmin`
`監査イベント`	`audit_event(4)` の編集	`secadmin`
`監査の開始`	`audit_startup.sh` スクリプトの編集 [`audit_startup(1M)` を参照]	`secadmin`
`ユーザー監査`	`audit_user(4)` の編集	`secadmin`
`エンコーディングの検査`	指定のエンコーディングファイルに対して `chk_encodings(1M)` を実行	`secadmin`
`TN ファイルの検査`	ローカルな `tnidb (4)`、`tnrhdb (4)`、`tnrhtp (4)` ファイルに対して、`tnchkdb (1M)` を実行	`secadmin` および `admin`
`TN NIS+ テーブルの検査`	`tnrhdb (4)`、`tnrhtp (4)`、および NIS+ トラステッドネットワークマップに対して、`tnchkdb (1M)` を実行	`secadmin` および `admin`
`選択構成の確認`	`/usr/dt/config/sel_config` の編集 [`sel_config(4)` を参照]	`secadmin`
`NIS+ クライアントの作成`	NIS+ マスターの指定ホスト名と、指定ドメイン名両方を使用して、`nisclient (1M)` を実行	`secadmin`
`NIS+ サーバーの作成`	指定ドメイン名を使用して、`nisserver (1M)` を実行	`secadmin`
`エンコーディングの編集`	指定の `label_encodings(4)` ファイルの編集と `chk_encodings(1M)` の実行	`secadmin`
`ネーム・サービス・スイッチ`	`nsswitch.conf(4)` の編集	`admin`
`NIS テーブルの生成`	指定ディレクトリから `nispopulate (1M)` を実行	`secadmin`
本日のメッセージの設定	`/etc/motd` の編集	`admin`
`デフォルトの経路の設定`	`/etc/defaultrouter` の編集 [マニュアルページの `route(1M)` を参照]	`admin`
`DNS サーバーの設定`	`resolv.conf(4)` の編集	`admin`
`メール・オプションの設定`	`/etc/mail/sendmail.cf` の編集 [`sendmail(1M)` を参照]	`admin`
`マウント属性の設定`	`vfstab_adjunct(4)` の編集	`secadmin`
`マウントポイントの設定`	`vfstab(4)` の編集	`admin`
`Tsol ゲートウェイの設定`	`tsolgateways(4)` の編集	`admin`
`ファイルシステムの共有`	`dfstab(4)` の編集、`share(1M)` は実行しない	`admin`
`テーブル属性の表示`	指定した NIS+ トラステッドネットワークデータベースに対して、`-o` オプションを付けて `niscat(1)` を実行 (テーブルの属性が表示される)	`admin`
`テーブル内容の表示`	指定した NIS+ トラステッドネットワークデータベースに対して、 `niscat (1)` を実行 (テーブルの属性が表示される)	`secadmin` および `admin`

詳細は、「管理アクションを起動するには」を参照してください。

ファイルを編集する Trusted Solaris 管理アクションは、いずれも /usr/dt/bin/trusted_edit シェルスクリプトを使用し、制限付きのエディタを起動し、ファイルが保存されたときの変更箇所を監査します。

実際に使用されるのは、役割の EDITOR 環境変数で指定したエディタです。この変数はデフォルトで adminvi(1M) に設定されます。セキュリティ管理者の役割は、EDITOR 変数を再定義して、/usr/dt/bin/dtpad にすることができます。adminvi が指定されると、/bin/adminvi がスーパーユーザーとして起動し、ファイルの編集を行います。adminvi コマンドは、他のファイル名ではファイルの保存ができません (adminvi の特徴については、「管理用 vi」および adminvi(1M) のマニュアルページを参照してください) 。dtpad(1) を指定すると、「ファイル (File)」メニューの New、Save、Open オプションは、アクション実行時に無効となり、ファイルのリネームはできなくなります。

必要に応じて、「役割のデフォルトエディタとしての trusted_edit の割り当て」および「trusted_edit エディタを役割に割り当てるには」を参照してください。

コマンドとアクションへのアクセス

管理役割ワークスペースに入っている間、特定の役割になったユーザーは、その役割の実行プロファイルまたは他のプロファイルに指定された属性を持つコマンドやアクションにしかアクセスできません。この場合、アプリケーションやアクションは、現在有効である役割ワークスペースの機密ラベルで起動されます。

プロファイルシェルを使ったその他の作業の実行

プロファイルシェル pfsh(1M) は管理役割で使用するデフォルトのシェルです。pfsh シェルは Trusted Solaris の管理で使用され、役割で使用できるコマンドを管理作業を実行するために必要な最小セットに制限し、実行時にこれらのコマンドが必要な特権を継承できるようにします。プロファイルシェルは任意の機密ラベルで実行できます。管理者は dtterm(1) やその他の端末エミュレータをフロントパネルから起動することによりプロファイルシェルを呼び出すことができます。このような端末上のプロファイルシェルは現在の役割ワークスペースの機密ラベルで起動されます。

管理用 `vi`

adminvi(1M) コマンドは vi コマンドの修正バージョンです。adminvi(1) では、シェルコマンドの実行や編集中のオリジナルのファイル以外への書き込み (または保存) が行えないようになっています。管理ファイルの編集や作成にはコマンドラインから adminvi を実行するのではなく、セキュリティ管理役割にデフォルトで割り当てられている「管理用エディタ (Admin Editor)」アクションを使うようにしてください。adminvi コマンドはデフォルトのシェルがプロファイルシェルであるユーザーにならば誰にでも割り当てることができます。セキュリティ管理者の役割が特定のユーザーにテキストエディタの使用を制限付きで許可したいと判断した場合にのみ、それらのユーザーに adminvi コマンドを割り当てるようにします。

管理役割に特有の操作手順

ログイン後、特定の管理役割になるには

リモートホスト上でログインセッションを開始するには、自分のローカルホストのログイン画面のリモートログインオプションを使用します。

次の図に、「オプション (Options)」ボタンのプルダウンメニューを引き出したときのログイン画面を示します。
1. 「オプション (Options)」ボタンプルダウンメニューから「リモートログイン (Remote Login)」を選択します。
2. 「ホスト名を入力 (Enter Host Name)」または「リストからホストを選択 (Choose Host From List)」を選択します。

CDE リモートログインオプションを使う場合も、ローカルホストに直接ログインする場合も、自分のユーザー名を入力し、(プロンプトが出たら) パスワードを入力します。

次のようなワークステーション情報ダイアログボックスが表示された場合、手順 5 に進みます。

必要に応じて「ログインを有効」にします。
1. 次のようなダイアログボックスが表示された場合、そのアカウントはログインを有効にすることが承認されていません。セキュリティ管理者に頼んで必要な承認をもらうか、承認されているユーザーに頼んでログインを有効にしてもらいます。
2. アカウントがログインを有効にすることが承認されている場合、次のダイアログでオプションの 1 つを選択します。あるいは、「了解 (OK)」をクリックして、ログインを有効にします。
ワークステーション情報ダイアログボックスが表示されたら、次の手順に進みます。

ワークステーション情報ダイアログボックスに表示されている情報を確認し、許可されているならばラベルを単一にするか複数にするかを選択します。　

注 -
アカウントが複数のラベルで作業できるように構成されている場合、ワークステーション情報ダイアログボックスの一番下には、「シングルラベルにセッションを制限 (Restrict Session to a Single Label」トグルボックスが表示されます。アカウントがシングルラベルだけで作業できるように構成されている場合、ワークステーション情報ダイアログボックスの一番下には、「シングルレベルセッション SL: (Single Level Session SL:)」と (その後に続いて) 作業できるように構成されているラベルが表示されます。
1. 最後にログインした日付と時間をチェックし、それらが妥当な値であり、何も疑わしいことがないことを確認します。
2. 「本日のメッセージ (Message Of The Day)」の内容を読みます。
3. 「最後のログアウトからのコンソールダイアログボックス・メッセージ (Console Messages Since Last Logout)」の内容を確認します。
4. 疑わしいログインや疑わしい活動を示すようなメッセージ、その他の問題を調べます。
5. ユーザーアカウントが複数ラベルで作業できるよう設定されている場合、「シングルラベルにセッションを制限 (Restrict Session to a Single Label)」トグルボックスをオンにします。

Return キーを押すか、または「了解 (OK)」をクリックしてワークステーション情報ダイアログボックスを閉じます。

「シングルラベルにセッションを制限 (Restrict Session to a Single Label)」トグルをオンにしていた場合、ユーザーの機密ラベル (SL) を設定するためのダイアログボックスが表示されます。この場合、手順 7 に進んでください。

複数のラベルでの作業が許されていて、「シングルラベルにセッションを制限 (Restrict Session to a Single Label)」トグルをオンにしなかった場合はユーザーのセッション認可上限を設定するためのダイアログボックスが表示されます。この場合、手順 8 に進んでください。

シングルラベルセッション用のラベルを指定します。このためにはデフォルトのラベルを受け入れるか、またはシングルラベルのユーザーセッション用 SL ラベルビルダーのダイアログボックスを使って任意のラベルを入力します。
1. ラベルを入力するには「更新後のラベル (Update With)」の下にあるテキスト入力フィールドを使います。入力が終わったら「更新 (Update)」をクリックします。
2. マウスを使ってラベルを作成するにはメニューから分類を選択し、表示されるチェックボックスの中から希望のものにチェックマークを付けます。
3. 「了解 (OK)」をクリックします。
4. 手順 9 に進みます。

複数ラベルセッション用の認可上限を指定します。これを行うにはマルチレベル用にユーザーセッションの認可上限を設定するラベルビルダーのダイアログボックス上のデフォルトの認可上限を受け入れるか、または任意の認可上限を入力します。
1. 認可上限を入力するには「更新後のラベル (Update With)」の下にあるテキスト入力フィールドを使います。入力が終わったら「更新 (Update)」をクリックします。
2. マウスを使って認可上限を作成するには格付けのメニューから分類を選択し、COMPS の下に表示されるコンパートメントを選択するチェックボックスの中から希望のものをチェックします。
  
  注 -
  「Class」や「Comps」以外の単語が表示されるように構成されている場合もあります。必要であれば、『Trusted Solaris のラベル管理』の「ラベルビルダーのラベルコンポーネントの名前の変更」を参照してください。
3. 「了解 (OK)」をクリックします。
4. 手順 9 に進みます。

トラステッドパスメニューから役割になるためのオプションを選択します。

下の図に管理者役割になれるユーザーのためのトラステッドパス (TP) メニューを示します。

注 -
役割になるためのオプションは特定の役割になれるように設定されているユーザーのトラステッドパスメニューにしか表示されません。

上記の操作を行うと役割用パスワードのダイアログボックスが表示されます。

役割用パスワードのダイアログボックスに役割のパスワードを入力し、「了解 (OK)」をクリックします。

管理役割ワークスペースが有効になり、新しい管理役割ワークスペースボタンがワークスペース切り替え領域に追加されます。

ログアウトの準備ができたら、フロントパネルの「終了 (EXIT)」ボタンをクリックします。

管理役割ワークスペースと通常のユーザーワークスペース間の切り替えを行うには

切り替え先のワークスペースのボタンをクリックします

セキュリティ属性を持つプロファイルとコマンドの一覧を表示するには

プロファイルシェルにおいて、clist コマンドを入力します。

clist のオプションについては、pfsh(1M) のマニュアルページを参照してください。

-p オプションを付けて clist を実行すると、現在のアカウントに指定されている順番で、実行プロファイル名、コマンドのパス名、およびコマンドがプロファイルシェル内で継承できる特権が表示されます。次に、典型的な出力の例を示します。

$ clist -p | more 
Custom Root Role:
    /opt/SUNWadm/bin/serialmgr: none
    /usr/dt/bin/trusted_edit: file_dac_read,file_dac_search,file_dac_write,proc_
Remote Administration:
    /usr/dt/bin/dtappsession: none
. . .

dtappsession で Trusted Solaris ホストをリモート管理するには

この節を読む前に、「dtappsession を使うための前提条件」と「dtappsession によるリモートの Trusted Solaris ホストの管理」を参照してください。

ログインして、実行プロファイルの 1 つに dtappsession(1) を持つ管理役割になります。

必要であれば、ログインする方法については、「管理役割」を参照してください。必要であれば、現在のアカウントのプロファイル内にあるコマンドを知る方法については、「セキュリティ属性を持つプロファイルとコマンドの一覧を表示するには」を参照してください。

注 -
デフォルトでは、dtappsession コマンドは secadmin、admin、および root 役割に割り当てられている Remote Administration プロファイル内にあります。

リモートとローカルの CDE アプリケーションを混同しないようにするために、この手順専用の管理役割ワークスペースを追加します。

必要であれば、管理役割ワークスペースを追加する方法については、「管理役割になっている間に、複数ラベルで作業するには」を参照してください。

新しい専用のワークスペースにおいて、rlogin(1) コマンドと (その後に続いて) リモート管理したいリモートホスト名を入力します。

dtappsession と (その後に続いて) ローカルホスト名を入力します。

次の図のように、「リモート管理 (Remote Administration)」ダイアログボックスが表示されます。この例では、リモートホスト名は「bunster」です。

bunster: Remote Administration Press Exit to logout of bunster

Exit

アプリケーションマネージャは、リモートホストで動作しながら、ローカルホストに表示されます。

終了したら、「終了 (Exit)」ボタンをクリックします。

注意 -
アプリケーションマネージャを閉じるだけでは、セッションは終了しません。

リモートログインセッションを終了します。
# exit # hostname trusted

管理役割になっている間に、複数ラベルで作業するには

注 -

複数のラベルで作業を行うには、新たに管理役割ワークスペースを作成し、それらに新しいラベル名を付ける必要があります。

新しい管理役割ワークスペースを追加します。
1. カーソルを管理役割ワークスペースボタンに置いた状態で、メニュー (右) マウスボタンをクリックしたままワークスペース役割名のメニューを起動します。
2. ワークスペース役割名のメニューから「ワークスペースの追加 (Add Workspace)」を選択します。
  
  新しい管理役割ワークスペースが有効になり、フロントパネルのワークスペースのスイッチ領域に新しい管理役割ワークスペース用のボタンが表示されます。
  
  デフォルトでは、新しいワークスペースの名前は役割のアカウント名の後にアンダーラインと番号が付けられたものとなります。たとえば、役割 admin で作成した第 2 番目の管理役割ワークスペースの名前は admin_1 になります。

ワークスペースのラベルを変更します。
1. カーソルを新しい役割ワークスペースボタンの上に移動します。
2. 新しい役割ワークスペースボタンの上にカーソルを置いた状態で、マウスの右ボタンをクリックします。画面にはワークスペース役割名のメニューが表示されます。
3. メニューから「ワークスペース SL を変更 (Change Workspace SL)」を選択します。
  
  ラベルビルダーが表示されます。
4. ラベルビルダーのダイアログボックスの「更新後のラベル (Update With)」の下にあるテキスト入力フィールドに、任意のラベルを入力します。入力が終わったら「更新 (Update)」をクリックし、続いて「了解 (OK)」をクリックします。
  
  これで、ワークスペースのラベルが、ラベルビルダーのダイアログボックスで指定したラベルへと変更されます。

管理アプリケーションを起動するには

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

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

アプリケーションサブパネルのアプリケーションマネージャのアイコンをクリックします。

アプリケーションマネージャフォルダが表示されます。

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

「Solstice アプリケーション (Solstice_Apps)」フォルダが表示されます。

希望するアイコンをダブルクリックし、「読み込み (Load)」の一覧を起動します。

「読み込み (Load)」一覧の「ネームサービス (Naming Service)」メニューからネームサービスを選択します。

注 -
デフォルトでは、NIS+ ネームサービスが選択されており、ドメインテキスト入力フィールドに NIS+ ドメイン名が表示されています。

None を選択するのは、ホストが NIS+ ネーミングサービスを使っていない場合、あるいは、ローカルファイルを変更しなければならない特別な理由がある場合だけです。デフォルトでは、「ホスト (Host)」フィールドにはローカルホスト名が表示されます。リモートホスト上のファイルを変更したい場合は、「ホスト (Host)」フィールドにリモートホスト名を指定します。NIS+ テーブルを変更したい場合は、NIS+ を選択します。

管理アクションを起動するには

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

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

アプリケーションのサブパネルのアプリケーションマネージャのアイコンをクリックします。

アプリケーションマネージャのフォルダが表示されます。

アプリケーションマネージャフォルダの「システム管理 (System_Admin)」アイコンをダブルクリックします。

起動したいアクションのアイコンをダブルクリックします。

管理用エディタアクションを使用してファイルを編集するには

「管理用エディタ」アクションを起動して、編集用のファイルを開きます。

必要に応じて、「管理アクションを起動するには」を参照してください。
1. 「管理用エディタ」アイコンをダブルクリックします。
  
  アクションとして、管理用エディタのプロンプトが表示されます。
2. 「編集するファイル」フィールドに該当ファイルのパス名を入力します。
3. 「了解」ボタンをクリックします。

変更内容を保存し、そのファイルを終了させます。
:wq
ファイルへの書き込みをしようとすると、:wq でエラーとなる場合は、:wq! を使用してください。

管理ファイルを編集する新しい管理アクションを作成するには

管理エディタアクションを起動して /usr/dt/appconfig/types/localename/TSOLadmin.dt ファイルを開いて、編集を行います (localename は、ロケール名を示しています)。

必要に応じて、16 ページの「ログイン後、特定の管理役割になるには」と 30 ページの「管理用エディタアクションを使用してファイルを編集するには」を参照してください。

TSOLadmin.dt ファイル内の既存のアクションの定義をどれか 1 つコピーしペーストします。

次の例では、「Vfstab」アクションの定義をコピーし、これを変更することにします。

ACTION Vfstab
{
        LABEL        Set Mount Points
        ICON         Dtpenpd
        TYPE         COMMAND
        WINDOW_TYPE  NO_STDIO
        EXEC_STRING  /usr/dt/bin/trusted_edit /etc/vfstab
        DESCRIPTION  Specify the file system mount points
}

コピーしたアクションの定義を変更します。
1. ACTION の名前を変更します。
  
  この例では、Trusted Solaris のカーネルスイッチ設定を変更するために system(4) ファイルを編集するような新しいアクションを定義することにします。
  ACTION EditSwitches {
2. LABEL を変更します。
  LABEL Set TSOL Switches
3. 新しいアイコンを作成した場合や、 /usr/dt/appconfig/icons/localename にある既存のアイコンを使用する場合には、ICON を変更します (localename は、ロケール名を示しています)。
  ICON Dtpenpd
4. EXEC_STRING のファイル名を変更します。
  EXEC_STRING /usr/dt/bin/trusted_edit /etc/system
5. DESCRIPTION のテキストを変更します。
  DESCRIPTION Modify TSOL-related kernel switches }

TSOLadmin.dt ファイルを保存し、このファイルを閉じます。
:wq

Vfstab アクションファイルをコピーし、リネームします。
1. /usr/dt/appconfig/appmanager/localename/System_Admin ディレクトリに移動します (localename は、ロケール名を示しています)。
2. Vfstab ファイルを別なファイルにコピーし、このファイルの名前を新しいアクションの名前にリネームします。
  
  たとえば、Vfstab から EditSwitches にリネームします。
3. このアクションファイルを実行可能にします。
  
  ファイルマネージャの「ファイル (File)」メニューから「アクセス権 (Permissions)」オプションを選択し、所有者、グループ、その他のユーザー用のアクセス権をすべて実行可能に設定します。または、コマンド行から次のコマンドを実行します。
```
$ chmod 777 EditSwitches
```

分散システム上のすべてのホストで管理役割がこのアクションを使えるようにするには、変更した TSOLadmin.dt ファイルおよびアクションファイルを NIS+ マスターおよび分散システム上のすべてのホストにコピーします。その後、プロファイルマネージャを起動し、ネームサービスとして NIS+ を選択します。

このアクションは NIS+ 経由では管理されないため、配布に当っては rdist(1) またはファイルをテープまたはフロッピーにコピーし、その媒体を持って各ホストを回り、1 台ごとにファイルをインストールするなどの方法が必要となります。

このアクションを 1 台のホスト上でのみ使用可能にするには、プロファイルマネージャを起動し、ネームサービスとして「なし (None)」を選択します。

システムセキュリティプロファイルまたはシステム管理プロファイルのどちらかのプロファイルを選択し、「表示 (View)」メニューから「アクション (Actions)」を選択します。

新しいアクション名が、「含まない (Excluded)」リスト内の「システム管理 (System_Admin)」アプリケーショングループ中に表示されます。
1. このアクションがセキュリティ関連ファイル (system(4) ファイルなど) を編集するものである場合、このアクションをシステムセキュリティプロファイルに割り当てます。
2. このアクションが UNIX システム管理者によって変更される通常のファイル (ラベルやその他のセキュリティ属性を持たないもの、たとえば group(4) ファイルなど) を編集するものである場合、このアクションをシステム管理プロファイルに割り当てます。

この新しいアクションに「マウント・ポイントの設定 (Set Mount Points)」アクションに割り当てられている特権(file_dac_read, file_dac_write, proc_audit_appl, proc_audit_tcb) と同じものを割り当てます。

いったんログアウトした後、再度ログインします。

「システム管理 (System_Admin)」フォルダの外側にアクションを追加するには

アクションの追加は『共通デスクトップ環境上級ユーザ及びシステム管理者ガイド』に述べられている方法で行えます。この場合、Trusted Solaris の MAC 制限が課されます。アクションの作成には「アクション作成」を使うか、または手動で作成します。作成したアクションはディレクトリ /etc/dt/appconfig/types/localename に置く必要があります (localename は、ロケール名を示しています)。

リブート後のログイン無効化を防ぐには

セキュリティ管理役割になります。

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

管理用エディタを使って /etc/init.d/RMTMPFILES を開き、編集します。

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

注 -
/etc/init.d ディレクトリにはバックアップファイルを作成しないでください。startup ディレクトリ内のすべてのファイルが実行されると、バックアップファイルはバージョンが変更された後に実行され、/etc/nologin ファイルが作成し直されます。したがって、この手順の効果が元に戻されるためです。

リブート後のログインを無効にする行をコメント行にします。

有効な行を次のようにコメント行にします。

# cp /dev/null /etc/nologin
# echo "" >> /etc/nologin
# echo "NO LOGINS: System booted" >> /etc/nologin
# echo "Logins must be enable by an authorized user." >>
# /etc/nologin
# echo "" >> /etc/nologin

編集が終わったら内容を保存し、ファイルを閉じます。
:wq

第 2 章その他の作業と操作手順

この章では、本マニュアルの他の章で紹介しているどの作業分類にも当てはまらない作業について説明し、その作業を実行するための操作手順を紹介します。この章には次の主要項目があります。

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

セキュリティの条件

ユーザーの日々の作業が、設定された構成の条件と矛盾しないようにする必要がある場合、この節の規則は特に重要です。システムのセキュリティが脅かされないように、管理者はパスワード、ファイル、および監査データが保護されることを保証する必要があります。

セキュリティの条件に関するユーザーの研修

セキュリティ管理者は、ユーザーの研修も設定する必要があります。以下の規則は、新入社員に手渡すとともに、従来の社員にもこれらの規則の存在を折を見て確認する必要があります (ここに示した以外の提案が必要な場合もあります)。

すべてのユーザーの規則

自分のパスワードは誰にも教えないこと。自分のパスワードを知られると、認証なしに、つまり、権限のない者が自分と同じ情報にアクセスできることになります。
- 自分以外の誰にもパスワードは教えない
- パスワードを書き留めたり、電子メールにそれを明記したりしない。

連想しにくいパスワードを使用すること。

この条件は、表 2-1 に示すように、トラステッドパスメニューでパスワードを変更する際にも必須になっています。
画面をロックしたりログアウトしないまま自分のワークステーションの席を離れない。
送信者情報を偽造するためにメールが書き換えられることがあることを留意すること。
管理者は、ユーザーに指示を出すときに電子メールには依存しないことに留意すること。電子メールによる指示に従う前に、それが確実に管理者からの電子メールであることを検証する必要がある。
パスワードを他人に電子メールで送信しないこと。
作成したファイルやディレクトリのアクセス権は作成者に責任がある。権限を持たないユーザーによるファイルの読み取り、変更、およびディレクトリの内容の一覧表示、ディレクトリへの書き込みができないように許可が設定されていることを確認すること。

ユーザーアカウントと役割アカウントのセキュリティ

セキュリティ管理者役割は、各アカウントに対する最初のパスワードを指定します。セキュリティ管理者役割が選択したパスワードは、表 2-1 に示すようなトラステッドパス (TP) メニューでのパスワード変更で求められているものと同じ条件を満たす必要があります。これらの条件を表 2-1 に示します。

表 2-1 手操作で作成されるパスワードについての規則


規則
パスワードの長さは、8 文字。
パスワードには、少なくとも2 文字のアルファベットが含まれていなければならない。
パスワードには、少なくとも 1 文字の数字あるいは特殊文字が含まれていなければならない。
パスワードは、ユーザーのログイン名、その逆やシフトしたものとは異なったものでなければならない (この場合、大文字と小文字は同一と見なす)。
新規に作成したパスワードは、その中の少なくとも 3 文字以上が古いパスワードと異なっていなければならない (この場合、大文字と小文字は同一と見なす)。

新規にローカルアカウントあるいは NIS+ 管理アカウントを作成するときに、管理役割は、一意のユーザー名を指定する必要があり、セキュリティ管理役割は、一意のユーザー ID を指定する必要があります。新規アカウントに名前や ID を選択するときは、管理者は、ユーザー名および関連 UID ともネットワーク上の他のものと重複しないことを確認しなければなりません。

システムが同一である限り、管理者は、ユーザー名やUID は、同じものを決して再使用しないようにする必要があります。ユーザー名や UID を再使用しないことによって、次のような混乱を防ぐことができます。

監査レコードの解析中、どのユーザーがどのアクションを実行しているか
アーカイブファイルの復元中、どのユーザーがどのファイルを所有しているか

セキュリティ管理者役割は、いつでもどのアカウントのパスワードも変更できる権限があります (セキュリティ管理者役割のパスワードは例外で、「自分を変更することを許可」承認を必要とします)。パスワードが誰か他の者によって知られたかもしれないと思われるときは、セキュリティ管理者は、そのアカウントのパスワードを変更する必要があります。セキュリティ管理者は、他の誰にも知られない方法により、そのアカウントにパスワードを手渡す必要があります。

管理者は、何らかの作業を始める指示をユーザーに与えるときに電子メールは使うべきではなく、ユーザーには、管理者からのメールであることを装ってくる指示を信用しないように指示する必要があります。それによって、偽の電子メールでユーザーにパスワードをある値に変更するか公表する指示を与えて、そのパスワードを使用してログインを行い、システムに被害を与えるといった事態を防ぐことができます。

アカウントのためにパスワードの指定を行うセキュリティ管理者役割は、セキュリティ管理役割になることのできるアカウントが「常に開く」に設定されていることを確認しておく必要があります。そうすることによって、少なくとも 1 人のアカウントが常にログインできる状態で、セキュリティ管理役割になることができ、仮にアカウントのすべてがロック状態になってもそれらを再びオープンすることができるようになります。

情報の保護

管理者は、責任をもって機密性の高いファイル (暗号化されたパスワードを含む shadow(4) ファイル、ローカルな tsoluser(4) および tsolprof(4) データベース、監査トレール) の DAC および MAC 保護を行う必要があります。

警告 -

NIS+ テーブルに適用される保護メカニズムは、Trusted Solaris システムで実施されているアクセス制御ポリシーの配下にないため、デフォルトの NIS+ テーブルの拡張やテーブルへのアクセスルールの変更は一切行うべきではありません。

パスワードの保護

ローカルファイルでは、DAC によりパスワードを見ることはできません。また、DAC と MAC によりパスワードが変更ができないように保護されています。ローカルアカウントのパスワードは、shadow (4) ファイルで保守されており、スーパーユーザーからしか読むことができません。

trusted4% ls -l /etc/shadow
-r------- 1 root

セキュリティ管理者役割は、DAC および MAC 属性が /etc/shadow ファイル用に変更されることのないようにしなければなりません。shadow ファイル上で保守をしなければならない属性を次の表に示します。

表 2-2 /etc/shadow で必要な属性


MAC	`ADMIN_LOW`
DAC	`所有者`	`グループ`	`アクセス権`
DAC	root	sys	400

NIS+ passwd.org_dir テーブルのパスワードフィールドは、NIS+ アクセスがテーブル内のフィールドに限定されていることで保護されています。ユーザーや管理者が passwd.org_dir テーブルを見ようとしても、表示される符号化されたパスワードは、そのアカウントに属するものだけです。

次の例では、niscat(1) コマンドを起動したユーザーである roseanne は、自分自身のアカウントの符号化されたパスワードを見ることはできても、他のユーザーである ricc のパスワードフィールドには、*NP* と表示されるだけであることを示しています。

trusted5% whoami
roseanne
trusted6% niscat passwd.org_dir
. . .
ricc:*NP*:33333:10:Ric Cheshire:/home/ricc:/bin/csh:*NP*
roseanne:0dk1EW44:10:Roseanne Sullivan:/home/roseanne:/bin/csh:38442::::::

また、次の例に示すとおり、shadow.org_dir テーブルはありません。

trusted5% niscat shadow.org_dir
shadow.org_dir: Not Found, no such name

グループの作成

管理者は、ローカルシステムとネットワークに対して、どのグループも一意の GID を持っていることを確認しておく必要があります。

ユーザーの削除

システムからアカウントを削除するとき、管理者およびセキュリティ管理者は次のアクションを実行する必要があります。

そのアカウントのホームディレクトリの削除

必要に応じて、「MLD を削除するには」を参照してください。
削除したアカウントに属するプロセス、ジョブをすべて除去する。
- そのアカウントが所有していたオブジェクトはすべて削除するか、他のユーザーに所有権を割り当てます。
- そのユーザーが代表になってスケジュールが組まれていた at またはバッチ処理をすべて削除します。必要であれば、at(1) と crontab(1) のマニュアルページも参照してください。

ユーザー (アカウント) 名および UID は決して再利用しない。

グループの削除

ローカルグループがシステムから削除されるとき、管理者役割は次のことを行う必要があります。

削除されたグループの GID の付いたオブジェクトをすべて削除するか、他のグループに割り当てる
削除されたグループに一次グループとして属していたユーザーの一次グループを他のグループに再割り当てする

フロントパネルの変更

デフォルトでは、セキュリティ管理者役割は管理エディタアクションを持つ唯一の役割です。そして、セキュリティ管理者役割は、「フロントパネル (Front Panel)」サブパネルの /usr/dt/appconfig/types/C/dtwm.fp ファイルなどの構成ファイルを変更する唯一の役割です。このマニュアルでは、既存のファイルを変更して新しいアクションを作成する 2 つの手順を説明します。1 つは、フロントパネルの特権で実行できる代用メールアプリケーションを作成する方法です。もう 1 つは、別の構成ファイルを編集するために、「システム管理 (System_Admin)」フォルダに継承された特権で実行できる管理アクションを追加する方法です。「管理ファイルを編集する新しい管理アクションを作成するには」と「他のメールアプリケーションを代用するには」を参照してください。

ワークスペースメニューの変更

ワークスペースメニューとは、ワークスペースの背景でマウスの右ボタン (メニューボタン) をクリックして押さえたままにするとアクセスできるメニューのことです。ワークスペースメニューの「メニューをカスタマイズ (Customize Menu)」と「メニューに項目を追加 (Add Item to Menu)」のオプションは、ベース CDE ウィンドウシステム内と同じように使うことができます。ただし、ラベル、MAC、MLD、およびプロファイル機構に関連する Trusted Solaris の警告が出ます。

次の規則は、ユーザーが複数ラベルで作業することが許可されているときに適用されます。

「メニューをカスタマイズ (Customize Menu)」と「メニューに項目を追加 (Add Item to Menu)」のオプションへの変更は、セッション認可上限で行う必要があります。

注意 -
他のラベルで変更を行った場合、その変更はウィンドウシステムによって認識されません。
変更は、通常のユーザーワークスペースだけで行うことができます。
ユーザーが役割になったときでも、ワークスペースメニューへの任意の変更はそのままです。
ワークスペースメニューへの変更は、作業機密ラベルで作成された SLD 内にあるユーザーの MLD ホームディレクトリに格納されます (セッション認可上限でなければならない)。
ユーザーが複数ラベルでログインできる場合、そのユーザーは、異なるログインセッション中に複数のセッション認可上限を持つ可能性があります。すべての可能性のあるログインセッションに変更を適用するには、可能性のあるセッション認可上限ごとに変更を行う必要があります。
ワークスペースメニューの項目は、作業機密ラベルに対応する SLD 内にあるユーザーの MLD ホームディレクトリ内の .dt/wsmenu ディレクトリに格納されます

たとえば、ユーザーのセッション認可上限が常に NEED_TO_KNOW ENG であるときにワークスペースメニューを変更するには、そのユーザーは NEED_TO_KNOW ENG 機密ラベルのワークスペースに移動します。ユーザーが「メニューに項目を追加 (Add Item to Menu)」オプションで「アプリケーション (Applications)」メニューに項目を追加する場合、そのアイテムは次のディレクトリに格納されます。
/home/username/.dt/wsmenu/Applications
上記ディレクトリは、次に示す実際の MLD パスに対応します。この例では、.SLD.3 は、ユーザー gfaden の NEED_TO_KNOW ENG 機密ラベルに対応する SLD です。
/home/.MLD.gfaden/.SLD.3/.dt/wsmenu/Applications

別の警告もプロファイル機構に接続できます。

ワークスペースメニューに追加された任意のオプションは、ユーザーの実行プロファイルの 1 つで処理される必要があります。そうしなければ、そのオプションを呼び出したときに問題が発見され、エラーメッセージが表示されます。

たとえば、「実行 (Run)」アクションを持つ任意のユーザーが実行可能ファイルのアイコンをダブルクリックした場合、そのアイコンが呼び出すアクションまたはコマンドがそのユーザーのアカウントの実行プロファイルに存在しない場合でも、そのファイルは実行できます。

デフォルトでは、役割は「実行 (Run)」アクションを持たず、すべての実行可能アクションは「実行 (Run)」アクションを必要とします。したがって、役割が「実行 (Run)」アクションを必要とする項目を実行すると、問題が発見されます。

ワークスペースメニューを変更するには

注 -

すべての可能性のあるログインセッションに変更を適用するには、複数ラベルを持つユーザーが、可能性のあるセッション認可上限に対応する機密ラベルごとに、以下の手順を繰り返す必要があります。

ログインし、セッション認可上限と同じラベルを持つワークスペースに移動します。役割にはなりません。

ワークスペースメニューから「メニューをカスタマイズ (Customize Menu)」または「メニューに項目を追加 (Add Item to Menu)」オプションを選択し、変更を行います。

ファイルと選択のアップグレードとダウングレードの規則の変更

ウィンドウシステム内で次の 3 つの種類の操作を行うと、機密ラベルがアップグレードまたはダウングレードされることがあります。

カット＆ペースト
コピー＆ペースト
ドラッグ＆ドロップ

/usr/dt/config/sel_config ファイルを調べて、次のことを決定します。

ある種類の操作が自動的に確認されるようになっているか
選択確認ダイアログが表示されるようになっているか

次の図に、ファイルマネージャ間におけるドラッグ＆ドロップ操作の選択確認ダイアログを示します。異なるラベルのファイルマネージャおよびウィンドウ間におけるカット＆ペーストやコピー＆ペーストの操作では、他の選択確認ダイアログが表示されます。

図 2-1 ファイルマネージャ選択確認ダイアログ

sel_config ファイルは次のことも指定します。

自動応答が行われる選択の種類の一覧

セキュリティ管理者役割は、デフォルトを受け入れることも、あるいは、アプリケーションマネージャにある「システム管理 (System_Admin)」フォルダの「選択構成 (Selection Configuration)」アクションを使って変更することもできます。「選択構成 (Selection Configuration)」アクションを実行すると、/usr/dt/config/sel_config ファイルが adminvi(1M) で開いて編集できます。新しい設定は、次回ログインしたときから有効になります。

次の節では、必要な背景について説明します。また、デフォルトを変更したいセキュリティ管理者向けに、ファイル内の各フィールドについても説明します。必要であれば、「ファイルと選択のアップグレードとダウングレードの規則の変更」を参照してください。

選択管理の概念について

この節では、ウィンドウシステム内でカット、ペースト、ドラッグ、およびドロップの各操作がどのように制御されるかについて説明します。

注 -

これらの操作をファイルアイコンに実行したときに適用される規則は、ウィンドウ内の選択に適用される規則とは異なります。

デフォルトでは、通常のユーザーは、カット＆ペースト、コピー＆ペースト、およびドラッグ＆ドロップの各操作を、発信元と宛先の機密ラベルとユーザー ID が同じ場合に限り、ファイルと選択の両方に実行できます。

特定の承認を持っていれば、ユーザーは次の種類の操作も実行できます。

所有者または機密ラベルが異なるファイルマネージャ間におけるファイルのカット＆ペースト、コピー＆ペースト、およびドラッグ＆ドロップ
所有者および機密ラベルが異なるウィンドウ間における選択のカット＆ペーストおよびコピー＆ペースト

注 -
選択のドラッグ＆ドロップでは、常に、機密ラベルと所有者が同じであることが必要です。

次の表に、機密ラベルおよび所有者の関係が異なるファイルに行う可能性のある種類の操作を要約し、必要な承認を示します。

表 2-3 ファイルマネージャ間におけるコピー＆ペースト、カット＆ペースト、およびドラッグ＆ドロップに必要な規則と承認


操作の説明	機密ラベル (SL) の関係	所有者の関係	承認
ファイルマネージャ間におけるファイルのコピー＆ペースト、カット＆ペースト、およびドラッグ＆ドロップ	同じ SL	同じ UID	必要なし
	ダウングレード	同じ UID	ファイルの機密ラベルをダウングレード
	アップグレード	同じ UID	ファイルの機密ラベルをアップグレード
	ダウングレード	異なる UID	ファイルの機密ラベルをダウングレードおよびファイル所有者として動作
	アップグレード	異なる UID	ファイルの機密ラベルをアップグレードおよびファイル所有者として動作

次の表に、機密ラベルおよび所有者の関係が異なるウィンドウ間の選択に行う可能性のある種類の操作を要約し、必要な承認を示します。

表 2-4 ウィンドウ間における選択のコピー＆ペースト、カット＆ペースト、およびドラッグ＆ドロップに必要な規則と承認


操作の説明	機密ラベル (SL) の関係	所有者の関係	承認
ウィンドウ間における選択のコピー＆ペーストまたはカット＆ペースト	同じ SL	同じ UID	必要なし
	ダウングレード	同じ UID	ダウングレードしたウィンドウにペースト
	アップグレード	同じ UID	アップグレードしたウィンドウにペースト
	ダウングレード	異なる UID	ダウングレードしたウィンドウにペーストおよびファイル所有者として動作
	アップグレード	異なる UID	アップグレードしたウィンドウにペーストおよびファイル所有者として動作
ウィンドウ間における選択のドラッグ＆ドロップ	同じ SL が常に必要	同じ UID が常に必要	適用なし

sel_config ファイルセクション

sel_config ファイル内の規則は、ファイルマネージャ間におけるファイルのコピー＆ペースト、カット＆ペースト、およびドラッグ＆ドロップに適用されます (ファイルマネージャアプリケーションについての詳細は、dtfile(1) のマニュアルページおよび『Trusted Solaris ユーザーズガイド』を参照)。sel_config ファイル内の規則は、ウィンドウ間における選択のコピー＆ペーストおよびカット＆ペーストにも適用されます。この場合、/usr/dt/bin/sel_mgr アプリケーションが調停します。

注 -

選択のドラッグ＆ドロップでは、常に、機密ラベルと所有者が同じであることが必要です。したがって、sel_config ファイル内の規則は、選択のドラッグ＆ドロップには適用されません。

sel_config ファイルには、次のような 2 つのセクションがあります。

自動確認
自動応答

自動確認セクション

次の表に、sel_config ファイルの自動確認セクション内の各行の形式を示します。

表 2-5 sel_config 内の自動確認セクションの形式


転送の種類	自動的に確認するか n = 選択確認ダイアログを表示
SL 関係	y \| n

SL 関係とは、発信元と宛先の SL 間の関係のことです。SL 関係は次のうちの 1 つです。

upgrade|downgrade|equal|disjoint

処理は常にラベルが同じときに許可されるため、選択確認ダイアログは機密ラベルが同じであることを定義した規則を持っていません。

自動応答セクション

autoreply フィールドは、後に指定されているすべての種類の選択に対する応答の種類を定義します。このセクションは、個々に応答するのではなく、複数の種類の選択にまとめて自動応答する方法を提供します。次の表に、デフォルトの autoreply セクションを示します。デフォルトでは autoreply は y に設定されており、後に続く 4 つの種類の選択に自動応答します。

autoreply: y

replytype: TARGETS

replytype: Pixel Sets

replytype: LENGTH

replytype: Type Of Monitor

autoreply の値が y の場合、残りのエントリは、確認なしで操作を完了させるための (実際の内容ではなく) 選択データの属性として使われます。autoreply の値が n の場合、残りのエントリは無視されます。これらのエントリは、「確認 (Confirmer)」ウィンドウに表示される任意の「種類 (Type)」フィールドに指定できます。

sel_config のデフォルトの設定

次の例に、/usr/dt/config/sel_config ファイル内のコメントとデフォルトの設定を示します。

例 2-1 `sel_config` 選択確認ファイル

#pragma ident   "@(#)sel_config 5.7     99/09/17 SMI; TSOL 2.x"
#
# Copyright (c) 1998, 1999 by Sun Microsystems, Inc.
#  All rights reserved.
#
# Auto settings default file
#
# This file controls the action of the selection
# manager and the file manager drag and drop confirmers.
# There is an entry for the 3 possible types of transfer based
# upon the source label and destination label.
#
# The file has two sections, the auto confirm section and
# and the auto reply section.
#
#
# Auto Confirm Section
#
#   Specifies for each transfer type whether the action should
#   be automatically or manually confirmed.
#
# Auto confirm?     y -> confirm transfer without displaying confirmer
#                        (note: user must still have proper authorizations)
#                   n -> display confirmer before processing transfer
#
#                     Auto
#  Transfer Type     Confirm?

downgradesl:	n

upgradesl: 		n

disjointsl:		n

# Auto Reply Section

autoreply: y
replytype: TARGETS
replytype: Pixel Sets
replytype: LENGTH
replytype: Type Of Monitor

選択構成ファイルを変更するには

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

アプリケーションマネージャの「システム管理 (System_Admin)」フォルダに移動します。

「選択構成 (Selection Configuration)」アクションをダブルクリックし、sel_config ファイルを adminvi(1M) で開いて編集します。

必要であれば、各フィールドの意味については、「ファイルと選択のアップグレードとダウングレードの規則の変更」を参照してください。

変更を行った後、ファイルを保存して終了します。
:wq
注 -
変更は、次回任意のユーザーがログインしたときから有効になります。

変更した構成ファイルのネットワーク上のホストへの配布

NIS+ によって配布されない構成ファイルの配布方法を次に示します。root の役割は、rdist(1) コマンドを使用して、分散システム上のマシンに同一のファイルのコピーを自動で配布します。

構成ファイルをリモート操作で配布するには

注 -

どのホストも、hosts.equiv(4) ファイルにあるのは追加分だけであること、/.rlogin または $HOME/.rlogin ファイルには何も入力されていないことを確認する必要があります。

ログイン後、root の役割になり、アプリケーションマネージャの「システム管理 (System_Admin)」フォルダから管理用エディタを使用して、distfile を開き、編集します。

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

マスターディレクトリからコピーしてくる構成ファイルのエントリを distfile に追加します。

下記の例は、rdist(1) が label_encodings と system ファイルを一覧表示された分散システムの全ホストに配布するように distfile を設定したものです。
HOSTS = ( machiavelli muckraker mugwump diehard warhorse ) FILES = ( /etc/security/tsol/label_encodings /etc/system ) ${FILES} -> ${HOSTS} install ;

ファイルを保存して、それを閉じます。
:wq

rdist コマンドを実行します。

rdist は、distfile と同じディレクトリで実行することができます。また、他の名前を付けた別のファイルのフルパス名に続けて -f オプションを使用することもできます。
# rdist /* OR */ # rdist -f /home/machiavelli/jedgar/label_encodings.master/distfile.sample
rdist(1) と hosts.equiv(4) のマニュアルページも参照してください。

各マシンをリブートします。

キーボードアボートの有効化

Solaris オペレーティング環境では、SPARC システム上の任意のユーザーはキーボードアボートシーケンスを使って、システムをモニタープロンプトにすることができます。カーネルデバッガが有効である場合、SPARC システムまたは X86 システム上の任意のユーザーはキーボードアボートシーケンス (SPARC の場合は Stop A、X86 システムの場合は Control Alt D) を使って、システムを kadb(1M) カーネルデバッガにすることができます。この動作は、/etc/default/kbd ファイル内の設定で制御されます。デフォルトの Solaris オペレーティング環境では、キーボードアボートシーケンスは有効です。

KEYBOARD_ABORT=enable

デフォルトの Trusted Solaris オペレーティング環境では、キーボードアボートシーケンスは無効です。

KEYBOARD_ABORT=disable

したがって、Trusted Solaris システムをダウンするには、トラステッドパスメニューから「シャットダウン (Shut Down)」オプションを選択し、順序よくシャットダウンするしか方法がありません。

サイトのセキュリティポリシーが許す場合は、デフォルトの設定を変更できます。また、管理者がデバッグ用に使っているホストでは、kadb(1M) カーネルデバッガにアクセスできるようにデフォルトの設定を変更できます。

パスワード入力ミス許容回数の最大値の変更

デフォルトでは、Trusted Solaris システムは、ホストへのログイン時あるいはパスワード変更作業時に 1 回のアクセス試行に対して 5 回までのパスワード入力失敗を許可しています。このログイン試行失敗回数の最大値を設定することで、いろいろなパスワードで何度もログイン試行を繰り返し、特定のアカウントのパスワードを探り当てようとするような行為を前もって封じることができます。1 つのセッションで設定した最大値を 1 回でも超えて誤ったパスワードを入力すると、そのアカウントは直ちに閉じられます。

アカウントが誤って閉じられてしまった場合、セキュリティ管理者は、ユーザーマネージャのパスワードダイアログボックスの状態メニューを使って、そのアカウントのステータスを「閉じる」から「開く」に変更できます。

セキュリティ管理者役割は、サイトのセキュリティポリシーに応じて、ログイン試行失敗回数の最大値を任意の値に設定できます。不正なログインの最大数は、各ホストのローカルな /etc/default/login ファイル内の RETRIES 値に設定されています。

また、セキュリティ管理者役割は、ユーザーマネージャの「パスワード」ダイアログボックスを使用して、任意のユーザーアカウントを「常に開く」に設定することができます。RETRIES 値は、「常に開く」(「常に開く」を設定すると、/etc/default/passwd ファイルに、FIXED が入力される) に設定されたアカウントには適用されません。管理役割になるアカウントおよびセキュリティ管理者役割になることのできるユーザー 1 名分のアカウントは、「常に開く」に設定すべきです。

パスワード入力ミス許容回数の最大値を変更するには

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

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

ADMIN_LOW として管理用エディタで /etc/default/login ファイルを開き、編集を行います。

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

文字列 RETRIES を検索します。

# RETRIES sets the number of consecutive authentication failures
# allowed  before the user is locked out.
#
RETRIES=5

上記の RETRIES の設定値を必要に応じて変更します。

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

構成ファイルへのラベルの入力

構成ファイルのラベルをテキスト形式にするか、16 進形式にすることができます。どちらの形式を使用するかは、その組織のセキュリティポリシーによって異なります。テキスト形式で入力されたラベルは、引用符で囲む必要があります。

注 -

ラベルが人が読める形式で記録されると、そのラベルを含むファイルは、認可上限が ADMIN_HIGH の管理役割の者だけが読めるように ADMIN_HIGH のレベルで保護する必要があります。

ラベルおよび認可上限の 16 進値を求めるには

管理者は、サイトのセキュリティポリシーによってはトラステッドネットワークデータベースやその他の設定ファイルにラベルおよび認可上限を 16 進形式で入力する必要があります。

次に示すオプションとともに atohexlabel(1M) を使用すると、機密ラベル、認可上限に対応する 16 進値を求めることができます。 atohexlabel(1M) コマンドはデフォルトの「Object Label Management」プロファイル内にあり、これはデフォルトでセキュリティ管理者役割に割り当てられます。

ラベルに対応する 16 進値を求めるには

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

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

ADMIN_HIGH ワークスペースで、端末エミュレータを起動します。

機密ラベルに対応する 16 進値を求めるには、atohexlabel の引数に -s オプションと機密ラベル名を指定します。
$ atohexlabel -s SECRET 0x00060c0000000000000000000000000000000000000000000003ffffffffffff0000

認可上限ラベルに対応する 16 進値を求めるには、atohexlabel の引数に -c オプションと認可上限名を指定します。
$ atohexlabel -c SECRET 0x00060c0000000000000000000000000000000000000000000003ffffffffffff0000

拡張可能なセキュリティ機能の追加

セキュリティ管理役割が追加することのできる Trusted Solaris セキュリティ機能には次のものがあります。

監査イベント
監査クラス
実行プロファイル
役割
承認
特権

監査イベントおよび監査クラスの追加に関しては、マニュアル『Trusted Solaris の監査管理』を参照してください。実行プロファイルの追加に関しては、「プロファイルマネージャを使った実行プロファイルの作成または変更」で説明します。役割の追加に関しては、「新しい役割の作成」で説明しています。この節では承認および特権の追加方法について説明します。

承認の基本概念

承認は、実行プロファイルを通じてのみ、そのユーザーに与えられます。

プロファイルマネージャを通じて、各実行プロファイルにはゼロまたはそれ以上の数の承認が割り当てられます。この割り当てられた承認は、各プロファイルの tsolprof(4) エントリ内の「承認 (authorizations)」フィールドに格納されます。承認フィールドの内容は、承認番号、名前、all、none のいずれかのキーワードのうち任意のものをコンマで区切ったものです。tsolprof エントリの書式を次に示します。

profile:description:authorizations:actions:commands:links:flags; (<プロファイル名> : <説明> : <承認名> : <アクション名> : <コマンド名> : <リンク名> : <フラグ> ;)

注意 -

tsolprof ファイルは直接編集しないでください。

下の図は、Audit Review という名前のプロファイルの tsolprof エントリを示しています。このプロファイルは、「端末ログイン」承認 (番号 3) と「ファイルの特権を設定」承認 (番号 9) を持っています。

例 2-2 `tsolprof` エントリの例

 
Audit Review:View The Audit Trail:none:none:/var/sbin;praudit;
3,9;none;none,0x0000000000000000000000000000000000000000000000
0000000000000000000000[0x7ffffffffffffffffffffffffffffffffffff
ffffffffffffffffffffffffffffff]:1:none

アカウントの設定や変更を行う際、セキュリティ管理者は、ユーザーマネージャを使ってゼロまたはそれ以上の数の実行プロファイルを割り当てます。割り当てられたプロファイルの名前は、そのアカウント用の tsoluser(4) エントリ内のプロファイル用のフィールドに格納されます。

次の図は、ローカルに作成された auditadmin という名前の管理役割アカウント用の tsoluser エントリを示しています。このエントリのプロファイル用のフィールドには、割り当てられたプロファイル名をコンマで区切ったものが格納されています。

例 2-3 管理役割アカウント用の `tsoluser` エントリ内に示されたプロファイル

 
auditadmin:fixed:automatic:Audit Control,Audit Review,Media Restore,:none:5:l
ock:internal, showil,showsl:0x0000:0x000000000000000000000000000000000000000000
00000000000000000000000000:0x7fffffffffffffffffffffffffffffffffffffffffffffffff
fffffffff:utadm:res1:res2:res3

上の例では、この新しい役割には、Audit Control、Audit Review、Media Restoreという 3 つのプロファイルが割り当てられています。

Trusted Solaris 承認の拡張

新しい承認を追加するには、その承認のためのエントリを次の 2 つのファイルに追加する必要があります (localename はロケール名を示しています)。

/usr/include/tsol/auth_names.h
/usr/lib/tsol/locale/localename/auth_name

`auth_names.h`

ヘッダーファイル /usr/include/tsol/auth_names.h には、承認用の明示的定数とそれに関連付けられている番号が定義されています。最大で 128 個の承認が定義できます。次に示すように、TSOL_AUTH_* ではじまる 55 個の承認が事前に定義されています。デフォルトでは、これらの承認は番号として 1〜55 を持ち、番号 0 は承認が存在しないことを表します。

例 2-4 `auth_names.h` に定義されている * `TSOL_AUTH` 承認

TSOL_AUTH_ENABLE_LOGIN = 1,		/* indirectly required*/
										.						
										.						
										.						
	TSOL_AUTH_PRINT_MAC_OVERRIDE = 55,

これ以外に、番号 56〜89 の承認が、将来のサンの拡張のために予約されています。これらの承認は、次の図に示すように、いずれも tsol_auth_reserved という名前で識別されています。

例 2-5 `auth_names.h` に定義されている `tsol_auth_reserved` 承認

tsol_auth_reserved53 = 53,
`										.						
										.						
										.						
tsol_auth_reserved89 = 89,

auth_reserved という名前で識別される残りの承認が、任意のサイトでの拡張用に使用可能です。これらの承認を次の図に示します。

例 2-6 拡張用に使用可能な承認

auth_reserved90 = 90,
										.						
										.						
										.			
auth_reserved127 = 127

`auth_name`(4)

デフォルトのシステムでは、auth_name(4) ファイルは、/usr/lib/tsol/locale/localename にあります (localename はロケール名を示しています)。

デフォルトのロケールにおけるファイルエントリの書式を次の図に示します。

例 2-7 `auth_name` ファイルの書式

constant:name:description (<定数>:<名前>:<説明>)

/usr/lib/tsol/locale/locale_name/auth.h の定数値は、/usr/include/tsol/auth.h ファイルで定義されている承認の宣言定数名とまったく同じものでなければなりません。名前フィールドには、承認の内容を正確に表すような名前を入力します。名前フィールドに入力した名前は、プロファイルマネージャなどの各種 GUI で使用されます。

注 -

承認の名前 (例 2-8 の例では「ログインを有効化」) は、プロファイルマネージャなどの GUI で承認の一覧を表示する場合に使用されます。

説明フィールドには、承認によって許可される動作の説明を入力します。この説明の文字数に制限はありません。この説明は、プロファイルマネージャによって、セキュリティ管理者役割が承認をプロファイルに割り当てる際のガイド情報として使われます。

例 2-8 に、デフォルトの auth_name ファイル内に定義した実際の承認の例を示します。承認の宣言定数名はすべて英大文字に、逆に承認の名前はすべて英小文字にします。承認の説明が複数行にまたがる場合には行末にバックスラッシュ (¥) を付けます。

例 2-8 `auth_name` ファイル内に定義した「ログインを有効化」承認

TSOLAUTH_ENABLE_LOGIN:enable logins:Allows a user to enable logins on a¥
machine that was just booted.  Until logins are enabled there is¥
no interactive use of the machine's resources.

承認を追加するには

注 -

可能であれば、作業開始前に Trusted Solaris のご購入先に連絡をとり、承認番号の予約をとってください。

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

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

ADMIN_LOW のセキュリティ管理者として、管理用エディタを使用して、/usr/include/tsol/auth_names.h ファイルを開き、編集を行います。

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

ファイル auth_names.h に、追加したい承認の宣言定数を持つエントリを作成します。
AUTH_POWER = 127, /* To leap tall MAC check failures and otherwise be irresponsible and unaccountable*/

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

管理用エディタを使用して、ファイル /usr/lib/tsol/locale/locale_name/auth_name を編集用に開きます (localename はロケール名を示しています)。

ファイル auth_name 内に、新しい承認の宣言定数・名前・説明を定義したエントリを作成します。

注意 -
第 1 フィールドには、ファイル auth_names.h に定義した承認の宣言定数名と全く同じものを指定しなければなりません。
AUTH_POWER:power user:Allows a user to bypass all MAC and DAC checks and auditing flag settings and to be otherwise totally unaccountable for his or her actions.

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

Trusted Solaris 特権の拡張

新しい特権を追加するには、その特権のためのエントリを次の 2 つのファイルに追加する必要があります(locale_name はロケール名を示しています)。

/usr/include/sys/tsol/priv_names.h
/usr/lib/tsol/locale/locale_name/priv_name

`priv_names.h`

ヘッダファイル /usr/include/sys/tsol/priv_names.h には、特権用の宣言定数とそれに関連付けられている番号が定義されています。最大で 128 個の特権が定義できます。デフォルトでは、これらの承認は番号として 1 〜 86 を持ち、番号 0 は特権が存在しないことを表します。また、後述するように、番号 29、62 は回収された特権を表します。

例 2-9 `priv_names.h` に定義されているデフォルトの特権の宣言定数と番号

PRIV_FILE_AUDIT = 1,		/* operational */
PRIV_FILE_CHOWN = 2,		/* operational */
PRIV_FILE_DAC_EXECUTE = 3,	/* policy */
										.						
										.						
										.						
PRIV_WIN_SELECTION = 84,	/* operational */
PRIV_WIN_UPGRADE_IL = 85,	/* operational */
PRIV_WIN_UPGRADE_SL = 86,	/* operational */

例 2-10 に示す特権が、Trusted Solaris での拡張用に予約されています。これらは、いずれも tsol_reserved という名前で識別されます。このうち、予約リストの番号 62 は回収された特権 (以前定義されていたが、現在は未定義である特権) を表します。このファイルの先頭に説明されているように、任意のユーザーが一度定義した特権を未定義に戻す場合、その特権は予約リストの先頭に追加するようにします。

例 2-10 Trusted Solaris での拡張用に予約されている特権

/* Reserved for Trusted Solaris */
 
	tsol_reserved28 = 28,
	tsol_reserved29 = 29,
	tsol_reserved62 = 62,
	tsol_reserved87 = 87,
	tsol_reserved88 = 88,
	tsol_reserved89 = 89,

reserved という名前で識別される残りの特権が、任意のサイトでの拡張用に使用可能です。これらの特権を次の例に示します。

例 2-11 拡張用に使用可能な特権

/* Reserved for ISV, GOTS, integrator, ... use */
 
	reserved90 = 90,
	reserved91 = 91,
	reserved92 = 92,
										.						
										.						
										.						
	reserved126 = 126,
	reserved127 = 127,
	reserved128 = 128

priv_name(4)

/usr/lib/tsol/locale/locale_name/priv_name ファイル内のエントリの書式を次に示します (locale_name はロケール名を示しています)。

constant:name:description(<定数>:<名前>:<説明>)

(priv_name(4) のマニュアルページを参照してください。) 上記の constant フィールドの値は、ファイル /usr/include/sys/tsol/priv.h に定義されている特権の宣言定数名と全く同じものを指定します。名前フィールドには、特権の内容を正確に表すような名前を入力します。名前フィールドに入力した名前は、GUI で使用されます。

注 -

特権の名前は、プロファイルマネージャ、ファイルマネージャなどの GUI で特権の一覧を表示する場合に使用されます。

説明フィールドには、特権によって許可される動作の説明を入力します。この説明の文字数に制限はありません。この説明は、プロファイルマネージャによって、セキュリティ管理者が特権をプログラムに割り当てる際のガイド情報として使われます。

例 2-12 に、デフォルトの priv_name ファイル内に定義した特権の例を示します。特権の宣言定数名はすべて英大文字に、逆に特権の名前はすべて英小文字にします。特権の説明が複数行にまたがる場合には行末にバックスラッシュ (¥) を付けます。

例 2-12 `priv_name` ファイル内に定義した「file_audit」という名前を持つ特権

PRIV_FILE_AUDIT:file_audit:Allows a process to get or set a file's or ¥
directory's audit preselection information. The auditing preselection ¥
information may override the preselection information associated with ¥
a process' access to a file or directory. ¥
Allows a process to get or set a file's or directory's public object ¥
flag. The public object flag may override the successful read/search ¥
access preselection information associated with a process' access to ¥
a file or directory.

特権を追加するには

注 -

可能であれば、作業開始前に Trusted Solaris のご購入先に連絡をとり、特権番号の予約をとってください。

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

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

ADMIN_LOW として、管理用エディタを使用して、/usr/include/sys/tsol/priv_names.h ファイルを開き、編集を行います。

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

priv_names.h ファイルの先頭にあるコメントを読みます。

コメントを次の図に示します。

/ *
* ********************** IMPORTANT **********************
*
* The privilege names should be maintained in alphabetical order
* not numeric order.
*
* When a privilege is retired it should be placed in the appropriate
* reserved area in the form "tsol_reserved## = ##," or
* "reserved## = ##".
*
* When a new privilege is needed, it should be taken from the first
* available privilege in the appropriate reserved area.
*
* ISVs, GOTS', integrators who need privileges are encouraged to
* request and retire them by contacting their respective Trusted
* Solaris support representative.
*
* This file is parsed by the priv_to_str(3) functions.
*
* In order to guarantee correct parsing, the format of the
* following priv_t definition must be preserved.
*
* Specifically, the following guidelines must be followed:
*
*	1. All privileges must have an explicitly assigned id.
*	   DO NOT RELY ON COMPILER TO ASSIGN IDs.
*
*	2. One privilege id assignment per line.
*	   DO NOT CONCATENATE OR BREAK LINES.
*
*	3. Do not use the `=' character at anywhere other than
*	   the privilege id assignment.
*	   For example, DO NOT use `=' in the comments.

ファイル priv_names.h に、追加したい特権の宣言定数を持つエントリを作成します。

入力例を次に示します。
PRIV_RISKY = 90,

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

管理用エディタを使用して、ファイル /usr/lib/tsol/locale/locale_name/priv_name を編集用に開きます (locale_name はロケール名を示しています)。

たとえば、C ロケールでは、/usr/lib/tsol/locale/C/priv_name ファイルを編集します。

ファイル priv_name 内に、新しい特権のための宣言定数、名前、説明を定義したエントリを作成します。

注 -
第 1 フィールドには、上の例のファイル priv_names.h に定義した特権の宣言定数名とまったく同じものを指定しなければなりません。

入力例を次に示します。
PRIV_RISKY:override everything:Allows a process to bypass all MAC and ¥ DAC checks and auditing flag settings and be otherwise totally ¥ unaccountable.

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

MLD を使った作業

マルチレベルディレクトリのことを「MLD」と呼び、シングルレベルディレクトリのことを「SLD」と呼びます。マニュアル『Trusted Solaris ユーザーズガイド』で説明しているように、1 つの MLD 内にある異なるラベルを持つディレクトリおよびファイルは、異なるラベルを持つ複数の SLD の内部へと自動的かつ透過的に分けられます。この場合、通常の使用では、これら複数の SLD の存在は隠されたままになります。

MLD は、異なるラベルで動作する複数のアプリケーションから、あたかも同じ 1 つのディレクトリに対して書き込みができるようにするためのものです。複数のアプリケーションによって頻繁に利用されるディレクトリとして /tmp がありますが、上記の理由から、デフォルトのシステムでは /tmp は MLD として実装されています。アプリケーションは、自分自身が /tmp 内にファイルを書き込む際に、/tmp が MLD であることを意識する必要はありません。実際には、アプリケーションは、自分自身が動作している機密ラベルを持つ /tmp ディレクトリ下の SLD にファイルを書き込みます。ホームディレクトリを MLD にすると、任意のアカウントは、自分のホームディレクトリ内に、異なる機密ラベルを持つ複数のファイルやフォルダを作成できるようになります。この場合、ユーザーアカウントや役割アカウントは、自分のホームディレクトリが MLD であることを意識する必要はありません。MLD であるホームディレクトリに移動した場合、実際には現在のワークスペースと同じ機密ラベルを持つ SLD に移動していることになります。

たとえば、roseanne というユーザーのために新しいアカウントを設定する際、ユーザーマネージャがホームディレクトリ /export/home/roseanne を MLD として作成したとします。この場合、ユーザー roseanne が、コマンド行から「cd ‾」を入力して自分のホームディレクトリに移動すると、roseanne はホームディレクトリ内にある SLD へと自動的かつ透過的に移行します。この SLD は、roseanne の現在のプロセスと同じ機密ラベルを持つものです。このため、NEED_TO_KNOW ワークスペースのラベルを持っていれば、 NEED_TO_KNOW 機密ラベルを持つ SLD へと移動していることになります。

以下の節では、MLD を使って作業する方法、MLD に含まれている任意の SLD に直接アクセスするために、MLD 全体を参照する方法などを説明します。

MLD 接頭辞 (MLD 装飾名)

MLD 接頭辞は MLD「装飾名」とも呼ばれます。MLD 名が MLD 接頭辞を含む場合、その MLD 名のことを単に「装飾名」と呼びます。MLD 装飾名は、SLD が格納されているトップレベルディレクトリに直接アクセスする場合に使われます。デフォルトのシステムでは、MLD 接頭辞は「.MLD.」になります。たとえば、MLD として実装されている /tmp の装飾名は「/.MLD.tmp」になります。

修飾名を使わずに MLD にアクセスした場合、同じ機密ラベルの適切な SLD に移動します。修飾名を使って MLD にアクセスした場合、MLD のトップレベルに移動します。MLD のトップレベルからは、MAC と DAC の制限内で、MLD に含まれているすべての SLD を見ることができます。

SLD の作成

ユーザーが新しい機密ラベルで初めて MLD にアクセスするたびに、現在のプロセスと同じ機密ラベルを持つ新しい SLD が 1 つ作成されます。

新規ユーザーの初回ログインで作成される最初の SLD の持つ機密ラベルは、そのユーザーの持つ最下位機密ラベルと同じになります。たとえば、ユーザー roseanne の持つ最下位機密ラベルは PUBLIC なので、roseanne が初めてログインした場合に作成される最初の SLD の持つ機密ラベルは PUBLIC になります。

SLD の命名規則

SLD の名前には必ず「.SLD.」という接頭辞が付けられます。SLD 接頭辞は、MLD 接頭辞とは異なり変更できません。1 つの MLD 内部で新しい SLD が作成されるたびに、その SLD の名前として順序番号が与えられます。たとえば、1 つの MLD 内部で最初に作成された SLD に与えられる番号は 0 (SLD 名は「.SLD.0」)、2 番目に作成された SLD に与えられる番号は 1 (SLD 名は「.SLD.1」)のようになります。

PUBLIC ワークスペースで作業している場合に、ユーザー roseanne がコマンド行から pwd コマンドを実行するか、またはファイルマネージャを使って自分のホームディレクトリのフォルダを見た場合、roseanne には現在のディレクトリ名は /export/home/roseanne としか見えません。一見、roseanne は自分のホームディレクトリで作業しているように見えますが、実際には roseanne は機密ラベル PUBLIC を持つ SLD (その名前は /export/home/.MLD.roseanne/.SLD.0) 内で作業しているのです。

SLD 名に含まれる番号は、そのディレクトリの持つ機密ラベルとは関係がありません。たとえば、どんな機密ラベルを持つユーザーのために作成されたとしても、最初に作成される SLD の名前は /export/home/.MLD.roseanne/.SLD.0 になります。

MLD は個々の SLD の持つラベルを記録しています。このため、同一 MLD に対して特定の機密ラベルでのアクセスが複数回実行された場合、2 回目以降のアクセスでは、アクセスを行なったユーザーは正しい機密ラベルを持つ SLD に自動的に移動されることになります。

たとえば、機密ラベル PUBLIC で作成された最初の SLD (名前は「.SLD.0」) があるとします。次回、ユーザー roseanne が機密ラベル PUBLIC で作業中に自分のホームディレクトリに移動した場合、roseanne は意識せぬままに実際には機密ラベル PUBLIC を持つ SLD に移動し、その後、彼女の作成したファイルはすべてディレクトリ「.SLD.0」内に保存されることになります。これらの仕組みは、ユーザーが接頭辞を使って MLD や SLD を直接参照しない限り、ユーザーの目からは見えません (「MLD 接頭辞と SLD 接頭辞の例」を参照のこと)。

MLD 作成に関する制限とその効果

MLD は、MLD でないディレクトリの内部にのみ作成できます。このような制限があるため、デフォルトのシステムでは、通常のユーザーは次の理由から MLD を作成することができません。

通常のユーザーが書き込めるディレクトリは自分自身のホームディレクトリだけである
ホームディレクトリが MLD である
ユーザーは自分のホームディレクトリ (MLD) 内には MLD を作成できない

通常のユーザーが MLD を作成するためには、管理者役割がまず、MLD ではなく、通常のユーザーが書き込みできる新しいディレクトリを作成する必要があります。

たとえば、あるサイトの管理者役割が /shark/doc とう名前のディレクトリを作成し、このディレクトリをすべての開発者が単一の機密レベルでマウント可能および書き込み可能に設定しておけば、設計仕様書やプロジェクト単位の文書などを誰もがアクセス可能な場所に保管することができます。このようにすれば、開発グループの誰もがこのディレクトリ内に新しいディレクトリを作成できますし、既存ディレクトリをMLDに変更できます。詳細は、「MLD の作成、変更、削除、MLD 内でのその他の操作」を参照してください。

MLD 接頭辞と SLD 接頭辞の例

次の例では、.MLD. 接頭辞を使って、NEED TO KNOW ENG ラベルにおける MLD の /tmp ディレクトリの内容一覧を表示しています。MLD 内にある 2 つの SLD は、そのラベルが NEED_TO_KNOW ラベルよりも優位であるため表示されていません。つまり、ls は現在のラベル以下の SLD を表示します。

trustworthy% 	ls /.MLD.tmp/.*
 /.MLD.tmp/.SLD.0
bt+_errlog.26629 
dtbcache_:0 bt+_errlog.26630 
ps_data
/.MLD.tmp/.SLD.4
bt+errlog.631
mpa000_M mailBAAa000K4
ps_data mpa000.E
sel_mgr.err

次の例では、getlabel(1) コマンドを使って、自分のラベルよりも優位な 2 つの SLD の名前を表示しています。しかし、getlabel は .SLD.1 や .SLD.2 のラベルよりも優位でないため、これらの SLD には「Not Owner」というエラーが表示され、ラベルの名前は表示されません。

trustworthy% ls /.MLD.tmp/.*
 /.MLD.tmp/.SLD.0
bt+_errlog.26629      
dtbcache_:0 bt+_errlog.26630      
ps_data  /.MLD.tmp/.SLD.4 bt+errlog.631         
mpa000_M mailBAAa000K4         
ps_data mpa000.E              
sel_mgr.err 
trustworthy% getlabel /.MLD.tmp/.*
.SLD.0 PUBLIC [PUBLIC]
.SLD.1 Not owner
.SLD.2 Not owner
.SLD.4 PUBLIC [NEED TO KNOW ENG]

MLD の作成、変更、削除、MLD 内でのその他の操作

新しい MLD を作成したり、既存のディレクトリを MLD に変更したりするには、次の条件が必要です。

ユーザーが DAC および MAC の書き込み権を持っていること。
ユーザーが DAC アクセス権を持っており、ディレクトリに書き込むときに MAC をバイパスする承認を持っていること。
使うコマンドが、MAC および DAC の制限をバイパスするために必要な優先権を持っていること。

新しい MLD を作成するには、次の方法を使うことができます。

ファイルマネージャを使う。「ファイルマネージャを使って MLD を作成するには」を参照のこと。
mkdir コマンドを使う。「コマンド行から MLD を作成するには」を参照のこと。

任意のディレクトリを MLD に変更する方法については、次の節を参照してください。

「コマンド行から MLD を作成するには」

MLD の操作に関係するコマンドやオプションの一覧を表 2-6 に示します。各コマンドやオプションの詳細については、それぞれのマニュアルページを参照してください。

表 2-6 MLD の操作に関係するコマンド


MLD 関係のコマンドとオプション	説明
`adornfc` `dirname` `adornfc(1)` を参照のこと	ディレクトリのパス名を装飾された最終コンポーネントとともに表示します。［このコマンドは、MLD 接頭辞を持つパス名、その最終コンポーネントが MLD であるかどうか、その最終コンポーネントがディレクトリであるかどうかだけを表示するものであり、何の変更も行いません。］
`getfattrflag` `-m` `dirname` `getfattrflag(1)` を参照のこと	ディレクトリが MLD であるかどうかを表示します。
`getmldadorn` `filesystem_name` `getmldadorn(1)` を参照のこと	ファイルシステムの持つ MLD 接頭辞を表示します。
`getsldname` `filesystem_name` または `getsldname-ssensitivity_label` `filesystem_name` `getsldname(1)` を参照のこと	ファイルシステムの持つ SLD 名を表示します。現在のプロセスの持つラベルに対応する SLD 名を表示します。ファイルシステム内にある指定の機密ラベルを持つ SLD 名を表示します。
`mldpwd` `mldpwd(1)` を参照のこと	現在作業中のディレクトリのパス名を表示します。そのディレクトリが MLD であれば MLD 接頭辞が、SLD であれば SLD 名が表示されます。
`mldrealpath` `dirname` `mldrealpath(1)` を参照のこと	指定のディレクトリのパス名を表示します。そのディレクトリが MLD であれば MLD 接頭辞が、SLD であれば SLD 名が表示されます。
`rm(1)-RMMLD_dirname` `rmdir(1)` を参照のこと	指定の MLD 内にあるすべての SLD のうち、DAC および MAC アクセス権を持つものを再帰的に削除します。
`mkdir` `-Mdirname` または `mkdir` `.mld_prefix.dirname` `mkdir(1)` を参照のこと	新しい MLD を作成します。
`setfattrflag` `--m` existing_dirname `setfattrflag(1)` を参照のこと	既存のディレクトリを MLD に変更します。

上記のコマンドを使って、MLD、SLD、プロセスの持つ機密ラベルの関係を見てみましょう。図 2-2 に、ラベル CLASSIFIED を持つワークスペース上で pwd(1)、plabel(1)、mldpwd(1) コマンドを実行した場合の出力を示します。この例では、ユーザーのホームディレクトリ (/export/home/roseanne) は MLD であり、.SLD.2 は機密ラベル CLASSIFIED で作成された SLD です。図 2-2 において、通常のユーザーコマンドの pwd ではユーザーのホームディレクトリ名が表示されるだけですが、mldpwd コマンドを使うと、ユーザーが実際には .MLD.roseanne ディレクトリ内の .SLD.2 にいることが表示されます。「.SLD.2」という名前は SLD 番号 2 を持つため、この CLASSIFIED ラベルを持つ SLD は、3 番目に作成された SLD であることが分かります。

図 2-2 ホームディレクトリ内に作成された 3 番目の SLD の SLD 名

図 2-3 に、機密ラベル TOP SECRET を持つ端末上で pwd、plabel、mldpwd コマンドを実行した場合の出力を示します。「.SLD.3」という名前は SLD 番号 3 を持つため、この TOP SECRET ラベルを持つ SLD は、4 番目に作成された SLD であることが分かります。

図 2-3 ホームディレクトリ内に作成された 4 番目の SLD の SLD 名

ディレクトリが MLD であるかどうかを調べるには

一般ユーザーとして -m オプションのgetfattrflag(1) コマンドで引数にディレクトリ名を指定します (MLD 接頭辞は付けません)。

trusted% getfattrflag -m olddir
olddir: is a multilevel directory

ファイルマネージャを使って MLD を作成するには

「ファイル」メニューから「新規フォルダ」を選択します。

新しいディレクトリ名を入力します。

「ここをクリックすると、このフォルダが MLD になります。」というボタンをクリックします。

コマンド行から MLD を作成するには

mkdir(1) コマンドで、引数に MLD 接頭辞付きのディレクトリ名を指定します。

trusted% mkdir .MLD.newdir

または

mkdir コマンドで、-M オプションの後にディレクトリ名を指定します (MLD 接頭辞は付けません)。

trusted% mkdir -M newdir

または、既存のディレクトリを MLD に変更する場合には、

setfattrflag(1) コマンドで、-m オプションの後に既存のディレクトリ名を指定します。

trusted% setfattrflag -m oldir

MLDを特定するには

MLD を特定するには、次のような方法があります。

コマンド行から file(1B) コマンドを使います。

trustworthy% file /export/home/roseanne
/export/home/roseanne:multi-level directory

コマンド行から mldrealpath(1) コマンドを使います。

trustworthy%mldrealpath /export/home/roseanne 
/export/home/.MLD.roseanne

getfattrflag（1） コマンドで、-m オプションの後に既存のディレクトリ名を指定します。

$ getfattrflag -m /tmp
/tmp: is a multilevel directory

SLD を特定するには

コマンド行から、getsidname(1) コマンドを使い、MLD 名を指定します。

trustworthy% getsldname /home/roseanne
.SLD.2

MLD 内にいる場合は、mldpwd(1) コマンドを使います。

trustworthy% pwd 
/home/roseanne
trustworthy% 
mldpwd
/home/roseanne/.SLD.2

MLD 全体の内容を表示するには

ls(1) -R コマンドの引数に MLD 接頭辞を指定し、ディレクトリの内容を再帰的に表示させます。

$ ls -R /export/home/.MLD.admin/.SLD*

上記のコマンドの結果何が表示されるかは、現在のプロセスの持つラベルにより異なります。MLD 全体の内容を参照することは、tar を使ってそのディレクトリをバックアップテープにコピーする場合に便利です。

MLD を削除するには

注 -

MLD を削除可能にするには、そのMLD 内にあるすべての SLD と、その SLD の内容をすべて削除しておく必要があります。

自分の認可上限内で最上位のラベルを持つワークスペースを立ち上げます。

すべての SLD およびその内容で自分のアカウントの機密ラベル範囲にあるものを削除するには、次のいずれかを実行します。
1. ファイルマネージャで、テキスト入力フィールドに MLD の装飾名を入力し、「ファイル (File)」メニューから「行先指定 (Go To)」を選択します。
2. 「表示 (View)」メニューから「隠しオブジェクトも表示」を選択します。
  
  MLD 内のすべての SLD をドラッグしてごみ箱に移動するか、すべての SLD を選択した後、「選択」メニューから「ごみ箱に捨てる」を選択します。
  
  次の図に、ファイルマネージャで、MLD 装飾名 (/.MLD.tmp,) を指定して /tmp ディレクトリの内容を表示させた状態を示します。「表示 (View)」メニューから「隠しオブジェクトも表示」を選択しているので、すべての SLD (.SLD.1、.SLD.2、など) が表示されています。

コマンド行で、rm(1) コマンドを -RMf オプション付きで実行すると、MLD、およびそれが含む SLD、その SLD の内容のすべてを削除できます。
$ rm -RMf MLD_dirname

パート I すべての作業と管理役割に共通の操作手順

第 1 章 特定の役割への移行と役割ワークスペースでの作業

管理役割と非管理役割の概念

管理役割

非管理役割

ログインと役割への移行

管理的アクションの監査

ログインを有効にするには

図 1-1 承認を持たないユーザーに表示される無効なログインを通知するダイアログボックス

図 1-2 「ログインを有効化」承認を持つユーザーに表示される無効なログインを通知するダイアログボックス

リブート後のログイン無効化を防ぐには

リモート管理オプション

リモートホスト上での CDE ログインセッションの起動

管理役割の実行

図 1-3 ワークスペースのメニューまたは TP Menu からの 役割になるためのオプションの選択

管理役割ワークスペースでの作業

図 1-4 管理役割 admin 用のボタンがあるワークスペースのスイッチ領域

図 1-5 管理用のワークスペースのメニューからの役割ワークスペースの新規作成

アプリケーションマネージャ内のフォルダとアクションのアイコン

「Solstice アプリケーション (Solstice_Apps)」アプリケーションフォルダ内の管理ツールの使用

「読み込み (Load)」ダイアログの使用

「システム管理 (System_Admin)」アプリケーションフォルダ内の管理アクションの使用

アプリケーションマネージャの呼び出し

図 1-6 「アプリケーションマネージャ (Application Manager)」アイコンと「アプリケーションマネージャ (Application Manager)」フォルダ

リモートホストからのアプリケーションマネージャの起動

dtappsession を使うための前提条件

dtappsession によるリモートの Trusted Solaris ホストの管理

「システム管理 (System_Admin)」フォルダ内の管理アクション

コマンドとアクションへのアクセス

プロファイルシェルを使ったその他の作業の実行

管理用 vi

管理役割に特有の操作手順

ログイン後、特定の管理役割になるには

管理役割ワークスペースと通常のユーザーワークスペース間の切り替えを行うには

セキュリティ属性を持つプロファイルとコマンドの一覧を表示するには

dtappsession で Trusted Solaris ホストをリモート管理するには

管理役割になっている間に、複数ラベルで作業するには

管理アプリケーションを起動するには

管理アクションを起動するには

管理用エディタアクションを使用してファイルを編集するには

管理ファイルを編集する新しい管理アクションを作成するには

「システム管理 (System_Admin)」フォルダの外側にアクションを追加するには

リブート後のログイン無効化を防ぐには

第 2 章 その他の作業と操作手順

セキュリティの条件

セキュリティの条件に関するユーザーの研修

すべてのユーザーの規則

ユーザーアカウントと役割アカウントのセキュリティ

情報の保護

パスワードの保護

グループの作成

ユーザーの削除

グループの削除

フロントパネルの変更

ワークスペースメニューの変更

ワークスペースメニューを変更するには

ファイルと選択のアップグレードとダウングレードの規則の変更

図 2-1 ファイルマネージャ選択確認ダイアログ

選択管理の概念について

sel_config ファイルセクション

自動確認セクション

自動応答セクション

sel_config のデフォルトの設定

例 2-1 sel_config 選択確認ファイル

選択構成ファイルを変更するには

変更した構成ファイルのネットワーク上のホストへの配布

構成ファイルをリモート操作で配布するには

キーボードアボートの有効化

パスワード入力ミス許容回数の最大値の変更

パスワード入力ミス許容回数の最大値を変更するには

構成ファイルへのラベルの入力

ラベルおよび認可上限の 16 進値を求めるには

ラベルに対応する 16 進値を求めるには

拡張可能なセキュリティ機能の追加

承認の基本概念

例 2-2 tsolprof エントリの例

例 2-3 管理役割アカウント用の tsoluser エントリ内に示されたプロファイル

Trusted Solaris 承認の拡張

auth_names.h

例 2-4 auth_names.h に定義されている * TSOL_AUTH 承認

第 1 章特定の役割への移行と役割ワークスペースでの作業

図 1-3 ワークスペースのメニューまたは `TP Menu` からの役割になるためのオプションの選択

管理用 `vi`

第 2 章その他の作業と操作手順

例 2-1 `sel_config` 選択確認ファイル

例 2-2 `tsolprof` エントリの例

例 2-3 管理役割アカウント用の `tsoluser` エントリ内に示されたプロファイル

`auth_names.h`

例 2-4 `auth_names.h` に定義されている * `TSOL_AUTH` 承認

例 2-5 `auth_names.h` に定義されている `tsol_auth_reserved` 承認

`auth_name`(4)

例 2-7 `auth_name` ファイルの書式

例 2-8 `auth_name` ファイル内に定義した「ログインを有効化」承認

`priv_names.h`

例 2-9 `priv_names.h` に定義されているデフォルトの特権の宣言定数と番号

例 2-12 `priv_name` ファイル内に定義した「file_audit」という名前を持つ特権