• 検索結果がありません。

Version Page 1

N/A
N/A
Protected

Academic year: 2021

シェア "Version Page 1"

Copied!
60
0
0

読み込み中.... (全文を見る)

全文

(1)

日本ヒューレット・パッカード株式会社

コンサルティング・インテグレーション

統括本部

HP Compartment

Guard

for Linux

Version 2.0

(2)

(c) Copyright 2000-2002 Hewlett-Packard Development Company, L.P (c) Copyright 2002-2004 Hewlett-Packard Japan, Ltd.

本書は著作権法により保護されています。 本書の内容の一部または全部を著作者の許諾なしに複製、改変、および翻訳することは、 著作権法下で許可事項を除き、禁止されています。 日本ヒューレット・パッカード株式会社 〒168-8585 東京都杉並区高井戸東 3 丁目 29 番地 21 号 ℡03-3331-6111(大代表)

(3)

改定履歴

Revision

改定日時 改定個所 改定理由 改定者

Rev1.0 2004/3/4 Version 2.0 Release K.Iwasaki

(4)

HP Compartment Guard for Linux Version 2.0 管理ガイド

目次

1 コンパートメントとは...6 2 コンパートメント間通信...7 3 制限されたファイルシステム(chroot 環境)...8 4 POSIX ケーパビリティと MAC ケーパビリティ ...9 5 動作環境...11 6 インストール方法...12 6.1 インストール... 12 6.2 Version 2.0 へのアップグレード ... 13 7 /etc/hpcg 設定ファイルについて...15 7.1 コンパートメント定義と設定... 15 7.2 サービス定義と設定... 17 7.3 初期ユーザ権限設定ファイル... 18 7.4 ポリシー設定ファイル... 18 7.4.1 boot-user.conf ファイル... 18 7.4.2 policy-user.conf ファイル... 19 7.5 INC・EXC ファイル ... 20 8 コンパートメント管理ユーティリティ...21 8.1 cgstatcap コマンド... 21 8.2 cgaddcomp コマンド ... 22 8.3 cgdelcomp コマンド ... 23 8.4 cgsealcomp コマンド... 23 8.5 cgstatcomp コマンド ... 24 8.6 cggetcomp コマンド... 25 8.7 cgadmlic コマンド ... 25 8.8 cgissecure コマンド ... 25 8.9 cgadmmod コマンド... 26 8.10 cgstatproc コマンド... 26 8.11 cgadmrule コマンド... 28

(5)

8.12 cgsetcomp コマンド... 30 8.13 cgadmserv コマンド ... 31 8.14 cgviewlog コマンド... 33 9 ルールの記述方法と意味...35 9.1 ルールの記述について... 35 9.2 capability ルール... 36 9.3 exec ルール... 37 9.4 file ルール... 39 9.5 inet ルール ... 41 9.6 ipc ルール ... 42 9.7 packet ソケットルール ... 43 9.8 ps ルール... 44 9.9 socket ルール... 45 9.10 unix ドメインソケットルール... 45

10 ログ記録・Alarm 機構・Pass through モード ...47

10.1 ログメッセージ... 47 10.1.1 ログメッセージ... 47 10.1.2 ログ記録するイベントの種類... 48 10.1.3 ログメッセージの記録方法 ... 48 10.1.4 syslog への記録方法 ... 49 10.1.5 ログメッセージ取りこぼしの可能性... 50 10.2 Alarm 機構... 51 10.2.1 Alarm 機構とは ... 51 10.2.2 Alarm スクリプトの実行... 51 10.2.3 Alarm の発生方法... 52 10.3 Pass through モード ... 54 10.3.1 Pass through モードとは... 54 10.3.2 Pass through モードへの切替え... 54 11 参考事項及び注意事項...56 11.1 ケーパビリティ設定の計算方法... 56 11.2 unix ルールのソケットドメインファイル ... 56 11.3 仮想マシンとの相違... 57 11.4 fsdb デーモン ... 57

(6)

11.5 cgalarmd デーモン ... 58

12 おかしいなと思ったら...59

(7)

1 コンパートメントとは

コンパートメントとは、システム上のプロセスのグループの周りに引かれた仮想的な境 界をあらわします。あるコンパートメントに属するプロセスは、同一のコンパートメントに 属するプロセスと通信することが出来ますが、異なるコンパートメントに属するプロセス との通信は出来ません。異なるコンパートメントに属するプロセス同士で通信するには、 コンパートメント間に明示的にコミュニケーションパスを設定しなければなりません。以 下の図において、WEB,DB,CGI,syshi,system 等はそれぞれコンパートメントを表して います。 Compartment Guard は、このコンパートメントのメカニズムを実現するための環境 を提供し、システムを外部からの侵入に対してセキュアな状態に保ことができます。 次の4 つのコンパートメントは、Compartment Guard 起動時にあらかじめ組み込ま れています。 syshi このコンパートメントに属するプロセスは、システム上の全てのプロセスとの通信が許可され ます。このコンパートメントでプログラムを実行した場合は、通常の Linux システムで実行した 場合と変わりません。 kernel カーネルスレッド用のコンパートメントです。 system 多くのサービスが実行されるコンパートメントです。このコンパートメントに属するプロセスは、 他のコンパートメントに属するプロセスと通信したり、ネットワークアクセスは許可されません。

syslog syslogd や klogd などのロギングデーモン用のコンパートメントです。

(8)

2 コンパートメント間通信

コンパートメントの概念からも明らかなように、異なるコンパートメントに属するプロセス 間の通信は通常、禁止されています。しかしながら、Compartment Guard は、シス テム外部からの権限のあるリクエストを受け入れたり、システム内からシステム外へと 正当な応答を返したりすることを許可する必要があります。同様にシステム内のプロセ スは、データベースから検索結果を取得したり、CGI プログラムからの出力を表示した り、e-mail 送信を通知したり等、オペレーションを正当に行うように他のコンパートメン トに属するプロセスにアクセスすることを許可する必要もあります。 Compartment Guard では、コンパートメント間またはコンパートメントと他のシステムとの間にルール を設定し、正当な通信を許可するようコミュニケーションパスを設定します。 上の図では、システムの外からWEB コンパートメントへ eth0 インターフェースを介して http リクエストを受け付け、システムの外から MAIL コンパートメントに eth0 インターフ ェースを介してsmtp 接続を許可し、telnet や ftp 接続を拒否する様子をあらわしてい ます。同様に、WEB コンパートメントから eth1 を通じて他の Server 群と通信を許可し ている様子をあらわしています。また、Compartment Guard システム内では WEB コンパートメントとDB コンパートメント間にコミュニケーションパスを設定しています。

(9)

3 制限されたファイルシステム(chroot 環境)

アプリケーションやデータファイルを制限されたファイルシステム(chroot 環境)に収集 することによって、ファイルシステムの他の部分からの干渉から保護することが可能に なります。chroot 環境にコンパートメントを適用することにより、コンパートメントの独立 性が高まります。

上の図では、web や cgi に関するアプリケーションやデータファイルを/compt/web 及び/compt/cgi に対してそれぞれ収集しています。それぞれのディレクトリに対して chroot 環境を構築することによって、chroot 環境のプロセスからシステム上の他の 部分にあるファイルを見えなくすることが可能です。

(10)

4 POSIX ケーパビリティと MAC ケーパビリティ

Linux では、POSIX ケーパビリティをサポートしています。POSIX ケーパビリティとは、 通常root ユーザが持っている権限をいくつかの種類に分割して、独自の管理レベルを 再構成するための権限分割単位を表します。 詳しくは、以下の文献やカーネルのソースファイル /usr/src/linux/include/linux/capability.h を参照して下さい。 http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2.tx t 以下ではPOSIX ケーパビリティを Linux ケーパビリティと呼びます。

Comparment Guard では、Linux ケーパビリティの他に、Compartment Guard 独自の管理レベルケーパビリティを追加しています。以下では、Compartment Guard 独自の管理レベルケーパビリティを MAC ケーパビリティと呼びます。 MAC ケーパビリティは、以下の通りです。 CAP_MAC_ADMIN Compartment Guard 管理者ケーパビリティ <権限>

ルールの表示/追加/削除

MAC ケーパビリティの設定

カーネルセキュリティモジュールのロード CAP_MAC_SETCID コンパートメント変更ケーパビリティ <権限>

コンパートメントID の変更 CAP_MAC_OVERRIDE_FS ファイルシステムルールのOverride ケーパビリティ <権限>

ファイルシステムルールのチェックを無効にする CAP_MAC_OVERRIDE_NET ネットワークルールのOverride ケーパビリティ <権限>

ネットワークルールのチェックを無効にする CAP_MAC_SIGNAL_SHIELD シグナルを無視するするケーパビリティ <権限> ♦ CAP_MAC_IGNORE_SIGNAL_SHIELD ケーパビリテ ィを持つプロセス以外から送信されるシグナルを無視す る CAP_MAC_IGNORE_SIGNAL_SHIELD シグナルを無視しているプロセスにシグナルを送信するケ ーパビリティ <権限> ♦ CAP_MAC_SIGNAL_SHIELD ケーパビリティを持つプ ロセスにシグナルを送信することが出来る

(11)

CAP_MAC_ALARM ログ記録、アラーム機構を有効にするケーパビリティ <権限> ♦ log_denial ファイルに対するアクセス ♦ log_allow ファイルに対するアクセス ♦ alarm_denial ファイルに対するアクセス ♦ use_syslog ファイルに対する書込みアクセス CAP_MAC_ALL

CAP_MAC_ADMIN

CAP_MAC_SETCID

CAP_MAC_OVERRIDE_FS

CAP_MAC_OVERRIDE_NET

CAP_MAC_IGNORE_SIGNAL_SHIELD

CAP_MAC_SIGNAL_SEALED

CAP_MAC_ALARM の7 つのケーパビリティをまとめたもの CAP_MAC_OVERRIDE

CAP_MAC_OVERRIDE_FS

CAP_MAC_OVERRIDE_NET の2 つのケーパビリティをまとめたもの CAP_LINUX_ALL Linux ケーパビリティをまとめたもの

(12)

5 動作環境

システム要件 Red Hat Enterprise Linux AS 2.1 が稼動している Pentium Pro 以降の

IA-32 システム。

(13)

6 インストール方法

6.1 インストール

インストールを行うには、まずインストールするターゲットマシンの構成に合わせて、ア ーカイブファイルを選択します。また、Compartment Guard のライセンスが必要に なりますので、予め入手しておきます。 次に、アーカイブファイルをインストール先のシステムの/tmp ディレクトリ等で展開しま す。 次に、以下のコマンドを実行してインストールを行います。 インストールスクリプトの指示に従ってインストールを進めます。システムの状況によっ ては"modutils","tux"などのアップグレードを行うように促される場合があります。これ らはRPM パッケージの依存性解決のためです。アップグレードを拒否した場合は、 Compartment Guard はインストールされません。 インストールシェルが正常に終了した場合は、最後に

"Compartment Guard Installation was successfully completed."と表示されま す。 次に、ライセンス・キーを登録します。入手したライセンス・キーのファイルを指定して cgadmlic コマンドを実行します。 Compartment Guard を起動するには、ここでシステムを再起動します。 hpcg-up-2.0.tar.gz UniProcessor 用カーネルを使用する場合 hpcg-smp-2.0.tar.gz SMP 対応カーネルを使用する場合 hpcg-ent-2.0.tar.gz 大容量メモリ(<64GB)対応カーネルを使用する場合 # tar zxf hpcg-XXX-2.0.tar.gz # cd hpcg-2.0 # ./install.sh

(14)

再起動時に、GRUB カーネルローダで、 "Compartment Guard(2.4.25-hpcg2.0)"を選択します。 º カーネルローダにLILO を使用している場合は、再起動する前に/etc/lilo.conf ファイルに以下のようなエントリを加え、lilo コマンドを実行して、エラーの出ない ことを確認しておきます。

6.2 Version

2.0 へのアップグレード

Compartment Guard の旧バージョン(Version 1.0 または Version 1.1)からアップ グレードを行うには、インストールと同様にインストールスクリプトから行います。また、 Compartment Guard Version 2.0 のライセンスが必要になりますので、予め入手 しておきます。

アップグレード行うには、システムを再起動します。ブートセレクタ画面で、 Compartment Guard ではない Linux システムを選択します。

次に、Version 2.0 のアーカイブファイルをアップグレード先のシステムの/tmp ディレ クトリ等で展開します。 次に、以下のコマンドを実行してアップグレードを行います。 インストールスクリプトの指示に従ってアップグレードを進めます。 # shutdown -r now image=/boot/vmlinuz-2.4.25-hpcg2.0 label=Compartment Guard read-only root=/dev/hda1 ※適宜修正する # tar zxf hpcg-XXX-2.0.tar.gz # cd hpcg-2.0 # ./install.sh

(15)

インストールシェルが正常に終了した場合は、最後に

"Compartment Guard Installation was successfully completed."と表示されま す。 次に、ライセンス・キーを登録します。入手したVersion 2.0 のライセンス・キーのファイ ルを指定してcgadmlic コマンドを実行します。 Compartment Guard を起動するには、ここでシステムを再起動します。 再起動時に、GRUB カーネルローダで、 "Compartment Guard(2.4.25-hpcg2.0)"を選択します。 # cgadmlic <license file>

(16)

7 /etc/hpcg 設定ファイルについて

/etc/hpcg ディレクトリには、Compartment Guard の動作に関する設定ファイル 群が収められています。 /etc/hpcg/init ディレクトリ以下のファイルでは、コンパートメント及びサービスの起動 や停止に関する設定を行います。サービスとは、コンパートメントを寄せ集めて、それら のコンパートメント群をひとまとまりとして定義したものです。

7.1 コンパートメント定義と設定

コンパートメントの定義と設定は、/etc/hpcg/init/<compartment>/ディレクトリ以 下のファイルで行います。

<compartment>.services

ファイル

このファイルでは、コンパートメント起動の可/不可、プラグイン起動の可/不可及び コンパートメント独自Setup スクリプト実行の可/不可について設定します。プラグイン とは、コンパートメント間で共通に使われるスクリプトのことであり、 /etc/hpcg/rc.d/plugin に置かれています。 あらかじめ、REGISTER_COMP、DNS、RULE、SEALED の 4 つのプラグインが組み込 まれています。

(17)

❖ foo.service ファイル(例)

comp コンパートメント名に続けて“{”と“}”の間に変数を設定します。設定できる変数 は、disable,plugin,setup です。plugin 及び setup 変数は更に“{”と“}”の間に変数 を設定できます。設定値の終には必ず";"をつけます。プラグイン及び Setup スクリプト は、コンパートメント起動時にはファイルの上から下へ起動操作が行なわれ、コンパー トメント停止時にはファイルの下から上へ停止操作が行なわれます。

comp foo {

disabled no;

plugin REGISTER_COMP; { /* compt first */ disabled no; } plugin DNS { disabled yes; param TLCFG_DNS_INTF "*"; } plugin SEALED { disabled yes; param SEALED TRUE; } setup foo.setup { disabled yes; } plugin RULE { disabled no; param EXC 1; param INC 1; } }

(18)

変数 設定値

disabled yes,no を指定します。 no の場合はコンパートメントの起動が可に、yes の場合は不可になります。

plugin (複数設定可) プラグイン名に続けて、{}の間にサブ変数を指定します。 <サブ変数>

disabled : yes,no を指定。 プラグインの使用をno の場合に可、yes の場合に不可にします。

param : プラグインスクリプトに渡すパラメータを指定します。 setup Setup スクリプト名に続けて、{}の間にサブ変数を指定します。 <サブ変数>

disabled : yes,no を指定。 スクリプトの使用をno の場合に可、yes の場合に不可にします。

arg : setup スクリプトに渡すパラメータを指定します。

<compartment>.rules

ファイル

plugin RULE で disabled 変数を no にした場合に、設定するルールを記述します。

<compartment>.setup

ファイル

setup で disabled 変数を no にした場合に、起動されるシェルスクリプトファイルです。

7.2 サービス定義と設定

サービスの定義と設定は、/etc/hpcg/init/<service>.services ファイルで行います。 ここで、/etc/hpcg/init/sysinit.services はシステム設定ですので、変更しないことを 推奨します。 ここでは、デフォルトで用意されているuser.services サービス定義ファイルの例を紹 介します。 user.services ファイル(例) service サービス名に続けて、{}の間に変数を設定します。設定できる変数は、 service usrinit { disabled no; required no; comp foo; comp bar; }

(19)

disabled,required,comp です。設定値の終には必ず";"をつけます。

変数 設定値

disabled yes,no で指定します。 no の場合はサービスの起動が可に、yes の場合は不可になります。

required yes,no で指定します。 no の場合はサービスの停止が可に、yes の場合は不可になります。

comp (複数設定可) そのサービスに所属させるコンパートメントを指定します。

7.3 初期ユーザ権限設定ファイル

ユーザログイン時の初期権限設定を行う場合は、/etc/hpcg/init/pam/access ファ イルで行います。 以下のフォーマットで、ファイルにエントリを加えます。 ユーザ名:ログインコンパートメント:ログイン時のケーパビリティ: ❖ /etc/hpcg/init/pam/access 設定例 この例では、root ユーザのログインコンパートメントが system、ケーパビリティが CAP_MAC_ADMIN、CAP_MAC_SETCID、CAP_MAC_OVERRIDE_FS とし、 cgadmin ユーザのログインコンパートメントが system、ケーパビリティが CAP_MAC_ADMIN、CAP_MAC_SETCID とし、cgadmin 以外の一般ユーザのロ グインコンパートメントがsystem、ケーパビリティはセットしないように設定しています。 なお、Version 1.1 以降では、Compartment Guard のインストールの際に

cgadmin ユーザは作成されません。/etc/hpcg/init/pam/access ファイルに cgadmin ユーザのエントリも作成されません。

7.4 ポリシー設定ファイル

7.4.1 boot-user.conf ファイル

ログ記録、Alarm 機構、Pass through モードの設定をシステム起動時に有効にする *:system::

cgadmin:system:cap_mac_admin,cap_mac_setcid:

(20)

には、/etc/hpcg/init/policy/boot-user.conf ファイルに記述を行います。詳しくは、 「10 ログ記録・Alarm 機構・Pass through モード」を参照してください。

boot-user.conf ファイルに指定できる変数は以下の表の通りです。

変数 設定値

ALARM_DENIAL アラームを発生させるイベントカテゴリを指定します。

DISABLE_MODULE_LOADING true,false で指定します。true の場合、システム起動の完了 時にカーネルモジュールのロードを禁止します。

LOG_ALLOW Allow ログを取得するイベントカテゴリを指定します。

LOG_DENIAL Denial ログを取得するイベントカテゴリを指定します。

PASS_THROUGH Pass through モードにするイベントカテゴリを指定します。

USE_SYSLOG 0 または 1 で指定します。1 にした場合、ログメッセージ出力を syslog に行います。 なお、/etc/hpcg/init/policy ディレクトリに予め存在している boot-sys.conf ファイ ルはシステムデフォルトの設定値が記述されています。boot-user.conf ファイルが作 成されていない場合は、boot-sys.conf ファイルの内容がシステムのデフォルト値とし て反映されています。デフォルト値を変更する場合は、boot-user.conf ファイルに変 更値を記述するとその内容が反映されます。boot-sys.conf ファイルは直接編集しな いようにして下さい。また、boot-sys.conf ファイルは所有者が root ユーザ(uid=0)で なければなりません。root ユーザ以外が所有者になっている場合は、内容が読込ま れません。

7.4.2 policy-user.conf ファイル

/etc/hpcg/init/policy ディレクトリ以下に存在するファイルで、名前が“-user.conf” 及び“-sys.conf”で終るファイルの所有者を定義します(ただし、policy-user.conf ファ イル及びpolicy-sys.conf ファイルは対象外です)。policy-user.conf ファイルで指定 したユーザとファイルの所有者が異なる場合は、そのファイルの内容は読込まれませ ん。

policy-user.conf ファイルには、OWNER_CHECK と OWNER_USER の値を指定しま す。OWNER_CHECK には、true か false を指定し、true の場合にはファイル所有者 のチェックを行います。false の場合は、ファイル所有者のチェックを行いません。 OWNER_USER の値は、OWNER_CHECK が true の場合に有効になり、チェックする ファイル所有者を指定します。OWNER_USER には 1 ユーザのみ指定可能です。 以下の例は、ファイル所有者がcgadmin であることをチェックする場合の記述です。

(21)

なお、/etc/hpcg/init/policy ディレクトリに予め存在している policy-sys.conf ファイ ルはシステムデフォルトの設定値です。policy-user.conf ファイルが作成されていな い場合は、policy-sys.conf ファイルの内容がシステムのデフォルト値として反映され ています。デフォルト値を変更する場合は、policy-user.conf ファイルに変更値を記 述するとその内容が反映されます。policy-sys.conf ファイルは直接編集しないように して下さい。

7.5 INC・EXC ファイル

/etc/hpcg/init/<compartment>ディレクトリには、INC ファイル

(<compartment>.rules-inc)、及び EXC ファイル(<compartment>.rules-exc)を 配置することが出来ます。syshi,system,kernel,syslog コンパートメントでは、予めこれ ら2 つのファイルが作成されています。 INC ファイル、EXC ファイルにはルールを記述します。 コンパートメントが起動する際には、最初に<compartment>.rules ファイルに記述さ れたルールが読込まれ、ロードされます。Compartment Guard はルールの重複 (例えば、同一コンパートメントで、同じファイルに異なるファイルアクセスを設定するル ール)を許可していないため、ルールの重複を回避するには、一旦既にロードされてい るルールを削除してから、新たなルールをロードする必要があります。 EXC ファイルには、コンパートメントが起動する際に<compartment>.rules ファイル から読込まれるルールのうち、一旦削除すべきルールを記述します。続いて、INC ファ イルに新たにロードされるべきルールを記述します。 INC ファイル、EXC ファイルをコンパートメント起動時に読込ませるには、 <compartment>.services ファイルの RULE プラグインに以下のように記述します。 EXC 及び INC に”1”以外のパラメータを指定すると、コンパートメント起動時に EXC フ ァイル及びINC ファイルは読込まれません。 OWNER_CHECK=true OWNER_USER=cgadmin plugin RULE { disabled no; param EXC 1; param INC 1; }

(22)

8 コンパートメント管理ユーティリティ

以下は、Compartment Guard におけるコンパートメント管理ユーティリティ(コマン ド)の機能の要約です。 また、次のコンパートメント名はCompartment Guard 専用のコンパートメント名とし て予約されていますので、使用しないで下さい。 コンパートメント名 “sys”で始まる名前(syshi、system、syslog など)、 kernel、default、及び“hpcg-”で始まる名前

8.1 cgstatcap コマンド

現在の管理レベルケーパビリティをリスト表示します。 MAC ケーパビリティを表示するには、オプションを指定せずに cgstatcap コマンドを 実行するか、-h オプションを指定します。 cgstatcap 現在の管理レベルケーパビリティを表示 cgaddcomp 新規のコンパートメントを追加 cgdelcomp コンパートメントを削除 cgsealcomp プロセスがUID を 0 にすることを許可/不許可 cgstatcomp 現在のコンパートメント名、シールフラグ、コンパートメントID をリスト cggetcomp コンパートメント名を表示 cgadmlic ライセンス・キーの登録、管理

cgissecure システムがCompartment Guard であるかどうかをチェック

cgadmmod カーネルモジュールのロード/アンロードの可/不可を切替え

cgstatproc プロセスが属するコンパートメント名とケーパビリティをリスト

cgadmrule コンパートメントコミュニケーションルールを設定

cgsetcomp コンパートメントの切替え

cgadmserv サービスの起動、停止、状態表示

(23)

この例では、system コンパートメントで CAP_MAC_ADMIN、CAP_MAC_SETCID、 CAP_MAC_OVERRIDE_FS がセットされていることがわかります。ケーパビリティの前 に"-"がついているものは、ケーパビリティがセットされていないことを意味します。 また、pie の表示は、それぞれ permitted,inheritable,effective のケーパビリティビ ット状態を示しています。"pie"または"p_e"となっている場合に限り、そのケーパビリテ ィが設定されます。 現在のLinux ケーパビリティを表示するには、-l オプションを指定します。

MAC ケーパビリティおよび Linux ケーパビリティを同時に表示するには、-a オプション を指定します。 MAC ケーパビリティおよび Linux ケーパビリティの計算方法については、参考事項で 詳しく解説します。

8.2 cgaddcomp コマンド

コンパートメントを作成します。 # cgstatcap -h Compartment: system MAC capabilities: pie CAP_MAC_ADMIN pie CAP_MAC_SETCID ___ -CAP_MAC_OVERRIDE_NET pie CAP_MAC_OVERRIDE_FS ___ -CAP_MAC_IGNORE_SIGNAL_SHIELD ___ -CAP_MAC_SIGNAL_SHIELD ___ -CAP_MAC_ALARM # cgstatcap -l Compartment: system Linux capabilities: p_e CAP_CHOWN p_e CAP_DAC_OVERRIDE p_e CAP_DAC_READ_SEARCH ___ -CAP_SETPCAP ... 以下省略

(24)

作成するコンパートメント名を引数に指定します。 これにより、コンパートメント名foo がシステムに登録され、/etc/hpcg/init/foo ディ レクトリに初期設定ファイルが作成されます。 コンパートメントをシステムに登録するだけで、初期設定ファイルを作成しない場合に は、-t オプションに続けてコンパートメント名を指定します。

8.3 cgdelcomp コマンド

コンパートメントを削除します。 削除するコンパートメントを引数に指定します。この時、 初期設定ファイルの削除確認のメッセージが表示されます。 この場合、/etc/hpcg/init/foo 以下のファイルがすべて削除されます。 /etc/hpcg/init/foo ディレクトリ自身も削除されます。 削除確認メッセージを表示させたくない場合は、-f オプションに続けてコンパートメント を指定します。この場合初期設定ファイルは強制削除されます。

8.4 cgsealcomp コマンド

コンパートメント上で、プロセスがUID 0 で起動することを許可(unseal)、あるいは不 許可(seal)にします。 コンパートメントの現在のseal/unseal 状態を表示するには、-s オプションに続けてコ ンパートメント名を指定します。 # cgaddcomp foo # cgaddcomp -t foo # cgdelcomp foo

Delete compartment initialization files [Yy/Nn]?: y

# cgdelcomp -f foo

# cgsealcomp -s foo

(25)

コンパートメントをseal 状態にするには、cgsealcomp コマンドに続けてコンパートメ ント名を指定します。 コンパートメントをunseal 状態にするには、-u オプションに続けてコンパートメント名を 指定します。

8.5 cgstatcomp コマンド

システムに登録されたコンパートメント名をリスト表示します。 コンパートメント名だけを表示させる場合は、オプションを指定せずにコマンドを実行し ます。 コンパートメントID(CID)、seal 状態を表示させるには、-s オプションを指定します。

この実行例では、test コンパートメンとの CID は 1000 で、Seal 状態にあることがわか ります。 # cgsealcomp foo # cgsealcomp -u foo # cgstatcomp syshi kernel system syslog test # cgstatcomp ‐s CID NAME 1 - syshi 3 - kernel 10 - syslog 11 ‐ syslog 1000 s test

(26)

8.6 cggetcomp コマンド

現在実行しているプロセスのコンパートメント名を表示します。 この場合、現在実行しているプロセスである/bin/bash が system コンパートメントに 属していることを表します。

8.7 cgadmlic コマンド

Compartment Guard のライセンス・キーを登録します。 ライセンス・キーを登録するには、ライセンス・キーを格納したファイルを引数に指定し ます。 ライセンス・キーを登録した後の、バイナリ形式ライセンス情報をチェックするには、-c オプションを指定します。 ライセンス・キーを登録する前の、ASCII 形式ライセンス情報をチェックするには、-n オ プションを指定してコマンドを実行し、標準入力からライセンス・キーを入力します。

8.8 cgissecure コマンド

システムがCompartment Guard であるかどうかを確認します。 # cggetcomp system

# cgadmlic <ASCII license file>

# cgadmlic -c

Examing binary license...

Target Compartment Guard Version: 2.0 Node id least 40-bit: c5 dd d6 00 00 Is valid license data: yes

# cgadmlic -n

Examing ASCII license... ライセンス・キーを入力 ...

(27)

このとき、何も表示されない場合は、リターンコードが0 に設定され、Compartment Guard であることを示しています。 また、明示的にメッセージを出力させる場合は、-v オプションをつけます。

8.9 cgadmmod コマンド

カーネルモジュールのロード/アンロードを許可、あるいは不許可にします。 現在の許可/不許可の状態を表示するには、-s オプションを指定します。 ロード/アンロードを許可する場合は、-e オプションを指定します。 ロード/アンロードを不許可する場合は、-d オプションを指定します。

8.10 cgstatproc コマンド

システム上で実行されているプロセスをリスト表示します。 # cgissecure # cgissecure ‐v

HP Compartment Guard for Linux version 2.0

# cgadmmod ‐s

Module loading/unloading is permitted

# cgadmmod -e

(28)

プロセスID、実行されているコンパートメント名、コマンド名を表示します。 追加情報を表示させるには、-f オプションを指定します。 追加情報として、ケーパビリティの設定状態が“lSsfnca”という形式で表示されます。こ こで、l は CAP_MAC_ALARM、S は CAP_MAC_SIGNAL_SHEILD、s は CAP_MAC_IGNORE_SIGNAL_SHEILD、f は CAP_MAC_OVERRIDE_FS、n は CAP_MAC_OVERRIDE_NET、c は CAP_MAC_SETCID、a は CAP_MAC_ADMIN にそれぞれ対応します。

上の表示例では、syslogd に CAP_MAC_OVERRIDE_NET が、bash に

CAP_MAC_OVERRIDE_FS、CAP_MAC_SETCID、CAP_MAC_ADMIN がセットさ れていることがわかります。 特定のプロセスについてのみ表示させるには、-p オプションに続けてプロセス ID を指 定します。 # cgstatproc │ more PID COMPT CMD 1 system init 2 kernel keventd 3 kernel kapm-idled 4 kernel ksoftirqd_CPU0 5 kernel kswapd ... # cgstatproc -f │ more PID CAPS COMPT CMD 1 --- system init 2 --- kernel keventd 3 --- kernel kapm-ideld ・・・ 487 ----n-- syslog syslogd ・・・

1460 ---f-ca system bash ・・・

(29)

さらに、特定のプロセスに設定されたケーパビリティを表示するには、-c オプションを更 に指定します。 この場合、Linux ケーパビリティも表示されます。

8.11 cgadmrule コマンド

ルールの表示、設定、削除を行います。このコマンドを実行するには、 CAP_MAC_ADMIN ケーパビリティが設定されている必要があります。 現在設定されているルールを表示するには、-l オプションをつけます。cgadmrule コ マンドに引数を何もつけない場合は、この動作と同じになります。 ❖ 出力表示例 ここで、ルールの最後に追加されているフィールドrid は、ルール ID を表します。この場 合、ルールID は 6 になっています。 ルールを設定するには、引数から、ファイルから、標準入力から入力する方法の3 通り の方法があります。 引数から入力するには、-a オプションに続けて、ルールをダブルクォーテーションで囲 みます ファイルから入力するには、-a オプションに続けて、設定するルールが記述されたファ イルを指定します。

cgadmrule に、7-bit ASCII でない文字を含むファイルを入力した場合は、 cgadmrule: Warning: non-ASCII character found in rule file と出力されます。このメッセージが出ても、ルールの読込み自体は継続されます。 # cgstatproc -p 1460 PID COMPT CMD 1460 system bash # cgstatproc -p 1460 -c 表示形式は cgstatcap の出力と同じ # cgadmrule -l

file { comp syshi; filename /; access read,write,execute; rid 6; }

(30)

標準入力から入力するには、-a オプションをつけて<Enter>とし、ルールを入力して <Ctrl-d>とします。 ルールを削除するには、ルールID から、ファイルから、標準入力から削除する方法の 3 通りの方法があります。 ルールID から削除するには、-d オプションに続けてルール ID を指定します。 ファイルから削除するには、-d オプションに続けて削除するルールが記述されたファイ ルを指定します。 標準入力から削除するには、-d オプションをつけて<Enter>とし、ルールを入力して <Ctrl-d>とします。 # cgadmrule -a <rulefile> # cgadmrule -a <Enter>

file { comp foo; filename /compt/foo; access read; } <Ctrl-d>

# cgadmrule -d 45

# cgadmrule -d <rulefile>

# cgadmrule -d <Enter>

(31)

8.12 cgsetcomp コマンド

コンパートメントを切替えます。 このコマンドには、CAP_MAC_SETCID ケーパビリティが必要です。 system コンパートメントから foo コンパートメントに切替えます。 切替え先のコンパートメントでプログラムを実行するには、-c オプションに続けてプログ ラム名を指定します。 ただし、この場合は実行シェルのコンパートメントは切替わりません。 さらに、実行プログラムのケーパビリティ設定を行うには、-p オプションを指定します。 ケーパビリティを付加する場合は"+"を、外す場合は"-"をケーパビリティの先頭につけ て指定します。ケーパビリティを複数指定する場合は、カンマで区切ります。 httpd プロセスの CAP_MAC_ADMIN と CAP_MAC_SETCID ケーパビリティがセッ トされていないことがわかります。 # cggetcomp system # cgsetcomp foo # cggetcomp foo # cggetcomp system

# cgsetcomp web -c /usr/sbin/httpd # cggetcomp

system

# cgstatproc │ grep httpd PID COMPT CMD

1490 web /usr/sbin/httpd

# cgsetcomp web -c /usr/sbin/httpd ‐p -CAP_MAC_ADMIN,-CAP_MAC_SETCID # cgstatproc -f │ grep httpd

PID CAPS COMPT CMD

(32)

また、-c オプションを指定せずに、-p オプションを指定した場合は、ケーパビリティの設 定が変更されて、コンパートメントが切替わります。

8.13 cgadmserv コマンド

サービス及びコンパートメントの起動、停止、状態表示を行います。 サービス及びコンパートメントの状態を表示させるには、-l オプションを指定します。特 定のサービスの状態を表示させるには続けて-s オプションを、特定のコンパートメント の状態を表示させるには-c オプションを併せて指定します。 # cgstatcap Compartment: system MAC capabilities: pie CAP_MAC_ADMIN pie CAP_MAC_SETCID ___ -CAP_MAC_OVERRIDE_NET pie CAP_MAC_OVERRIDE_FS ___ -CAP_MAC_IGNORE_SIGNAL_SHEILD ___ -CAP_MAC_SIGNAL_SHEILD ___ -CAP_MAC_ALARM

# cgsetcomp web -p +CAP_MAC_OVERRIDE_NET # cgstatcap Compartment: web MAC capabilities: pie CAP_MAC_ADMIN pie CAP_MAC_SETCID pie CAP_MAC_OVERRIDE_NET pie CAP_MAC_OVERRIDE_FS ___ -CAP_MAC_IGNORE_SIGNAL_SHEILD ___ -CAP_MAC_SIGNAL_SHEILD ___ -CAP_MAC_ALARM

(33)

上の表示例から、usrinit サービスが開始しており、usrinit サービスのメンバーである foo コンパートメントが開始しているのがわかります。また、foo コンパートメントの REGISTER_COMP プラグイン、RULE プラグインが開始しており、DNS プラグインと foo.setup プラグインが停止しているのがわかります。"---”は停止状態を表します。 また、コンパートメント状態表示の2 つの数字は、左側が起動カウントを、右側が参照 カウントをそれぞれ表します。通常、コンパートメントは複数のサービスに所属すること があり、あるサービスで起動されていなくても、別のサービスで起動されている場合が あります。起動カウントは、そのコンパートメントが実際に起動された回数を表していま す。参照カウントは、他のサービスからそのコンパートメントを起動/停止する度に増 加/減少します。また、起動カウントは参照カウントを越えることはありません。つまり、 参照カウントが0 の場合は、そのコンパートメントは起動できません。これはすなわち、 コンパートメントは必ずいずれかのサービスに所属しなければならないことを意味しま す。コンパートメントを新規に追加した場合のデフォルトの所属サービスはusrinit にな っています。 サービスを起動/停止するには、-m オプションに続けて start/stop を指定し、-s オプ ションに続けてサービス名を指定します。 service1 サービスを起動します。 ただし、/etc/hpcg/init/user.services ファイルのサービス定義で、disable 変数が yes に設定されている場合は、起動されません。 service2 サービスを停止します。 ただし、/etc/hpcg/init/user.service ファイルのサービス定義で、required 変数が yes に設定されている場合は、停止されません。 コンパートメントを起動/停止するには、-m オプションに続けて start/stop を指定し、 # cgadmserv -m start -s service1

# cgadmserv -m stop -s service2 # cgadmserv -l -s usrinit service usrinit started comp foo started 1 1

plugin REGISTER_COMP start plugin DNS ---

plugin foo.setup --- plugin RULE started

(34)

-c オプションに続けてコンパートメント名を指定します。 foo コンパートメントを起動し ます。 ただし、/etc/hpcg/init/foo/foo.services ファイルのコンパートメント定義で、 disable 変数が yes に設定されている場合は、起動されません。また、起動しようとす るコンパートメントが所属するサービスが起動されていない場合は、コンパートメントは 起動されません。 bar コンパートメントを停止します。 -m オプションに続けて、restart を指定した場合は、サービス/コンパートメントを再起 動します。この操作は、停止してから起動する動作と同じですので、disable 変数や required 変数に従います。 また、-m オプションと共に、特定のサービス/コンパートメントを指定せずに、-a オプ ションを指定した場合は、すべてのサービス/コンパートメントを起動/停止します。

8.14 cgviewlog コマンド

/var/log/hpcg/ディレクトリ以下のファイルから、“hpcg:”の含まれているログ行の みを抽出して表示します。ただし、ログ記録をsyslog に残すように設定している場合は、 syslog から抽出して表示します。 -H オプションに続けて、ホスト名を指定した場合は、指定したホスト名が含まれたログ だけを表示します。 -c オプションに続けてコンパートメント ID を指定した場合は、指定したコンパートメント ID が含まれたログだけを表示します。 -t オプションに続けてイベントタイプ(denial または allow)を指定した場合は、指定し たイベントタイプのログだけを表示します。 --csv オプションを指定した場合は、各イベントカテゴリ別のログの計数値を CSV (Comma Separated Value)形式で出力します。計数値を集計する単位は 1 日で す。

socket,inet,unix,packet,ipc,file,ps,su の順に、各ログカテゴリについてのイベント # cgadmserv -m start -c foo

# cgadmserv -m stop -c bar

(35)

計数値を10 進数で表します。左端のデータ(date フィールド)はログ記録された日付 (月/日)です。

# cgviewlog --csv

date,socket,inet,unix,packet,ipc,file,ps,su 1/19,0,3,0,0,0,0,0,0

(36)

9 ルールの記述方法と意味

9.1 ルールの記述について

ルールの記述は、BNF 記法(Backus-Naur Form)に基づいています。 各ルールの記述は、ルール名で始めて、"{"と"}"の間に一連のフィールドとその設定値 を記述していきます。各フィールドと設定値は";"で区切ります。 設定されたルールには、ルールを識別するためのルールID がつきます。cgadmrule コマンドで設定されたルールを表示させた時に、各ルールの最後に追加されているフィ ールドがルールID になります。ルール ID は 1 から始まる整数で、カーネルにより自動 的に割り当てられます。 また、"$"で始まる環境変数の記述をサポートしています。環境変数が設定されていな い場合は、ルール設定時にエラーになります。

rule = type '{' ( element ) ';' )* '}'; type = symbol;

element = name value (',' value )* │ name '*'

│ name '{}' │ name ; name = symbol;

value = atom │ string │ range ; range = int '-' int ;

int = { integer in decimal };

string = { quoted string allowing usual escapes }; symbol = { token with no space starting with alpha }; atom = { token with no space };

DNS_SERVER="192.168.1.2, 10.1.1.10" inet { from.comp *;

to.port $DNS_SERVER; port domain;

(37)

cgadmrule コマンドで、7-bit ASCII でない文字を含むファイルを入力した場合は、 cgadmrule: Warning: non-ASCII character found in rule file

と出力されます。このメッセージが出ても、ルールの読込み自体は継続されます。 以下は、各ルール設定の定義の要約です。 capability コンパートメントに許可されたケーパビリティ境界を定義 exec ファイルの実行に関する扱いを定義 file ファイルのアクセス制御を定義 inet IPv4 プロトコルの通信を制御 ipc プロセス間通信(IPC)の使用を制御 packet Packet ソケットの通信を制御 ps コンパートメント間のプロセスオブジェクトの可視性を制御 socket ソケットファミリーの使用を制御 unix Unix ドメインソケットの通信を制御

9.2 capability ルール

capability ルールは、コンパートメントのケーパビリティ境界を設定します。 CAP_MAC_ADMIN ケーパビリティのついたユーザは capability ルールは適用され ません。つまり、このようなユーザには、ケーパビリティを制限するようなルールが設定 されていても、ケーパビリティ制限は適用されません。 以下の表に、capability ルールのフィールドレコードを示します。

capability ルールフィールド

フィールド名 デフォルト値 説明 comp なし コンパートメント名 permitted.* なし 以下のうちのどれか1 つ permitted.raise permitted.lower permitted.filter ケーパビリティの計算処理を制御します。 ※ケーパビリティの計算方法は、参考事項を参照して下さい。 permitted,inheritable,effective それぞれのケーパビリティビットについて、以下の modifier が存在します。

(38)

.raise 指定したケーパビリティのpermitted ビットを立てます。 .lower 指定したケーパビリティのpermitted ビットを落します。 .filter 指定したケーパビリティのは落とします。 permitted ビットを保存し、他のケーパビリティビット ❖ 設定例

9.3 exec ルール

exec ルールでは、実行ファイルを実行する際にプロセスのセキュリティ属性を制御し ます。exec ルールはプロセスが最終的に実行されるコンパートメント、ケーパビリティ、 を制御します。 以下の表に、exec ルールのフィールドレコードを示します。

exec ルールフィールド

フィールド名 デフォルト値 説明 from.comp (必須) なし exec を実行しようとするコンパートメント名。 *を指定した場合は、全てのコンパートメント名になる。 filename (必須) なし 実行されるファイル/ディレクトリの絶対パスを指定。 comp なし 指定した場合、そのコンパートメントに切替わって実行され る。 uid なし 指定した場合、そのユーザ名、またはユーザID に切替わ って実行される。 指定しない場合は、現在のまま実行される。 gid なし 指定した場合、そのグループ名、またはグループID に切 替わって実行される。 指定しない場合は、現在のまま実行される。 effective.* なし 以下のうちどれか1 つ

permitted.raise

permitted.lower

permitted.filter

capability { comp syslog;

permitted.lower CAP_LINUX_ALL, CAP_MAC_ALL; permitted.raise CAP_SYS_PTRACE, CAP_SYS_RAWIO, CAP_NET_BIND_SERVICE; }

(39)

ケーパビリティの計算過程を制御します。 inheritable.* なし 以下のうちどれか1 つ

permitted.raise

permitted.lower

permitted.filter ケーパビリティの計算過程を制御します。 permitted.* なし 以下のうちどれか1 つ

permitted.raise

permitted.lower

permitted.filter ケーパビリティの計算過程を制御します。 ※ケーパビリティの計算方法は、参考事項を参照して下さい。 permitted,inheritable,effective それぞれのケーパビリティビットについて、以下の modifier が存在します。 .raise 指定したケーパビリティの対応ビットを立てます。 .lower 指定したケーパビリティの対応ビットを落とします。 .filter 指定したケーパビリティの対応ビットを保存し、他のケーパビリティビットは落とします。 ❖ 設定例

(40)

9.4 file ルール

file ルールは、ファイルまたはディレクトリの強制アクセス制御(MAC)を設定します。こ れは、通常のLinux の DAC(Discretionary Access Control)とは別に行なわれま す。 以下の表に、file ルールのフィールドレコードを示します。

file ルールフィールド

フィールド名 デフォルト値 説明 comp (必須) なし コンパートメント名を指定。 filename (必須) なし ファイル/ディレクトリの絶対パスを指定。 access (必須) なし read,write,execute,append の組み合わせ write は append も含む

file ルールが全く存在しない場合には、Linux の DAC で許可された操作はすべて許可 されます。DAC は、ファイル操作が行なわれる時にカーネルにより

read,write,execute のチェックが行なわれます。file ルールが存在する場合には、 MAC 制御により、Linux の DAC によるチェック機能を拡張します。

例えば、

‐ 読込み専用で Open するファイルは、file ルールの read 権限を必要とする ‐ 追加書込み専用で Open するファイルは、file ルールの append 権限を必要とす る

‐ execve で実行させるファイルには、file ルールの execute 権限を必要とする 通常、ファイル名を解決する場合には、カーネルがそのファイルのあるディレクトリに、

exec { from.comp xinetd;

filename /usr/sbin/in.ftpd; comp ftp; }

exec { from.comp xinetd;

filename /usr/sbin/in.ftpd; comp ftp;

uid ftp; gid ftp;

(41)

read 権限ではなく execute 権限を必要とします。一方、MAC の場合には、ディレクト リにexecute 権限を必要としませんので、ディレクトリに execute 権限を与えずに read 権限を与えることが可能です。ディレクトリの移動、ディレクトリの内容表示には、 そのディレクトリのread 権限が必要になります。ファイル名を解決するには、そのディ レクトリに何のアクセス権限がなくても可能です。 file ルールは、存在しないファイルについては適用されません。 file ルールが存在しない場合は、上位ディレクトリの file ルールを参照して、そのディレ クトリに設定されているfile ルールが適用されます。上位ディレクトリを遡って/ディレク トリまで到達してもルールが設定されていない場合は、コンパートメント名が*のルール が適用されます。 但し、名前が*のコンパートメントは実在しておらず、サービス定義上は default コンパ ートメントとして扱われます。つまり、最終的に適用されるルールは /etc/hpcg/init/default に存在します。

(42)

❖ 設定例

9.5 inet ルール

inet ルールは、PF_INET ファミリーのソケットを使用した通信を制御します。INET ソケッ トはTCP や UDP で使われ、リモートホストとの通信、Loopback インターフェースを利 用したローカルホスト内の通信に使用されます。また、INET ソケットは、ICMP のように SOCK_RAW モードでも使用されます。 inet ルールは、PF_INET ソケットのトラフィックに適用されます。カーネルはソケット、パ ケット及びインターフェースを見極め、起点/終点アドレス、ポート、コンパートメント、プ ロトコルファミリーやネットワークインターフェースと設定されたルールとの比較を行い ます。これらのパラメータが設定されたルールに合致しない場合は、パケットが破棄さ れます。 送信時には、送信ソケットを作成したプロセスが、起点コンパートメントに属しているか どうかチェックします。受信時には、ソケットを受信するプロセスが終点コンパートメント に属しているかどうかをチェックします。Loopback インターフェース経由のローカルト ラフィックの場合は、受信時にのみチェックされます。 TCP コネクションが生成された場合、反対方向のトラフィックについてはカーネルにより 自動的に許可されます。つまり、TCP コネクションを受けつける場合には、入ってくるト ラフィックのルールを設定すればよいことになります。出ていくトラフィックはカーネルで 自動的に許可されます。TCP コネクションをこちらから張る場合も同様です。ただし、 UDP や他のプロトコルの場合はこれに当てはまりません。UDP や他のプロトコルで双 方向通信させる場合は、bidir フィールドで許可する必要があります。 以下の表に、inet ルールのフィールドレコードを示します。

inet ルールフィールド

フィールド名 デフォルト値 説明

from.comp * メッセージの起点となるコンパートメント名を指定。少なくともfrom.comp か from.host のどちらかを指定しなければならない。

file { comp foo; filename /; access (); }

file { comp foo;

filename /compt/foo/bin; access read,write,execute; }

(43)

from.host localhost メッセージの起点となるホストアドレスを指定。 少なくともfrom.comp か from.host のどちらかを指定しなければならない。 それぞれのアドレスは、通常のIPv4 のドット記法、もしくは 192.168.1.100 255.255.255.0 (スペースで区切る) 192.168.1.100/24 (/でビット数を指定する) のようなnetmask を付けて指定します。 from.port * メッセージの起点となるポート。 ポート番号またはポートの範囲で指定する。 ポート番号はTCP,UDP のものを指定し、RAW ソケットのものは指定しない。 ポート番号は1∼65536 の整数で指定する。 ポートの範囲指定は、2 つのポート番号をコロンで区切る(1024:65536) サービス名を指定した場合、/etc/services を参照する。

to.comp * メッセージの終点となるコンパートメント名を指定。少なくともto.comp か to.host のどちらかを指定しなければならない。

to.host localhost メッセージの終点となるコンパートメント名を指定。少なくともto.comp か to.host のどちらかを指定しなければならない。

to.port * メッセージの終点となるポート protocol * 使用するプロトコルを指定。 通常はtcp,upd のどちらかを指定。 あるいは/etc/protocol にあるプロトコル名もしくはプロトコル番号を指定す る。 interface * ネットワークインターフェース名を指定。

bidir false true か false を指定して、双方向通信の許可/不許可を指定する。

❖ 設定例

9.6 ipc ルール

ipc ルールでは、セマフォ、共有メモリ、メッセージキューの System V IPC を使用した プロセス間通信を制御します。

IPC オペレーションは ipc ルールを設定しない限り、許可されません。IPC オペレーショ inet { from.comp web;

to.host 192.168.1.100; protocol tcp; interface eth0; } inet { from.comp dns; to.host $DNS_HOST; to.port domain; bidir true; }

(44)

ンでは、起点となるコンパートメントに属するプロセスが共有リソースの作成を行います。 また、終点となるコンパートメントに属するプロセスが共有リソースを利用できます。 以下の表に、ipc ルールのフィールドレコードを示します。

ipc ルールフィールド

フィールド名 デフォルト値 説明 from.comp (必須) なし 起点となるコンパートメント名か、*を指定。 to.comp (必須) なし 終点となるコンパートメント名か、*を指定。 method (必須) なし sem,shm,msq から指定する。 それぞれ、セマフォ、共有メモリ、メッセージキューに対応する。 *も指定可能。

key * IPC リソース ID を指定(API で指定)。*は明示的に使用できない

❖ 設定例

9.7 packet ソケットルール

packet ソケットルールでは、PF_PACKET ファミリーのソケットを使用した通信を制御し ます。packet ソケットはネットワークへの低レベルアクセスを可能にします。 packet ソケットのトラフィックは、起点/終点コンパートメントおよび使用するインター フェースに基づいて制御されます。ルールで許可されていない場合は、そのトラフィック は破棄されます。送信時は、送信ソケットを作成したプロセスが起点コンパートメントに 属しているかどうかチェックします。受信時は、受信ソケットを受信するプロセスが終点 コンパートメントに属しているかチェックします。 また、外から入ってくるトラフィックは、不特定の起点コンパートメントを持ちます。 以下の表に、packet ルールのフィールドレコードを示します。

ipc { from.comp foo; to.comp bar;

method sem,shm,msq; }

ipc { from.comp foo; to.comp bar; method msq; key 1234; }

(45)

packet ソケットルールフィールド

フィールド名 デフォルト値 説明 from.comp (必須) なし 起点となるコンパートメント名か、*を指定。 to.comp (必須) なし 終点となるコンパートメント名か、*を指定。 interface * ネットワークインターフェース名を指定。

bidir false true か false を指定して、双方向通信の許可/不許可を指定する。

❖ 設定例

9.8 ps ルール

ps ルールでは、コンパートメント間のプロセスや TCP コネクションなどのリソースの可 視性を定義します。これは例えば、ps コマンドや netstat コマンドの出力結果に影響を 及ぼします。ps ルールが設定されない限り、プロセスは自分自身が属するコンパートメ ントの他のプロセスにしかアクセスできません。 ps ルールは、プロセスへのシグナル送信、プロセスのリスト、コネクションの列挙及、 優先度設定、プロセスグループやケーパビリティの設定などを制御します。ps ルール は/proc にあるプロセスファイルへのアクセスも制御します。 以下の表に、ps ルールのフィールドレコードを示します。

ps ルールフィールド

フィールド名 デフォルト値 説明 from.comp (必須) なし 操作を呼び出す側のコンパートメント名か、*を指定。 to.comp (必須) なし アクセスされるコンパートメント名か、*を指定。 packet { from.comp *; to.comp foo; }

packet { from.comp bar; to.comp foo; interface eth0; bidir true; }

(46)

❖ 設定例

9.9 socket ルール

socket ルールでは、PF_INET,PF_PACKET,PF_UNIX ファミリー、およびそれ以外のフ ァミリーのソケットを使用した通信を制御します。 以下の表に、socket ルールのフィールドレコードを示します。

socket ルールフィールド

フィールド名 デフォルト値 説明 comp (必須) * socket を作成するコンパートメント名を指定。 family * プロトコルファミリーを指定。 ❖ 設定例

9.10 unix ドメインソケットルール

unix ドメインソケットルールでは、PF_UNIX ファミリーのソケットを使用した通信を制御 します。UNIX ソケットはローカルシステム上のプロセス間通信に利用されます。UNIX ソケットには、SOCK_STREAM および SOCK_DGRAM の 2 つのタイプが存在します が、unix ルールではこれらを区別しません。 異なるコンパートメント間で双方向通信を行う場合は、ルールを双方向に設定しなけれ ばなりません。 以下の表に、unix ドメインソケットルールのフィールドレコードを示します。

unix ドメインソケットルールフィールド

フィールド名 デフォルト値 説明 from.comp なし 起点となるコンパートメント名か、*を指定。 ps { from.comp dev; to.comp *; }

socket { comp kernel;

family PF_UNIX,PF_INET,PF_PACKET,PF_NETLINK; }

(47)

(必須) to.comp

(必須) なし 終点となるコンパートメント名か、*を指定。

address * ドメインソケットファイルを指定。

❖ 設定例

unix { from.comp xserver; to.comp xfs;

(48)

10 ログ記録・Alarm 機構・Pass through モード

10.1 ログメッセージ

10.1.1

ログメッセージ

Compartment Guard では、設定されているルールに対して、ルール違反を犯すよ うなイベント操作を行った場合や、ルールに従ったイベント操作を行った場合に、 /var/log/hpcg/hpcg.log ファイルにメッセージを残すことができます。以下では、ル ール違反を犯したイベント操作に対して残すログをDenial ログ、ルールに従ったイベ ント操作に対して残すログをAllow ログと呼びます。 記録されるDenial ログ及び Allow ログのログメッセージのフォーマットは以下の通り です。 ここで各フィールドは、以下の意味を持ちます。 hpcg : Compartment Guard のセキュリティモジュールが発生したログであること を示します OPCODE : プロセスが行おうとしたイベント操作

TYPE : Allowed または Denied(Allow ログか Denied ログかを表す) pid PID : ログメッセージを発生させたプロセス ID(PID)を表示

PROCESS : ログメッセージを発生させたプロセス名 RULE : プロセスが行おうとした操作をルール表記で表示

ログ記録(Denial ログ)の例を以下に示します。

❖ Denial ログ(例)

hpcg: OPCODE TYPE pid PID (PROCESS) RULE

Jan 19 22:55:14 rhas-2 kernel: hpcg: IP_OUTPUT Denied pid 1904 (ping) inet { from.comp 10; from.host 127.0.0.1; to.host 172.16.155.1; type raw; protocol 1; interface eth0; }

(49)

10.1.2

ログ記録するイベントの種類

ログ記録されるイベントは以下の表の通りです。それぞれのイベントは8 種類のイベン トカテゴリに分類されており、イベントカテゴリ単位にログ記録を行うことが出来ます。 イベントカテゴリ イベント socket SOCKET_CREATE inet IP_INPUT,IP_OUTPUT,RAW_RCV,TCP_RCV,UDP_RCV,SKB_RCV unix UNIX_CONN,UNIX_SND,UNIX_RCV packet PACKET_SND,PACKET_RCV ipc IPC_MSG_GET,IPC_MSG_SND,IPC_MSG_RCV, IPC_SHM_GET,IPC_SHM_RCV,IPC_SHM_RCV file FS_PERMISSION,FS_CHDIR,FS_CHMOD,FS_CHOWN, FS_FILEOPEN,FS_LINK_DST,FS_LINK_SRC,FS_MKDIR,FS_MKNOD, FS_MOUNT,FS_NAMEIOPEN,FS_RENAME_DST,FS_RENAME_SRC, FS_RENAME_SRC_FILE,FS_RMDIR,FS_STAT,FS_TRUNCATE, FS_UMOUNT,FS_UNLINK,FS_UTIME ps PS su SU

10.1.3

ログメッセージの記録方法

/var/log/hpcg/hpcg.log に Allow ログ及び Denial ログの記録を行うには、/proc ディレクトリ以下の擬似ファイルへの書込みを行うことによって行います。

Denial ログについては、/proc/sys/csec/log_denial ファイルに、Allow ログについ ては、/proc/sys/csec/log_allow ファイルにそれぞれ記録を取りたいイベントカテゴ リを指定します。ただし、これらのファイルへの書込みにはCAP_MAC_ALARM ケー パビリティが必要になります。

例えば、inet イベントカテゴリの Denial ログを記録する場合は以下のコマンドを実行し ます。

# echo inet > /proc/sys/csec/log_denial あるいは、

(50)

複数のイベントカテゴリを記録する場合は、イベントカテゴリをカンマ(,)で区切って指 定します。 また、全てのイベントカテゴリを記録したい場合は、”all”をイベントカテゴリ記述部分に 指定します。 Denial ログの記録を終了するには、”none”をイベントカテゴリ記述部分に指定しま す。 また、システム起動時にDenial ログ、Allow ログの取得を開始する場合は、 /etc/hpcg/init/policy/boot-user.conf ファイルに以下のように取得するイベントカ テゴリを記述します。 ❖ boot-user.conf ファイル記述(例)

10.1.4 syslog への記録方法

ログメッセージを/var/log/hpcg/hpcg.log ファイルに記録するのではなく、syslog に記録することも可能です。syslog にログメッセージを記録するには、/proc ディレクト リ以下の擬似ファイルへの書込みを行うことによって行います。 以下のように、/proc/sys/csec/use_syslog ファイルに 1 を書き込むことによって、 syslog にログメッセージを記録することが可能です。ただし、このファイルへの書込み にはCAP_MAC_ALARM ケーパビリティが必要になります。 syslog へのログメッセージの記録を解除し、/var/log/hpcg/hpcg.log ファイルへ記 # echo socket,inet,file > /proc/sys/csec/log_denial

LOG_DENIAL=inet,file LOG_ALLOW=none

# echo all > /proc/sys/csec/log_denial

# echo none > /proc/sys/csec/log_denial

# echo 1 > /proc/sys/csec/use_syslog あるいは、

(51)

録を戻す場合は、/proc/sys/csec/use_syslog 擬似ファイルに 0 を書き込みます。

10.1.5

ログメッセージ取りこぼしの可能性

ログメッセージは、瞬間的に非常に多数のログ記録が発生するような場合には、仕組 み上、ディスクへの書込みが間に合わなくなる為、ログメッセージの取りこぼしが発生 する可能性があります。取りこぼしが発生した場合には、記録されたログメッセージの 信憑性は低下します。 Compartment Guard は、取りこぼしが発生するような状況を予め知らせる機能を 備えています。記録用のバッファーが全体の80%を超えた場合には、以下のようなメッ セージがログファイルに(syslog にも)記録されます。 その後、バッファーの使用率が全体の50%までに回復した場合は、以下のメッセージ がログファイルに(syslog にも)記録されます。 ログメッセージをsyslog に記録している場合は、これらのメッセージは syslog に記録さ れません。 # echo 0 > /proc/sys/csec/use_syslog あるいは、 # sysctl ‐w csec.use_syslog=0

hpcg: Warn: log buffer use exceeds 80%.

参照

関連したドキュメント

C)付為替によって決済されることが約定されてその契約が成立する。信用

l 「指定したスキャン速度以下でデータを要求」 : このモード では、 最大スキャン速度として設定されている値を指 定します。 有効な範囲は 10 から 99999990

この設定では、管理サーバ(Control Center)自体に更新された Windows 用の Dr.Web Agent のコンポ ーネントがダウンロードされませんので、当該 Control Center で管理される全ての Dr.Web

題が検出されると、トラブルシューティングを開始するために必要なシステム状態の情報が Dell に送 信されます。SupportAssist は、 Windows

・カメラには、日付 / 時刻などの設定を保持するためのリチ ウム充電池が内蔵されています。カメラにバッテリーを入

・電源投入直後の MPIO は出力状態に設定されているため全ての S/PDIF 信号を入力する前に MPSEL レジスタで MPIO を入力状態に設定する必要がある。MPSEL

3  治療を継続することの正当性 されないことが重要な出発点である︒

定的に定まり具体化されたのは︑