test

Trusted Solaris 管理の手順

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

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

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

セキュリティの条件

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

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

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

すべてのユーザーの規則

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

セキュリティ管理者役割は、各アカウントに対する最初のパスワードを指定します。セキュリティ管理者役割が選択したパスワードは、表 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

 

所有者

グループ

アクセス権

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 を持っていることを確認しておく必要があります。

ユーザーの削除

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

グループの削除

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

フロントパネルの変更

デフォルトでは、セキュリティ管理者役割は管理エディタアクションを持つ唯一の役割です。そして、セキュリティ管理者役割は、「フロントパネル (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 の警告が出ます。

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

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

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

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

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

注 -

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

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

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

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

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

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

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

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

Graphic

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

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

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

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

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

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

  4. 変更を行った後、ファイルを保存して終了します。


    :wq
    注 -

    変更は、次回任意のユーザーがログインしたときから有効になります。

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

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

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

注 -

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

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

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

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

    下記の例は、rdist(1) が label_encodings と system ファイルを一覧表示された分散システムの全ホストに配布するように distfile を設定したものです。


    HOSTS = ( machiavelli muckraker mugwump diehard warhorse )
FILES = ( /etc/security/tsol/label_encodings /etc/system )
${FILES} -> ${HOSTS}	install ;

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


    :wq

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

    rdist は、distfile と同じディレクトリで実行することができます。また、他の名前を付けた別のファイルのフルパス名に続けて -f オプションを使用することもできます。


    # rdist 	/* OR */
# rdist -f /home/machiavelli/jedgar/label_encodings.master/distfile.sample

    rdist(1) と hosts.equiv(4) の マニュアルページも参照してください。

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

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

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 名分のアカウントは、「常に開く」に設定すべきです。

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

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

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

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

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

  3. 文字列 RETRIES を検索します。


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

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

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


    :wq!

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

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

注 -

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

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

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

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

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

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

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

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

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


    $ atohexlabel -s SECRET
0x00060c0000000000000000000000000000000000000000000003ffffffffffff0000

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


    $ atohexlabel -c SECRET
0x00060c0000000000000000000000000000000000000000000003ffffffffffff0000

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

セキュリティ管理役割が追加することのできる 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 はロケール名を示しています)。

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 のご購入先に連絡をとり、承認番号の予約をとってください。

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

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

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

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

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


    AUTH_POWER = 127,	 /* To leap tall MAC check failures and otherwise be irresponsible and
unaccountable*/

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


    :wq

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

  6. ファイル 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.

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


    :wq

Trusted Solaris 特権の拡張

新しい特権を追加するには、その特権のためのエントリを次の 2 つのファイルに追加する必要があります(locale_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 のご購入先に連絡をとり、特権番号の予約をとってください。

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

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

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

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

  3. 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.

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

    入力例を次に示します。


    PRIV_RISKY = 90,

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


    :wq

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

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

  7. ファイル 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.

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


    :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 ではなく、通常のユーザーが書き込みできる新しいディレクトリを作成する必要があります。

たとえば、あるサイトの管理者役割が /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 に変更したりするには、次の条件が必要です。

新しい 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 名

Graphic

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

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

Graphic

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

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


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

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

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

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

  3. 「ここをクリックすると、このフォルダが 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 の内容をすべて削除しておく必要があります。

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

  2. すべての SLD およびその内容で自分のアカウントの機密ラベル範囲にあるものを削除するには、次のいずれかを実行します。

    1. ファイルマネージャ で、テキスト入力フィールドに MLD の装飾名を入力し、「ファイル (File)」メニューから「行先指定 (Go To)」を選択します。

    2. 「表示 (View)」メニューから「隠しオブジェクトも表示」を選択します。

      MLD 内のすべての SLD をドラッグしてごみ箱に移動するか、すべての SLD を選択した後、「選択」メニューから「ごみ箱に捨てる」を選択します。

      次の図に、ファイルマネージャで、MLD 装飾名 (/.MLD.tmp,) を指定して /tmp ディレクトリの内容を表示させた状態を示します。「表示 (View)」メニューから「隠しオブジェクトも表示」を選択しているので、すべての SLD (.SLD.1、.SLD.2、など) が表示されています。

      Graphic

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


    $ rm -RMf MLD_dirname