test

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

第 25 章 BSM サービスの参照

この章では、BSM モジュール、監査、およびデバイス割り当ての重要な構成要素について説明します。

監査を使用して、システムが通常と異なる方法で使用されていないかどうかを検査すると、潜在的なセキュリティ違反を検出することができます。また、通常と異なる動作を追跡して、特定のユーザーを突き止めることができるため、セキュリティ違反を抑えることができます。つまり、ユーザーは自分の動作が監査されそうだと考えると、違反行為を思いとどまる可能性が大きくなります。

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

監査コマンド

この節では、監査サービスで使用されるコマンドについて説明します。

監査デーモン

次に、監査デーモン auditd の機能を一覧表示します。

auditd デーモンは、マシンがマルチユーザーモードになると自動的に起動されますが、コマンド行から起動することもできます。監査デーモンが起動すると、デーモンは監査ログファイルに必要な空き容量を判断します。

監査デーモンは、audit_control ファイル内に指定されている監査ディレクトリに、監査ファイルを作成します。監査デーモンは、このディレクトリの一覧へのポインタを、最初のディレクトリに位置付けます。監査デーモンが監査ファイルを作成する必要があるたびに、監査デーモンはその現在のポインタから始めて、監査ファイルをリスト内の最初の使用可能ディレクトリに入れます。このポインタを一覧の最初のディレクトリに設定し直すには、audit -s コマンドを実行します。audit -n コマンドを使用して、新しい監査ファイルに切り替えるようにデーモンに指示すると、新しいファイルは現在のファイルと同じディレクトリ内で作成されます。

audit コマンド

audit コマンドは、監査デーモンの動作を制御します。audit コマンドは、次の操作を実行できます。

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

auditreduce コマンド

auditreduce コマンドを使用すると、1 つまたは複数の入力監査ファイルから監査レコードをマージしたり、監査レコードの事後選択を実行できます。auditreduce(1M) のマニュアルページを参照してください。監査トレール全体をマージするには、すべての監査ファイルシステムがマウントされているマシン上で、auditreduce コマンドを実行します。

auditreduce コマンドを使用すると、複数のマシン上のすべての監査対象動作を、1 か所から追跡できます。監査機能をインストールするときにすべてのマシンを同じ構成にし、監査ログファイルのサーバーとローカルディレクトリを作成しておくと、auditreduce コマンドはインストール中にすべての監査ファイルを論理的に結合して、1 つの監査トレールとして読み取ることができます。auditreduce では、レコードのマージ方法や格納場所は無視されます。auditreduce コマンドにオプションを指定しなかった場合は、監査ルートディレクトリ (/etc/security/audit) のすべてのサブディレクトリにあるすべての監査ファイルの監査レコードがマージされ、その結果が標準出力に送られます。マージされた監査レコードは、時系列に並べて 1 つの出力ファイルに格納することもできます。このファイルの形式はバイナリデータです。

auditreduce コマンドを使用して、特定の種類のレコードを選択し、解析に利用することもできます。auditreduce のマージ機能と選択機能は論理的にほかに依存しません。auditreduce は、入力ファイルのレコードを読み取ると、マージしてディスクに書き込む前に、データを抽出します。

praudit コマンドは、auditreduce のバイナリ出力を、読み込み可能な書式に変換します。

auditreduce コマンドにオプションを指定すると、次の操作も実行できます。

auditreduce に引数を指定しなかった場合は、デフォルトの監査ルートディレクトリ /etc/security/audit 内のサブディレクトリが検査されます。このコマンドは、start-time.end-time.hostname ファイルが配置されている files ディレクトリを検査します。auditreduce コマンドは、さまざまなホスト (図 25-1) または監査サーバー (図 25-2) の監査データが異なるディレクトリに格納されているときに使用します。

図 25-1 ホストごとに格納された監査トレール

Graphic

図 25-2 サーバーごとに格納された監査トレール

Graphic

/etc/security/audit のパーティションが小さいため、監査データをデフォルトのディレクトリに格納しない場合は、-R オプションを使用して auditreduce コマンドを別のディレクトリに渡すことができます。


# auditreduce -R /var/audit-alt

-S オプションを使用して、特定のサブディレクトリを指定することもできます。


# auditreduce -S /var/audit-alt/host1

特定の監査ログファイルだけを処理するには、auditreduce にそのファイルをコマンド引数として直接指定できます。


# auditreduce /var/audit/egret/files/2001*.2001*egret

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

praudit コマンド

praudit コマンドは、標準入力からバイナリ形式の監査レコードを読み込み、そのレコードを表示可能な書式で表示します。auditreduce コマンドまたは 1 つの監査ファイルからの出力は、praudit コマンドの入力にパイプできます。catコマンドを使用すると、複数のファイルを連結して入力にパイプすることができます。tail コマンドを使用すると、現在の監査ファイルを入力にパイプできます。

praudit コマンドでは、次の 4 つの出力形式を生成できます。

praudit のデフォルトの出力形式では、各レコードは監査トークンのシーケンスとして表示されます。各トークンは 1 行ごとに出力されます。すべての監査レコードは header トークンで始まります。awk コマンドなどを使用すると、出力をさらに処理できます。

次の出力は、 headerトークンを praudit コマンドのデフォルトで出力したものです。


header,240,1,ioctl(2),es,Tue Sept  7 16:11:44 1999, + 270 msec

次の出力は、同じ header トークンを praudit -r コマンドで出力したものです。 


20,240,1,158,0003,699754304, + 270 msec

praudit コマンドの出力は、必要に応じてテキストとして操作できます。たとえば、auditreduce コマンドでは選択できないレコードを選択したいことがあります。単純なシェルスクリプトを使用すると、praudit の出力を処理できます。次の単純なスクリプトの例では、header トークンに Control-A の接頭辞を付け、1 つのレコードのすべての監査トークンを 1 行に結合します。このとき、改行は Control-A として保持されます。次に、grep コマンドを実行して、元の改行を復元します。


#!/bin/sh
praudit | sed -e '1,2d' -e '$s/^file.*$//' -e 's/^header/^aheader/' \\
| tr '\\012\\001' '\\002\\012' \\
| grep "$1" \\
| tr '\\002' '\\012'

スクリプトの ^a は、^ と a という 2 つの文字ではなく、Control-A です。この接頭辞によって、ヘッダートークンが、テキストとして表示される header 文字列と区別されます。

auditconfig コマンド

auditconfig コマンドは、監査構成パラメータを取得して設定するためのコマンド行インタフェースを提供します。auditconfig(1M) のマニュアルページを参照してください。auditconfig コマンドには、次のオプションを指定できます。

-chkconf

カーネルイベントとクラスの割り当ての構成を検査し、不一致を報告します。

-conf

カーネルイベントとクラスの割り当てが、audit_event ファイル内の現在の割り当てと一致するように実行時に構成し直します。

-getcond

マシンの監査の状態を取得します。次の表に、応答コード例を示します。

表 25-1 監査状態の例

応答コード 

意味 

auditing

監査が有効でオンに設定されている 

no audit

監査は有効だが、監査デーモンは動作していない 

disabled

監査が無効になっている 

-setcond condition

マシンの監査状態をauditing または noaudit に設定する

-getclass event_number

指定するイベントが割り当てられている事前選択クラスを取得する

-setclass event_number audit_flags

指定するイベントが割り当てられる事前選択クラスを設定する

-lsevent

現在構成されている (実行時) カーネルとユーザー監査イベント情報を表示する

-getpinfo pid

指定するプロセスの監査 ID、事前選択マスク、端末 ID、監査セッション ID を取得する

-setpmask pid flags

指定するプロセスの事前選択マスクを設定する

-setsmask asid flags

指定する監査セッション ID を持つすべてのプロセスの事前選択マスクを設定する

-setumask auid flags

指定するユーザー監査 ID を持つすべてのプロセスの事前選択マスクを設定する

-lspolicy

監査ポリシーの一覧と、各ポリシーの簡単な説明を表示する

-getpolicy

現在の監査ポリシーフラグを表示する

-setpolicy policy_flag[, policy_flag]

監査ポリシーフラグを、指定するポリシーに設定する ( 「使用する監査ポリシーの決定」を参照)

監査ファイル

監査プロセスでは、次のファイルが使用されます。

/etc/system ファイル

/etc/system ファイルには、カーネルが初期設定で読み込み、システム動作をカスタマイズするためのコマンドが格納されます。bsmconv および bsmunconv シェルスクリプトは、監査機能を起動および終了するときに使用され、/etc/system ファイルを変更します。bsmconv シェルスクリプトは、/etc/system ファイルに次の行を追加します。


set c2audit:audit_load=1
set abort_enable=0

最初のコマンドは、システムのブート時に、読み込み可能なカーネルモジュール (監査モジュール) c2audit を読み込みます。2 番目のコマンドは、Stop-A を使用不可にします。Stop-A を使用すると、システムを停止して、デバッガが起動し、セキュリティ違反が発生する可能性があります。bsmunconv シェルスクリプトでは、2 つの行を削除し、システムをリブートすると監査が無効になります。

audit_class ファイル

audit_class ファイルには、既存の監査クラスの定義が含まれます。監査クラスは、監査イベントのグループです。各監査クラスには、クラスの短縮名として監査フラグが関連付けられます。audit_control ファイル内のこの短縮名を使用して、監査するイベントのクラスを事前選択します。このとき、+ または - を接頭辞として使用します。スーパーユーザー、またはそれと同等の役割を持つ管理者は、新しい監査クラスを定義したり、既存のクラス名を変更したりすることができます。また、vi、ed などのエディタを使用して、既存のクラスを編集することもできます。詳細は、audit_class(4)のマニュアルページを参照してください。監査フラグについては、「監査フラグの定義」を参照してください。

audit_controlファイル

各マシン上の audit_control ファイルは、監査デーモンによって読み込まれます (audit_control(4) のマニュアルページを参照)。audit_control ファイルは /etc/security ディレクトリにあります。各マシンには固有の audit_control ファイルがローカルに割り当てられるため、監査ファイルシステムはさまざまな場所からさまざまな順序でマウントできます。たとえば、マシン A の一次監査ファイルシステムは、マシン B の二次監査ファイルシステムであることがあります。

audit_control ファイルには、次の 4 種類の情報を指定します。

audit_controlファイルは、各マシンを構成するときに作成されます。

audit_control ファイルを変更したときは、audit -s を実行すると、監査デーモンによってファイルが再度読み取られます。

注 -

audit -s コマンドでは、既存のプロセスについて指定された事前選択マスクは変更されません。既存のプロセスについては auditconfig、setaudit (getaudit(2) のマニュアルページを参照)、または auditon を使用します。

audit_control ファイルの例

次の例は、マシン dopey で使用する audit_control ファイルです。dopey では、監査サーバー blinken 上で 2 つの監査ファイルシステムを使用し、2 つ目の監査サーバー winken からマウントされる 3 つ目の監査ファイルシステムを使用します。3 つ目のファイルシステムは、blinken 上の監査ファイルシステムがいっぱいであるか使用できないときにだけ使用されます。20% に指定された minfree の値は、ファイルシステムが 80% まで使用され、次に利用できる監査ディレクトリがあればそこに現在のマシンの監査データが格納される場合に、警告スクリプトを実行するように指示します (audit_warn(1M) のマニュアルページを参照)。このフラグによって、すべてのログインと管理操作が正常に終了するかどうかにかかわらず監査されることと、ファイルシステムオブジェクトの作成に失敗した場合を除き、すべての種類の失敗が監査されることが指定されます。 


flags:lo,ad,-all,^-fc
naflags:lo,nt
minfree:20
dir:/etc/security/audit/blinken/files
dir:/etc/security/audit/blinken.1/files
#
# Audit filesystem used when blinken fills up
#
dir:/etc/security/audit/winken

audit_data ファイル

auditd デーモンは、各マシン上で起動されると、ファイル /etc/security/audit_data を作成します。このファイルの書式は、1 つのエントリに、コロンで区切られた 2 つのフィールドで構成されます (audit_data(4) のマニュアルページを参照)。最初のフィールドには、監査デーモンのプロセス ID を指定します。2 番目のフィールドには、監査デーモンが監査レコードを現在書き込んでいる監査ファイルのパス名を指定します。次に例を示します。 


# cat /etc/security/audit_data
116:/etc/security/audit/blinken.1/files/19990320100002.not_terminated.dopey

audit_event ファイル

audit_event ファイルは、/etc/security ディレクトリに配置され、イベントとクラスのデフォルトの割り当てが格納されます (audit_event(4)のマニュアルページを参照)。このファイルを編集して、クラスの割り当てを変更できます。ただし、変更した場合は、システムをリブートするか auditconfig -conf を実行して、変更した割り当てをカーネルに読み込む必要があります。

audit_startup スクリプト

監査を使用可能にするには、監査デーモン auditd を起動します。監査デーモンを起動するには、スーパーユーザーまたは同等の役割を持って /usr/sbin/auditd を実行します。詳細については、auditd(1M)のマニュアルページを参照してください。

ファイル /etc/security/audit_startup が存在する場合、システムがマルチユーザーモードに移行すると、自動的に監査デーモンが動作します。このファイルは、監査デーモンを実行する前に起動シーケンスの一部として起動される実行可能スクリプトです (audit_startup(1M) のマニュアルページを参照)。デフォルトの audit_startup スクリプトは、イベントとクラスの割り当てを自動的に構成して、BSM パッケージをインストールしたときに作成された監査ポリシーを設定します。

audit_user ファイル

ユーザーごとに異なる方法で監査するには、audit_user ファイルを編集して、ユーザーごとに監査フラグを追加します。これらの監査フラグが指定されている場合は、audit_control ファイルのシステム全体で有効なフラグと組み合わせ、そのユーザーに対して監査するイベントクラスが決定されます。audit_user ファイル内のユーザーエントリに追加するフラグは、audit_control ファイルにあるデフォルトを次の 2 つの方法で変更します。

audit_user ファイルの各ユーザーエントリには、次の 3 つのフィールドがあります。

これらの監査フィールドは、この順番で処理されます。監査機能を有効にするときは、 always-audit フィールドを使用し、無効にするときは、never-audit フィールドを使用します。

注 -

never-audit フィールド内で all 監査フラグを設定したままにする誤りがよくあるので注意してください。all 監査フラグを指定したままにすると、そのユーザーの監査がすべてオフに設定され、always-audit フィールドに設定されているフラグが無効になります。

ユーザーに never-audit フラグを使用することと、always-audit の設定からクラスを削除することとは異なります。たとえば、ファイルシステムオブジェクトが正常に読み込まれた場合を除いて、ユーザー tamiko のすべてのイベントを監査するとします。この場合、ユーザー tamiko のほとんどのイベントが監査されます。ただし、監査データは、すべてのデータ読み込みを監査した場合の約 4 分の 3 しか生成されません。システムデフォルトを tamiko に適用することもできます。次に 2 つの audit_user エントリを示します。

正しいエントリ


tamiko:all,^+fr:

間違ったエントリ


tamiko:all:+fr

1 つ目の例は、「ファイルの読み込みが成功した場合を除き、常にすべての動作を監査する」ことを表しています。2 つ目の例は、「常にすべての動作を監査するが、ファイルの読み込みに成功した場合はまったく監査しない」ことを表しています。2 つ目の例はシステムのデフォルト値が無効になるため、正しいエントリではありません。1 つ目の例では期待どおりの結果になります。つまり、audit_user エントリで指定した内容の他に、システムデフォルト値が適用されます。

注 -

正常終了したイベントと失敗したイベントは別々に取り扱われるので、プロセスが生成する監査レコードのボリュームは、そのイベントが正常終了したときよりも、失敗したときの方が多くなることがあります。

audit_warn スクリプト

監査デーモンは、監査レコードの書き込み中に異常な状態が発生すると、/etc/security/audit_warn スクリプトを起動します。詳細については、audit_warn(1M) のマニュアルページを参照してください。このスクリプトを環境に合わせてカスタマイズして、手動による割り込みを要求する警告を発行したり、自動的に実行する処理を指定したりできます。どのエラーの場合も、audit_warn はメッセージをコンソールに書き込み、audit_warn メールの別名にメールを送ります。監査を有効にしたときは、この別名を設定する必要があります。

監査デーモンは、次の状態を検出すると、 audit_warn スクリプトを起動します。

監査フラグ

監査フラグは監査対象となるイベントのクラスを示します。マシン全体で有効な監査関連のデフォルト値は、audit_control ファイル内のフラグによって各マシン上のすべてのユーザーに指定されます。詳細については、「audit_controlファイル 」を参照して下さい。

監査フラグを audit_user ファイルにあるユーザーエントリに入れることにより、各ユーザーについて監査を行う対象を変更できます。また、監査フラグは、auditconfig コマンドの引数として使用できます (auditconfig(1M) のマニュアルページを参照)。

監査フラグの定義

次の表に、事前に定義されている各監査クラスについて、監査フラグ (クラスを表す短縮名)、ロング名、および簡単な説明の一覧を示します。監査するイベントのクラスを指定するときは、監査構成ファイルの監査フラグを使用します。新しいクラスを定義したり、既存のクラス名を変更したりするときは、audit_class ファイルを変更します (audit_class(4)のマニュアルページを参照)。

表 25-2 監査フラグ

短縮名 

ロング名 

短い説明 

no

no_class

イベントの事前選択を無効にする空の値

fr

file_read

データを読み取る、読み取りのために開く 

fw

file_write

データを書き込む、書き込みのために開く 

fa

file_attr_acc

オブジェクト属性にアクセスする : stat、 pathconf

fm

file_attr_mod

オブジェクト属性を変更する : chown、 flock

fc

file_creation

オブジェクトの作成 

fd

file_deletion

オブジェクトの削除 

cl

file_close

close システムコール

pc

process

プロセスの操作: fork、 exec、exit

nt

network

ネットワークイベント: bind, connect , accept

ip

ipc

System V の IPC 操作

na

non_attrib

ユーザーが原因ではないイベント 

ad

administrative

管理上の操作 

lo

login_logout

ログインとログアウトのイベント 

ap

application

アプリケーションが定義するイベント 

io

ioctl

ioctl システムコール

ex

exec

プログラムの実行 

ot

other

その他 

all

all

全フラグのセット

監査フラグの構文

接頭辞に応じて、イベントのクラスは、成功したまたは失敗した場合、成功した場合のみ、または、失敗した場合のみ、監査を行うことができます。監査フラグの書式は次のとおりです。

prefixflag

次の表に、成功した場合、失敗した場合、またはその両方の場合に、監査クラスを監査するかどうかを指定する接頭辞を示します。

表 25-3 監査フラグに使用する接頭辞

接頭辞 

定義 

なし

成功と失敗の両方の場合に監査する 

+

成功の場合のみ監査する 

-

失敗の場合のみ監査する 

たとえば、監査フラグ lo (接頭辞なし) を指定した場合は、ログインとログアウトのすべての成功、およびすべてのログインの失敗について、監査が発生します。ログアウトの失敗は想定していません。また、-all フラグを指定した場合は、あらゆる種類の失敗について監査が発生します。+all フラグを指定した場合は、あらゆる種類の成功について監査が発生します。

注意 - 注意 -

-all フラグを指定すると、大量のデータが生成され、すぐに監査ファイルシステムがいっぱいになることがあります。-all フラグは、特別な理由ですべての活動を監査する場合にだけ使用してください。

監査フラグを変更する接頭辞

次の表の接頭辞を次の 3 つの方法のいずれかで使用します。

詳細については、auditconfig(1M) のマニュアルページを参照してください。

次の表に示す接頭辞を監査クラスの短縮名とともに使用して、指定済みの監査クラスの設定をオンまたはオフにします。

表 25-4 指定済みの監査フラグを変更する接頭辞

接頭辞 

定義 

^-

失敗した試みに対する監査をオフにする 

^+

成功した試みに対する監査をオフにする

^

成功した試みと失敗した試みの両方に対して監査をオフにする 

^- 接頭辞は、次の例のように audit_control ファイルの flags 行で使用します。

次の例では、lo フラグと ad フラグが、すべてのログインと管理操作について成功と失敗の両方の場合に、監査することを指定します。-all は「失敗したすべてのイベント」を監査することを意味します。^- 接頭辞は「指定したクラスの、失敗した試みについて監査の設定をオフにする」ため、^-fc フラグは、失敗したすべてのイベントの監査を指定した以前のフラグを変更します。この 2 つのフィールドを指定すると、ファイルシステムオブジェクトの作成に失敗した場合を除いて、失敗したすべてのイベントが監査されます。 


flags:lo,ad,-all,^-fc

監査ポリシー

監査ポリシーには、監査トレールにトークンまたは情報を追加するかどうかを指定します。監査ポリシーについては、「使用する監査ポリシーの決定」 を参照してください。

プロセスの監査特性

最初のログイン時に次の監査特性が設定されます。

監査トレール

監査トレールは監査デーモンによって作成されます (詳細は、auditd(1M) のマニュアルページを参照)。監査デーモンは、マシンが起動されるとその各マシン上で起動されます。auditd デーモン は、ブート時に起動されると、監査トレールデータを収集し、監査レコードを監査ファイルに書き込む処理を受け持ちます。このファイルを監査ログファイルとも呼びます。ファイルの書式については、audit.log(4) のマニュアルページを参照してください。

監査ディレクトリは、監査専用でない他のファイルシステム内に物理的に配置することもできますが、予備のディレクトリを除き、この配置は行わないでください。予備のディレクトリとは、他の適切なディレクトリが使用できないときに限り、監査ファイルが書き込まれるディレクトリです。

次の場合にも、監査ディレクトリを監査専用でないファイルシステムに配置することができます。つまり、監査がオプションで提供されるソフトウェア開発環境で、監査トレールを保存せずに、ディスク容量をすべて使用することを優先する場合です。セキュリティが重視される実行環境では、監査ディレクトリを他のファイルシステム内に入れることは許可されません。

また、次の点も考慮する必要があります。

監査ファイルの詳細

各監査ファイルは、それ自体で意味がわかるレコードの集合です。ファイル名には、レコードが生成された時間の範囲と、それを生成したマシン名が含まれます。

監査ファイルの命名

完全な監査ファイルには、次の書式の名前が付いています。 


start-time.finish-time.machine

start-time は、監査ファイル内の最初の監査レコードが生成された時刻です。finish-timeは、最後のレコードがファイルに書き込まれた時刻です。machine は、ファイルを生成したマシン名です。監査ファイル名の例については、「閉じられた監査ファイル名の例」を参照してください。

監査ログファイルが動作中である場合は、次の書式の名前が付いています。 


start-time.not_terminated.machine

監査ファイル名の使用方法

auditreduce コマンドは、ファイル名のタイムスタンプを使用して、要求された特定期間内のレコードが入ったファイルを検索します。たとえば、1 か月以上蓄積された監査ファイルの全レコードから、24 時間以内に生成されたレコードを検索する場合、タイムスタンプを使用しなければ、検索時間が大幅に増大することになるため、タイムスタンプは重要な意味を持ちます。

タイムスタンプの書式と説明

start-time と end-time は 1 秒単位のタイムスタンプです。これらのタイムスタンプは、グリニッジ標準時 (GMT) で指定されます。タイムスタンプの書式は、次のように年が 4 桁で、2 桁ずつの月、日、時、分、秒があとに続きます。 


YYYYMMDDHHMMSS

タイムスタンプには GMT が使用されるため、夏時間によるずれがあっても正しい順序でソートされることが保証されます。また、日時を把握しやすいように現在の時間帯に変換する必要があります。監査ファイルを auditreduce コマンドではなく標準ファイルコマンドで操作するときには、この点に注意してください。

動作中のファイル名の例

動作中のファイル名の書式は次のとおりです。 


YYYYMMDDHHMMSS.not_terminated.machine

次に例を示します。


19990327225243.not_terminated.dopey

監査ログファイルの名前には、開始日が使用されます。上記の例の監査ファイルは、GMT の1990 年 3 月 27 日午後 10:52:43 に作成されています。ファイル名のうち not_terminated は、このファイルがまだ動作中であるか、または auditd デーモンが予期しない割り込みを行なったことを意味します。末尾の名前 dopey は、監査データが収集されているマシンのホスト名です。

閉じられた監査ファイル名の例

閉じられた監査ログファイル名の書式は次のとおりです。 


YYYYMMDDHHMMSS.YYYYMMDDHHMMSS.hostname

次に例を示します。


19990320005243.19900327225351.dopey

この例の監査ログファイルは、GMT の 1999 年 3 月 20 日の午前 12:52:43 に作成されています。このファイルは、GMT の 3 月 27 日午後 10:53:51 に閉じられました。末尾の名前 dopey は、監査データが収集されたマシンのホスト名です。

auditd が予期しない割り込みを行うと、その時点で開いている監査ファイル名には not_terminated が付きます。また、マシンがリモートでマウントされた監査ファイルに書き込んでいるときに、ファイルサーバーがクラッシュするか、またはアクセスできなくなると、not_terminated が現在のファイル名に付いたままになります。監査デーモンは、古い監査ファイル名の監査ファイルをそのまま残して新しい監査ファイルを開きます。

監査レコードの構造

監査レコードは、一連の監査トークンです。監査トークンには、ユーザー ID、時刻、日付などのイベント情報が入っています。header トークンは監査レコードで始まり、オプションの trailer トークンで終わります。ほかの監査トークンには、監査可能なイベントに関連する情報が入っています。次の図は、標準的な監査レコードを示しています。

図 25-3 標準的な監査レコードの構造

Graphic

監査トークンの形式

各トークンにはトークンの種類識別子とそのあとにトークン固有のデータが続いています。各トークンの種類には固有の形式があります。次の表は、各トークンの名前と説明の一覧です。

表 25-5 基本セキュリティモジュール (BSM) の監査トークン

トークン名 

説明 

参照先 

acl

アクセス制御リスト情報 

「acl トークン」

arbitrary

書式情報と型情報が付いたデータ 

「arbitrary トークン」

arg

システムコールの引数値 

「arg トークン」

attr

ファイル vnode トークン

「attr トークン」

exec_args

exec システムコールの引数

「exec_args トークン」

exec_env

exec システムコールの環境変数

「exec_env トークン」

exit

プログラム終了情報 

「exit トークン」

file

監査ファイル情報 

「file トークン」

groups

プロセスグループ情報 (現在は使用しない) 

「groups トークン (現在は使用しない)」

header

監査レコードの始まりを示す 

「header トークン」

in_addr

インターネットアドレス 

「in_addr トークン」

ip

IP ヘッダー情報 

「ip トークン」

ipc

System V IPC 情報 

「ipc トークン」

ipc_perm

System V IPC オブジェクトトークン 

「ipc_perm トークン」

iport

インターネットポートアドレス 

「iport トークン」

newgroups

プロセスグループ情報 

「newgroups トークン」

opaque

構造化されていないデータ (形式が未指定) 

「opaque トークン」

path

パス情報 

「path トークン」

process

プロセスのトークン情報 

「process トークン」

return

システムコールの状態 

「return トークン」

seq

シーケンス番号トークン 

「seq トークン」

socket

ソケットの種類とアドレス 

「socket トークン」

subject

サブジェクトのトークン情報 (process トークンと同じ書式)

「subject トークン」

text

ASCII 文字列 

「text トークン」

trailer

監査レコードの終わりを示す 

「trailer トークン」

監査レコードには、必ず header トークンが入っています。header トークンは、監査トレール内で監査レコードの始まりを示します。ユーザーの動作に起因しないイベントからの監査レコードを除き、どの監査レコードにも subject トークンが入っています。ユーザーに起因するイベントの場合、この 2 つのトークンはイベントを引き起こしたプロセスの値を参照します。非同期イベントの場合、process トークンはシステムを参照します。

acl トークン

acl トークンレコードには、アクセス制御リストに関する情報を記録します。次の 4 つの固定フィールドがあります。

praudit コマンドでは、acl トークンは次のように表示されます。


acl,tpanero,staff,0755

次の図に acl トークンの形式を示します。

図 25-4 acl トークンの形式

Graphic

arbitrary トークン

arbitrary トークンは、監査トレール用にデータをカプセル化します。次の 4 つの固定長フィールドと 1 つのデータ配列からなっています。

トークンの残りの部分は、指定された形式の 1 つまたは複数の項目からなっています。praudit コマンドでは、arbitrary トークンは次のように表示されます。


arbitrary,decimal,int,1
42

次の図に arbitrary トークンの形式を示します。

図 25-5 arbitrary トークンの形式

Graphic

次の表は、出力形式フィールドに指定できる値を示します。

表 25-6 arbitrary トークンの出力形式フィールドの値

値 

動作 

AUP_BINARY

日付が 2 進形式で出力される 

AUP_OCTAL

日付が 8 進形式で出力される 

AUP_DECIMAL

日付が 10 進形式で出力される 

AUP_HEX

日付が 16 進形式で出力される 

AUP_STRING

日付が文字列で出力される 

次の表は、項目サイズフィールドに指定できる値を示します。

表 25-7 arbitrary トークンの項目サイズフィールドの値

値 

動作 

AUR_BYTE

データはバイト単位 (1 バイト) 

AUR_SHORT

データは短い形式の単位 (2 バイト) 

AUR_LONG

データは長い形式の単位 (4 バイト) 

arg トークン

arg トークンには、システムコールの引数情報 (システムコールの引数の数、引数の値、およびオプションの説明) が含まれています。このトークンを使用すると、監査レコード内で 32 ビット整数のシステムコール引数を指定できます。次の 5 つのフィールドがあります。

praudit コマンドでは、arg トークンは次のように表示されます。


argument,1,0x00000000,addr

arg トークンの形式を示します。

図 25-6 arg トークンの形式

Graphic

attr トークン

attr トークンには、ファイル v ノードからの情報が含まれています。次のトークンには 7 つのフィールドがあります。

ファイルシステム ID とデバイス ID の詳細は、statvfs(2) のマニュアルページを参照してください。

一般に、attrトークンには path トークンが付いており、パスの検索中に生成されます。パス検索エラーが発生すると、必要なファイル情報を取得するために利用できる v ノードがないため、attrトークンは監査レコードの一部として組み込まれません。praudit コマンドでは、attr トークンは次のように表示されます。


attribute,100555,root,staff,1805,13871,-4288

attr トークンの形式を示します。

図 25-7 attr トークンの形式

Graphic

exec_args トークン

exec_args トークンは、 exec() システムコールへの引数を記録します。次の 2 つの固定フィールドがあります。

このトークンの残りの部分は、0 個以上の NULL で終わる文字列からなっています。praudit コマンドでは、 exec_args トークンは次のように表示されます。


vi,/etc/security/audit_user

exec_args トークンの形式を示します。

図 25-8 exec_args トークンの形式

Graphic

注 -

exec_args トークンは、監査ポリシー argv が有効なときにだけ出力されます。

exec_env トークン

exec_envトークンは、exec() システムコールの現在の環境変数を記録します。次の 2 つの固定フィールドがあります。

このトークンの残りの部分は、0 個以上の NULL で終わる文字列からなっています。praudit コマンドでは、exec_env トークンは次のように表示されます。


exec_env,25,
GROUP=staff,HOME=/export/home/matrix,HOST=mestrix,HOSTTYPE=sun4,HZ=100,
LC_COLLATE=en_US.ISO8859-1,LC_CTYPE=en_US.ISO8859-1,LC_MESSAGES=C,
LC_MONETARY=en_US.ISO8859-1,LC_NUMERIC=en_US.ISO8859-1,
LC_TIME=en_US.ISO8859-1,LOGNAME=matrix,MACHTYPE=sparc,
MAIL=/var/mail/matrix,OSTYPE=solaris,PATH=/usr/sbin:/usr/bin,PS1=#,
PWD=/var/audit,REMOTEHOST=209.198.087.208,SHELL=/usr/bin/csh,SHLVL=1,
TERM=dtterm,TZ=US/Pacific,USER=matrix,VENDOR=sun

次の図に exec_env トークンの形式を示します。

図 25-9 exec_env トークンの形式

Graphic

注 -

exec_env トークンは、監査ポリシー arge が有効なときにだけ出力されます。

exit トークン

exit トークンは、プログラムの終了状態を記録します。次のフィールドがあります。

praudit コマンドでは、exit トークンは次のように表示されます。


exit,Error 0,0

次の図に exit トークンの形式を示します。

図 25-10 exit トークンの形式

Graphic

file トークン

file トークンは、監査デーモンによって生成される特殊なトークンです。古い監査トレールファイルが終了すると、新しい監査トレールファイルの開始と古いファイルの終了をマークします。監査デーモンは、このトークンを含む特殊な監査レコードを構築して、連続する監査ファイルを 1 つの監査トレールに「リンク」します。次の 4 つのフィールドがあります。

praudit コマンドでは、file トークンは次のように表示されます。


file,Tue Sep  1 13:32:42 1992, + 79249 msec,
	/var/audit/localhost/files/19990901202558.19990901203241.quisp

次の図に file トークンの形式を示します。

図 25-11 file トークンの形式

Graphic

groups トークン (現在は使用しない)

このトークンは、newgroups トークンに置き換えられています。newgroups トークンは同じ種類の情報を少ない領域で提供します。ここでは完全を期すために groups トークンについて説明しますが、アプリケーション設計者は newgroups トークンを使用してください。ASCII 出力が表示されるときには、どちらのトークン ID にも groups というラベルが付いているため、praudit はこの 2 つのトークンを区別しないことに注意します。

groups トークンは、プロセスの資格からグループのエントリを記録します。次のトークンには 2 つの固定長フィールドがあります。

このトークンの残りの部分は 0 個以上のグループエントリからなっています。praudit コマンドでは、group トークンは次のように表示されます。


group,staff,admin,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1

次の図に groups トークンの形式を示します。

図 25-12 groups トークンの形式

Graphic

注 -

groups トークンは、監査ポリシー group が有効なときにだけ出力されます。

header トークン

header トークンは、監査レコードの始まりをマークし、trailer トークンとの組み合わせでレコード内の他のすべてのトークンを囲む特殊なトークンです。次の 6 つのフィールドがあります。

64 ビットシステムでは、header トークンは、32 ビットタイムスタンプではなく 64 ビットタイムスタンプで表示されます。

praudit では、ioctl() システムコールの header トークンは次のように表示されます。


header,240,1,ioctl(2),es,Tue Sept  1 16:11:44 2001, + 270000 msec

次の図に header トークンの形式を示します。

図 25-13 header トークンの形式

Graphic

ID 修飾子フィールドでは、次のフラグが定義されています。 


0x4000			PAD_NOTATTR						nonattributable event
0x8000			PAD_FAILURE						fail audit event

in_addr トークン

in_addr トークンには、4 バイトのインターネットプロトコルアドレスが含まれます。次の 2 つのフィールドがあります。

praudit コマンドでは、in_addr トークンは次のように表示されます。


ip address,129.150.113.7

Solaris 9 では、インターネットアドレスは、4 バイトを使用する IPv4 アドレス、または型の記述に 16 バイトとアドレスに 16 バイトを使用する IPv6 アドレスとして表示できます。次の図に in_addr トークンの形式を示します。

図 25-14 in_addr トークンの形式

Graphic

ip トークン

ip トークンには、インターネットプロトコルのヘッダーのコピーが含まれていますが、IP オプションは含まれていません。IP オプションは、トークン内の IP ヘッダー数を増やすと追加できます。次の 2 つのフィールドがあります。

praudit コマンドでは、ip トークンは次のように表示されます。


ip address,0.0.0.0

IP ヘッダー構造は、/usr/include/netinet/ip.h ファイル内で定義されています。次の図に ip トークンの形式を示します。

図 25-15 ip トークンの形式

Graphic

ipc トークン

ipc トークンには、特定のIPC オブジェクトを識別するために呼び出し元に使用される System V IPC メッセージ、セマフォ、または共有メモリーハンドルが含まれています。次の 3 つのフィールドがあります。

praudit コマンドでは、ipc トークンは次のように表示されます。


IPC,msg,3
注 -

IPC オブジェクト識別子は、コンテキストに依存しない Solaris CMW 監査トークンに準拠していません。IPC オブジェクトを一意に識別するグローバルな「名前」はありません。代わりに、IPC オブジェクトの動作中だけ有効なハンドルで識別されます。System V の IPC メカニズムはあまり使用されず、すべてが同じ監査クラスを共有するので、識別は問題にはなりません。

次の表は、IPC オブジェクトの形式フィールドに指定できる値の一覧です。値は /usr/include/bsm/audit.h ファイル内で定義されます。

表 25-8 IPC オブジェクトの形式フィールドの値

名前 

値 

説明 

AU_IPC_MSG

1 

IPC メッセージオブジェクト 

AU_IPC_SEM

2 

IPC セマフォオブジェクト  

AU_IPC_SHM

3 

IPC 共有メモリーオブジェクト 

次の図に ipc トークンの形式を示します。

図 25-16 ipc トークンの形式

Graphic

ipc_perm トークン

ipc_perm トークンには、System V の IPC アクセス情報が含まれています。このトークンは、IPC 共有メモリーイベント、IPC セマフォイベント、および IPC メッセージイベントによって生成される監査レコードに追加されます。次の 8 つのフィールドがあります。

praudit コマンドでは、ipc_perm トークンは次のように表示されます。


IPC perm,root,wheel,root,wheel,0,0,0x00000000

値は、IPC オブジェクトに関連付けられた ipc_perm 構造から取り出されます。次の図に ipc_perm トークンの形式を示します。

図 25-17 ipc_perm トークンの形式

Graphic

iport トークン

iport トークンには、TCP (または UDP) ポートアドレスが含まれています。次の 2 つのフィールドがあります。

praudit コマンドでは、iport トークンは次のように表示されます。


ip port,0xf6d6

次の図に iport トークンの形式を示します。

図 25-18 iport トークンの形式

Graphic

newgroups トークン

groups トークンは、このトークンによって置き換えられます。ASCII 出力が表示されるときには、どちらのトークン ID にも groups というラベルが付いているため、praudit はこの 2 つのトークンを区別しないことに注意してください。

newgroups トークンは、プロセスの資格からグループエントリを記録します。次の 2 つの固定長フィールドがあります。

このトークンの残りの部分は 0 個以上のグループエントリからなっています。praudit コマンドでは、newgroups トークンは次のように表示されます。


group, staff, admin

次の図に newgroups トークンの形式を示します。

図 25-19 newgroups トークンの形式

Graphic

注 -

newgroups トークンは、監査ポリシー group が有効なときにだけ出力されます。

opaque トークン

opaque トークンには、フォーマットされていないデータが一連のバイトとして含まれています。次の 3 つのフィールドがあります。

praudit コマンドでは、opaque トークンは次のように表示されます。


opaque,12,0x4f5041515545204441544100

次の図に opaque トークンの形式を示します。

図 25-20 opaque トークンの形式

Graphic

path トークン

path トークンには、オブジェクトのアクセスパス情報が含まれています。次のフィールドがあります。

praudit コマンドでは、path トークンは次のように表示されます。パス長フィールドは、表示されません。


path,/etc/security/audit_user

次の図に path トークンの形式を示します。

図 25-21 path トークンの形式

Graphic

process トークン

process トークンには、信号の受信者など、プロセスに関連するユーザーの情報が含まれています。次の 9 つのフィールドがあります。

praudit コマンドでは、process トークンは次のように表示されます。


process,root,root,wheel,root,wheel,0,0,0,0.0.0.0

次の図に process トークンの形式を示します。

図 25-22 process トークンの形式

Graphic

監査 ID、ユーザー ID、グループ ID、プロセス ID、セッション ID は、短い形式ではなく長い形式です。

注 -

セッション ID、実ユーザー ID、または実グループ ID の processトークンのフィールドを使用できないことがあります。その場合、値は -1 に設定されます。

端末 ID を含むトークンには、いくつかの種類があります。praudit コマンドでは、端末 ID の書式の違いを吸収して、同じ書式で出力されます。端末 ID フィールドを含むすべてのトークンでは、端末 ID フィールドは同じ方式で処理されます。端末 ID は、IP アドレスとポート番号の組み合わせか、デバイス ID です。たとえば、モデムに接続されたシリアルポートの場合は、0 になります。端末 ID には、次の書式があります。

デバイス番号の場合は、次のようになります。

Solaris 7 またはそれ以前のリリースのポート番号の場合は、次のようになります。

Solaris 8 または Solaris 9 のポート番号の場合は、次のようになります。

return トークン

return トークンには、システムコールの戻り状態 (u_error) とプロセスの戻り値 (u_rval1) が含まれています。次の 3 つのフィールドがあります。

return トークンは、必ずシステムコールに関してカーネルによって生成される監査レコードの一部として返されます。このトークンは、アプリケーションを監査中の終了状態と他の戻り値を示します。

praudit コマンドにより return トークンは次のように表示されます。


return,success,0

次の図に return トークンの形式を示します。

図 25-23 return トークンの形式

Graphic

seq トークン

seq トークン (シーケンストークン) は、シーケンス番号が含まれるオプションのトークンです。このトークンは、デバッグに使用されます。seq ポリシーが有効な場合は、このトークンが各監査レコードに追加されます。次の 2 つのフィールドがあります。

シーケンス番号は、監査レコードが生成されて監査トレールに組み込まれるたびに 1 ずつ増分します。praudit コマンドでは、seq トークンは次のように表示されます。


sequence,1292

次の図に seq トークンの形式を示します。

図 25-24 seq トークンの形式

Graphic

注 -

seq トークンは、監査ポリシー seq が有効なときだけ出力されます。

socket トークン

socket トークンには、インターネットソケットを記述する情報が含まれています。次の 6 つのフィールドがあります。

praudit コマンドでは、socket トークンは次のように表示されます。


socket,0x0000,0x0000,0.0.0.0,0x0000,0.0.0.0

Solaris 9 では、インターネットアドレスは、4 バイトを使用する IPv4 アドレス、または型の記述に 16 バイトとアドレスに 16 バイトを使用する IPv6 アドレスとして表示できます。次の図に socket トークンの形式を示します。

図 25-25 socket トークンの形式

Graphic

subject トークン

subject トークンには、操作を実行するユーザーまたは実行する予定のユーザーを記述します。形式は process トークンと同じです。次の 9 つのフィールドがあります。

subjectトークンは、必ずシステムコールに関してカーネルによって生成される監査レコードの一部として返されます。praudit コマンドでは、subject トークンは次のように表示されます。


subject,cjc,cjc,staff,cjc,staff,424,223,0 0 quisp

監査 ID、ユーザー ID、グループ ID、プロセス ID、セッション ID は、短い形式ではなく長い形式です。

注 -

セッション ID、実ユーザー ID、または実グループ ID の subject トークンのフィールドを使用できないことがあります。その場合、値は -1 に設定されます。

端末 ID を含むトークンには、いくつかの種類があります。praudit コマンドでは、端末 ID の書式の違いを吸収して、同じ書式で出力されます。端末 ID フィールドを含むすべてのトークンでは、端末 ID フィールドは同じ方式で処理されます。端末 ID は、IP アドレスとポート番号の組み合わせか、デバイス ID です。たとえば、モデムに接続されたシリアルポートの場合は、0 になります。端末 ID には、次の書式があります。

デバイス番号の場合は、次のようになります。

Solaris 7 またはそれ以前のリリースのポート番号の場合は次のようになります。

Solaris 8 または Solaris 9 リリースのポート番号の場合は次のようになります。

次の図に subject トークンの形式を示します。

図 25-26 subject トークンの形式

Graphic

text トークン

text トークンにはテキスト文字列が含まれています。次の 3 つのフィールドがあります。

praudit コマンドでは、text トークンは次のように表示されます。


text,aw_test_token

次の図に text トークンの形式を示します。

図 25-27 text トークンの形式

Graphic

trailer トークン

header と trailer の 2 つのトークンは、監査レコードの終端を区別し、他のすべてのトークンを囲む特殊なトークンです。header トークンは監査レコードを開始します。trailer トークンは監査レコードを終了します。 trailer トークンは、省略可能なトークンで、trail 監査ポリシーが設定されているときにだけ、各レコードの最後のトークンとして追加されます。

また、trailer トークンを使用すると監査トレールを逆方向に検索できます。3 つのフィールドがあります。

praudit コマンドでは、trailer トークンは次のように表示されます。 


trailer,136

次の図に trailer トークンの形式を示します。

図 25-28 trailer トークンの形式

Graphic

監査トレール解析ソフトウェアでは、header および trailer トークンが常に監査レコードに追加されます。ファイルシステムがいっぱいのときなど、書き込みエラーが発生すると、監査レコードが不完全になって切り捨てられることがあります。auditsvc() システムコールは、監査トレールにデータを書き込むときに、監査レコードをすべて書き込もうとします。ファイルシステムの容量が足りなくなると、システムコールは現在の監査レコードを解放せずに終了します。システムコールが再開するときには、切り捨てたレコードを反復できます。詳細は、auditsvc(2) のマニュアルページを参照してください。

デバイス割り当て参照

デバイス割り当てを行うことによって、承認されていないユーザーがリムーバブルメディアを使用できないようにします。デバイス割り当てを要求したり、デバイスを使用する権限を拒否したりすることで、データの損失、コンピュータウィルスなどのセキュリティ違反から使用する環境を保護することができます。次の節では、BSM デバイス割り当てについて説明します。

デバイス割り当てメカニズムの構成要素

デバイス割り当てメカニズムは、次の要素で構成されます。

device_allocate ファイル、device_map ファイル、ロックファイルは、ローカル構成ファイルです。これらのファイルは、ネームサービスデータベースとして管理されません。テープドライブ、フロッピーディスクドライブ、およびプリンタ はすべて、特定のマシンに接続されるためです。

デバイス割り当てコマンドの使用方法

この節では、allocate、deallocate、および list_devices コマンドのいくつかのオプションについて説明します。これらのコマンドを使用するには、スーパーユーザーまたは同等の役割が必要です。各コマンドについての詳細は、それぞれのマニュアルページを参照してください。

allocate -F device_special_filename

指定するデバイスを再度割り当てます。通常は、このオプションに -U オプションを付けて、指定するデバイスを指定するユーザーに再度割り当てます。-U オプションを指定しない場合、デバイスは root に割り当てられます。

allocate -U username

デバイスは、現在のユーザーではなく指定するユーザーに割り当てられます。このオプションを使用すると、スーパーユーザーになっている間は、指定するユーザーの識別情報がなくても、そのデバイスを割り当てることができます。

deallocate -F device_special_filename

デバイス割り当てを強制的に解除します。ユーザーに割り当てられたデバイスは、プロセスが終了するとき、またはそのユーザーがログアウトするときに、自動的に割り当てが解除されます。ユーザーがテープドライブの割り当てを解除し忘れたときには、スーパーユーザーになっている間に -F オプションを使用して割り当てを強制的に解除することができます。

deallocate -I

割り当て可能なすべてのデバイス割り当てを強制的に解除します。このオプションは、システムの初期化時にのみ使用します。

list_devices

device_maps ファイルに一覧されたデバイスに関連付けられているデバイス特殊ファイルが一覧されます。

list_devices -U username

指定したユーザー名に関連付けられたユーザー ID に割り当て可能のデバイスまたは割り当て済みのデバイスが一覧されます。このオプションを使用すると、スーパーユーザーになっている間に、別のユーザーに割り当て可能なデバイス、または割り当て済みのデバイスを確認できます。

割り当てエラー状態

割り当て可能デバイスは、デバイス特殊ファイルモードが 0100 になっているユーザー bin とグループ bin に所有されている場合に、割り当てエラー状態になります。割り当てエラー状態になっているデバイスを割り当てる場合は、deallocate コマンドの -F オプションを使用して、そのデバイスの割り当てを強制的に解除する必要があります。または、allocate -U を使用して、デバイスをユーザーに割り当て、表示されるエラーメッセージを調べます。デバイス関連の問題が解決したあと、 deallocate -F または allocate - F コマンドを再度実行して、デバイスから割り当てエラー状態をクリアする必要があります。

device_maps ファイル

/etc/security/device_maps ファイルを調べると、各割り当て可能デバイスに関連付けられたデバイス名、デバイスの種類、デバイス特殊ファイルを判断できます。詳細については、device_maps(4) のマニュアルページを参照してください。デバイスマップは、デバイス割り当てを設定したときに作成されます。device_maps の初期ファイルは、BSM を有効にしたときに、bsmconv によって作成されます。この初期 device_maps ファイルは、あくまでも開始点として使用する必要があります。device_maps は、使用する環境に合わせて拡張およびカスタマイズできます。

device_maps ファイルでは、デバイスごとにデバイス特殊ファイルの割り当てが定義されます。多くの場合、この割り当ては単純ではありません。このファイルによって、各種のプログラムはどのデバイス特殊ファイルがどのデバイスに割り当てられているかを検出できます。たとえば、dminfo コマンドを使用すると、デバイス名、デバイスの種類およびデバイス特殊ファイルを取得して、割り当て可能なデバイスを設定するときに指定できます。dminfo コマンドは、device_maps ファイルを使用してデバイス割り当て情報を報告します。

各デバイスは、次の形式の 1 行のエントリで表されます。

device-name:device-type:device-list

エントリを次の行に続けるには、行末にバックスラッシュ (\) を付けます。コメントも挿入できます。# を付けると、それに続くすべてのテキストは、行末にバックスラッシュ (\) のない次の改行までコメントになります。どのフィールドでも先行ブランクと後続ブランクを使用できます。

device-name

st0、fd0、または audio などのデバイス名を指定します。ここで指定するデバイス名は、/etc/security/dev ディレクトリ内で使用されるロックファイル名と対応している必要があります。

device-type

汎用デバイスタイプ (st、fd、audio などのデバイスクラス名) を指定します。device-type では、関連するデバイスが論理的にグループ化されます。

device-list

物理デバイスに関連付けられたデバイス特殊ファイルの一覧です。device-list には、特定のデバイスにアクセスできるすべての特殊ファイルが含まれている必要があります。リストが不完全な場合は、悪意を持ったユーザーでも個人情報を入手または変更できることになります。device-list フィールドには、/devices 内または/dev 内のシンボリックリンクに置かれた実デバイスファイルを入力します。/dev ディレクトリ内のシンボルリンクは、バイナリ互換性を持ちます。

次の例では、SCSI テープ st0 とフロッピーディスク fd0 の device_maps ファイルエントリを示します。 


fd0:\
	fd:\
	/dev/fd0 /dev/fd0a /dev/fd0b /dev/rfd0 /dev/rfd0a /dev/rfd0b:\
					.
					.
					.
st0:\
	st:\
	/dev/rst0 /dev/rst8 /dev/rst16 /dev/nrst0 /dev/nrst8 /dev/nrst16:\

device_allocate ファイル

device_allocate ファイルを変更して、デバイスを割り当て可能から割り当て不可に変更したり、新しいデバイスを追加したりします。device_allocate ファイルの例を次に示します。 


st0;st;;;;/etc/security/lib/st_clean
fd0;fd;;;;/etc/security/lib/fd_clean
sr0;sr;;;;/etc/security/lib/sr_clean
audio;audio;;;*;/etc/security/lib/audio_clean

割り当て可能にするデバイスは、BSM を初期構成するときに定義します。上述の device_allocate ファイルの例のように、デフォルトのデバイスとそれらに定義されている特性をそのまま使用することもできます。システム稼働後の実行中にマシンにデバイスを追加するときには、新しいデバイスを割り当て可能にするかどうかを決定する必要があります。

BSM をインストールしたあとで、デバイスのエントリは device_allocate ファイルを変更できます。割り当てたいデバイスは、使用する前に各マシン上の device_allocate ファイル内で定義する必要があります。現在、カートリッジテープドライブ、フロッピーディスクドライブ、CD-ROM デバイス、オーディオチップは割り当て可能と見なされ、デバイスクリーンスクリプトが用意されています。

注 -

XylogicsTM テープドライブまたは Archive テープドライブでは、SCSI デバイス用に用意されている st_clean スクリプトも使用できます。また、モデム、端末、グラフィックスタブレットなどのデバイスも割り当て可能にすることができます。ただし、これらのデバイスを使用する場合は、独自のデバイスクリーンスクリプトを作成し、オブジェクト再使用要求に対応する必要があります。

device_allocate ファイル内のエントリは、デバイスが割り当て可能であると特に記述されていない限り、そのデバイスが割り当て可能であることを説明しません。上述の device_allocate ファイルの例では、オーディオデバイスエントリの第 5 フィールドにアスタリスク (*) が指定されています。第 5 フィールド内のアスタリスクは、そのデバイスが割り当て可能でないことをシステムに示します。つまり、システム管理者はユーザーにデバイスを使用する前に割り当てたり、あとで割り当てを解除するように要求したりする必要がありません。このフィールド内の他の文字列は、デバイスが割り当て可能であることを示します。

各デバイスは、次の形式の 1 行のエントリで表します。 


device-name;device-type;reserved;reserved;alloc;device-clean

たとえば、次の行はデバイス名 st0: のエントリを示しています。


st0;st;;;;;/etc/security/lib/st_clean

エントリを次の行に続けるには、行末にバックスラッシュ (\) を付けます。コメントも挿入できます。# を付けると、それに続くのすべてのテキストは、行末にバックスラッシュ (\) のない次の改行までコメントになります。どのフィールドでも先行ブランクと後続ブランクを使用できます。

次の各段落では、device_allocate ファイル内の各フィールドについて詳しく説明します。

device-name

st0、fd0、または sr0 などのデバイス名を指定します。割り当て可能デバイスを作成するときには、device_maps ファイル内の device-name フィールドから device-name を取得するか、または dminfo コマンドを使用します (device-name 名は、デバイスの DAC ファイル名でもある)。

device-type

汎用デバイスタイプ (st、fd、sr などのデバイスクラス名) を指定します。このフィールドによって、関連するデバイスがグループ化されます。割り当て可能デバイスを作成するときには、device_maps ファイル内の device-type フィールドから device-type を取得するか、または dminfo コマンドを使用します。

reserved

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

alloc

デバイスが割り当て可能かどうかを指定します。このフィールドにアスタリスク (*) が入っている場合は、デバイスが割り当て不可能であることを示します。このフィールドに他の文字列が入っている場合や、空の場合は、デバイスが割り当て可能であることを示します。

device-clean

割り当てプロセス中にクリーンアップやオブジェクト再使用防止などの特殊処理のために呼び出されるスクリプトのパス名を指定します。deallocate - F を使用してデバイスの割り当てを強制的に解除するときなど、デバイスに対して deallocate コマンドを実行すると、device-clean スクリプトが実行されます。

デバイスクリーンスクリプト

「デバイスクリーン」スクリプトは、使用可能なすべてのデータを再使用する前に物理デバイスからパージするというセキュリティ要件に対応するものです。デフォルトでは、カートリッジテープドライブ、フロッピーディスクドライブ、CD-ROM デバイス、オーディオデバイスには、必要なデバイスクリーンスクリプトが用意されています。この節では、デバイスクリーンスクリプトが実行する処理について説明します。

オブジェクトの再使用

デバイス割り当てによって、オブジェクト再使用の要件の一部が満たされます。デバイスクリーンスクリプトによって、あるユーザーがデバイス上に残したデータは、そのデバイスが別のユーザーによって割り当て可能になる前に確実にクリアされます。

テープ用のデバイスクリーンスクリプト

st_clean デバイスクリーンスクリプトでは、3 つのテープデバイスがサポートされます。サポートされるテープデバイスは次のとおりです。

st_cleanスクリプトでは、mt コマンドの rewofflオプションを使用して、デバイスのクリーンアップを制御します。詳細は、mt(1) のマニュアルページを参照してください。st_clean スクリプトは、システムブート中に実行されると、デバイスを照会し、そのデバイスがオンラインになっていてメディアが挿入されているかどうかを調べます。1/4 インチのテープデバイスにメディアが挿入されているときは、そのデバイスは強制的に割り当てエラー状態になるため、システム管理者はそのデバイスを手動でクリーンアップする必要があります。

通常のシステム操作中に、allocate または deallocate コマンドを対話型モードで実行すると、割り当てを解除しようとしているデバイスからメディアを取り出すように求めるプロンプトが表示されます。スクリプトは、メディアがデバイスから取り出されるまで一時停止します。

フロッピーディスクと CD-ROM 用のデバイスクリーンスクリプト

次の表に、フロッピーディスクとCD-ROM 用のデバイスクリーンスクリプトを示します。

表 25-9 フロッピーディスクと CD-ROM 用のデバイスクリーンスクリプト

ディスクデバイスの種類 

デバイスクリーンスクリプト 

フロッピーディスク 

fd_clean

CD-ROM  

sr_clean

スクリプトは、eject コマンドを使用してドライブからメディアを取り出します。詳細については、eject(1) のマニュアルページを参照してください。eject コマンドが失敗すると、デバイスは割り当てエラー状態になります。

オーディオ用のデバイスクリーンスクリプト

オーディオデバイスは、audio-clean スクリプトを使用してクリーンアップします。スクリプトは、AUDIO_DRAIN ioctl システムコールを実行してデバイスをフラッシュしてから、AUDIO_SETINFO ioctl システムコールコマンドを実行してデバイス構成をデフォルトにリセットします。また、スクリプトは AUDIOGETREG ioctl システムコールを使用して、オーディオチップレジスタを検出します。レジスタのデフォルト設定にリセットする場合は、AUDIOSETREG ioctl システムコールを使用します。

新しいデバイスクリーンスクリプトの作成

システムに新しく割り当て可能デバイスを追加する場合は、独自のデバイスクリーンスクリプトを作成する必要があります。deallocate コマンドは、デバイスクリーンスクリプトにパラメータを渡します。次のように、パラメータはデバイス名が入った文字列です (device_allocate(4) のマニュアルページを参照)。 


st_clean -[I|F|S] device-name

デバイスクリーンスクリプトは、正常終了した場合は 0 を、失敗した場合は 1 以上の値を返します。オプション -I、-F、-S を使用すると、スクリプトに実行モードを判断させることができます。

-I オプションは、システムをブートするときにだけ指定します。すべての出力は、システムコンソールに送られます。失敗した場合や、メディアを強制的に取り出せない場合は、デバイスを割り当てエラー状態にします。

-F オプションは、強制クリーンアップを行うときに指定します。このオプションは対話型で、ユーザーがプロンプトに応答するものと見なします。このオプションが付いたスクリプトは、クリーンアップの一部に失敗した場合に、クリーンアップ全体を完了しようとします。

-S オプションは、標準クリーンアップを行うときに指定します。このオプションは対話型で、ユーザーがプロンプトに応答するものと見なします。

デバイス割り当てメカニズムの機能

この節では、デバイス割り当てメカニズムの機能について例を挙げて説明します。

allocate コマンドは、まず/etc/security/dev ディレクトリ内で、指定されたデバイスのデバイス名が付いたロックファイルがあるかどうかを確認します。ファイルが allocate によって所有されている場合は、ロックファイルの所有権が allocate コマンドを起動したユーザー名に変更されます。

次に、allocate コマンドは device_allocate ファイル内のデバイスのエントリを確認し、そのエントリでデバイスが割り当て可能に設定されているかどうかを確認します。

次の例の最初の一覧は、/etc/security/dev 内に、st0 デバイスを所有者 bin、グループ bin、モード 600 で使用するロックファイルがあることを示しています。2 つ目の一覧は、それに関連するデバイス特殊ファイルが正しく設定されていて、所有者は bin、グループは bin、モードは 000: であることを示します。


untouchable% ls -lg /etc/security/dev/st0
-rw------- 1 bin bin      		      0 Dec 6 15:21 /etc/security/dev/st0
untouchable% ls -lg /devices/sbus@1,f8000000/esp@0,800000
c--------- 1 bin bin		       18,  4 May 12 13:11 st@4,0:
c--------- 1 bin bin	       18, 20 May 12 13:11 st@4,0:b
c--------- 1 bin bin	       18, 28 May 12 13:11 st@4,0:bn
c--------- 1 bin bin	       18, 12 May 12 13:11 st@4,0:c
					 .
					 .
					 .
c--------- 1 bin bin	       18,  0 May 12 13:11 st@4,0:u
c--------- 1 bin bin	       18, 16 May 12 13:11 st@4,0:ub
c--------- 1 bin bin	       18, 24 May 12 13:11 st@4,0:ubn
c--------- 1 bin bin	       18,  8 May 12 13:11 st@4,0:un

次の例では、ユーザー vanessa がデバイス st0 を割り当てます。


untouchable% whoami
vanessa
untouchable% allocate st0

ユーザー vanessa が allocate コマンドを実行してテープ st0 を割り当てると、allocate はまず /etc/security/dev/st0 ファイルが存在することを確認します。ロックファイルが存在しない場合や、allocate 以外のユーザーに所有されている場合は、ユーザー vanessa はデバイスを割り当てることができません。

allocate コマンドは正しい所有権とアクセス権が設定されたロックファイルを見つけると、そのデバイスのエントリが device_allocate ファイルに入っていることと、そのエントリでデバイスが割り当て可能として指定されていることを確認します。

この例では、st0 デバイスのデフォルトの device_allocate エントリでは、デバイスが割り当て可能として指定されています。allocate コマンドではこれらの条件がすべて満たされていることを認識し、デバイスが vanessa に割り当てられます。

allocate コマンドは、/dev ディレクトリ内でデバイスに関連付けられたデバイス特殊ファイルの所有権とアクセス権を変更します。st0 デバイスをユーザー vanessa に割り当てるために、それに関連付けられたデバイス特殊ファイルのモードを 600 に変更し、所有者を vanessa に変更します。

また、allocate コマンドは、/etc/security/dev ディレクトリ内でデバイスに関連付けられたロックファイルの所有権も変更します。st0 デバイスをユーザー vanessa に割り当てるために、/etc/security/dev/st0 の所有者を vanessa に変更します。

次の例では、ユーザー vanessa が デバイス名 st0 を指定して allocate コマンドを実行すると、/etc/security/dev/st0 の所有者が vanessa に変更され、デバイス特殊ファイルに関連付けられた所有者も vanessa に変更されます。最後に、ユーザー vanessa にファイルの読み取り権と書き込み権が与えられます。


untouchable% whoami
vanessa
untouchable% allocate st0
untouchable% ls -lg /etc/security/dev/st0
-rw------- 1 vanessa staff 		      0 Dec 6 15:21 /etc/security/dev/st0
untouchable% ls -la /devices/sbus@1,f8000000/esp@0,800000
.
.
.
crw------- 1 vanessa 18,  4 May 12 13:11 st@4,0:
crw------- 1 vanessa 18, 12 May 12 13:11 st@4,0:b
crw------- 1 vanessa 18, 12 May 12 13:11 st@4,0:bn
crw------- 1 vanessa 18, 12 May 12 13:11 st@4,0:c
.
.
.
crw------- 1 vanessa 18,  4 May 12 13:11 st@4,0:u
crw------- 1 vanessa 18, 12 May 12 13:11 st@4,0:ub
crw------- 1 vanessa 18, 12 May 12 13:11 st@4,0:ubn
crw------- 1 vanessa 18, 12 May 12 13:11 st@4,0:un