第 23 章 BSM サービス (参照)
この章では、BSM サービスの重要なコンポーネントである、監査サブシステムとデバイス割り当てメカニズムについて説明します。
監査メカニズムを使用して、システムが通常と異なる方法で使用されていないかどうか検査すると、潜在的なセキュリティ違反を検出できます。また、通常と異なる動作を追跡して、特定のユーザーを突き止めることができるため、セキュリティ違反を抑えることができます。つまり、ユーザーは自分の動作が監査されそうだと考えると、違反行為を思いとどまる可能性が大きくなります。
この章の内容は次のとおりです。
監査の概要については、第 20 章「BSM (概要)」を参照してください。計画時のヒントについては、第 21 章「監査の計画」を参照してください。サイトで監査を構成する手順については、第 22 章「BSM サービスの管理 (手順)」を参照してください。
監査コマンド
この節では、監査サービスで使用されるコマンドについて説明します。
監査デーモン
-
auditd は、 audit_control ファイル内で指定されたディレクトリ内の監査ログファイルを、指定された順序で開き、閉じます。
-
auditd は、監査データをカーネルから読み取り、監査ログファイルに書き込みます。
-
auditd は、監査ディレクトリ内のデータ量が audit_controlファイル内で指定された上限を超えると、 audit_warn スクリプトを実行します。デフォルトでは、このスクリプトは audit_warn メールの別名とコンソールに警告を送信します。
-
デフォルトでは、監査ディレクトリがすべていっぱいになると、監査レコードを生成するプロセスは中断されます。また、auditd コマンドは、コンソールと audit_warn メールの別名にメッセージを送ります。この監査ポリシーは、auditconfig コマンドを使用して構成し直すことができます。この時点では、システム管理者だけが、監査メカニズムの修復を行えます。管理者は、ログインして監査ファイルをテープに書き込んだり、監査ファイルをシステムから削除したり、その他のクリーンアップを実行したりできます。
auditd デーモンは、マシンがマルチユーザーモードになると自動的に起動されますが、コマンド行から起動することもできます。監査デーモンが起動すると、デーモンは監査ログファイルに必要な空き容量を判断します。
監査デーモンは、audit_control ファイル内に指定されている監査ディレクトリに、監査ファイルを作成します。監査デーモンは、このディレクトリの一覧へのポインタを、最初のディレクトリに位置付けます。監査デーモンは、監査ファイルを作成する必要があるたびに、一覧内の最初の使用可能ディレクトリ内に監査ファイルを格納します。一覧は、監査デーモンの現在のポインタ位置から始まります。このポインタを一覧の最初のディレクトリに設定し直すには、audit -s コマンドを実行します。audit -n コマンドは、新しい監査ファイルに切り替えるように監査デーモンに指示します。新しいファイルは、現在のファイルと同じディレクトリ内に作成されます。
audit コマンド
audit コマンドは、監査デーモンの動作を制御します。audit コマンドは、次の操作を実行できます。
-
監査機能を使用可能および使用不可にする
-
監査デーモンを設定し直す
-
ローカルマシンの監査事前選択マスクを調整する
-
監査レコードを別の監査ログファイルに書き込む
利用できるオプションについては、audit(1M) のマニュアルページを参照してください。
bsmrecord コマンド
bsmrecord コマンドは、/etc/security/audit_event ファイル内に定義されている監査イベントの書式を表示します。監査イベントの監査 ID、監査クラス、監査フラグ、およびレコードのトークンが順に出力されます。オプションを指定しなかった場合、 bsmrecord は端末での表示に適した形で出力します。-h オプションを指定した場合、ブラウザでの表示に適した形式で出力します。使用例については、監査レコードの書式の表示方法を参照してください。詳細は、bsmrecord(1M) のマニュアルページを参照してください。
auditreduce コマンド
auditreduce コマンドを使用すると、1 つまたは複数の入力監査ファイル内の監査レコードをマージできます。このコマンドでは、監査レコードの事後選択を実行することもできます。auditreduce(1M) のマニュアルページを参照してください。監査トレール全体をマージするには、監査サーバー上でこのコマンドを実行します。監査サーバーとは、すべての監査ファイルシステムがマウントされているマシンのことです。
auditreduce コマンドを使用すると、複数のマシン上のすべての監査対象動作を、1 か所から追跡できます。このコマンドは、すべての監査ファイルを論理的に結合し、単一の監査トレールとして読み取ることができます。サイト内のすべてのマシンが同一の監査構成を持つようにするとともに、サーバーと監査ログファイル用のローカルディレクトリを作成しておく必要があります。auditreduce では、レコードの生成方法や格納場所は無視されます。オプションを指定しなかった場合、auditreduce コマンドは、監査ルートディレクトリのすべてのサブディレクトリ内のすべての監査ファイルの監査レコードをマージします。通常、/etc/security/audit が監査ルートディレクトリです。auditreduce コマンドは、マージ結果を標準出力に送ります。マージ結果は、時系列に並べて 1 つの出力ファイルに格納することもできます。このファイルの形式はバイナリデータです。
auditreduce コマンドを使用して、特定の種類のレコードを選択し、解析に利用することもできます。auditreduce コマンドのマージ機能と選択機能は、論理的にほかに依存しません。auditreduce は、入力ファイルのレコードを読み取ると、マージしてディスクに書き込む前に、データを抽出します。
praudit コマンドは、auditreduce コマンドのバイナリ出力を、ユーザーが読める書式に変換します。
auditreduce コマンドにオプションを指定すると、次の操作も実行できます。
-
特定の監査フラグによって生成された監査レコードを要求する
-
特定のユーザーによって作成された監査レコードを要求する
-
特定の日付に作成された監査レコードを要求する
auditreduce に引数を指定しなかった場合は、デフォルトの監査ルートディレクトリ /etc/security/audit 内のサブディレクトリが検査されます。このコマンドは、start-time.end-time.hostname ファイルが配置されている files ディレクトリを検査します。auditreduce コマンドは、監査データが異なるディレクトリに格納されている場合に非常に有用です。図 23–1 は、監査データがホスト別のディレクトリ内に格納されている場合を示しています。図 23–2 は、監査データが監査サーバー別のディレクトリ内に格納されている場合を示しています。
図 23–1 ホストごとに格納された監査トレール
図 23–2 サーバーごとに格納された監査トレール
/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 コマンドでは、次の 5 つの出力形式を生成できます。
-
デフォルト – デフォルトでは、1 行に 1 つの監査トークンが表示されます。デフォルトでは、監査イベントは ioctl(2) などのその内容が表示され、テキストで表示できる値はすべてテキスト形式で表示されます。たとえば、ユーザーは、ユーザー ID ではなく、ユーザー名で表示されます。
-
-l オプション – このオプションでは、1 行に 1 つの監査レコードが表示されます。-d オプションを指定すると、トークンフィールドおよびトークン間で使用される区切り文字を変更できます。デフォルトの区切り文字は、コンマです。
-
-r オプション – このオプションでは、数値で表現できる値はすべて数値として表示されます。たとえば、ユーザーはユーザー ID で、インターネットアドレスは 16 進形式で、モードは 8 進形式で表示されます。監査イベントは、イベント番号 (158 など) で表示されます。
-
-s オプション – このオプションでは、監査イベントがテーブル名 ( AUE_IOCTL など) で表示されます。その他のトークンは、デフォルトと同じ形式で表示されます。
-
-x オプション – このオプションでは、監査レコードが XML 形式で表示されます。このオプションは、出力結果をブラウザや XML を操作するスクリプトに入力する場合に便利です。
XML は、監査サブシステムが提供する DTD によって記述されます。また、Solaris ソフトウェアにはスタイルシートも付属しています。DTD とスタイルシートは /usr/share/lib/xml ディレクトリ内に格納されています。
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 出力をスクリプトで処理する
praudit コマンドの出力は、必要に応じてテキストとして操作できます。たとえば、auditreduce コマンドでは選択できないレコードを選択したいことがあります。単純なシェルスクリプトを使用すると、praudit の出力を処理できます。次の単純なスクリプトの例は、1 つの監査レコードを 1 行にまとめ、ユーザーが指定した文字列を検索し、最後に監査ファイルを元の形式に戻します。具体的には、スクリプトは次の処理を実行します。
-
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 コマンドは、次の操作を実行できます。
-
監査ポリシーの表示、チェック、構成
-
監査状態 (オン/オフ) の確認
-
監査状態 (オン/オフ) の切り替え
-
監査ディレクトリと監査ファイルの管理
-
監査キューの管理
-
事前選択マスクの取得/設定
-
監査イベントの監査クラスへの割り当ての取得/設定
-
セッション ID や監査 ID などの構成情報の取得/設定
-
プロセス、シェル、セッションの監査特性の構成
-
監査統計情報のリセット
利用できるオプションについては、auditconfig(1M) のマニュアルページを参照してください。
監査サービスファイル
監査プロセスでは、次のファイルが使用されます。
/etc/system ファイル
/etc/system ファイルには、カーネルが初期設定で読み込み、システム動作をカスタマイズするためのコマンドが格納されます。bsmconv および bsmunconv シェルスクリプトは、監査機能を起動および終了するときに使用され、/etc/system ファイルを変更します。bsmconv シェルスクリプトは、 /etc/system ファイルに次の行を追加します。
set c2audit:audit_load=1 |
set c2audit:audit_load=1 コマンドは、システムのブート時に監査モジュール (カーネルモジュールの一種) をロードします。bsmunconv シェルスクリプトは、システムのリブート時に監査を無効にします。このコマンドは、/etc/system ファイルから c2audit の行を削除します。
audit_class ファイル
/etc/security/audit_class ファイルには、既存の監査クラスの定義が含まれます。監査クラスは、監査イベントのグループです。各監査クラスには、クラスの短縮名として監査フラグが関連付けられます。audit_control ファイル内のこの短縮名を使用して、監査するイベントのクラスを事前選択します。監査フラグでは、接頭辞を使ってきめ細かな選択が行えます。詳細については、監査フラグの構文を参照してください。
root ユーザーまたはそれと同等の役割を持つ管理者は、監査クラスの定義を変更できます。管理者は、audit_class ファイルをテキストエディタで編集することによって、新しい監査クラスを定義したり、既存クラスの名前を変更したり、既存クラスにその他のさまざまな変更を施したりすることができます。詳細は、audit_class(4)のマニュアルページを参照してください。監査フラグについては、監査フラグの定義を参照してください。
audit_controlファイル
各マシン上の /etc/security/audit_control ファイルは、監査デーモンによって読み込まれます。詳細については、audit_control(4) のマニュアルページを参照してください。audit_control ファイルは /etc/security ディレクトリにあります。各マシンには、独自の audit_control ファイルがローカルに格納されています。このファイルを使用すると、個々のマシン上で、さまざまな場所にある監査ファイルシステムをさまざまな順序でマウントすることが可能となります。たとえば、マシン A の一次監査ファイルシステムは、マシン B の二次監査ファイルシステムになっている場合があります。
audit_control ファイルには、次の 4 種類の情報を指定します。各行の情報は、キーワードで始まります。
-
「監査フラグ」行は flags: で始まります。 この行に指定する監査フラグでは、マシン上のすべてのユーザーを対象に監査するイベントのクラスを、事前選択します。ここで指定する監査フラグは、「マシン全体の監査フラグ」または「マシン全体の監査事前選択マスク」と呼びます。 監査フラグは、空白を入れずにコンマで区切ります。
-
「帰属不可能フラグ」行は naflags: で始まります。この行に指定する監査フラグでは、特定のユーザーに起因しない動作が発生したときに監査するイベントクラスを、事前選択します。監査フラグは空白を入れずにコンマで区切ります。
-
「監査しきい値」行は minfree: で始まります。この行では、すべての監査ファイルシステムに確保する最小空き領域のレベルを定義します。minfree の割合は、0 以上で指定します。デフォルトは 20% です。監査ファイルシステムの使用率が 80% に達すると、次に利用可能な監査ディレクトリに監査データが格納されるようになります。audit_warn(1M) のマニュアルページを参照してください。
-
「ディレクトリ定義」行は dir: で始まります。 各行には、監査ログファイルを格納するためにマシンが使用する、監査ファイルシステムとディレクトリを定義します。1 行または複数行のディレクトリを定義できます。dir: 行では、順番が重要になります。auditd デーモンは、ここで指定した順番でディレクトリに監査ファイルを作成します。1 番目のディレクトリがそのマシンの 1 次監査ディレクトリになり、2 番目のディレクトリが 2 次監査ディレクトリになります。1 番目のディレクトリがいっぱいになると、監査デーモンは 2 番目以降のディレクトリに監査トレールファイルを作成します。 audit(1M) のマニュアルページを参照してください。
audit_control ファイルは、各マシン上での構成処理中に作成されます。
audit_control ファイルを変更したときは、audit -s コマンドを実行すると、監査デーモンによってファイルが再度読み取られます。
注 –
audit -s コマンドでは、既存のプロセスについて指定された事前選択マスクは変更されません。既存のプロセスについては、auditconfig、setaudit、auditon のいずれかを使用してください。詳細は、getaudit(2) および auditconfig(1M) のマニュアルページを参照してください。
audit_control ファイルの例
次の例は、マシン dopey で使用する audit_control ファイルです。dopey では、監査サーバー blinken 上で 2 つの監査ファイルシステムを使用し、2 つ目の監査サーバー winken からマウントされる 3 つ目の監査ファイルシステムを使用します。3 つ目のファイルシステムは、blinken 上の監査ファイルシステムがいっぱいであるか使用できないときにだけ使用されます。minfree の値として 20% を指定しているため、ファイルシステムの使用率が 80% に達した時点で警告スクリプトが実行されます。以下のフラグでは、監査対象としてログイン操作と管理操作が指定されています。これらの操作について、その成功と失敗が監査されます。ファイルシステムオブジェクト作成の失敗を除くすべての失敗が、監査対象となります。また、ユーザーに起因しないイベントも監査されています。
flags:lo,am,-all,^-fc naflags:lo,nt minfree:20 dir:/etc/security/audit/blinken/files dir:/etc/security/audit/blinken.1/files # # blinken がいっぱいになったときに使用する監査ファイルシステム # dir:/etc/security/audit/winken |
audit_data ファイル
auditd デーモンは、各マシン上で起動されると、ファイル /etc/security/audit_data を作成します。このファイルの書式は、コロンで区切られた 2 つのフィールドを含む 1 行のエントリから構成されています。audit_data(4) のマニュアルページを参照してください。最初のフィールドには、監査デーモンのプロセス ID を指定します。2 番目のフィールドには、監査デーモンが監査レコードを現在書き込んでいる監査ファイルのパス名を指定します。次に例を示します。
# cat /etc/security/audit_data 116:/etc/security/audit/blinken.1/files/19990320100002.not_terminated.dopey |
audit_event ファイル
/etc/security/audit_event ファイルには、イベントからクラスへの割り当てのデフォルト値が格納されます。このファイルを編集して、クラスの割り当てを変更できます。ただし、変更した場合は、システムをリブートするか auditconfig -conf を実行して、変更した割り当てをカーネルに読み込む必要があります。audit_event(4) のマニュアルページを参照してください。
audit_startup スクリプト
/etc/security/audit_startup スクリプトは、システムがマルチユーザーモードに移行すると監査デーモンを自動的に起動します。このスクリプトは、監査デーモンの実行直前に起動シーケンスの一部として起動されます。詳細は、audit_startup(1M)のマニュアルページを参照してください。
デフォルトの audit_startup スクリプトは、イベントからクラスへの割り当てを自動的に構成し、監査ポリシーを設定します。このスクリプトは、BSM パッケージのインストール時に作成されます。
audit_user ファイル
ユーザーごとに異なる方法で監査するには、/etc/security/audit_user ファイルを編集して、ユーザーごとに監査フラグを追加します。これらの監査フラグが指定されている場合は、audit_control ファイルのシステム全体で有効なフラグと組み合わせ、そのユーザーに対して監査するイベントクラスが決定されます。audit_user ファイル内のユーザーエントリに追加するフラグは、audit_control ファイルにあるデフォルトを次の 2 つの方法で変更します。
-
そのユーザーについて常に監査するイベントクラスを指定する
-
そのユーザーについて監査しないイベントクラスを指定する
audit_user ファイルの各ユーザーエントリには、次の 3 つのフィールドがあります。
-
username フィールド
-
always-audit フィールド
-
never-audit フィールド
これらの監査フィールドは、この順番で処理されます。always-audit フィールドは、指定されたクラスの監査を有効にします。never-audit フィールドは、指定されたクラスの監査を無効にします。
注 –
never-audit フィールド内で all 監査フラグを設定したままにする誤りがよくあるので注意してください。all 監査フラグを指定したままにすると、そのユーザーの監査がすべてオフに設定され、always-audit フィールドに設定されているフラグが無効になります。このフラグは、audit_control ファイルで設定されたマシン全体の監査フラグよりも優先されます。
ユーザーの never-audit フラグは、システムのデフォルト値よりも優先されます。システムのデフォルトを有効にしたい場合も考えられます。たとえば、ファイルシステムオブジェクトの正常な読み込みを除いて、ユーザー tamiko のすべてのイベントを監査するとします。この方法は、ユーザーのほとんどすべての動作を監査しますが、監査データは、すべてのデータ読み取りを監査した場合の約 4 分の 3 しか生成されません。このとき、システムデフォルトを tamiko に適用したいとします。次に 2 つの audit_user エントリ例を示します。
正しいエントリ
tamiko:all,^+fr: |
間違ったエントリ
tamiko:all:+fr |
1 つ目の例は、「ファイル読み取り動作を除くすべての動作を監査する」ことを表しています。2 つ目の例は「常にすべての動作を監査するが、正常なファイルの読み取り動作はまったく監査しない」ことを表しています。2 つ目の例は正しいエントリではありません。never-audit フィールドがシステムのデフォルト値を無効にするからです。1 つ目の例では期待どおりの結果になります。always-audit フラグには、all フラグへの例外が含まれています。never-audit フィールドにはフラグが指定されていないため、audit_control ファイル内のシステムデフォルト値は無効になりません。
注 –
正常終了したイベントと失敗したイベントは別々に取り扱われます。プロセスが生成する監査レコードの数は、イベントが正常終了した場合よりも失敗した場合のほうが多くなる可能性があります。
audit_warn スクリプト
監査デーモンは、監査レコードの書き込み中に異常な状態が発生すると、/etc/security/audit_warn スクリプトを起動します。詳細については、audit_warn(1M) のマニュアルページを参照してください。このスクリプトをサイトに合わせてカスタマイズすることで、手動による対処が必要な状態を警告するようにしたり、そのような状態を自動的に処理するための方法を指定したりできます。エラーが発生すると、audit_warn はコンソールにメッセージを書き込みます。audit_warn はさらに、audit_warn メール別名にもメッセージを送信します。監査を有効にしたときは、この別名を設定する必要があります。
監査デーモンは、次の状態を検出すると、 audit_warn スクリプトを起動します。
-
監査ディレクトリが minfree の許容値を超えていっぱいになった場合。minfree 値はソフト制限値で、監査ファイルシステム上で使用できる領域の割合です。
audit_warn スクリプトは、文字列 soft と、使用可能領域が下限値を下回ったディレクトリ名を使用して起動されます。監査デーモンは、次の適切なディレクトリに自動的に切り替えます。デーモンは、新しいディレクトリが minfree 制限値に達するまで、このディレクトリに監査ファイルを書き込みます。その後、監査デーモンは、audit_control ファイルに指定された順序で残りの各ディレクトリに順次アクセスします。デーモンは、各ディレクトリが minfree 制限値に達するまで監査レコードを書き込みます。
-
すべての監査ディレクトリが minfree のしきい値に達した場合。
文字列 allsoft を使用して audit_warn スクリプトが起動されます。コンソールにメッセージが書き込まれます。さらに、audit_warn の別名にメールが送信されます。
audit_control ファイルに指定されたすべての監査ディレクトリが minfree しきい値に達すると、監査デーモンは最初のディレクトリに戻ります。デーモンは、そのディレクトリが完全にいっぱいになるまで監査レコードを書き込みます。
-
監査ディレクトリが完全にいっぱいになり、残りの容量がなくなった場合。
文字列 hard とディレクトリ名を使用して、audit_warn スクリプトが起動されます。コンソールにメッセージが出力されます。さらに、audit_warn の別名にメールが送信されます。
監査デーモンは、使用可能領域が残っている次の適切なディレクトリに自動的に切り替えます。その後、監査デーモンは、audit_control ファイルに指定された順序で残りの各ディレクトリに順次アクセスします。デーモンは、各ディレクトリがいっぱいになるまで完全レコードを書き込みます。
-
すべての監査ディレクトリが完全にいっぱいになった場合。引数として文字列 allhard を使用して、audit_warn スクリプトが起動されます。
デフォルトの構成では、コンソールにメッセージが書き込まれます。さらに、audit_warn の別名にメールが送信されます。監査レコードを生成するプロセスは中断されます。監査デーモンはループに入り、領域が使用可能になるのを待って監査レコードの処理を再開します。監査レコードが処理されるまで、監査対象の動作は待機します。監査レコードを生成しようとするプロセスは、すべて中断されます。このため、別の監査管理アカウントを設定し、監査機能を有効にしないで操作できるように設定する必要があります。このように設定すれば、操作を中断せずに継続することができます。
-
内部エラーが発生した場合。次のような内部エラーが考えられます。
-
ebusy – 別の監査デーモンプロセスがすでに動作している
-
tmpfile – 一時ファイルを使用できない
-
auditsvc – auditsvc() システムコールが失敗した
audit_warn の別名にメールが送られます。
-
-
audit_control ファイルの構文に問題が検出された場合。デフォルトでは、コンソールにメッセージが書き込まれます。さらに、audit_warn の別名にメールが送信されます。
監査管理プロファイル
Solaris オペレーティング環境には、監査サービスを構成するためのプロファイルや監査トレールを分析するためのプロファイルが用意されています。
-
Audit Control – 特定の役割が Solaris 監査を構成できるようにするためのプロファイル。このプロファイルは、監査ファイルを構成したり監査コマンドを実行したりする権限を付与します。Audit Control プロファイルで割り当てられた役割が実行できるコマンドは次のとおりです。 audit、auditd、auditconfig、bsmconv、および bsmunconv
-
Audit Review – 特定の役割が Solaris 監査レコードを分析できるようにするためのプロファイル。このプロファイルは、praudit コマンドと auditreduce コマンドを使って監査レコードを読み取る権限を付与します。このプロファイルで割り当てられた役割は、 auditstat コマンドを実行することもできます
-
System Administrator – Audit Review プロファイルを含むプロファイル。System Administrator プロファイルで割り当てられた役割は、監査レコードを分析できます。
プロファイルを役割に割り当てるには、役割の作成を参照してください。
監査クラスと監査フラグ
「監査フラグ」は監査対象となるイベントのクラスを示します。マシン全体で有効な監査デフォルト値は、audit_control ファイル内のフラグによって各マシン上のすべてのユーザーに対して指定されます。このファイルについては、audit_controlファイル を参照してください。
監査フラグを audit_user ファイルにあるユーザーエントリに入れることにより、各ユーザーについて監査を行う対象を変更できます。監査フラグは、auditconfig コマンドの引数としても使用します。auditconfig(1M) のマニュアルページを参照してください。
監査フラグの定義
次の表に、事前に定義されている監査クラスを示します。この表には、監査フラグ、ロング名、および短い説明が記載されています。監査フラグは、監査クラスを表す短縮名です。監査するイベントのクラスを指定するときは、監査構成ファイルの監査フラグを使用します。監査フラグは、auditconfig などの監査コマンドの引数としても使用します。新しいクラスを定義するには、audit_class ファイルを変更します。既存クラスの名前の変更も可能です。詳細は、audit_class(4) のマニュアルページを参照してください。
表 23–1 事前に定義されている監査フラグ|
短縮名 |
ロング名 |
短い説明 |
|---|---|---|
|
すべてのクラス (メタクラス) |
||
|
ユーザーが原因ではないイベント |
||
|
データを読み取る、読み取りのために開く |
||
|
データを書き込む、書き込みのために開く |
||
|
オブジェクト属性にアクセスする :stat、pathconf |
||
|
オブジェクト属性を変更する :chown、flock |
||
|
オブジェクトの作成 |
||
|
オブジェクトの削除 |
||
|
アプリケーションが定義するイベント |
||
|
管理上の操作 (旧 administrative メタクラス) |
||
|
管理上の操作 (メタクラス) |
||
|
システムの状態を変更 |
||
|
システム全体の管理 |
||
|
ユーザー管理 |
||
|
監査の使用 |
||
|
プロセスの起動、プロセスの停止 |
||
|
プロセスの変更 |
||
|
プロセス (メタクラス) |
||
|
プログラムの実行 |
||
|
ログインとログアウトのイベント |
||
|
ネットワークイベント: bind、connect、accept |
||
|
その他 |
監査フラグの構文
監査フラグの接頭辞によって、イベントクラスが成功した場合に監査するのか、失敗した場合に監査するのか、が決まります。接頭辞を指定しなかったクラスは、成功した場合も失敗した場合も監査されます。次の表に、監査フラグの書式といくつかの例を示します。
表 23–2 接頭辞 (プラス記号、マイナス記号) の付いた監査フラグ|
prefixflag |
意味 |
|---|---|
|
lo |
成功したすべてのログインとログアウト、および失敗したすべてのログインを監査する。ログアウトが失敗することはない |
|
+lo |
成功したすべてのログインとログアウトを監査する |
|
-all |
失敗したすべてのイベントを監査する |
|
+all |
成功したすべてのイベントを監査する |
注意 – all フラグを指定すると、大量のデータが生成され、監査ファイルシステムがすぐにいっぱいになる可能性があります。all フラグは、特別な理由ですべての活動を監査する場合にだけ使用してください。
監査フラグを変更する接頭辞
キャレット接頭辞 ^ を使えば、選択されている監査フラグをさらに変更できます。次の表は、キャレット接頭辞を使って選択済みの監査フラグを変更する方法を示したものです。
表 23–3 指定済みの監査フラグを変更するキャレット接頭辞|
^prefixflag |
意味 |
|---|---|
|
-all,^-fc | |
|
am,^+aa | |
|
am,^ua |
成功または失敗したすべての管理イベントを監査する。ただし、ユーザー管理イベントは監査しない |
監査フラグの接頭辞は、次のファイルとコマンドで使用できます。
-
audit_control ファイルの flags 行で使用する
-
audit_user ファイルのユーザーエントリの flags フィールドで使用する
-
auditconfig コマンドの引数で使用する
audit_control ファイル内での接頭辞の使用例については、audit_controlファイル を参照してください。
監査ポリシー
監査ポリシーには、監査トレールにトークンまたは情報を追加するかどうかを指定します。監査ポリシーについては、使用する監査ポリシーの決定 を参照してください。
プロセスの監査特性
-
「プロセス事前選択マスク」 – audit_control ファイル内の監査フラグと audit_user ファイル内の監査フラグを結合したもの。ユーザーがログインすると、login コマンドは、これらのフラグを結合し、そのユーザーのプロセスに対する「プロセス事前選択マスク」を確立します。 プロセス事前選択マスクは、各監査イベントクラス内のイベントで監査レコードを生成するかどうかを指定します。
プロセス事前選択マスクを取得するアルゴリズムは、次の式で表されます。
user's process preselection mask = (flags: line + always-audit flags) - never-audit flags
audit_control ファイル内の flags: 行にある監査フラグを、audit_userファイル内のユーザーエントリの always-audit フィールドにあるフラグに追加します。次に、ユーザーの never-audit フィールドにあるフラグを、全体のフラグから減算します。
-
「監査 ID」 – ユーザーがログインすると、プロセスは監査 ID を取得します。監査 ID は、ユーザーの初期プロセスが起動するすべての子プロセスに継承されます。監査 ID はアカウントの追跡を強行するときにも役立ちます。ユーザーがスーパーユーザーになったあとも、監査 ID はそのまま変わらずに残ります。各監査レコード内に保存された監査 ID を使用すると、常に動作を追跡してログインした元のユーザーまでたどることができます。
-
「監査セッション ID」 – 監査セッション ID はログイン時に割り当てられます。このセッション ID はすべての子孫プロセスに継承されます。
-
「端末 ID (ポート ID、マシン ID)」 – 端末 ID は、ホスト名とインターネットアドレスで構成され、そのあとにユーザーがログインした物理デバイスを識別する一意の番号が続きます。通常、ログインはコンソールから行われ、そのコンソールデバイスに対応する番号は 0 になります。
監査トレール
「監査トレール」は監査デーモンによって作成されます。監査デーモンは、マシンが起動されるとその各マシン上で起動されます。 auditd デーモンは、ブート時に起動されると、監査トレールデータを収集し、監査レコードを「監査ファイル」に書き込む処理を受け持ちます。このファイルを「監査ログファイル」とも呼びます。ファイルの書式については、audit.log(4) のマニュアルページを参照してください。auditd(1M) のマニュアルページも参照してください。
監査ディレクトリは、監査専用でないほかのファイルシステム内に物理的に配置することもできますが、予備のディレクトリを除き、この配置は行わないでください。予備のディレクトリとは、他の適切なディレクトリが使用できないときに限り、監査ファイルが書き込まれるディレクトリです。
監査ディレクトリを監査専用でないファイルシステムに配置してもかまわない場合が、もう 1 つあります。つまり、ソフトウェア開発環境を使用していて、監査がオプションである場合は、そうしてもかまいません。監査トレールを保存するよりも、ディスク容量を有効に使用するほうが重視されるからです。しかし、セキュリティが重視される環境では、監査ディレクトリをほかのファイルシステム内に入れることは許されません。
また、次の要因も考慮する必要があります。
-
各ホストには、少なくとも 1 つのローカル監査ディレクトリを用意する必要があります。このローカルディレクトリは、ホストが監査サーバーと通信できなかった場合の予備ディレクトリとして使用できます。
-
監査ディレクトリは、読み取りオプションと書き込みオプション (rw) を使用してマウントしてください。監査ディレクトリをリモートマウントするときは、intr および noac オプションも使用してください。
-
監査ファイルシステムを、格納先の監査サーバー上で一覧してください。エクスポートリストには、監査サーバーを使用するように構成されたすべてのマシンが含まれます。
監査ファイルの命名規則
各監査ファイルは、それ自体で意味がわかるレコードの集合です。ファイル名には、レコードが生成された時間の範囲と、それを生成したマシン名が含まれます。
監査ファイルの命名
完全な監査ファイルには、次の書式の名前が付いています。
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 トークンで終わります。ほかの監査トークンには、監査可能なイベントに関連する情報が入っています。次の図は、標準的な監査レコードを示しています。
図 23–3 標準的な監査レコードの構造
監査トークンの形式
各トークンにはトークンの種類識別子とそのあとにトークン固有のデータが続いています。各トークンの種類には固有の形式があります。次の表は、各トークンの名前と説明の一覧です。
表 23–4 基本セキュリティモジュール (BSM) の監査トークン|
トークン名 |
説明 |
参照先 |
|---|---|---|
|
acl |
アクセス制御リスト情報 | |
|
arbitrary |
書式情報と型情報が付いたデータ | |
|
arg |
システムコールの引数値 | |
|
attr |
ファイル vnode トークン | |
|
exec_args |
exec システムコールの引数 | |
|
exec_env |
exec システムコールの環境変数 | |
|
exit |
プログラム終了情報 | |
|
file |
監査ファイル情報 | |
|
groups |
プロセスグループ情報 | |
|
header |
監査レコードの始まりを示す | |
|
in_addr |
インターネットアドレス | |
|
ip |
IP ヘッダー情報 | |
|
ipc |
System V IPC 情報 | |
|
ipc_perm |
System V IPC オブジェクトトークン | |
|
iport |
インターネットポートアドレス | |
|
newgroups |
プロセスグループ情報 | |
|
opaque |
構造化されていないデータ (形式が未指定) | |
|
path |
パス情報 | |
|
process |
プロセスのトークン情報 | |
|
return |
システムコールの状態 | |
|
seq |
シーケンス番号トークン | |
|
socket |
ソケットの種類とアドレス | |
|
subject |
サブジェクトのトークン情報 (process トークンと同じ書式) | |
|
text |
ASCII 文字列 | |
|
trailer |
監査レコードの終わりを示す |
監査レコードには、必ず header トークンが入っています。header トークンは、監査トレール内で監査レコードの始まりを示します。ユーザーの動作に起因しないイベントからの監査レコードを除き、どの監査レコードにも subject トークンが入っています。ユーザーに起因するイベントの場合、この 2 つのトークンはイベントを引き起こしたプロセスの値を参照します。非同期イベントの場合、process トークンはシステムを参照します。
acl トークン
acl トークンには、アクセス制御リストに関する情報を記録します。次の 4 つの固定フィールドがあります。
-
acl トークンであることを特定するトークン ID
-
ACL タイプを指定するフィールド
-
ACL ID フィールド
-
ACL に関連付けるアクセス権を一覧するフィールド
praudit コマンドでは、acl トークンは次のように表示されます。
acl,tpanero,staff,0755 |
次の図に acl トークンの形式を示します。
図 23–4 acl トークンの形式
arbitrary トークン
arbitrary トークンは、監査トレール用にデータをカプセル化します。4 つの固定長フィールドと 1 つのデータ配列からなっています。固定長フィールドは次のとおりです。
-
arbitrary トークンであることを特定するトークン ID
-
推奨される形式フィールド (16 進など)
-
カプセル化するデータのサイズを指定する (短い形式など) サイズフィールド
-
後続の項目数を指定するカウントフィールド
トークンの残りの部分は、指定された形式の 1 つまたは複数の項目からなっています。praudit コマンドでは、arbitrary トークンは次のように表示されます。
arbitrary,decimal,int,1 42 |
次の図に arbitrary トークンの形式を示します。
図 23–5 arbitrary トークンの形式
表 23–5 arbitrary トークンの出力形式フィールドの値|
値 |
動作 |
|---|---|
|
AUP_BINARY |
日付が 2 進形式で出力される |
|
AUP_OCTAL |
日付が 8 進形式で出力される |
|
AUP_DECIMAL |
日付が 10 進形式で出力される |
|
AUP_HEX |
日付が 16 進形式で出力される |
|
AUP_STRING |
日付が文字列で出力される |
表 23–6 arbitrary トークンの項目サイズフィールドの値
|
値 |
動作 |
|---|---|
|
AUR_BYTE |
データはバイト単位 (1 バイト) |
|
AUR_SHORT |
データは短い形式の単位 (2 バイト) |
|
AUR_LONG |
データは長い形式の単位 (4 バイト) |
arg トークン
arg トークンには、システムコールの引数情報 (システムコールの引数番号、引数の値、およびオプションの説明) が含まれています。このトークンを使用すると、監査レコード内で 32 ビット整数のシステムコール引数を指定できます。次の 5 つのフィールドがあります。
-
argトークンであることを特定するトークン ID
-
トークンが参照するシステムコールの引数の ID
-
引数の値
-
テキスト文字列の長さ
-
テキスト文字列
praudit コマンドでは、arg トークンは次のように表示されます。
argument,1,0x00000000,addr |
図 23–6 arg トークンの形式
attr トークン
attr トークンには、ファイル v ノードからの情報が含まれています。次のトークンには 7 つのフィールドがあります。
-
attr トークンであることを特定するトークン ID
-
ファイルのアクセスモードと種類
-
所有者のユーザー ID
-
所有者のグループ ID
-
ファイルシステム ID
-
i ノード ID
-
ファイルが示すデバイス ID
ファイルシステム ID とデバイス ID の詳細は、statvfs(2) のマニュアルページを参照してください。
attr トークンには通常、path トークンが付いています。attr トークンはパスの検索中に生成されます。パス検索エラーが発生すると、必要なファイル情報を取得するための v ノードが利用できません。このため、attr トークンは監査レコードの一部として組み込まれません。praudit コマンドでは、attr トークンは次のように表示されます。
attribute,100555,root,staff,1805,13871,-4288 |
図 23–7 attr トークンの形式
exec_args トークン
exec_args トークンは、 exec() システムコールへの引数を記録します。次の 2 つの固定フィールドがあります。
-
exec_args トークンであることを特定するトークン ID
-
exec() システムコールに渡す引数の数を表すカウント
このトークンの残りの部分は、0 個以上の NULL で終わる文字列からなっています。praudit コマンドでは、 exec_args トークンは次のように表示されます。
vi,/etc/security/audit_user |
図 23–8 exec_args トークンの形式
注 –
exec_args トークンは、監査ポリシー argv が有効なときにだけ出力されます。
exec_env トークン
exec_envトークンは、exec() システムコールの現在の環境変数を記録します。次の 2 つの固定フィールドがあります。
-
exec_env トークンであることを特定するトークン ID
-
exec() システムコールに渡す引数の数を表すカウント
このトークンの残りの部分は、0 個以上の NULL で終わる文字列からなっています。praudit コマンドでは、exec_env トークンは次のように表示されます。
exec_env,25, GROUP=staff,HOME=/export/home/matrix,HOST=mestrix,HOSTTYPE=sun4u,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=192.168.13.5,SHELL=/usr/bin/csh,SHLVL=1, TERM=dtterm,TZ=US/Pacific,USER=matrix,VENDOR=sun |
図 23–9 exec_env トークンの形式
注 –
exec_env トークンは、監査ポリシー arge が有効なときにだけ出力されます。
exit トークン
exit トークンは、プログラムの終了状態を記録します。次のフィールドがあります。
-
exit トークンであることを特定するトークン ID
-
exit() システムコールに渡されるプログラムの終了状態
-
終了状態を記述するか、システムエラー番号を示す戻り値
praudit コマンドでは、exit トークンは次のように表示されます。
exit,Error 0,0 |
次の図に exit トークンの形式を示します。
図 23–10 exit トークンの形式
file トークン
file トークンは、監査デーモンによって生成される特殊なトークンです。このトークンは、古い監査ファイルが終了した時点で、新しい監査ファイルの開始と古い監査ファイルの終了をマークします。監査デーモンは、このトークンを含む特殊な監査レコードを構築して、連続する監査ファイルを 1 つの監査トレールに「リンク」します。次の 4 つのフィールドがあります。
-
file トークンであることを特定するトークン ID
-
ファイルが作成または閉じた日時を識別する時刻と日付のスタンプ
-
NULL 終了文字を含むファイル名のバイト数
-
NULL で終了するファイル名を保持するフィールド
praudit コマンドでは、file トークンは次のように表示されます。
file,Tue Sep 1 13:32:42 1992, + 79249 msec, /var/audit/localhost/files/19990901202558.19990901203241.quisp |
図 23–11 file トークンの形式
group トークン (現在は使用しない)
このトークンは、newgroups トークンに置き換えられています。newgroups トークンは同じ種類の情報を少ない領域で提供します。ここでは完全を期すために group トークンについて説明しますが、アプリケーション設計者は newgroups トークンを使用してください。praudit の出力では、どちらのトークン ID にも group というラベルが付いているため、praudit がこれら 2 つのトークンを区別しない点に注意してください。
group トークンは、プロセスの資格からグループエントリを記録します。group トークンには次の 2 つの固定長フィールドがあります。
-
group トークンであることを特定するトークン ID
-
サイズが NGROUPS_MAX (16) のグループエントリの配列
このトークンの残りの部分は 0 個以上のグループエントリからなっています。praudit コマンドでは、group トークンは次のように表示されます。
group,staff,admin,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1 |
次の図に group トークンの形式を示します。
図 23–12 group トークンの形式
注 –
group トークンは、監査ポリシー group が有効なときにだけ出力されます。
header トークン
header トークンは、監査レコードの始まりをマークし、trailer トークンとの組み合わせでレコード内のほかのすべてのトークンを囲む特殊なトークンです。次の 6 つのフィールドがあります。
-
header トークンであることを特定するトークン ID
-
この監査レコード全体の長さのバイト数。ヘッダーとトレーラを含む
-
この監査レコード構造体のバージョンを特定するバージョン番号
-
このレコードが表す監査イベントの種類を特定する監査イベント ID
-
この監査イベントの特殊な特性を特定する ID 修飾子
-
レコードの作成日時
64 ビットシステムでは、header トークンは、32 ビットタイムスタンプではなく 64 ビットタイムスタンプで表示されます。
praudit では、ioctl() システムコールの header トークンは次のように表示されます。
header,240,1,ioctl(2),es,Tue Sept 1 16:11:44 2001, + 270000 msec |
図 23–13 header トークンの形式
0x4000 PAD_NOTATTR nonattributable event 0x8000 PAD_FAILURE fail audit event |
in_addr トークン
in_addr トークンには、インターネットプロトコルアドレスが含まれます。Solaris 8 リリースから、IPv4 形式、IPv6 形式のいずれかでインターネットアドレスを表示できるようになりました。IPv4 アドレスは 4 バイトを使用します。IPv6 アドレスは、16 バイトを使って種類を記述し、さらに 16 バイトを使用してアドレスを記述します。次の 2 つのフィールドがあります。
-
in_addr トークンであることを特定するトークン ID
-
インターネットアドレス
praudit コマンドでは、in_addr トークンは次のように表示されます。
ip address,129.150.113.7 |
図 23–14 in_addr トークンの形式
ip トークン (現在は使用しない)
ip トークンには、インターネットプロトコルのヘッダーのコピーが含まれます。次の 2 つのフィールドがあります。
-
ip トークンであることを特定するトークン ID
-
IP ヘッダーのコピー (全部で 20 バイト)
praudit コマンドでは、ip トークンは次のように表示されます。
ip address,0.0.0.0 |
IP ヘッダー構造は、/usr/include/netinet/ip.h ファイル内で定義されています。次の図に ip トークンの形式を示します。
図 23–15 ip トークンの形式
ipc トークン
ipc トークンには、特定のIPC オブジェクトを識別するために呼び出し元に使用される System V IPC メッセージ、セマフォ、または共有メモリーハンドルが含まれています。次の 3 つのフィールドがあります。
-
IPC トークンであることを特定するトークン ID
-
IPC オブジェクトの形式を指定する形式フィールド
-
IPC オブジェクトを識別するハンドル
praudit コマンドでは、ipc トークンは次のように表示されます。
IPC,msg,3 |
注 –
IPC オブジェクト識別子は、コンテキストに依存しない Solaris 監査トークンに準拠していません。IPC オブジェクトを一意に識別するグローバルな「名前」はありません。代わりに、IPC オブジェクトはハンドルで識別されます。これらのハンドルは、IPC オブジェクトの動作中にのみ有効です。しかし IPC オブジェクトの識別は問題となりません。System V の IPC メカニズムはあまり使用されず、すべてのメカニズムが同じ監査クラスを共有するからです。
次の表は、IPC オブジェクトの形式フィールドに指定できる値の一覧です。値は /usr/include/bsm/audit.h ファイル内で定義されます。
表 23–7 IPC オブジェクトの形式フィールドの値|
名前 |
値 |
説明 |
|---|---|---|
|
AU_IPC_MSG |
1 |
IPC メッセージオブジェクト |
|
AU_IPC_SEM |
2 |
IPC セマフォオブジェクト |
|
AU_IPC_SHM |
3 |
IPC 共有メモリーオブジェクト |
図 23–16 ipc トークンの形式
ipc_perm トークン
ipc_perm トークンには、System V の IPC アクセス情報が含まれています。このトークンは、IPC 共有メモリーイベント、IPC セマフォイベント、および IPC メッセージイベントによって生成される監査レコードに追加されます。次の 8 つのフィールドがあります。
-
ipc_perm トークンであることを特定するトークン ID
-
IPC 所有者のユーザー ID
-
IPC 所有者のグループ ID
-
IPC 作成者のユーザー ID
-
IPC 作成者のグループ ID
-
IPC のアクセスモード
-
IPC のシーケンス番号
-
IPC 鍵の値
praudit コマンドでは、ipc_perm トークンは次のように表示されます。
IPC perm,root,wheel,root,wheel,0,0,0x00000000 |
値は、IPC オブジェクトに関連付けられた ipc_perm 構造から取り出されます。次の図に ipc_perm トークンの形式を示します。
図 23–17 ipc_perm トークンの形式
iport トークン
iport トークンには、TCP (または UDP) ポートアドレスが含まれています。次の 2 つのフィールドがあります。
-
iport トークンであることを特定するトークン ID
-
TCP または UDP ポートのアドレス
praudit コマンドでは、iport トークンは次のように表示されます。
ip port,0xf6d6 |
図 23–18 iport トークンの形式
newgroups トークン
group トークンは、このトークンによって置き換えられます。praudit の出力では、どちらのトークン ID にも group というラベルが付いているため、praudit はこれら 2 つのトークンを区別しない点に注意してください。
newgroups トークンは、プロセスの資格からグループエントリを記録します。次の 2 つの固定長フィールドがあります。
-
newgroups トークンであることを特定するトークン ID
-
この監査レコードに含まれるグループ数を表すカウント
このトークンの残りの部分は 0 個以上のグループエントリからなっています。praudit コマンドでは、newgroups トークンは次のように表示されます。
group, staff, admin |
次の図に newgroups トークンの形式を示します。
図 23–19 newgroups トークンの形式
注 –
newgroups トークンは、監査ポリシー group が有効なときにだけ出力されます。
opaque トークン
opaque トークンには、フォーマットされていないデータが一連のバイトとして含まれています。次の 3 つのフィールドがあります。
-
opaque トークンであることを特定するトークン ID
-
このデータのバイト数
-
バイトデータ配列
praudit コマンドでは、opaque トークンは次のように表示されます。
opaque,12,0x4f5041515545204441544100 |
図 23–20 opaque トークンの形式
path トークン
path トークンには、オブジェクトのアクセスパス情報が含まれています。次のフィールドがあります。
-
path トークンであることを特定するトークン ID
-
パス長のバイト数
-
システムの実ルートを基点としたオブジェクトへの絶対パス
praudit コマンドでは、path トークンは次のように表示されます。パス長フィールドは、表示されません。
path,/etc/security/audit_user |
図 23–21 path トークンの形式
process トークン
process トークンには、信号の受信者など、プロセスに関連するユーザーの情報が含まれています。次の 9 つのフィールドがあります。
-
process トークンであることを特定するトークン ID
-
不変監査 ID
-
実効ユーザー ID
-
実効グループ ID
-
実ユーザー ID
-
実グループ ID
-
プロセス ID
-
監査セッション ID
-
デバイス ID とマシン ID で構成される端末 ID
監査 ID、ユーザー ID、グループ ID、プロセス ID、セッション ID は、短い形式ではなく長い形式です。
注 –
セッション ID、実ユーザー ID、または実グループ ID の processトークンのフィールドを使用できないことがあります。その場合、値は -1 に設定されます。
端末 ID を含むトークンには、いくつかの種類があります。praudit コマンドは、これらの違いを吸収します。このため、端末 ID を含むすべてのトークンで、端末 ID は同じ方法で処理されます。端末 ID は、IP アドレスとポート番号の組み合わせか、デバイス ID です。モデムに接続されたシリアルポートなどのデバイス ID は、0 である可能性があります。端末 ID には、次の書式があります。
デバイス番号の場合、端末 ID は次のようになります。
-
「32 ビットアプリケーション」 – 4 バイトのデバイス番号、4 バイトは未使用
-
「64 ビットアプリケーション」 – 8 バイトのデバイス番号、4 バイトは未使用
Solaris 8 よりも前のリリースのポート番号の場合、端末 ID は次のようになります。
-
「32 ビットアプリケーション」 – 4 バイトのポート番号、4 バイトの IP アドレス
-
「64 ビットアプリケーション」 – 8 バイトのポート番号、4 バイトの IP アドレス
Solaris 8 リリースまたは Solaris 9 リリースのポート番号の場合、端末 ID は次のようになります。
-
「32 ビット IPv4」 – 4 バイトのポート番号、4 バイトの IP タイプ、4 バイトの IP アドレス
-
「32 ビット IPv6」 – 4 バイトのポート番号、4 バイトの IP タイプ、16 バイトの IP アドレス
-
「64 ビット IPv4」 – 8 バイトのポート番号、4 バイトの IP タイプ、4 バイトの IP アドレス
-
「64 ビット IPv6」 – 8 バイトのポート番号、4 バイトの IP タイプ、16 バイトの IP アドレス
praudit コマンドでは、process トークンは次のように表示されます。
process,root,root,wheel,root,wheel,0,0,0,0.0.0.0 |
図 23–22 process トークンの形式
return トークン
return トークンには、システムコールの戻り状態 (u_error) とプロセスの戻り値 (u_rval1) が含まれています。次の 3 つのフィールドがあります。
-
return トークンであることを特定するトークン ID
-
システムコールのエラー状態
-
システムコールの戻り値
return トークンは、必ずシステムコールに関してカーネルによって生成される監査レコードの一部として返されます。このトークンは、アプリケーションを監査中の終了状態と他の戻り値を示します。
praudit コマンドにより return トークンは次のように表示されます。
return,success,0 |
図 23–23 return トークンの形式
seq トークン
seq トークン (シーケンストークン) は、シーケンス番号が含まれるオプションのトークンです。このトークンは、デバッグに使用されます。seq ポリシーが有効な場合は、このトークンが各監査レコードに追加されます。次の 2 つのフィールドがあります。
-
seq トークンであることを特定するトークン ID
-
シーケンス番号が含まれる 32 ビットの符号なし長形式フィールド
シーケンス番号は、監査レコードが生成されて監査トレールに組み込まれるたびに 1 ずつ増分します。praudit コマンドでは、seq トークンは次のように表示されます。
sequence,1292 |
図 23–24 seq トークンの形式
注 –
seq トークンは、監査ポリシー seq が有効なときだけ出力されます。
socket トークン
socket トークンには、インターネットソケットを記述する情報が含まれています。次の 6 つのフィールドがあります。
-
socket トークンであることを特定するトークン ID
-
参照するソケットの型 (TCP、UDP、UNIX) を示すソケット形式フィールド
-
ローカルポートアドレス
-
ローカルのインターネットアドレス
-
リモートポートアドレス
-
リモートのインターネットアドレス
praudit コマンドでは、socket トークンは次のように表示されます。
socket,0x0000,0x0000,0.0.0.0,0x0000,0.0.0.0 |
Solaris 8 リリースから、IPv4 形式、IPv6 形式のいずれかでインターネットアドレスを表示できるようになりました。IPv4 アドレスは 4 バイトを使用します。IPv6 アドレスは、16 バイトを使って種類を記述し、さらに 16 バイトを使ってアドレスを記述します。次の図に socket トークンの形式を示します。
図 23–25 socket トークンの形式
subject トークン
subject トークンには、操作を実行するユーザーまたは実行する予定のユーザーを記述します。形式は process トークンと同じです。次の 9 つのフィールドがあります。
-
subject トークンであることを特定するトークン ID
-
不変監査 ID
-
実効ユーザー ID
-
実効グループ ID
-
実ユーザー ID
-
実グループ ID
-
プロセス ID
-
監査セッション ID
-
デバイス ID とマシン ID で構成される端末 ID
監査 ID、ユーザー ID、グループ ID、プロセス ID、セッション ID は、短い形式ではなく長い形式です。
注 –
セッション ID、実ユーザー ID、または実グループ ID の subject トークンのフィールドを使用できないことがあります。その場合、値は -1 に設定されます。
端末 ID を含むトークンには、いくつかの種類があります。praudit コマンドは、これらの違いを吸収します。このため、端末 ID を含むすべてのトークンで、端末 ID は同じ方法で処理されます。端末 ID は、IP アドレスとポート番号の組み合わせか、デバイス ID です。モデムに接続されたシリアルポートなどのデバイス ID は、0 である可能性があります。端末 ID には、次の書式があります。
デバイス番号の場合、端末 ID は次のようになります。
-
「32 ビットアプリケーション」 – 4 バイトのデバイス番号、4 バイトは未使用
-
「64 ビットアプリケーション」 – 8 バイトのデバイス番号、4 バイトは未使用
Solaris 8 よりも前のリリースのポート番号の場合、端末 ID は次のようになります。
-
「32 ビットアプリケーション」 – 4 バイトのポート番号、4 バイトの IP アドレス
-
「64 ビットアプリケーション」 – 8 バイトのポート番号、4 バイトの IP アドレス
Solaris 8 リリースまたは Solaris 9 リリースのポート番号の場合、端末 ID は次のようになります。
-
「32 ビット IPv4」 – 4 バイトのポート番号、4 バイトの IP タイプ、4 バイトの IP アドレス
-
「32 ビット IPv6」 – 4 バイトのポート番号、4 バイトの IP タイプ、16 バイトの IP アドレス
-
「64 ビット IPv4」 – 8 バイトのポート番号、4 バイトの IP タイプ、4 バイトの IP アドレス
-
「64 ビット IPv6」 – 8 バイトのポート番号、4 バイトの IP タイプ、16 バイトの IP アドレス
subjectトークンは、必ずシステムコールに関してカーネルによって生成される監査レコードの一部として返されます。praudit コマンドでは、subject トークンは次のように表示されます。
subject,cjc,cjc,staff,cjc,staff,424,223,0 0 quisp |
図 23–26 subject トークンの形式
text トークン
text トークンにはテキスト文字列が含まれています。次の 3 つのフィールドがあります。
-
text トークンであることを特定するトークン ID
-
テキスト文字列の長さ
-
テキスト文字列
praudit コマンドでは、text トークンは次のように表示されます。
text,aw_test_token |
図 23–27 text トークンの形式
trailer トークン
header と trailer の 2 つのトークンは、監査レコードの終端を区別し、他のすべてのトークンを囲む特殊なトークンです。header トークンは監査レコードを開始します。 trailer トークンは監査レコードを終了します。 trailer トークンは省略可能です。trailer トークンは、trail 監査ポリシーが設定されているときにだけ、各レコードの最後のトークンとして追加されます。
trailer トークンを含む監査レコードが生成された場合、auditreduce コマンドは、trailer がレコードの header を正しくポイントしているかどうかを確認します。また、trailer トークンを使用すると監査トレールを逆方向に検索できます。
3 つのフィールドがあります。
-
trailer トークンであることを特定するトークン ID
-
レコードの終了を示すパッド番号
-
header トークンと trailerトークンを含む監査レコードの合計文字数
praudit コマンドでは、trailer トークンは次のように表示されます。
trailer,136 |
図 23–28 trailer トークンの形式
デバイス割り当て参照
デバイス割り当てを行うことによって、承認されていないユーザーがリムーバブルメディアを使用できないようにします。ユーザーへのデバイス割り当てを要求することができます。デバイスを使用する権限を拒否することができます。そのような割り当てによって、データの損失、コンピュータウィルスなどのセキュリティ違反からサイトを保護できます。次の節では、デバイス割り当てについて説明します。
デバイス割り当てメカニズムの構成要素
-
allocate、deallocate、dminfo、list_devices コマンド。詳細については、デバイス割り当てコマンドの使用方法を参照してください。
-
/etc/security/device_allocate ファイル。詳細については、device_allocate(4) のマニュアルページを参照してください。
-
/etc/security/device_maps ファイル。詳細については、 device_maps(4) のマニュアルページを参照してください。
-
ロックファイル。割り当て可能デバイスごとに /etc/security/dev ディレクトリに配置する
-
各割り当て可能デバイスに関連付けられた「デバイス特殊ファイル」の変更後の属性
-
各割り当て可能デバイスのデバイスクリーンスクリプト
device_allocate ファイル、device_maps ファイル、およびロックファイルは、ローカル構成ファイルです。これらのファイルは、ネームサービスデータベースとして管理されません。テープドライブ、フロッピーディスクドライブ、およびプリンタはすべて、特定のマシンに接続されるためです。
デバイス割り当てコマンドの使用方法
この節では、管理者向けのコマンド allocate、deallocate、および list_devices のオプションのいくつかについて説明します。これらのオプションにアクセスできるのは、root またはそれと同等の役割のみです。各コマンドについての詳細は、それぞれのマニュアルページを参照してください。
表 23–8 デバイス割り当てコマンドの管理オプション
割り当てエラー状態
割り当て可能デバイスは、デバイス特殊ファイルのモードが 0100 でかつユーザー bin とグループ bin に所有されている場合に、「割り当てエラー状態」になります。割り当てエラー状態になっているデバイスを割り当てたい場合は、そのデバイスの割り当ての強制解除を試みます。-F オプションを指定して deallocate コマンドを実行すると、割り当てが強制的に解除されます。または、allocate -U を使用して、そのデバイスをユーザーに割り当てます。いったんデバイスが割り当てられると、発生したエラーメッセージを調査できます。デバイスの問題が解決したら、強制オプション -F を使用して、デバイスの割り当てエラー状態をクリアする必要があります。
device_maps ファイル
/etc/security/device_maps ファイルを調べると、各割り当て可能デバイスに関連付けられたデバイス名、デバイスの種類、デバイス特殊ファイルを判断できます。 device_maps(4) のマニュアルページを参照してください。デバイスマップは、デバイス割り当てを設定したときに作成されます。device_maps の初期ファイルは、BSM を有効にしたときに、bsmconv によって作成されます。この初期 device_maps ファイルは、あくまでも開始点として使用する必要があります。device_maps は、使用する環境に合わせて拡張およびカスタマイズできます。
device_maps ファイルでは、デバイスごとにデバイス特殊ファイルの割り当てが定義されます。多くの場合、この割り当ては単純ではありません。このファイルによって、各種のプログラムはどのデバイス特殊ファイルがどのデバイスに割り当てられているかを検出できます。たとえば、dminfo コマンドを使用すると、デバイス名、デバイスの種類およびデバイス特殊ファイルを取得して、割り当て可能なデバイスを設定するときに指定できます。dminfo コマンドは、device_maps ファイルを使用してデバイス割り当て情報を報告します。
device-name:device-type:device-list
エントリを次の行に続けるには、行末にバックスラッシュ (\) を付けます。コメントも挿入できます。# を付けると、それに続くすべてのテキストは、行末にバックスラッシュ (\) のない次の改行までコメントになります。どのフィールドでも先行ブランクと後続ブランクを使用できます。
表 23–9 device_maps エントリ内のフィールドの説明
次の例では、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 フィールド内のアスタリスクは、そのデバイスが割り当て可能でないことをシステムに示します。つまり、システム管理者はユーザーにデバイスを使用する前に割り当てたり、あとで割り当てを解除するように要求したりする必要がありません。このフィールドに他の文字列が入っている場合は、デバイスが割り当て可能であることを示します。
device-name;device-type;reserved;reserved;alloc;device-clean |
たとえば、次の行はデバイス名 st0 のエントリを示しています。
st0;st;;;;;/etc/security/lib/st_clean |
エントリを次の行に続けるには、行末にバックスラッシュ (\) を付けます。コメントも挿入できます。# を付けると、それに続くすべてのテキストは、行末にバックスラッシュ (\) のない次の改行までコメントになります。どのフィールドでも先行ブランクと後続ブランクを使用できます。
次の表では、device_allocate ファイル内の各フィールドについて詳しく説明します。
表 23–10 device_allocate エントリ内のフィールドの説明
デバイスクリーンスクリプト
「デバイスクリーン」スクリプトは、使用可能なすべてのデータを再使用する前に物理デバイスからパージするというセキュリティ要件に対応するものです。デフォルトでは、カートリッジテープドライブ、フロッピーディスクドライブ、CD-ROM デバイス、オーディオデバイスには、必要なデバイスクリーンスクリプトが用意されています。この節では、デバイスクリーンスクリプトが実行する処理について説明します。
オブジェクトの再使用
デバイス割り当てによって、オブジェクト再使用の要件の一部が満たされます。デバイスクリーンスクリプトによって、あるユーザーがデバイスに残したデータは確実にクリアされます。データのクリアは、そのデバイスが別のユーザーによって割り当て可能になる前に実行されます。
テープ用のデバイスクリーンスクリプト
st_clean デバイスクリーンスクリプトでは、3 つのテープデバイスがサポートされます。サポートされるテープデバイスは次のとおりです。
-
SCSI 1/4 インチテープ
-
Archive 1/4 インチテープ
-
オープンリール 1/2 インチテープ
st_cleanスクリプトでは、mt コマンドの rewofflオプションを使用して、デバイスのクリーンアップを制御します。詳細は、mt(1) のマニュアルページを参照してください。このスクリプトは、システムブート中に実行されると、デバイスを照会します。スクリプトは、そのデバイスがオンラインになっているかどうかを調べます。デバイスがオンラインになっていた場合、スクリプトはさらに、そのデバイスにメディアが挿入されているかどうかを調べます。1/4 インチのテープデバイスにメディアが挿入されていた場合、このデバイスは割り当てエラー状態になります。このため、管理者はそのデバイスを手動でクリーンアップする必要があります。
通常のシステム操作中に、allocate または deallocate コマンドを対話型モードで実行すると、メディアを取り出すように求めるプロンプトが表示されます。スクリプトは、メディアがデバイスから取り出されるまで一時停止します。
フロッピーディスクと CD-ROM 用のデバイスクリーンスクリプト
次の表に、フロッピーディスクとCD-ROM 用のデバイスクリーンスクリプトを示します。
表 23–11 フロッピーディスクと CD-ROM 用のデバイスクリーンスクリプト|
ディスクデバイスの種類 |
デバイスクリーンスクリプト |
|---|---|
|
フロッピーディスク | |
|
CD-ROM |
スクリプトは、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 を使用すると、スクリプトに実行モードを判断させることができます。次の表は、オプションの一覧です。
表 23–12 デバイスクリーンスクリプトのオプション
デバイス割り当てメカニズムの機能
この節では、デバイス割り当てメカニズムの機能について例を挙げて説明します。
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 |
- © 2010, Oracle Corporation and/or its affiliates