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

パート II システム、ファイル、およびデバイスのセキュリティー

このパートでは、ネットワークに接続されていないシステムで設定されるセキュリティーについて説明します。各章では、ディスク、ファイル、および周辺機器へのアクセスの計画、監視、および制御について説明します。

第 2 章マシンセキュリティーの管理 (概要)

マシンの情報のセキュリティーを保つことは、重要なシステム管理作業です。この章では、マシンセキュリティー管理の概要を説明します。

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

Solaris 10 リリースにおけるマシンセキュリティーの向上

Solaris 9 のリリース以降、システムセキュリティーを向上させるために次の機能が追加されました。

強力なパスワード暗号化機能を利用できます。この機能はユーザーによる設定が可能です。詳細は、「パスワードの暗号化」を参照してください。
デバイスポリシーが特権によって強化されました。詳細は、「デバイスポリシー (概要)」を参照してください。

デバイス割り当てについては、今後の Solaris OS リリースで /etc/security/dev ディレクトリがサポートされなくなる可能性があります。
基本監査報告機能 (BART) は、システム上のファイルの信頼性を監視するために使用できます。詳細は、第 5 章基本監査報告機能の使用方法 (作業)を参照してください。
強力な暗号化でファイルを保護できるようになりました。詳細は、「暗号化によるファイルの保護」を参照してください。
特権により、カーネルレベルでプロセスの権限を指定できるようになりました。詳細は、「特権 (概要)」を参照してください。
Solaris 暗号化フレームワークにより、プロバイダやコンシューマを対象にした暗号化サービスが一元化できるようになりました。詳細は、第 13 章Solaris の暗号化フレームワーク (概要)を参照してください。
PAM フレームワークで、さまざまなプログラムに対応できる機能 (Solaris Secure Shell など) が提供されました。詳細は、「Solaris 10 リリースにおける PAM への変更」を参照してください。
マシンリソースに対して Solaris ゾーンの指定やリソース管理制御アクセスが行えるようになりました。詳細については、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』を参照してください。

コンピュータシステムへのアクセスを制御する

ワークスペースでは、サーバーに接続されたすべてのマシンを 1 つの大規模多重システムと見なすことができます。システム管理者は、この大規模なシステムのセキュリティー管理に責任があります。システム管理者は、ネットワークの外部からの侵入を防ぐ必要があります。また、ネットワーク内部のマシン上のデータの完全性を確保する必要もあります。

ファイルレベルにおいて、Solaris OS には標準セキュリティー機能が組み込まれており、ファイル、ディレクトリ、およびデバイスを保護するために使用できます。システムレベルとネットワークレベルでは、セキュリティーの内容はほぼ同じです。セキュリティー防御の第一線は、システムへのアクセスを制御することです。

次の方法でシステムへのアクセスを制御または監視できます。

物理的なセキュリティーの管理

システムへのアクセスを制御するには、コンピュータ環境の物理的なセキュリティーを管理する必要があります。たとえば、システムにログインしたままこれを放置することは未承認アクセスを招く原因になります。侵入者がオペレーティングシステムやネットワークにアクセスしないとも限らないからです。コンピュータの周辺環境やコンピュータハードウェアは、不当なアクセスから物理的に保護する必要があります。

システム管理者は、ハードウェア設定に対する不当なアクセスから SPARC システムを保護することができます。eeprom コマンドを使って、パスワードがないと PROM にアクセスできないようにしてください。詳細は、「ハードウェアアクセスのパスワードを必須にする方法」を参照してください。

ログイン制御の管理

システムやネットワークへの無許可のログインも防止する必要があります。この制限は、パスワード割り当てとログイン制御によって行うことができます。システム上のすべてのアカウントには、パスワードを設定します。パスワードはシンプルな認証メカニズムです。アカウントにパスワードを設定しないと、ユーザー名を推測できる侵入者であれば誰でもネットワーク全体にアクセスできることになります。力ずくの野蛮な攻撃を許さないためには、強力なパスワードアルゴリズムが必要です。

ユーザーがシステムにログインすると、login コマンドは /etc/nsswitch.confファイル内の情報に従って、該当するネームサービスまたはディレクトリサービスのデータベースを照会します。このファイルには次のエントリを含めることができます。

files – ローカルシステムの /etc ファイルを指定します
ldap – LDAP サーバーの LDAP ディレクトリサービスを指定します
nis – NIS マスターサーバーの NIS データベースを指定します
nisplus – NIS+ root サーバーの NIS+ データベースを指定します

nsswitch.conf ファイルの詳細は、nsswitch.conf(4) のマニュアルページを参照してください。ネームサービスおよびディレクトリサービスについては、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』または『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』を参照してください。

login コマンドは、指定されたユーザー名とパスワードを検証します。ユーザー名がパスワードファイルにないと、login コマンドはシステムへのアクセスを拒否します。あるいは、指定されたユーザー名に対するパスワードが正しくないと、login コマンドはシステムへのアクセスを拒否します。有効なユーザー名とそれに対応するパスワードが入力されれば、システムはシステムへのアクセスをユーザーに認可します。

PAM モジュールには、システムへのログインが正常に完了したあとでアプリケーションへのログインをスムーズに行わせる効果があります。詳細については、第 17 章PAM の使用を参照してください。

Solaris システムには、精巧な認証メカニズムと承認メカニズムが備わっています。ネットワークレベルでの認証メカニズムや承認メカニズムについては、「遠隔アクセスの認証と承認」を参照してください。

パスワード情報の管理

ユーザーはシステムにログインするときに、ユーザー名とパスワードの両方を入力する必要があります。ログイン名は公開されていますが、パスワードは秘密にしなければなりません。ユーザーは、自分のパスワードを他人に知られてはいけません。また、各自のパスワードを慎重に選択し、頻繁に変更するようにしなければなりません。

パスワードは、最初にユーザーアカウントを設定するときに作成されます。ユーザーアカウントのセキュリティーを管理するために、パスワード有効期限を設定し、パスワードを定期的に強制変更することができます。また、ユーザーアカウントを無効にして、パスワードをロックすることもできます。パスワードの管理の詳細については、『Solaris のシステム管理 (基本編)』の第 4 章「ユーザーアカウントとグループの管理 (概要)」と、passwd(1) のマニュアルページを参照してください。

ローカルパスワード

ネットワークでローカルファイルを使用してユーザーの認証を行なっている場合、パスワード情報はシステムの /etc/passwd ファイルと /etc/shadow ファイルに保持されます。ユーザー名などの情報は、パスワードファイル /etc/passwd に保持されます。暗号化されたパスワードは、/etc/shadow という「シャドウ」ファイルに保持されます。このセキュリティー方式によって、暗号化されたパスワードにアクセスされることを防ぎます。/etc/passwd ファイルは、システムにログインするユーザーであれば誰でも使用できますが、/etc/shadow ファイルを読み取ることができるのはスーパーユーザー、またはスーパーユーザーと同等の役割だけです。passwd コマンドを使用すると、ローカルシステム上のユーザーのパスワードを変更できます。

NIS パスワードおよび NIS+ パスワード

ネットワークで NIS を使用してユーザーの認証を行なっている場合、パスワード情報は NIS パスワードマップに保持されます。NIS では、パスワードの有効期間を指定できません。NIS パスワードマップに保持されているユーザーのパスワードを変更するには、コマンド passwd -r nis を使用します。

ネットワークで NIS+ を使用してユーザーの認証を行っている場合、パスワード情報は NIS+ データベースに保持されます。NIS+ データベース内の情報は、承認されたユーザーだけにアクセスを制限することによって保護できます。NIS+ データベースに保持されているユーザーのパスワードを変更するには、passwd -r nisplus コマンドを使用します。

LDAP パスワード

Solaris の LDAP ネーミングサービスは、パスワード情報とシャドウ情報を LDAP ディレクトリツリーの ou=people コンテナに格納します。Solaris LDAP ネーミングサービスクライアントでユーザーのパスワードを変更するには、passwd -r ldap コマンドを使用します。LDAP ネーミングサービスは、パスワードを LDAP リポジトリに格納します。

パスワードポリシーは、Sun Java System Directory Server 上で適用されます。つまり、クライアントの pam_ldap モジュールは、Sun Java System Directory Server で適用されているパスワードポリシー制御に従います。詳細は、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』の「LDAP ネームサービスのセキュリティーモデル」を参照してください。

パスワードの暗号化

パスワードの強力な暗号化は攻撃に対する最初の障壁になります。Solaris ソフトウェアには、4 つのパスワード暗号化アルゴリズムがあります。2 つの MD5 アルゴリズムと Blowfish アルゴリズムでは、UNIX アルゴリズムよりも強力なパスワードの暗号化が行われます。

パスワードアルゴリズムの識別子

サイトのアルゴリズムの構成は、/etc/security/policy.conf ファイルに指定します。policy.conf ファイルには、次の表に示す識別子でアルゴリズムを指定します。

表 2–1 パスワードの暗号化アルゴリズム


識別子	説明	アルゴリズムのマニュアルページ
`1`	BSD システムや Linux システムの MD5 アルゴリズムと互換性のある MD5 アルゴリズム。	crypt_bsdmd5(5)
`2a`	BSD システムの Blowfish アルゴリズムと互換性のある Blowfish アルゴリズム。	crypt_bsdbf(5)
`md5`	BSD バージョンや Linux バージョンの MD5 よりも強力とされている Sun MD5 アルゴリズム。	crypt_sunmd5(5)
`5`	SHA256 アルゴリズム。SHA は、Secure Hash Algorithm (セキュアハッシュアルゴリズム) を表します。このアルゴリズムは、SHA-2 ファミリのメンバーです。SHA256 では 255 文字のパスワードがサポートされます。	crypt_sha256(5)
`6`	SHA512 アルゴリズム。	crypt_sha512(5)
`__unix__`	従来の UNIX 暗号化アルゴリズム。`policy.conf` ファイルのデフォルトモジュールはこのアルゴリズムです。	crypt_unix(5)

`policy.conf` ファイルのアルゴリズム構成

次に、policy.conf ファイルに指定されたデフォルトのアルゴリズム構成を示します。

#
…
# crypt(3c) Algorithms Configuration
#
# CRYPT_ALGORITHMS_ALLOW specifies the algorithms that are allowed to
# be used for new passwords.  This is enforced only in crypt_gensalt(3c).
#
CRYPT_ALGORITHMS_ALLOW=1,2a,md5,5,6

# To deprecate use of the traditional unix algorithm, uncomment below
# and change CRYPT_DEFAULT= to another algorithm.  For example,
# CRYPT_DEFAULT=1 for BSD/Linux MD5.
#
#CRYPT_ALGORITHMS_DEPRECATE=__unix__

# The Solaris default is the traditional UNIX algorithm.  This is not
# listed in crypt.conf(4) since it is internal to libc.  The reserved
# name __unix__ is used to refer to it.
#
CRYPT_DEFAULT=__unix__
…

CRYPT_DEFAULT の値を変更すると、新しいユーザーのパスワードは、新しい値に対応するアルゴリズムを使って暗号化されます。現在のユーザーがパスワードを変更したときに新しいパスワードがどのアルゴリズムで暗号化されるかは、古いパスワードがどのように暗号化されているかによって異なります。

たとえば、CRYPT_ALGORITHMS_ALLOW=1,2a,md5,5,6 かつ CRYPT_DEFAULT=1 であるとします。次の表は、パスワードの暗号化にどのアルゴリズムが使用されるかを示します。

識別子 = パスワードアルゴリズム		意味
元のパスワード	変更後のパスワード	意味
`1` = `crypt_bsdmd5`	同じアルゴリズムを使用します。	`1` 識別子は `CRYPT_DEFAULT` の値でもあります。ユーザーのパスワードは引き続き `crypt_bsdmd5` アルゴリズムで暗号化されます。
`2a` = `crypt_bsdbf`	同じアルゴリズムを使用します。	`2a` 識別子は `CRYPT_ALGORITHMS_ALLOW` リストにあります。このため、新しいパスワードは `crypt_bsbdf` アルゴリズムで暗号化されます。
`md5` = `crypt_md5`	同じアルゴリズムを使用します。	`md5` 識別子は `CRYPT_ALGORITHMS_ALLOW` リストにあります。このため、新しいパスワードは `crypt_md5` アルゴリズムで暗号化されます。
`5` = `crypt_sha256`	同じアルゴリズムを使用します。	`5` 識別子は `CRYPT_ALGORITHMS_ALLOW` リストにあります。このため、新しいパスワードは `crypt_sha256` アルゴリズムで暗号化されます。
`6` = `crypt_sha512`	同じアルゴリズムを使用します。	`6` 識別子は `CRYPT_ALGORITHMS_ALLOW` リストにあります。このため、新しいパスワードは `crypt_sha512` アルゴリズムで暗号化されます。
`__unix__` = `crypt_unix`	`crypt_bsdmd5` アルゴリズムを使用します。	`__unix__` 識別子は `CRYPT_ALGORITHMS_ALLOW` リストにありません。このため、`crypt_unix` アルゴリズムを使用することはできません。新しいパスワードは `CRYPT_DEFAULT` アルゴリズムで暗号化されます。

選択したアルゴリズムの構成の詳細については、policy.conf(4) のマニュアルページを参照してください。パスワード暗号化アルゴリズムを指定する方法については、「パスワードアルゴリズムの変更 (作業マップ)」を参照してください。

特別なシステムログイン

システムにアクセスする一般的な方法としては、通常のユーザーログインを使用するものと、root ログインを使用するものがあります。また、多数の特別な「システム」ログインを使用すると、ユーザーは root アカウントを使用しなくても管理コマンドを実行できます。システム管理者は、これらのログインアカウントにパスワードを割り当てます。

次の表に、システムのログインアカウントとその用途を示します。システムログインは特殊な機能を実行します。それぞれのログインに固有のグループ識別番号 (GID) が付いています。各ログインには固有のパスワードを設定し、必要のある人だけに知らせるようにしてください。

表 2–2 システムログインアカウントとそれらの用途


ログインアカウント	グループ ID	用途
`root`	`0`	ほぼ無制限です。ほかのすべてのログイン、保護、アクセス権に優先します。`root` アカウントはシステム全体へのアクセス権を持ちます。`root` ログインのパスワードはきわめて厳密に保護する必要があります。`root` アカウント (スーパーユーザー) は、ほとんどの Solaris コマンドを所有します。
`デーモン`	`1`	バックグラウンド処理を制御します。
`bin`	`2`	一部の Solaris コマンドを所有します。
`sys`	`3`	多数のシステムファイルを所有します。
`adm`	`4`	特定のシステム管理ファイルを所有します。
`lp`	`71`	プリンタ用のオブジェクトデータファイルとスプールデータファイルを所有します。
`uucp`	`5`	UNIX 間のコピープログラム、UUCP 用のオブジェクトデータファイルとスプールデータファイルを所有します。
`nuucp`	`9`	システムにログインしてファイル転送を開始するために遠隔システムで使用されます。

遠隔ログイン

侵入者にとって、遠隔ログインは魅力的な手段です。Solaris OS には、遠隔ログインを監視、制限、および無効にするコマンドがいくつもあります。手順については、「ログインとパスワードの保護 (作業マップ)」を参照してください。

デフォルトでは、システムのマウスやキーボード、フレームバッファー、オーディオデバイスなど、特定のシステムデバイスを、遠隔ログインを通して制御したり読み取ったりすることはできません。詳細は、logindevperm(4) のマニュアルページを参照してください。

ダイヤルアップログイン

モデムやダイヤルアップポートを通してアクセスされうるコンピュータには、セキュリティー層をもう 1 つ追加できます。つまり、モデムやダイヤルアップポートを通してシステムにアクセスするユーザーには「ダイヤルアップパスワード」を要求することができます。ダイヤルアップパスワードは、ユーザーがシステムへのアクセス権を取得する前に指定する必要があります。

ダイヤルアップパスワードの作成または変更が行えるのは、スーパーユーザー、またはスーパーユーザーと同等の役割だけです。システムの完全性を確保するために、月に一度はパスワードを変更する必要があります。この機能のもっとも有効な使用方法は、ゲートウェイシステムへのアクセス権を取得するためのダイヤルアップパスワードを要求することです。ダイヤルアップパスワードの設定方法については、「ダイヤルアップパスワードを作成する方法」を参照してください。

ダイヤルアップパスワードの作成には、/etc/dialups と /etc/d_passwd という 2 つのファイルが必要です。dialups ファイルには、ダイヤルアップパスワードを必要とするポートのリストを含みます。d_passwd ファイルには、追加のダイヤルアップパスワードとして暗号化パスワードを必要とするシェルプログラムのリストを含みます。これら 2 つのファイルの情報は次のように処理されます。

/etc/passwd 内のユーザーのログインシェルが /etc/d_passwd 内のエントリと一致する場合、そのユーザーはダイヤルアップパスワードを入力する必要があります。
/etc/passwd 内のユーザーのログインシェルが /etc/d_passwd 内で見つからない場合、そのユーザーはデフォルトのパスワードを入力する必要があります。デフォルトのパスワードは /usr/bin/sh のエントリです。
/etc/passwd 内のログインシェルフィールドが空の場合、そのユーザーはデフォルトのパスワードを入力する必要があります。デフォルトのパスワードは /usr/bin/sh のエントリです。
/etc/d_passwd に /usr/bin/sh のエントリがない場合、/etc/passwd 内のログインシェルフィールドが空のユーザー、または /etc/d_passwd 内のエントリと一致しないユーザーには、ダイヤルアップパスワードの入力を求めるプロンプトは表示されません。
/etc/d_passwd ファイルのエントリが /usr/bin/sh:*: だけである場合、ダイヤルアップログインは無効です。

デバイスアクセスの制御

コンピュータシステムに接続された周辺機器は、セキュリティーリスクをもたらします。たとえば、マイクは会話をキャッチし、その会話を遠隔システムに送信します。CD-ROM の場合、その情報を CD-ROM に残して、CD-ROM デバイスを次に使うユーザーが読み取れるようにすることができます。プリンタは、遠隔サイトからもアクセスできます。システムの必須デバイスもまた、セキュリティー問題を引き起こす可能性があります。たとえば、hme0 のようなネットワークインタフェースは不可欠なデバイスとみなされています。

Solaris ソフトウェアには、デバイスアクセスを制御する方法が 2 つ用意されています。「デバイスポリシー」は、システムに不可欠なデバイスに対するアクセスの制限または防止を行うものです。デバイスポリシーはカーネル内で適用されます。「デバイス割り当て」は、周辺機器に対するアクセスの制限または防止を行う作業です。デバイス割り当ては、ユーザー割り当ての時点で適用されます。

デバイスポリシーは、特権を使用して特定のデバイスをカーネル内で保護します。たとえば、ネットワークインタフェースのデバイスポリシー (hme など) は、読み取りまたは書き込みに対してすべての権限を要求します。

デバイス割り当ては、承認を利用してプリンタやマイクなどの周辺機器を保護します。デフォルトでは、デバイス割り当ては無効な状態になっています。デバイス割り当てが有効な状態では、この構成を変更してデバイスの使用を防いだり、デバイスアクセスに承認が必要なように設定したりできます。デバイスの使用割り当てが行われると、現在のユーザーがその割り当てを解除するまでほかのユーザーはそのデバイスにアクセスできません。

デバイスアクセスを制御する手段として、次に示すようないくつかの方法で Solaris システムを構成できます。

デバイスポリシーを設定する – Solaris OS では、特定のデバイスにプロセスがアクセスする場合、そのプロセスが特定の権限のもとで実行されていることを必要条件とすることができます。それらの権限を持たないプロセスは、そのデバイスを使用できません。起動時に、Solaris ソフトウェアはデバイスポリシーを設定します。Sun 以外のドライバは、そのインストール時にデバイスポリシーを組み込むことができます。インストール後、システム管理者はデバイスポリシーをデバイスに追加できます。
デバイスを割り当て可能にする – デバイス割り当てを有効にする際には、一度に 1 人しかそのデバイスを使用できないように制限できます。また、ユーザーが何らかのセキュリティー要件を満たすように要求することも可能です。たとえば、そのデバイスを使用する承認を得ていることを要求できます。
デバイスの使用を防ぐ – コンピュータシステム上のどのユーザーも特定のデバイス (マイクなど) を使用できないように設定できます。特定のデバイスを使用できない状態にする例としては、コンピュータキオスクが挙げられます。
デバイスを特定のゾーンに限定する – デバイスの使用を非大域ゾーンにだけ割り当てることができます。詳細は、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』の「非大域ゾーンでのデバイスの使用」を参照してください。デバイスとゾーンに関する一般的な説明は、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』の「ゾーンで構成されるデバイス」を参照してください。

デバイスポリシー (概要)

デバイスポリシーメカニズムを使用することで、デバイスを開こうとするプロセスに特定の権限を要求するように指定できます。デバイスポリシーによって保護されたデバイスをアクセスできるのは、デバイスポリシーで指定されている権限で稼働しているプロセスだけです。Solaris OS には、デフォルトのデバイスポリシーが用意されています。たとえば、hme0 などのネットワークインタフェースは、インタフェースにアクセスするプロセスが net_rawaccess 権限で稼働していることを必要とします。この要件はカーネルで適用されます。特権の詳細は、「特権 (概要)」を参照してください。

以前の Solaris OS リリースでは、デバイスノードの保護はファイルアクセス権だけで行われました。たとえば、グループ sys が所有しているデバイスをオープンできるのはこのグループのメンバーだけでした。デバイスを開くことができるユーザーをアクセス権が予測することはありません。デバイスは、ファイルアクセス権によって保護されるとともに、デバイスポリシーでも保護されます。たとえば、/dev/ip ファイルのアクセス権は 666 です。しかし、このデバイスは適切な権限を持つプロセスによってしかオープンできません。

デバイスポリシーの設定は監査の対象とすることができます。デバイスポリシーの変更は、AUE_MODDEVPLCY 監査イベントによって記録されます。

デバイスポリシーの詳細は、次のページを参照してください。

デバイス割り当て (概要)

デバイス割り当てメカニズムを使用すれば、CD-ROM などの周辺機器に対するアクセスを制限できます。このメカニズムは、システム管理者によってローカルに管理されます。デバイス割り当てが有効になっていない場合、周辺機器の保護はファイルアクセス権によってのみ行われます。たとえば、デフォルトでは周辺機器は次のように使用できます。

すべてのユーザーがフロッピーディスクや CD-ROM の読み取りと書き込みが行えます。
すべてのユーザーがマイクを接続できます。
すべてのユーザーが接続されたプリンタにアクセスできます。

デバイス割り当てを行うことで、承認されたユーザーにだけデバイスの使用を限定できます。デバイス割り当てによって、デバイスアクセスを完全に防ぐこともできます。デバイスを割り当てるユーザーは、そのユーザー自身が割り当てを解除するまでそのデバイスを独占的に使用できます。デバイスの割り当てが解除される際には、残っているすべてのデータがデバイスクリーンスクリプトによって消去されます。デバイスにスクリプトがない場合には、デバイスクリーンスクリプトを作成してそのデバイスから情報を一掃できます。この例は、「新しいデバイスクリーンスクリプトの作成」を参照してください。

デバイス割り当てに関連した試み (デバイスの割り当て、デバイスの割り当て解除、割り当て可能なデバイスの一覧表示) は、監査の対象とすることができます。監査イベントは、ot 監査クラスの一部です。

デバイス割り当ての詳細は、次のページを参照してください。

マシンリソースへのアクセス制御

システム管理者は、システム活動の制御や監視を行うことができます。システム管理者は、だれがどのリソースを使用できるかを制限したり、リソースの使用状況を記録したり、だれがリソースを使用しているかを監視したりできます。さらに、システム管理者は、リソースの不適切な使用を最小限に抑えるようにマシンを設定できます。

スーパーユーザーの制限と監視

システムでスーパーユーザーアクセスを行うには、root パスワードが必要です。デフォルトの構成では、ユーザーは遠隔からシステムに root としてログインできません。遠隔ログインするとき、ユーザーは自分のユーザー名でログインしてから、su コマンドを使用して root になる必要があります。管理者は、必要に応じて su コマンドを使用中のユーザー (特にスーパーユーザーのアクセス権を取得しようとしているユーザー) を監視できます。スーパーユーザーを監視したり、スーパーユーザーのアクセス権を制限したりする手順については、「スーパーユーザーの監視と制限 (作業マップ)」を参照してください。

役割によるアクセス制御を構成してスーパーユーザーを置き換える

役割によるアクセス制御 (RBAC) は、スーパーユーザーの権限を制限することを目的として設計されています。スーパーユーザーすなわち root ユーザーは、システムのすべてのリソースにアクセスできますが、RBAC を使用すれば、スーパーユーザーの権限を個別の権限からなる役割の集合に置き換えることができます。たとえば、ユーザーアカウントの作成を行う役割やシステムファイルの変更を行う役割を個別に設定できます。特定の機能または機能群を扱う役割を設定したら、これらの機能をroot の機能から取り除くことができます。

個々の役割を引き受けるためには、既存のユーザーが自分のユーザー名とパスワードを使ってログインする必要があります。ログインしたユーザーは、特別な役割パスワードを入力してその役割を引き受けます。これによって、他人が root パスワードを知ったとしても、システムに損傷を与える能力は限定されます。RBAC の詳細は、「役割によるアクセス制御 (概要)」を参照してください。

マシンリソースの意図しない使用の防止

システム管理者は、自分自身やユーザーによって意図しないエラーが引き起こされないように防止できます。

たとえば、PATH 変数を正しく設定することによって、トロイの木馬の実行を防止できます。
制限されたシェルをユーザーに割り当てることもできます。システムのうち各人の作業に必要な部分だけをユーザーに提供するという方法でシェル機能を制限すると、ユーザーエラーを避けることができます。実際、慎重に設定すれば、作業を能率的に行う上で必要な部分以外にユーザーがアクセスできないように制限できます。
そのユーザーがアクセスする必要がないファイルには、限定的なアクセス権を設定できます。

`PATH` 変数の設定

PATH 変数を正しく設定しないと、他人が持ち込んだプログラムを誤って実行し、データを壊したりシステムを損傷したりするおそれがあります。このようなプログラムはセキュリティー上の危険を招くので、「トロイの木馬」と呼ばれます。たとえば、公開ディレクトリの中に別の su プログラムが置かれていると、システム管理者が気づかずに実行してしまう可能性があります。このようなスクリプトは正規の su コマンドとまったく同じに見えます。このようなスクリプトは実行後に自らを削除してしまうため、トロイの木馬が実際に実行されたという証拠はほとんど残りません。

PATH 変数はログイン時に自動的に設定されます。パスは、起動ファイル、すなわち .login、.profile、および .cshrc を通して設定されます。現在のディレクトリ (.) への検索パスを最後に指定すれば、トロイの木馬のようなタイプのプログラムを実行するのを防ぐことができます。スーパーユーザーの PATH 変数には、現在のディレクトリを指定しないでください。

自動セキュリティー拡張ツール (ASET) は、起動ファイルの PATH 変数が正しく設定されているかどうかを調べます。また、PATH 変数にドット (.) エントリが含まれていないか確認します。

ユーザーに制限付きシェルを割り当てる

標準シェルを使用すると、ユーザーはファイルを開く、コマンドを実行するなどの操作を行うことができます。制限付きシェルを使用すると、ディレクトリの変更やコマンドの実行などのユーザー能力を制限できます。制限付きシェルは、/usr/lib/rsh コマンドで呼び出されます。制限付きシェルは、遠隔シェル /usr/sbin/rsh ではありません。

標準のシェルと異なる点は次のとおりです。

ユーザーはホームディレクトリ内に限定されるため、 cd コマンドを使用してディレクトリを変更できません。したがって、システムファイルを閲覧することはできません。
ユーザーは PATH 変数を変更できないため、システム管理者によって設定されたパスのコマンドしか使用できません。さらに、完全なパス名を使ってコマンドやスクリプトを実行することもできません。
ユーザーは、> または >> を使用して出力をリダイレクトできません。

制限付きシェルでは、ユーザーが使用できるシステムファイルを制限できます。このシェルは、特定のタスクを実行するユーザーのために限られた環境を作成します。ただし、制限付きシェルは完全に安全なわけではありません。このシェルの目的は、あくまでも、経験の少ないユーザーが誤ってシステムファイルを損傷するのを防止することです。

制限付きシェルについては、rsh(1M) のマニュアルページを参照してください。このマニュアルページは、man -s1m rsh コマンドで表示できます。

ファイル内のデータへのアクセス制限

Solaris OS はマルチユーザー環境なので、ファイルシステムのセキュリティーは、システムのもっとも基本的な問題です。ファイルの保護には、従来の UNIX のファイル保護と、より確実なアクセス制御リスト (ACL) との両方が使用できます。

一部のユーザーには特定のファイルの読み取りを許可し、別のユーザーには特定のファイルを変更または削除するアクセス権を与えることができます。一方、あるデータを、どのユーザーからも読み取られないよう設定することもできます。ファイルのアクセス権の設定方法については、第 6 章ファイルアクセスの制御 (作業)を参照してください。

`setuid` 実行可能ファイルの制限

実行可能ファイルがセキュリティーリスクとなる場合があります。多くの実行可能プログラムは、スーパーユーザー (root) として実行しなければ適切に動作しません。これらの setuid プログラムは、ユーザー ID が 0 に設定された状態で実行されます。このようなプログラムはだれが実行したとしても root ID で実行されます。root ID で動作するプログラムは、プログラムがセキュリティーを念頭に置いて作成されていない限り、セキュリティーの問題をはらんでいます。

Sun が setuid ビットを root に設定して出荷する実行可能プログラムを除き、setuid プログラムの使用を許可するべきではありません。setuid プログラムの使用を禁止できない場合は、少なくともその使用を制限するべきです。しっかりした管理を行うためには setuid プログラムの数を少なくする必要があります。

詳細は、「実行可能ファイルを原因とするセキュリティーへの悪影響を防止する」を参照してください。作業手順については、「セキュリティーリスクのあるプログラムからの保護 (作業マップ)」を参照してください。

自動セキュリティー拡張ツールの使用

ASET セキュリティーパッケージには、システムのセキュリティーを制御して監視できるように、自動管理ツールが組み込まれています。ASET には、低、中、高という 3 つのセキュリティーレベルがあります。システム管理者は ASET セキュリティーレベルを指定します。上のレベルほど、ASET のファイル制御機能が増え、ファイルアクセスは減少し、システムセキュリティーが厳しくなります。詳細は、第 7 章自動セキュリティー拡張ツールの使用 (手順)を参照してください。

Sun Security Toolkit の使用

ASET はシステムにセキュリティー上のわずかな変更を加えるのに使用できますが、Sun Security Toolkit は Solaris システムの最小化、強化、保護などに対応できる、柔軟で、拡張性のあるメカニズムです。Sun Security Toolkit (旧名称: JASS ツールキット) は、システムにセキュリティー変更を加えるためのツールです。このツールを使用して、システムのセキュリティー状態に関するレポートを生成できます。このツールには、ツールの直前の実行を取り消す機能もあります。JASS ツールキットは、Sun の Web サイト http://www.sun.com/software/security/jass からダウンロードできます。この Web サイトでは、関連するオンラインドキュメントもリンクされています。

このツールキットの詳細は、『Securing Systems with the Solaris Security Toolkit』(Alex Noordergraaf、Glenn Brunette 共著、ISBN 0-13-141071-7、2003 年 6 月発行) を参照してください。このドキュメントは、Sun Microsystems Press によって発行されている Sun BluePrints Series の 1 つです。

`netservices limited` 構成の使用

デフォルトでは、Solaris 10 リリースのインストール時に多数のネットワークサービスが有効になります。システムのネットワーク接続を制限するには、netservices limited コマンドを実行します。このコマンドは、「デフォルトでのセキュリティー強化 (Secure By Default)」(SBD) 構成を有効にします。SBD により、ネットワーク要求を受け付けるネットワークサービスは sshd デーモンだけになります。ほかのネットワークサービスはすべて無効になるか、ローカル要求だけを処理するようになります。ftp などの個々のネットワークサービスを有効にするには、Solaris のサービス管理機能 (SMF) を使用します。詳細は、netservices(1M) および smf(5) のマニュアルページを参照してください。

Solaris のリソース管理機能の使用

Solaris ソフトウェアには、精巧なリソース管理機能があります。これらの機能を使用することで、サーバー統合環境内のアプリケーションによるリソース利用の割り当て、スケジュール、監視、上限設定などを行うことができます。リソース制御フレームワークにより、プロセスが使用するシステムリソースを制限できます。このような制約を行うことで、システムリソースを混乱させようとするスクリプトによるサービス拒否攻撃を防ぎやすくなります。

Solaris リソース管理機能により、特定のプロジェクトに必要なリソースを割り当てたり、使用できるリソースを動的に調整したりできます。詳細は、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』のパート I「資源管理」を参照してください。

Solaris ゾーンの使用

Solaris ゾーンは、単一の Solaris OS インスタンス内に存在するほかのシステムからプロセスが分離されるアプリケーション実行環境です。この分離を行うことで、1 つのゾーン内で稼働しているプロセスがほかのゾーンで稼働しているプロセスを監視したりそれらのプロセスに影響を及ぼしたりすることが防止されます。これは、スーパーユーザー権限によって稼働しているプロセスでも同様です。

Solaris ゾーンは、単一のサーバー上にアプリケーションを複数配置する環境に適しています。詳細は、『Oracle Solaris のシステム管理 (Oracle Solaris コンテナ : 資源管理と Oracle Solaris ゾーン)』のパート II「ゾーン」を参照してください。

マシンリソースの使用状況の監視

システム管理者は、システムの動作を監視する必要があります。次の点を含め、マシンのあらゆる側面に注意する必要があります。

通常の負荷はどの程度か
誰がシステムへのアクセス権を持っているか
各ユーザーはいつシステムにアクセスするか
システムでは通常どのようなプログラムを実行するか

このような情報を把握していれば、ツールを使用してシステムの使用状況を監査し、各ユーザーのアクティビティーを監視できます。セキュリティー侵害と思われる場合は、監視作業が特に役立ちます。監査サービスの詳細は、第 28 章Solaris 監査 (概要) を参照してください。

ファイルの整合性の監視

システム管理者は、管理対象のシステムにインストールされたファイルが予想外の方法で変更されないように確実な対策をとる必要があります。大規模インストールでは、各システム上のソフトウェアスタックの比較や報告を行うツールを使用すればシステムの追跡、記録が行えます。基本監査報告機能 (BART) を使用すると、一定期間にわたって1 つ以上のシステムをファイルレベルでチェックし、システムを包括的に検証できます。一定期間にわたってすべてのシステムまたは 1 つのシステムにおける BART 目録の変化を調べることで、システムの整合性を検証できます。BART には、目録作成機能、目録比較機能、レポート生成規則などが用意されています。詳細は、第 5 章基本監査報告機能の使用方法 (作業)を参照してください。

ファイルアクセスの制御

Solaris OS はマルチユーザー環境です。マルチユーザー環境では、システムにログインしているすべてのユーザーが、ほかのユーザーに属しているファイルを読み取ることができます。さらに、適切なアクセス権をもっているユーザーは、ほかのユーザーに属しているファイルを使用できます。詳細は、第 6 章ファイルアクセスの制御 (作業)を参照してください。ファイルに適切なアクセス権を設定する操作の手順は、「ファイルの保護 (作業マップ)」を参照してください。

暗号化によるファイルの保護

ほかのユーザーがアクセスできないようにすることによって、ファイルを安全に保つことができます。たとえば、アクセス権 600 の付いたファイルに、所有者やスーパーユーザー以外の人がアクセスすることはできません。アクセス権 700 の付いたディレクトリも同様です。ただし、ほかのだれかがユーザーパスワードや root パスワードを推測して発見すると、そのファイルにアクセスできます。さらに、アクセス不能なはずのファイルも、システムファイルのバックアップをオフラインメディアにとるたびに、バックアップテープ上に保存されます。

Solaris 暗号化フレームワークには、ファイルを保護するコマンドとして digest、mac、および encrypt が用意されています。詳細は、第 13 章Solaris の暗号化フレームワーク (概要)を参照してください。

アクセス制御リストの使用

ACL (「アクル」と読む) では、ファイルアクセス権の制御をより強化できます。ACL は、従来の UNIX ファイル保護機能では不十分な場合に追加で使用します。従来の UNIX ファイル保護機能は、所有者、グループ、その他のユーザーという 3 つのユーザークラスに読み取り権、書き込み権、実行権を提供します。ACL では、ファイルセキュリティーを管理するレベルがさらに詳細になります。

ACL では、次のファイルアクセス権を定義できます。

所有者のファイルアクセス権
所有者のグループのファイルアクセス権
所有者のグループに属していないユーザーのファイルアクセス権
特定ユーザーのファイルアクセス権
特定グループのファイルアクセス権
以上のカテゴリそれぞれのデフォルトアクセス権

ACL の使用についての詳細は、「アクセス制御リストによる UFS ファイルの保護」を参照してください。

マシン間でのファイルの共有

ネットワークファイルサーバーは、どのファイルを共有できるかを制御できます。また、共有ファイルにアクセスできるクライアント、およびそれらのクライアントに許可するアクセス権の種類も制御します。一般に、ファイルサーバーは、すべてのクライアントまたは特定のクライアントに、読み取り権と書き込み権、または読み取り専用アクセス権を与えることができます。アクセス制御は、share コマンドでリソースを利用可能にするときに指定します。

ファイルサーバー上の /etc/dfs/dfstab ファイルは、サーバーがネットワーク上のクライアントに提供するファイルシステムをリストします。ファイルシステムの共有の詳細については、『Solaris のシステム管理 (ネットワークサービス)』の「ファイルシステムの自動共有」を参照してください。

共有ファイルへの `root` アクセスの制限

一般的にスーパーユーザーは、ネットワーク上で共有されるファイルシステムには root としてアクセスできません。NFS システムは、要求者のユーザーをユーザー ID 60001 を持つユーザー nobody に変更することによって、マウントされているファイルシステムへの root アクセスを防止します。ユーザー nobody のアクセス権は、公共ユーザーに与えられているアクセス権と同じです。つまり、ユーザー nobody のアクセス権は資格をもたないユーザーのものと同じです。たとえば、ファイルの実行権しか公共に許可していなければ、ユーザー nobody はそのファイルを実行することしかできません。

NFS サーバーは、共有ファイルシステムのスーパーユーザー能力をホスト単位で与えることができます。この権限を与えるには、share コマンドの root=hostname オプションを使用します。このオプションは慎重に使用してください。NFS のセキュリティーオプションの詳細は、『Solaris のシステム管理 (ネットワークサービス)』の第 6 章「ネットワークファイルシステムへのアクセス (リファレンス)」を参照してください。

ネットワークアクセスの制御

コンピュータは通常、複数のコンピュータからなる構成の一部です。この構成を「ネットワーク」と呼びます。ネットワークでは、接続されたコンピュータの間で情報を交換できます。さらに、ネットワークに接続されたコンピュータは、ネットワーク上のほかのコンピュータにあるデータなどのリソースにアクセスできます。コンピュータをネットワーク化すると処理能力と性能が向上しますが、同時にセキュリティーの悪化にも繋がります。

たとえば、ネットワーク内では個々のマシンは情報を共有できるため、未承認アクセスがセキュリティーリスクとなります。多くの人々がネットワークにアクセスするので、(特にユーザーエラーを通して) 未承認アクセスが発生する可能性も大きくなります。また、パスワードの不適切な扱いも未承認アクセスの原因となります。

ネットワークセキュリティー機構

一般にネットワークセキュリティーは、遠隔システムからの操作の制限またはブロックを通して維持されます。次の図は、遠隔操作に適用できるセキュリティー制限を示します。

図 2–1 遠隔操作のセキュリティー制限

この図は、遠隔システムに対するアクセスを制限する 3 つの方法、ファイアウォールシステム、認証メカニズム、承認メカニズムを示しています。

遠隔アクセスの認証と承認

「認証」とは、遠隔システムにアクセスできるユーザーを特定のユーザーに限定する方法です。認証は、システムレベルでもネットワークレベルでも設定できます。ユーザーが遠隔システムにアクセスすると、「承認」という方法でそのユーザーが実行できる操作が制限されます。次の表は、認証と承認を提供するサービスを示したものです。

表 2–3 遠隔アクセス用の認証サービスと承認サービス


サービス	説明	詳細
IPsec	IPsec は、ホストに基づく認証および認可に基づく認証と、ネットワークトラフィックの暗号化を行います。	『Solaris のシステム管理 (IP サービス)』の第 19 章「IP セキュリティーアーキテクチャー (概要)」
Kerberos	Kerberos は、システムにログインしているユーザーの認証と承認を暗号化を通して行います。	この例は、「Kerberos サービスの動作」を参照してください。
LDAP と NIS+	LDAP ディレクトリサービスと NIS+ ネームサービスは、ネットワークレベルで認証および承認を行います。	『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』および『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』
遠隔ログインコマンド	遠隔ログインコマンドを使用すると、ユーザーはネットワーク経由で遠隔システムにログインし、そのリソースを使用できます。遠隔ログインコマンドには `rlogin`、`rcp`、`ftp` などがあります。「信頼される (trusted) ホスト」の場合、認証は自動的に処理されます。それ以外の場合は、自分自身を認証するように求められます。	『Solaris のシステム管理 (ネットワークサービス)』の第 29 章「リモートシステムへのアクセス (手順)」
SASL	簡易認証セキュリティー層 (SASL) は、ネットワークプロトコルに認証サービスとセキュリティーサービス (オプション) を提供するフレームワークです。プラグインによって、適切な認証プロトコルを選択できます。	「SASL (概要)」
Secure RPC	Secure RPC を使用すると、遠隔マシン上で要求を出したユーザーの認証が行われ、ネットワーク環境のセキュリティーが高まります。Secure RPC には、UNIX、DES、または Kerberos 認証システムを使用できます。	「Secure RPC の概要」
	Secure RPC を使用すると、NFS 環境にセキュリティーを追加できます。Secure RPC を備えた NFS 環境を Secure NFS と呼びます。Secure NFS は、公開鍵に Diffie-Hellman 認証を使用します。	「NFS サービスと Secure RPC」
Solaris Secure Shell	Solaris Secure Shell は、セキュリティー保護されていないネットワーク上のネットワークトラフィックを暗号化します。Solaris Secure Shell は、パスワードまたは公開鍵、あるいはこの両方による認証を提供します。このサービスは、公開鍵に RSA 認証と DSA 認証を使用します。	「Solaris Secure Shell (概要)」

Secure RPC に匹敵する機能として、Solaris の「特権ポート」メカニズムがあります。特権ポートには、1024 未満のポート番号が割り当てられます。クライアントシステムは、クライアントの資格を認証したあと、特権ポートを使用してサーバーへの接続を設定します。次に、サーバーは接続のポート番号を検査してクライアントの資格を検証します。

Solaris ソフトウェアを使用していないクライアントは、特権ポートを使用して通信できないことがあります。クライアントが特権ポートを使って通信できない場合は、次のようなエラーメッセージが表示されます。

“Weak Authentication
NFS request from unprivileged port”

ファイアウォールシステム

ファイアウォールシステムを設定すると、ネットワーク内のリソースを外部のアクセスから保護できます。「ファイアウォールシステム」は、内部ネットワークと外部ネットワークの間のバリアとして機能するセキュリティー保護ホストです。内部ネットワークは、ほかのネットワークを「信頼できる状態でない」ものとして扱います。内部ネットワークと、インターネットなどの外部ネットワークとの間に、このような設定を必ず行うようにしてください。

ファイアウォールはゲートウェイとしても機能しますし、バリアとしても機能します。ファイアウォールは、まず、ネットワーク間でデータを渡すゲートウェイとして機能します。さらに、ファイアウォールは、データが勝手にネットワークに出入りしないようにブロックするバリアとして機能します。ファイアウォールは、内部ネットワーク上のユーザーに対して、ファイアウォールシステムにログインして遠隔ネットワーク上のホストにアクセスするように要求します。また、外部ネットワーク上のユーザーは、内部ネットワーク上のホストにアクセスする前に、まずファイアウォールシステムにログインしなければなりません。

ファイアウォールは、一部の内部ネットワーク間でも有効です。たとえば、ファイアウォール、すなわちセキュリティー保護ゲートウェイコンピュータを設定することによって、パケットの転送を制限できます。ゲートウェイコンピュータは、ゲートウェイ自身をパケットの発信元アドレスまたは着信先アドレスとしないような、2 つのネットワーク間のパケット交換を禁止できます。また、ファイアウォールは、特定のプロトコルについてのみパケットを転送するように設定する必要があります。たとえば、パケットでメールを転送できるが、telnet や rlogin コマンドのパケットは転送できないようにできます。ASET は、高度なセキュリティーを適用して実行すると、インターネットプロトコル (IP) パケットの転送機能を無効にします。

さらに、内部ネットワークから送信されるすべての電子メールは、まずファイアウォールシステムに送信されます。ファイアウォールは、このメールを外部ネットワーク上のホストに転送します。ファイアウォールシステムは、すべての着信電子メールを受信して内部ネットワーク上のホストに配信するという役割も果たします。

注意 –

ファイアウォールは、アクセス権のないユーザーが内部ネットワーク上のホストにアクセスする行為を防止します。ファイアウォールに適用される厳密で確実なセキュリティーを管理する必要がありますが、ネットワーク上の他のホストのセキュリティーはもっと緩やかでも構いません。ただし、ファイアウォールシステムを突破できる侵入者は、内部ネットワーク上の他のすべてのホストへのアクセスを取得できる可能性があります。

ファイアウォールシステムには、信頼されるホストを配置しないでください。「信頼されるホスト」とは、ユーザーがログインするときに、パスワードを入力する必要がないホストのことです。ファイアウォールシステムでは、ファイルシステムを共有しないでください。また、ほかのサーバーのファイルシステムをマウントしないでください。

次の技術は、システムを強化してファイアウォールを確立するのに利用できます。

ASET は、ファイアウォールシステムにおける高セキュリティーを実現します。詳細は、第 7 章自動セキュリティー拡張ツールの使用 (手順)を参照してください。
Sun Security Toolkit (旧名称: JASS ツールキット) は、Solaris システムを強化してファイアウォールを確立するために利用できます。このツールキットは、Sun の Web サイト http://www.sun.com/software/security/jass からダウンロードできます。
IPsec と Solaris IP フィルタには、ファイアウォール保護機能があります。ネットワークトラフィックの保護についての詳細は、『Solaris のシステム管理 (IP サービス)』のパート IV「IP セキュリティー」を参照してください。

暗号化システムとファイアウォールシステム

ほとんどのローカルエリアネットワークでは、データは「パケット」と呼ばれるブロック単位でコンピュータ間で転送されます。ネットワークの外部にいるアクセス権のないユーザーが、「パケットスマッシング」という方法により、データを変更または破壊する可能性があります。

パケットスマッシングでは、パケットが宛先に到達する前に取り込まれます。侵入者は、その内容に勝手なデータを書き込み、パケットを元のコースに戻します。ローカルエリアネットワーク上では、パケットはサーバーを含むすべてのシステムに同時に到達するので、パケットスマッシングは不可能です。ただし、ゲートウェイ上ではパケットスマッシングが可能なため、ネットワーク上のすべてのゲートウェイを保護する必要があります。

もっとも危険なのは、データの完全性に影響するような攻撃です。このような攻撃を受けると、パケットの内容が変更されたり、ユーザーが偽装されたりします。盗聴を伴う攻撃では、データの完全性が損なわれることはありません。盗聴者は、会話を記録して、あとで再生します。盗聴者がユーザーを偽装することはありません。盗聴攻撃によってデータの完全性が損なわれることはありませんが、プライバシが侵害されます。ネットワーク上でやりとりされるデータを暗号化すると、重要な情報のプライバシを保護できます。

セキュリティー保護されていないネットワーク上での遠隔処理を暗号化する方法については、第 19 章Solaris Secure Shell の使用 (手順)を参照してください。
ネットワーク上でのデータの暗号化と認証を行う方法については、第 21 章Kerberos サービスについてを参照してください。
IP データグラムを暗号化する方法については、『Solaris のシステム管理 (IP サービス)』の第 19 章「IP セキュリティーアーキテクチャー (概要)」を参照してください。

セキュリティー問題の報告

セキュリティーの問題が発生した可能性がある場合は、Computer Emergency Response Team/Coordination Center (CERT/CC) に連絡してください。CERT/CC は、Defense Advanced Research Projects Agency (DARPA) の資金提供を受けたプロジェクトで、カーネギメロン大学の Software Engineering Institute にあります。CERT/CC はセキュリティー問題の解決を支援できます。また、特定のニーズに合った他の Computer Emergency Response Team を紹介することもできます。CERT/CC に連絡するには、24 時間のホットラインに電話する方法と、電子メールをcert@cert.sei.cmu.edu に送る方法があります。

第 3 章システムアクセスの制御 (作業)

この章では、Solaris システムにアクセスできるユーザーを制御する方法について説明します。この章の内容は次のとおりです。

システムセキュリティーの概要については、第 2 章マシンセキュリティーの管理 (概要)を参照してください。

システムアクセスの制御 (作業マップ)

コンピュータのセキュリティーレベルは、コンピュータのもっとも弱い点によって決まります。次の作業マップは、どのような分野を監視してそのセキュリティーを確保すべきかを示しています。

作業	説明	参照先
ユーザーログインを監視、許可、および拒否します	一般的でないログインアクティビティーを監視します。ログインを一時的に禁止します。ダイヤルアップログインを管理します。	「ログインとパスワードの保護 (作業マップ)」
パスワードの強力な暗号化を可能にします	ユーザーパスワードを暗号化するアルゴリズムを指定します。ほかのアルゴリズムをインストールします。	「パスワードアルゴリズムの変更 (作業マップ)」
スーパーユーザーによる処理の監視と制限を行います	スーパーユーザーによる処理を定期的に監視します。`root` ユーザーによる遠隔ログインを禁止します。	「スーパーユーザーの監視と制限 (作業マップ)」
ハードウェア設定へのアクセスを禁止します	通常のユーザーを PROM にアクセスさせません。	「SPARC: システムハードウェアに対するアクセスの制御 (作業マップ)」

ログインとパスワードの保護 (作業マップ)

次の作業マップは、ユーザーログインを監視する手順と、ユーザーログインを無効にする手順を示しています。

作業	説明	参照先
ユーザーのログイン状態を表示します	ユーザーのログインアカウントについての広範な情報 (フルネーム、パスワードの有効期限など) を表示します。	「ユーザーのログイン状態を表示する方法」
パスワードを所有していないユーザーを発見します	パスワードを必要としないアカウントを持つユーザーだけを検出します。	「パスワードを持たないユーザーを表示する方法」
ログインを一時的に無効にします	システムシャットダウンや定常的な保守の中でマシンへのユーザーログインを拒否します。	「ユーザーのログインを一時的に無効にする方法」
ログイン失敗操作を保存します	正しいパスワードの入力に 5 回失敗したユーザーのログを作成します。	「ログイン失敗操作を監視する方法」
失敗したすべてのログイン操作を保存します	失敗したログイン操作のログを作成します。	「すべてのログイン失敗操作を監視する方法」
ダイヤルアップパスワードを作成します	モデムやダイヤルアップポートを通して遠隔ログインするユーザーに追加パスワードを要求します。	「ダイヤルアップパスワードを作成する方法」
ダイヤルアップログインを一時的に無効にします	ユーザーがモデムやポートを通して遠隔からダイヤルできないようにします。	「ダイヤルアップログインを一時的に無効にする方法」

ログインとパスワードのセキュリティー

遠隔ログインを制限し、ユーザーにパスワードを要求するようにできます。失敗したアクセス操作を監視し、ログインを一時的に無効にすることもできます。

ユーザーのログイン状態を表示する方法

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

logins コマンドを使用してユーザーのログイン状態を表示します。
# logins -x -l username
-x

ログイン状態情報の拡張セットを表示します。

-l username

指定するユーザーのログイン状態を表示します。変数 username はユーザーのログイン名です。複数のログイン名は、コンマで区切って指定します。

logins コマンドは、適切なパスワードデータベースを使ってユーザーのログイン状態を表示します。このデータベースは、ローカルの /etc/passwd ファイルか、ネームサービスのパスワードデータベースです。詳細は、logins(1M) のマニュアルページを参照してください。

例 3–1 ユーザーのログイン状態を表示する

次の例では、ユーザー rimmer のログイン状態が表示されます。

# logins -x -l rimmer
rimmer       500     staff           10   Annalee J. Rimmer
                     /export/home/rimmer
                     /bin/sh
                     PS 010103 10 7 -1

rimmer

ユーザーのログイン名を示します。

500

ユーザー ID (UID) を示します。

staff

ユーザーの一次グループを示します。

10

グループ ID (GID) を示します。

Annalee J. Rimmer

コメントを示します。

/export/home/rimmer

ユーザーのホームディレクトリを示します。

/bin/sh

ログインシェルを示します。

PS 010170 10 7 -1

次のパスワード有効期限情報を示します。

パスワードの最終変更日
次に変更するまでに必要な日数
変更しないで使用できる日数
警告期間

パスワードを持たないユーザーを表示する方法

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

loginsコマンドを使用して、パスワードを持っていないユーザーをすべて表示します。
# logins -p
-p オプションを指定すると、パスワードを持たないユーザーが一覧表示されます。logins コマンドは、ネームサービスが有効になっていない限り、ローカルシステムのパスワードデータベースを使用します。

例 3–2 パスワードを持たないユーザーを表示する

次の例では、ユーザー pmorph はパスワードを持っていません。

# logins -p
pmorph          501     other           1       Polly Morph
#

ユーザーのログインを一時的に無効にする方法

システムシャットダウンや定常的な保守の際にユーザーのログインを一時的に無効にします。スーパーユーザーのログインは影響を受けません。詳細は、nologin(4) のマニュアルページを参照してください。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

テキストエディタで、/etc/nologin ファイルを作成します。
# vi /etc/nologin

システムの利用に関するメッセージを入力します。

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

例 3–3 ユーザーログインを無効にする

この例では、システムを使用できないことがユーザーに通知されます。

# vi /etc/nologin
(Add system message here)
 
# cat /etc/nologin 
***No logins permitted.***

***The system will be unavailable until 12 noon.***

システムを実行レベル 0、つまりシングルユーザーモードにしてログインを無効にすることもできます。システムをシングルユーザーモードにする方法については、『Solaris のシステム管理 (基本編)』の第 10 章「システムのシャットダウン (手順)」を参照してください。

ログイン失敗操作を監視する方法

この作業は、端末ウィンドウで行われたログイン操作の失敗を記録します。CDE ログインと GNOME ログインの操作失敗は記録しません。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

/var/adm ディレクトリに loginlog ファイルを作成します。
# touch /var/adm/loginlog

loginlog ファイルに root ユーザーの読み取り権と書き込み権を設定します。
# chmod 600 /var/adm/loginlog

loginlog ファイルのグループのメンバーシップを sys に変更します。
# chgrp sys /var/adm/loginlog

ログが正常に記録されるか検証します。

たとえば、間違ったパスワードを使用してシステムに 5 回ログインします。次に、/var/adm/loginlog ファイルを表示します。

# more /var/adm/loginlog
jdoe:/dev/pts/2:Tue Nov  4 10:21:10 2003
jdoe:/dev/pts/2:Tue Nov  4 10:21:21 2003
jdoe:/dev/pts/2:Tue Nov  4 10:21:30 2003
jdoe:/dev/pts/2:Tue Nov  4 10:21:40 2003
jdoe:/dev/pts/2:Tue Nov  4 10:21:49 2003
#

loginlog ファイルには、失敗操作ごとに 1 つずつエントリが入っています。各エントリには、ユーザーのログイン名、tty デバイス、操作の失敗回数が入っています。4 回以下の失敗であれば、ログに記録されません。

loginlog ファイルのサイズが大きくなる場合は、コンピュータシステムへの侵入が試みられている可能性があります。このため、このファイルの内容を定期的にチェックして空にしてください。詳細は、loginlog(4) のマニュアルページを参照してください。

すべてのログイン失敗操作を監視する方法

この作業は、失敗したログイン操作をすべて syslog ファイルに記録します。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

SYSLOG と SYSLOG_FAILED_LOGINS に希望する値を指定して、/etc/default/login ファイルを設定します。

/etc/default/login ファイルを編集して、エントリを変更します。SYSLOG=YES のコメントを解除していることを確認してください。
# grep SYSLOG /etc/default/login # SYSLOG determines whether the syslog(3) LOG_AUTH facility # should be used SYSLOG=YES … SYSLOG_FAILED_LOGINS=0 #

ログ操作の情報を記録できる適切なアクセス権でファイルを作成します。
1. /var/adm ディレクトリに authlog ファイルを作成します。
  # touch /var/adm/authlog
2. authlog ファイルに、root ユーザーの読み取り権と書き込み権を設定します。
  # chmod 600 /var/adm/authlog
3. authlog ファイルのグループのメンバーシップを sys に変更します。
  # chgrp sys /var/adm/authlog

失敗したパスワード操作を記録するように、syslog.conf ファイルを編集します。

失敗は、authlog ファイルに送る必要があります。
1. syslog.conf ファイルに次のエントリを入力します。
  
  syslog.conf 内の同じ行にあるフィールドは、タブで区切ります。
  auth.notice <Press Tab> /var/adm/authlog
2. syslog デーモンの構成情報を再表示します。
  # svcadm refresh system/system-log

ログが正常に記録されるか検証します。

たとえば、間違ったパスワードを使用し、通常のユーザーとしてシステムにログインします。続いて、Primary Administrator 役割かスーパーユーザーとして、/var/adm/authlog ファイルを表示します。
# more /var/adm/authlog Nov 4 14:46:11 example1 login: [ID 143248 auth.notice] Login failure on /dev/pts/8 from example2, stacey #

定期的に /var/adm/authlog ファイルを監視します。

例 3–4 ログインが 3 回失敗したあとのアクセス操作を記録する

/etc/default/login ファイルの SYSLOG_FAILED_LOGINS の値を 3 に設定する点以外は、前述の作業と同じです。

例 3–5 ログイン操作が 3 回失敗したあとで接続を遮断する

/etc/default/login ファイルの RETRIES エントリのコメントを解除し、RETRIES の値を 3 に設定します。この編集結果はただちに適用されます。1 つのセッションでログインが 3 回試されたあと、システムは接続を遮断します。

ダイヤルアップパスワードを作成する方法

注意 –

最初にダイヤルアップパスワードを設定するときには、少なくとも 1 つのポートにログインしたまま別のポートでパスワードをテストしてください。ログアウトして新しいパスワードをテストすると、元どおりログインできなくなることがあります。まだ別のポートにログインしていれば、元に戻ってミスを訂正できます。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

シリアルデバイスの一覧が入った /etc/dialups ファイルを作成します。

このファイルには、ダイヤルアップパスワードで保護されているすべてのポートを含めてください。/etc/dialups ファイルは次のようになります。
/dev/term/a /dev/term/b /dev/term/c

ダイヤルアップパスワードを要求するログインプログラムが入った /etc/d_passwd ファイルを作成します。

uucico、sh、ksh、csh など、ユーザーがログイン時に実行できるシェルプログラムを含めます。/etc/d_passwd ファイルは次のようになります。
/usr/lib/uucp/uucico:encrypted-password: /usr/bin/csh:encrypted-password: /usr/bin/ksh:encrypted-password: /usr/bin/sh:encrypted-password:
この手順の後半で、各ログインプログラムに暗号化されたパスワードを追加することになります。

2 つのファイルの所有権を root に設定します。
# chown root /etc/dialups /etc/d_passwd

2 つのファイルのグループの所有権を root に設定します。
# chgrp root /etc/dialups /etc/d_passwd

2 つのファイルに root の読み取り権と書き込み権を設定します。
# chmod 600 /etc/dialups /etc/d_passwd

暗号化パスワードを作成します。
1. 一時的なユーザーを作成します。
  # useradd username
2. 一時的なユーザーのパスワードを作成します。
  # passwd username New Password: <Type password> Re-enter new Password: <Retype password> passwd: password successfully changed for username
3. 暗号化パスワードを取り出します。
  # grep username /etc/shadow > username.temp
4. username.temp ファイルを編集します。
  
  暗号化パスワードを除くすべてのフィールドを削除します。2 つ目のフィールドに、暗号化パスワードが入っています。
  
  たとえば、次の行では、暗号化パスワードは U9gp9SyA/JlSk です。
  temp:U9gp9SyA/JlSk:7967:::::7988:
5. 一時的なユーザーを削除します。
  # userdel username

username.temp ファイルから /etc/d_passwd ファイルに暗号化パスワードをコピーします。

ログインシェルごとに別のパスワードを作成することも、共通のパスワードを使用することもできます。

パスワードをダイヤルアップユーザーに知らせます。

盗聴のおそれがない方法でパスワードを知らせる必要があります。

ダイヤルアップログインを一時的に無効にする方法

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

/etc/d_passwd ファイルのエントリを次の 1 行だけにします。
/usr/bin/sh:*:

パスワードアルゴリズムの変更 (作業マップ)

次の作業マップは、パスワードアルゴリズムを管理する手順を示しています。

作業	参照先
パスワードの強力な暗号化を可能にします	「パスワード暗号化のアルゴリズムを指定する方法」
ネームサービスでパスワードの強力な暗号化を提供します	「NIS ドメイン用の新しいパスワードアルゴリズムを指定する方法」
	「NIS+ ドメイン用の新しいパスワードアルゴリズムを指定する方法」
	「LDAP ドメイン用の新しいパスワードアルゴリズムを指定する方法」
新しいパスワード暗号化モジュールを追加します	「Sun 以外のパスワード暗号化モジュールをインストールする方法」

パスワード暗号化のデフォルトアルゴリズムを変更する

デフォルトでは、ユーザーパスワードは crypt_unix アルゴリズムで暗号化されます。デフォルトのパスワード暗号化アルゴリズムを変更することによって、MD5 や Blowfish など、より強力な暗号化アルゴリズムを使用できます。

パスワード暗号化のアルゴリズムを指定する方法

この手順では、ユーザーがパスワードを変更するときのデフォルト暗号化アルゴリズムとして BSD-Linux バージョンの MD5 アルゴリズムが使用されます。このアルゴリズムは、Solaris、BSD、Linux バージョンの UNIX が混在するマシンネットワークに適しています。パスワード暗号化アルゴリズムとアルゴリズム識別子の一覧は、表 2–1 を参照してください。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

選択した暗号化アルゴリズムの識別子を指定します。

暗号化アルゴリズムの識別子を、/etc/security/policy.conf ファイルの CRYPT_DEFAULT 変数の値として入力します。

選択についての説明をコメントとして入力できます。

# cat  /etc/security/policy.conf
…
CRYPT_ALGORITHMS_ALLOW=1,2a,md5,5,6
#
# Use the version of MD5 that works with Linux and BSD systems.
# Passwords previously encrypted with __unix__ will be encrypted with MD5
# when users change their passwords.
#
#
CRYPT_DEFAULT=__unix__
CRYPT_DEFAULT=1

この例では、アルゴリズム構成を指定することによって、もっとも弱いアルゴリズムである crypt_unix がパスワードの暗号化に使用されることがないようにします。crypt_unix モジュールで暗号化されているパスワードは、次回のパスワード変更から crypt_bsdmd5 で暗号化されます。

選択したアルゴリズムの構成の詳細については、policy.conf(4) のマニュアルページを参照してください。

例 3–6 パスワードの暗号化に Blowfish アルゴリズムを使用する

この例では、policy.conf ファイルの CRYPT_DEFAULT 変数の値として、Blowfish アルゴリズムの識別子 2a が指定されています。

CRYPT_ALGORITHMS_ALLOW=1,2a,md5,5,6
#CRYPT_ALGORITHMS_DEPRECATE=__unix__
CRYPT_DEFAULT=2a

この構成は、Blowfish アルゴリズムを使用する BSD システムに対応しています。

NIS ドメイン用の新しいパスワードアルゴリズムを指定する方法

NIS ドメインのユーザーがパスワードを変更すると、NIS クライアントは、/etc/security/policy.conf ファイルにある自身のローカルアルゴリズム構成を調べ、パスワードを暗号化します。

パスワード暗号化アルゴリズムを NIS クライアント上の /etc/security/policy.conf ファイルに指定します。

変更された /etc/security/policy.conf ファイルを NIS ドメインのすべてのクライアントマシンにコピーします。

混乱をできるだけ少なくするために、変更された /etc/security/policy.conf ファイルを NIS ルートサーバーとスレーブサーバーにコピーします。

NIS+ ドメイン用の新しいパスワードアルゴリズムを指定する方法

NIS+ ドメインのユーザーがパスワードを変更すると、NIS+ ネームサービスは、NIS+ マスターにある/etc/security/policy.conf ファイルのアルゴリズム構成を調べます。rpc.nispasswd デーモンが動作するこの NIS+ マスターが、暗号化されたパスワードを作成します。

パスワード暗号化アルゴリズムを NIS+ マスター上の /etc/security/policy.conf ファイルに指定します。

混乱をできるだけ少なくするために、NIS+ マスターの /etc/security/policy.conf ファイルを NIS+ ドメインのすべてのホストにコピーします。

LDAP ドメイン用の新しいパスワードアルゴリズムを指定する方法

適切に構成された LDAP クライアントでは、新しいパスワードアルゴリズムを使用できます。LDAP クライアントは NIS クライアントと同じように動作します。

パスワード暗号化アルゴリズムを LDAP クライアント上の /etc/security/policy.conf ファイルに指定します。

変更された policy.conf ファイルを LDAP ドメインのすべてのクライアントマシンにコピーします。

クライアントの /etc/pam.conf ファイルが pam_ldap モジュールを使用していないことを確認します。

pam_ldap.so.1 を含むエントリの前にコメント記号 (#) があることを確認します。pam_authtok_store.so.1 モジュールには新しい server_policy オプションを使用しないでください。

ローカルアルゴリズム構成に基づくパスワードの暗号化は、クライアントの pam.conf ファイルの PAM エントリに従って行われます。また、パスワードの認証もこの PAM エントリによって行われます。

LDAP ドメインのユーザーがパスワードを変更すると、LDAP クライアントは、/etc/security/policy.conf ファイルにある自身のローカルアルゴリズム構成を調べ、パスワードを暗号化します。続いてクライアントは、{crypt} タグ付きの暗号化パスワードをサーバーに送信します。このタグは、パスワードが暗号化済みであることをサーバーに知らせます。パスワードはそのままの形でサーバーに格納されます。認証時に、クライアントはこのパスワードをサーバーから取り出します。クライアントは、このパスワードと、入力されたユーザーのパスワードからクライアントが暗号化したばかりのパスワードとを比較します。

注 –
LDAP サーバーでパスワードポリシー制御を使用するには、pam.conf ファイルの pam_authtok_store エントリに server_policy オプションを指定します。これによって、パスワードは、Sun Java System Directory Server の暗号化メカニズムを使ってサーバー上で暗号化されます。この手順については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』の第 11 章「LDAP クライアントと Sun Java System Directory Server の設定 (手順)」を参照してください。

Sun 以外のパスワード暗号化モジュールをインストールする方法

Sun 以外のパスワード暗号化アルゴリズムは、通常、ソフトウェアパッケージのモジュールの 1 つとして配布されます。したがって、pkgadd コマンドを実行すると、/etc/security/crypt.conf ファイルはベンダーのスクリプトによって変更されるはずです。このあとで、/etc/security/policy.conf ファイルに新しいモジュールとその識別子を指定してください。

pkgadd コマンドを実行してソフトウェアを追加します。

ソフトウェアの追加方法については、『Solaris のシステム管理 (基本編)』の「ソフトウェアパッケージの追加または削除 (pkgadd)」を参照してください。

新しいモジュールとモジュール識別子が追加されたことを確認します。

/etc/security/crypt.conf ファイル内の暗号化アルゴリズムの一覧でチェックしてください。

たとえば、次の行は、crypt_rot13 アルゴリズムを実装するモジュールが追加されていることを示します。

# crypt.conf
#
md5 /usr/lib/security/$ISA/crypt_md5.so
rot13 /usr/lib/security/$ISA/crypt_rot13.so

# For *BSD - Linux compatibility
# 1 is MD5,  2a is Blowfish
1 /usr/lib/security/$ISA/crypt_bsdmd5.so
2a /usr/lib/security/$ISA/crypt_bsdbf.so

/etc/security/policy.conf ファイルに、新たにインストールされたアルゴリズムの識別子を追加します。

次に、識別子 rot13 を追加する必要がある policy.conf ファイルの一部を示します。

# Copyright 1999-2002 Sun Microsystems, Inc.  All rights reserved.
# ...
#ident  "@(#)policy.conf        1.12     08/05/14 SMI"
# ...
# crypt(3c) Algorithms Configuration
CRYPT_ALGORITHMS_ALLOW=1,2a,md5,5,6,,rot13
#CRYPT_ALGORITHMS_DEPRECATE=__unix__
CRYPT_DEFAULT=md5

この例では、現在のパスワードが crypt_rot13 アルゴリズムで暗号化されていれば、rot13 アルゴリズムが使用されます。新しいユーザーパスワードは crypt_sunmd5 アルゴリズムで暗号化されます。このアルゴリズム構成は Solaris だけからなるネットワークで有効です。

スーパーユーザーの監視と制限 (作業マップ)

次の作業マップは、root ユーザーログインの監視と制限の方法を示しています。

作業	説明	参照先
`su` コマンドを使用しているユーザーを監視します	`sulog` ファイルを定期的に走査します。	「`su` コマンドを使用するユーザーを監視する方法」
スーパーユーザーの活動をコンソールに表示します	スーパーユーザーによるアクセス操作が行われたときそのアクセス操作を監視します。	「スーパーユーザーのログインを制限し監視する方法」

スーパーユーザーの監視と制限

スーパーユーザーのアカウントを使用する代わりに、役割によるアクセス制御を設定できます。役割によるアクセス制御を RBAC と呼びます。RBAC の概要は、「役割によるアクセス制御 (概要)」を参照してください。RBAC の設定方法については、第 9 章役割によるアクセス制御の使用 (手順)を参照してください。

`su` コマンドを使用するユーザーを監視する方法

sulog ファイルには、ユーザーからスーパーユーザーに切り替えたときの su コマンドの使用を含め、すべての su コマンドの使用歴が記録されます。

/var/adm/sulog ファイルの内容を定期的に監視します。

# more /var/adm/sulog
SU 12/20 16:26 + pts/0 stacey-root
SU 12/21 10:59 + pts/0 stacey-root
SU 01/12 11:11 + pts/0 root-rimmer
SU 01/12 14:56 + pts/0 pmorph-root
SU 01/12 14:57 + pts/0 pmorph-root

ここには、次のような情報が表示されます。

コマンドが入力された日時。
コマンド試行の成否。プラス記号 (+) は成功を示し、マイナス記号 (-) は失敗を示します。
コマンドが実行されたポート。
ユーザー名と切り替えたユーザー ID。

このファイルへの su ログの記録は、デフォルトで、 /etc/default/su ファイルの次のエントリで有効になっています。

SULOG=/var/adm/sulog

注意事項

??? を含むエントリは、su コマンドの制御端末を識別できないことを示しています。通常、デスクトップが表示される前の su コマンドのシステム呼び出しには、??? が含まれます。たとえば、SU 10/10 08:08 + ??? root-root です。ユーザーがデスクトップセッションを開始すると、ttynam コマンドは、次のように制御端末の値を sulog に返します。 SU 10/10 10:10 + pts/3 jdoe-root。

次のようなエントリは、su コマンドがコマンド行で呼び出されなかったことを示している場合があります。SU 10/10 10:20 + ??? root-oracle。ユーザーが GUI を使用して oracle ロールに切り替えた可能性があります。

スーパーユーザーのログインを制限し監視する方法

この方法では、ローカルシステムにアクセスしようとするスーパーユーザーをただちに検出できます。

/etc/default/login ファイルの CONSOLE エントリを確認します。
CONSOLE=/dev/console
デフォルトのコンソールデバイスは /dev/console に設定されています。このように設定されていると、root はコンソールにログインできます。root は遠隔ログインを行うことはできません。

root が遠隔ログインできないことを検証します。

遠隔システムから、スーパーユーザーとしてログインを試みます。
mach2 % rlogin -l root mach1 Password: <Type root password of mach1> Not on system console Connection closed.

スーパーユーザーになろうとする試みを監視します。

デフォルトでは、スーパーユーザーになろうとすると、その試行が SYSLOG ユーティリティーによってコンソールに表示されます。
1. デスクトップに端末コンソールを開きます。
2. 別のウインドウで、su コマンドを使ってスーパーユーザーになります。
  % su - Password: <Type root password> #
  端末コンソールにメッセージが表示されます。
  Sep 7 13:22:57 mach1 su: 'su root' succeeded for jdoe on /dev/pts/6

例 3–7 スーパーユーザーのアクセス試行のログを作成する

この例では、スーパーユーザーになろうとする試みは SYSLOG によってログされていません。そのため、管理者は、/etc/default/su ファイルの #CONSOLE=/dev/console エントリのコメントを解除して、試行のログを作成します。

# CONSOLE determines whether attempts to su to root should be logged
# to the named device
#
CONSOLE=/dev/console

ユーザーがスーパーユーザーになろうとすると、その試行が端末コンソールに表示されます。

SU 09/07 16:38 + pts/8 jdoe-root

注意事項

/etc/default/login ファイルにデフォルトの CONSOLE エントリが含まれている場合、遠隔システムからスーパーユーザーになるには、ユーザーはまず自分のユーザー名でログインする必要があります。自分のユーザー名でログインしたあとに、su コマンドを使ってスーパーユーザーになることができます。

コンソールに Mar 16 16:20:36 mach1 login: ROOT LOGIN /dev/pts/14 FROM mach2.Example.COM のようなエントリが表示されたら、システムは遠隔 root ログインを認めていることになります。遠隔システムからのスーパーユーザーアクセスを禁止するには、/etc/default/login ファイルの #CONSOLE=/dev/console エントリを CONSOLE=/dev/console に変更します。

SPARC: システムハードウェアに対するアクセスの制御 (作業マップ)

次の作業マップは、PROM を不当なアクセスから守る方法を示しています。

作業	説明	参照先
ユーザーにシステムのハードウェア設定を変更させません	PROM 設定の変更にパスワードを求めます。	「ハードウェアアクセスのパスワードを必須にする方法」
アボートシーケンスを無効にします	ユーザーが PROM にアクセスできないようにします。	「システムのアボートシーケンスを無効にする方法」

システムハードウェアアクセスの制御

物理的なマシンは、ハードウェア設定にアクセスする際にパスワードを入力させることで保護できます。さらに、ユーザーがアボートシーケンスを使ってウィンドウシステムを離れるのを防ぐことによってマシンを保護する方法もあります。

ハードウェアアクセスのパスワードを必須にする方法

x86 システムでは、BIOS の保護が PROM の保護に相当します。BIOS を保護する方法については、使用しているマシンのマニュアルを参照してください。

スーパーユーザーになるか、あるいは Device Security プロファイル、Maintenance and Repair プロファイル、または System Administrator プロファイルを含んだ役割を引き受けます。

System Administrator プロファイルには、Maintenance and Repair プロファイルが含まれます。System Administrator プロファイルを含む役割の作成や、役割をユーザーに割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。

端末ウィンドウで、次のように入力して PROM セキュリティーモードに入ります。
# eeprom security-mode=command Changing PROM password: New password: <Type password> Retype new password: <Retype password>
値として command か full を選択します。詳細は、eeprom(1M) のマニュアルページを参照してください。

前述のコマンドを入力する際に PROM パスワードを要求されない場合は、システムがすでに PROM パスワードを持っています。

(省略可能) PROM パスワードを変更する場合は、次のコマンドを入力します。
# eeprom security-password= Press Return Changing PROM password: New password: <Type password> Retype new password: <Retype password>
新しい PROM セキュリティーモードとパスワードはただちに有効になりますが、それが認識できるのは、ほとんどの場合、次回の起動時です。

注意 –
PROM パスワードを忘れないでください。このパスワードがないと、ハードウェアは使用できません。

システムのアボートシーケンスを無効にする方法

一部のサーバーシステムにはキースイッチがあります。このキースイッチを安全な位置に設定すると、ソフトウェアキーボードのアボート設定が無効になります。そのため、次の手順で行った変更が実装されないことがあります。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

KEYBOARD_ABORT の値を disable に変更します。

/etc/default/kbd ファイルの enable 行をコメントにします。次に disable 行を追加します。

# cat /etc/default/kbd
…
# KEYBOARD_ABORT affects the default behavior of the keyboard abort
# sequence, see kbd(1) for details.  The default value is "enable".
# The optional value is "disable".  Any other value is ignored.
…
#KEYBOARD_ABORT=enable
KEYBOARD_ABORT=disable

キーボードのデフォルトを更新します。
# kbd -i

第 4 章デバイスアクセスの制御 (作業)

この章では、デバイスを保護するための作業について説明するとともに、参考となる節を示します。この章の内容は次のとおりです。

デバイスの保護についての概要は、「デバイスアクセスの制御」を参照してください。

デバイスの構成 (作業マップ)

次の作業マップは、デバイスへのアクセスを管理する作業を示しています。

作業	参照先
デバイスポリシーを管理します	「デバイスポリシーの設定 (作業マップ)」
デバイス割り当てを管理します	「デバイス割り当ての管理 (作業マップ)」
デバイス割り当てを実行します	「デバイスの割り当て (作業マップ)」

デバイスポリシーの設定 (作業マップ)

次の作業マップは、デバイスポリシーに関連するデバイス構成作業の参照先を示しています。

作業	説明	参照先
システム上のデバイスのデバイスポリシーを確認します	デバイスとそれらのデバイスポリシーの一覧を表示します。	「デバイスポリシーを表示する方法」
デバイス使用に対して特権を要求します	特権を使用してデバイスを保護します。	「既存のデバイスのデバイスポリシーを変更する方法」
デバイスから特権要件を削除します	デバイスのアクセスに必要な特権を削除するか、そのレベルを下げます。	例 4–3
デバイスポリシーの変更を監査します	監査トレールでデバイスポリシーの変更を記録します	「デバイスポリシーの変更を監査する方法」
`/dev/arp` にアクセスします	Solaris IP MIB-II 情報を取得します。	「`/dev/*` デバイスから IP MIB-II 情報を取得する方法」

デバイスポリシーの設定

デバイスポリシーは、システムに不可欠なデバイスに対するアクセスの制限または防止を行うものです。このポリシーはカーネルで適用されます。

デバイスポリシーを表示する方法

システム上のすべてのデバイスのデバイスポリシーを表示します。

% getdevpolicy | more
DEFAULT
        read_priv_set=none
        write_priv_set=none
ip:*
        read_priv_set=net_rawaccess
        write_priv_set=net_rawaccess
…

例 4–1 特定のデバイスのデバイスポリシーを表示する

この例では、3 つのデバイスのデバイスポリシーが表示されています。

% getdevpolicy /dev/allkmem /dev/ipsecesp /dev/hme
/dev/allkmem
        read_priv_set=all
        write_priv_set=all
/dev/ipsecesp
        read_priv_set=sys_net_config
        write_priv_set=sys_net_config
/dev/hme
        read_priv_set=net_rawaccess
        write_priv_set=net_rawaccess

既存のデバイスのデバイスポリシーを変更する方法

Device Security 権利プロファイルを含む役割を引き受けるか、あるいはスーパーユーザーになります。

Primary Administrator 役割には、Device Security 権利プロファイルが含まれます。また、作成する役割に Device Security 権利プロファイルを割り当てることもできます。役割を作成してその役割をユーザーに割り当てる方法については、例 9–3 を参照してください。

デバイスにポリシーを追加します。
# update_drv -a -p policy device-driver
-a

device-driver 用の policy を指定します。

-p policy

device-driver のデバイスポリシーです。デバイスポリシーは、2 セットの特権を指定します。1 つは、デバイスの読み取りに必要です。もう 1 つは、デバイスへの書き込みに必要です。

device-driver

デバイスドライバです。

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

例 4–2 既存のデバイスにポリシーを追加する

次の例では、デバイス ipnat にデバイスポリシーが追加されています。

# getdevpolicy /dev/ipnat
/dev/ipnat
        read_priv_set=none
        write_priv_set=none
# update_drv -a \
-p 'read_priv_set=net_rawaccess write_priv_set=net_rawaccess' ipnat
# getdevpolicy /dev/ipnat
/dev/ipnat
        read_priv_set=net_rawaccess
        write_priv_set=net_rawaccess

例 4–3 デバイスからポリシーを削除する

次の例では、デバイス ipnat のデバイスポリシーから読み取り特権セットが削除されます。

# getdevpolicy /dev/ipnat
/dev/ipnat
        read_priv_set=net_rawaccess
        write_priv_set=net_rawaccess
# update_drv -a -p write_priv_set=net_rawaccess ipnat
# getdevpolicy /dev/ipnat
/dev/ipnat
        read_priv_set=none
        write_priv_set=net_rawaccess

デバイスポリシーの変更を監査する方法

デフォルトでは、as 監査クラスに、AUE_MODDEVPLCY 監査イベントが含まれます。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

AUE_MODDEVPLCY 監査イベントを含む監査クラスをあらかじめ選択します。

audit_control ファイルの flags 行に as クラスを追加してください。このファイルは次のようになります。
# audit_control file dir:/var/audit flags:lo,as minfree:20 naflags:lo
詳しい操作説明は、「audit_control ファイルの変更方法」を参照してください。

`/dev/*` デバイスから IP MIB-II 情報を取得する方法

Solaris IP MIB-II 情報を取得するアプリケーションは、/dev/ip ではなく /dev/arp を開く必要があります。

/dev/ip および /dev/arp のデバイスポリシーを決定します。
% getdevpolicy /dev/ip /dev/arp /dev/ip read_priv_set=net_rawaccess write_priv_set=net_rawaccess /dev/arp read_priv_set=none write_priv_set=none
/dev/ip の読み取りおよび書き込みには、net_rawaccess 特権が必要であることに注意してください。/dev/arp は特権を必要としません。

/dev/arp を開き、tcp モジュールと udp モジュールをプッシュします。

特権は不要です。この方法は、/dev/ip を開いて arp、tcp、および udp モジュールをプッシュするのと同じです。現在、/dev/ip を開くには特権が必要なため、/dev/arp メソッドを推奨します。

デバイス割り当ての管理 (作業マップ)

次の作業マップは、デバイス割り当ての有効化と設定について説明した箇所を示しています。デフォルトではデバイス割り当ては有効になっていません。デバイス割り当てを有効にしたあとで、「デバイスの割り当て (作業マップ)」を参照してください。

作業	説明	参照先
デバイスを割り当て可能にします	デバイスを一度に 1 人のユーザーに割り当てられるようにします。	「デバイスを割り当て可能にする方法」
ユーザーによるデバイス割り当てを承認します	デバイス割り当ての承認をユーザーに与えます。	「ユーザーによるデバイス割り当てを承認する方法」
システム上の割り当て可能なデバイスを表示します	割り当てが可能なデバイスと、そのデバイスの状態を一覧表示します。	「デバイスの割り当て情報を表示する方法」
デバイスを強制的に割り当てます	ただちにデバイスを使う必要があるユーザーにデバイスを割り当てます	「デバイスの強制的な割り当て」
デバイスの割り当てを強制的に解除します	現在ユーザーに割り当てられているデバイスの割り当てを解除します	「デバイスの強制的な割り当て解除」
デバイスの割り当てプロパティーを変更します	デバイス割り当ての要件を変更します	「割り当て可能デバイスの変更方法」
デバイスクリーンスクリプトを作成します	物理デバイスからデータを一掃します。	「新しいデバイスクリーンスクリプトの作成」
デバイス割り当てを無効にします	すべてのデバイスの割り当て制限を解除します。	「監査サービスを無効にする方法」
デバイス割り当ての監査を行います	デバイス割り当てを監査トレールに記録します	「デバイス割り当てを監査する方法」

デバイス割り当ての管理

デバイス割り当ては、周辺機器に対するアクセスの制限または防止を行う作業です。制限は、ユーザーの割り当て時に適用されます。デフォルトでは、割り当て可能デバイスにアクセスする場合、ユーザーは承認を必要とします。

デバイスを割り当て可能にする方法

すでに bsmconv コマンドを実行して監査を有効にしている場合、システムではすでにデバイス割り当てが有効になっています。詳細は、bsmconv(1M) のマニュアルページを参照してください。

Audit Control 権利プロファイルを含む役割を引き受けるか、あるいはスーパーユーザーになります。

Primary Administrator 役割には、Audit Control 権利プロファイルが含まれます。また、作成する役割に Audit Control 権利プロファイルを割り当てることもできます。役割を作成してその役割をユーザーに割り当てる方法については、例 9–3 を参照してください。

デバイス割り当てを有効にします。

# bsmconv
This script is used to enable the Basic Security Module (BSM).
Shall we continue with the conversion now? [y/n] y
bsmconv: INFO: checking startup file.
bsmconv: INFO: move aside /etc/rc3.d/S81volmgt.
bsmconv: INFO: turning on audit module.
bsmconv: INFO: initializing device allocation files.

The Basic Security Module is ready.
If there were any errors, please fix them now.
Configure BSM by editing files located in /etc/security.
Reboot this system now to come up with BSM enabled.

注 –

Volume Management デーモン (/etc/rc3.d/S81volmgt) は、このコマンドによって無効になります。

ユーザーによるデバイス割り当てを承認する方法

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

適切な承認とコマンドが入った権利プロファイルを作成します。

一般には、solaris.device.allocate 承認を含む権利プロファイルを作成します。「権利プロファイルを作成または変更する方法」に挙げられている説明に従って操作してください。権利プロファイルに、次に示すような適切なプロパティーを指定します。
- 権利プロファイル名: Device Allocation
- 付与される承認: solaris.device.allocate
- セキュリティー属性を指定したコマンド: sys_mount 特権を指定した mount、sys_mount 特権を指定した umount

権利プロファイルの役割を作成します。

「GUI を使用して役割の作成および割り当てを行う方法」に挙げられている説明に従って操作してください。次に示す役割プロパティーを参考にしてください。
- 役割名: devicealloc
- 役割の完全名: Device Allocator
- 役割の説明: Allocates and mounts allocated devices
- 権利プロファイル: Device Allocation
  
  この権利プロファイルは、役割に含めるプロファイルのリストの先頭に配置する必要があります。

デバイス割り当てを許可する各ユーザーに、この役割を割り当てます。

これらのユーザーにデバイス割り当ての方法を教えます。

リムーバブルメディアの割り当て例は、「デバイスを割り当てる方法」を参照してください。

Volume Management デーモン (vold) が稼働していないため、リムーバブルメディアは自動的にはマウントされません。割り当て済みのデバイスをマウントする例については、「割り当て済みデバイスをマウントする方法」を参照してください。

デバイスの割り当て情報を表示する方法

始める前に

この作業を行うには、デバイス割り当てが有効になっていなければなりません。デバイス割り当てを有効にする方法については、「デバイスを割り当て可能にする方法」を参照してください。

Device Security 権利プロファイルを含む役割を引き受けるか、あるいはスーパーユーザーになります。

Primary Administrator 役割には、Device Security 権利プロファイルが含まれます。また、作成する役割に Device Security 権利プロファイルを割り当てることもできます。役割を作成してその役割をユーザーに割り当てる方法については、例 9–3 を参照してください。

システム上の割り当て可能デバイスについての情報を表示します。
# list_devices device-name
device-name は次のいずれかです。
- audio[n] – マイクとスピーカーです。
- fd[n] – フロッピーディスクドライブです。
- sr[n] – CD-ROM ドライブです。
- st[n] – テープドライブです。

注意事項

list_devices コマンドが次のようなエラーメッセージを返す場合は、デバイス割り当てが有効になっていないか、情報を取得するために必要なアクセス権がありません。

list_devices: No device maps file entry for specified device.

コマンドを実行するには、デバイス割り当てを有効にし、solaris.device.revoke 承認のある役割を引き受けてください。

デバイスの強制的な割り当て

強制的な割り当ては、誰かがデバイスの割り当て解除を忘れた場合や、デバイスをただちに使用する必要がある場合などに行います。

始める前に

この処理を行うには、ユーザーまたは役割に solaris.device.revoke 承認がなければなりません。

自分の役割に適切な承認が含まれているか確認します。
$ auths solaris.device.allocate solaris.device.revoke

デバイスを必要としているユーザーにデバイスを強制的に割り当てます。

この例では、テープドライブがユーザー jdoe に強制的に割り当てられます。
$ allocate -U jdoe

デバイスの強制的な割り当て解除

ユーザーが割り当てたデバイスは、プロセスの終了時やそのユーザーのログアウトの際に自動的に割り当てが解除されることはありません。強制的な割り当て解除は、ユーザーがデバイスの割り当てを解除することを忘れた場合に行います。

始める前に

この処理を行うには、ユーザーまたは役割に solaris.device.revoke 承認がなければなりません。

自分の役割に適切な承認が含まれているか確認します。
$ auths solaris.device.allocate solaris.device.revoke

デバイスの割り当てを強制的に解除します。

この例では、プリンタの割り当てが強制的に解除されます。現在、このプリンタはほかのユーザーが割り当てを行える状態にあります。
$ deallocate -f /dev/lp/printer-1

割り当て可能デバイスの変更方法

Device Security 権利プロファイルを含む役割を引き受けるか、あるいはスーパーユーザーになります。

Primary Administrator 役割には、Device Security 権利プロファイルが含まれます。また、作成する役割に Device Security 権利プロファイルを割り当てることもできます。役割を作成してその役割をユーザーに割り当てる方法については、例 9–3 を参照してください。

承認が必要であるかどうかを指定するか、あるいは solaris.device.allocate 承認を指定します。

device_allocate ファイルのデバイスエントリにある 5 つ目のフィールドを変更します。

audio;audio;reserved;reserved;solaris.device.allocate;/etc/security/lib/audio_clean
fd0;fd;reserved;reserved;solaris.device.allocate;/etc/security/lib/fd_clean
sr0;sr;reserved;reserved;solaris.device.allocate;/etc/security/lib/sr_clean

solaris.device.allocate は、デバイスの使用に solaris.device.allocate 承認が必要であることを示します。

例 4–4 任意のユーザーによるデバイス割り当てを許可する

次の例では、システム上のどのユーザーも任意のデバイスを割り当てることができます。device_allocate ファイルの各デバイスエントリ内にある 5 番目のフィールドは、単価記号 (@) に変更されました。

$ whoami
devicesec
$ vi /etc/security/device_allocate
audio;audio;reserved;reserved;@;/etc/security/lib/audio_clean
fd0;fd;reserved;reserved;@;/etc/security/lib/fd_clean
sr0;sr;reserved;reserved;@;/etc/security/lib/sr_clean
…

例 4–5 一部の周辺機器の使用を防止する

次の例では、オーディオデバイスの使用が禁止されています。device_allocate ファイルのオーディオデバイスエントリにある 5 番目のフィールドは、アスタリスク (*) に変更されました。

$ whoami
devicesec
$ vi /etc/security/device_allocate
audio;audio;reserved;reserved;*;/etc/security/lib/audio_clean
fd0;fd;reserved;reserved;solaris device.allocate;/etc/security/lib/fd_clean
sr0;sr;reserved;reserved;solaris device.allocate;/etc/security/lib/sr_clean
…

例 4–6 すべての周辺機器の使用を防止する

次の例では、使用できる周辺機器はありません。device_allocate ファイルの各デバイスエントリにある 5 番目のフィールドは、アスタリスク (*) に変更されました。

$ whoami
devicesec
$ vi /etc/security/device_allocate
audio;audio;reserved;reserved;*;/etc/security/lib/audio_clean
fd0;fd;reserved;reserved;*;/etc/security/lib/fd_clean
sr0;sr;reserved;reserved;*;/etc/security/lib/sr_clean
…

デバイス割り当てを監査する方法

デフォルトでは、デバイス割り当てコマンドは、監査クラス other の状態です。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

監査の対象となるように、ot クラスをあらかじめ選択します。

audit_control ファイルの flags 行にクラス ot を追加してください。このファイルは次のようになります。
# audit_control file dir:/var/audit flags:lo,ot minfree:20 naflags:lo
詳しい操作説明は、「audit_control ファイルの変更方法」を参照してください。

デバイスの割り当て (作業マップ)

次の作業マップは、デバイスの割り当て方法を説明した手順を示しています。

作業	説明	参照先
デバイスを割り当てます	デバイスの使用を 1 人のユーザーだけに限定し、ほかのユーザーがそのデバイスを使用できないようにします。	「デバイスを割り当てる方法」
割り当てられたデバイスをマウントします	マウントが必要なデバイス (CD-ROM やフロッピーディスクなど) をユーザーが確認できるようにします。	「割り当て済みデバイスをマウントする方法」
デバイスの割り当てを解除します	割り当て可能なデバイスをほかのユーザーが使用できるようにします。	「デバイスの割り当てを解除する方法」

デバイスの割り当て

デバイス割り当ては、一度に 1 人のユーザーだけが使用できるようにデバイスを予約 (確保) する作業です。マウントポイントが必要なデバイスはマウントする必要があります。

デバイスを割り当てる方法

始める前に

デバイス割り当ての有効化は、「デバイスを割り当て可能にする方法」に説明されている方法で行う必要があります。承認が必要な場合は、そのユーザーは承認を得ていなければなりません。

デバイスを割り当てます。

デバイス名でデバイスを指定します。
% allocate device-name

デバイスが割り当てられたことを検証します。

同じコマンドをもう一度実行します。
% allocate device-name allocate. Device already allocated.

例 4–7 マイクを割り当てる

この例では、ユーザー jdoe がマイク audio を割り当てます。

% whoami
jdoe
% allocate audio

例 4–8 プリンタを割り当てる

この例では、ユーザーがプリンタを割り当てます。このユーザーが printer-1 の割り当てを解除するか、このプリンタが強制的にほかのユーザーに割り当てられるまで、ほかのユーザーはこのプリンタを使用できません。

% allocate /dev/lp/printer-1

強制的な割り当て解除の例は、「デバイスの強制的な割り当て解除」を参照してください。

例 4–9 テープドライブを割り当てる

この例では、ユーザー jdoe がテープドライブ st0 を割り当てます。

% whoami
jdoe
% allocate st0

注意事項

allocate コマンドがデバイスを割り当てることができない場合は、コンソールウィンドウにエラーメッセージが表示されます。割り当てのエラーメッセージについては、allocate(1) のマニュアルページを参照してください。

割り当て済みデバイスをマウントする方法

始める前に

ユーザーまたは役割によってすでにデバイスが割り当てられています。デバイスをマウントするには、そのデバイスのマウントに必要な特権をそのユーザーまたは役割が保持していなければなりません。必要な特権を与える方法については、「ユーザーによるデバイス割り当てを承認する方法」を参照してください。

デバイスの割り当てまたはマウントが行える役割を引き受けます。
% su - role-name Password: <Type role-name password> $

この役割のホームディレクトリにマウントポイントを作成し、このマウントポイントを保護します。

このステップが必要なのは、マウントポイントが初めて必要になった時だけです。
$ mkdir mount-point ; chmod 700 mount-point

割り当てが可能なデバイスを一覧表示します。
$ list_devices -l List of allocatable devices

デバイスを割り当てます。

デバイス名でデバイスを指定します。
$ allocate device-name

デバイスをマウントします。
$ mount -o ro -F filesystem-type device-path mount-point
次に、各引数について説明します。

-o ro

デバイスは読み取り専用としてマウントされることを示します。デバイスに書き込みができるように指定するには、-o rw を使用します。

-F filesystem-type

デバイスのファイルシステムフォーマットを示します。一般に、CD-ROM は HSFS ファイルシステムでフォーマットされています。フロッピーディスクは、一般に PCFS ファイルシステムでフォーマットされています。

device-path

デバイスへのパスを示します。list_devices -l コマンドの出力には、device-path が含まれます。

mount-point

手順 2 で作成したマウントポイントを示します。

例 4–10 フロッピーディスクドライブの割り当て

この例では、ユーザーはフロッピーディスクドライブ fd0 の割り当てとマウントが行える役割を引き受けます。このフロッピーディスクは、PCFS ファイルシステムでフォーマットされています。

% roles
devicealloc
% su - devicealloc
Password: <Type devicealloc password>
$ mkdir /home/devicealloc/mymnt
$ chmod 700 /home/devicealloc/mymnt
$ list_devices -l
...
device: fd0 type: fd files: /dev/diskette /dev/rdiskette /dev/fd0a
...
$ allocate fd0
$ mount -o ro -F pcfs /dev/diskette /home/devicealloc/mymnt
$ ls /home/devicealloc/mymnt
List of the contents of diskette

例 4–11 CD-ROM ドライブを割り当てる

この例では、ユーザーは CD-ROM ドライブ sr0 の割り当てとマウントが行える役割を引き受けます。このドライブは、HSFS ファイルシステムでフォーマットされています。

% roles
devicealloc
% su - devicealloc
Password: <Type devicealloc password>
$ mkdir /home/devicealloc/mymnt
$ chmod 700 /home/devicealloc/mymnt
$ list_devices -l
...
device: sr0 type: sr files: /dev/sr0 /dev/rsr0 /dev/dsk/c0t2d0s0 ...
...
$ allocate sr0
$ mount -o ro -F hsfs /dev/sr0 /home/devicealloc/mymnt
$ cd /home/devicealloc/mymnt ; ls
List of the contents of CD-ROM

注意事項

mount コマンドがデバイスをマウントできない場合は、「mount: insufficient privileges」というエラーメッセージが表示されます。次の点を確認します。

mount コマンドをプロファイルシェルで実行していることを確認します。役割を引き受けた場合は、その役割にプロファイルシェルがあります。mount コマンドでプロファイルを割り当てられたユーザーの場合、プロファイルシェルを作成する必要があります。プロファイルシェルの作成には、コマンド pfsh、pfksh、および pfcsh を使用します。
指定されたマウントポイントを所有しているかを確認します。このマウントポイントに対して読み取り、書き込み、および実行のアクセス権がなければなりません。

以上の要件を満たしているにもかかわらず割り当て済みデバイスをマウントできないという場合は、管理者に問い合わせてください。

デバイスの割り当てを解除する方法

割り当てを解除すると、ほかのユーザーもユーザーの使用後にそのデバイスを割り当てて使用できるようになります。

始める前に

デバイスをすでに割り当てていなければなりません。

デバイスがマウントされている場合は、デバイスのマウントを解除します。
$ cd $HOME $ umount mount-point

デバイスの割り当てを解除します。
$ deallocate device-name

例 4–12 マイクの割り当てを解除する

この例では、ユーザー jdoe がマイク audio の割り当てを解除します。

% whoami
jdoe
% deallocate audio

例 4–13 CD-ROM ドライブの割り当てを解除する

この例では、Device Allocator 役割が、CD-ROM ドライブの割り当てを解除します。次のメッセージが表示されたあとで、CD-ROM が取り出されます。

$ whoami
devicealloc
$ cd /home/devicealloc
$ umount /home/devicealloc/mymnt
$ ls /home/devicealloc/mymnt
$ 
$ deallocate sr0
/dev/sr0:      326o
/dev/rsr0:     326o
…
sr_clean: Media in sr0 is ready.  Please, label and store safely.

デバイスの保護 (参照)

Solaris OS では、デバイスはデバイスポリシーによって保護されます。周辺機器は、デバイス割り当てによって保護できます。デバイスポリシーはカーネルによって適用されます。デバイス割り当ては、ユーザーレベルで任意に有効化と適用が行われます。

デバイスポリシーコマンド

デバイス管理コマンドは、ローカルファイルのデバイスポリシーを管理するコマンドです。デバイスポリシーは特権要件を含むことができます。デバイスを管理できるのは、スーパーユーザーと、スーパーユーザーと同等の能力を持つ役割だけです。

次の表は、デバイス管理コマンドを示しています。

表 4–1 デバイス管理コマンド


コマンド	目的	マニュアルページ
`devfsadm`	稼働しているシステム上のデバイスとデバイスドライバを管理します。また、デバイスポリシーの読み込みも行います。 `devfsadm` コマンドは、ディスクデバイス、テープデバイス、ポートデバイス、オーディオデバイス、および擬似デバイスに対する `/dev` リンクのクリーンアップにも使用できます。名前付きドライバのデバイスの再構成も行えます。	devfsadm(1M)
`getdevpolicy`	1 つ以上のデバイスに関連付けられたポリシーを表示します。このコマンドはどのユーザーでも実行できます。	getdevpolicy(1M)
`add_drv`	稼働中のシステムに新しいデバイスドライバを追加します。新しいデバイスにデバイスポリシーを追加するオプションを含みます。一般に、このコマンドはデバイスドライバのインストール中にスクリプト内で呼び出されます。	add_drv(1M)
`update_drv`	既存のデバイスドライバの属性を更新します。デバイスのデバイスポリシーを更新するオプションを含みます。一般に、このコマンドはデバイスドライバのインストール中にスクリプト内で呼び出されます。	update_drv(1M)
`rem_drv`	デバイスまたはデバイスドライバを削除します。	rem_drv(1M)

デバイスの割り当て

デバイス割り当てによって、データの消失、コンピュータウイルス、セキュリティー侵害などからサイトを保護できます。デバイスポリシーと違い、デバイス割り当ては任意です。デバイスは、bsmconv スクリプトが実行されるまで割り当てることはできません。デバイス割り当ては、割り当て可能デバイスへのアクセスを制限するのに承認を使用します。

デバイス割り当ての構成要素

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

allocate、deallocate、dminfo、list_devices コマンド。詳細は、「デバイス割り当てコマンド」を参照してください。
各割り当て可能デバイスのデバイスクリーンスクリプト。

これらのコマンドとスクリプトは、次のローカルファイルを使用してデバイス割り当てを実装します。

/etc/security/device_allocate ファイル。詳細は、device_allocate(4) のマニュアルページを参照してください。
/etc/security/device_maps ファイル。詳細は、device_maps(4) のマニュアルページを参照してください。
ロックファイル。割り当て可能デバイスごとに /etc/security/dev ディレクトリに配置します。
各割り当て可能デバイスに関連付けられたロックファイルの変更後の属性。

注 –

/etc/security/dev ディレクトリは、将来の Solaris OS リリースでサポートされなくなる可能性があります。

デバイス割り当てコマンド

大文字のオプションが指定された allocate、deallocate、および list_devices コマンドは管理用コマンドです。それ以外ではこれらのコマンドはユーザーコマンドです。次の表は、デバイス割り当てコマンドを示しています。

表 4–2 デバイス割り当てコマンド


コマンド	目的	マニュアルページ
`bsmconv`	デバイス割り当てを処理するデータベースを作成します。監査サービスの有効化も行います。スーパーユーザーであるか、Primary Administrator 役割を引き受ける必要があります。	bsmconv(1M)
`dminfo`	デバイスタイプ、デバイス名、またはフルパス名を指定して、割り当て可能デバイスを検索します。	dminfo(1M)
`list_devices`	割り当て可能なデバイスの状態を表示します。 `device_maps` ファイルにリストされたデバイスに関連付けられている、デバイス特殊ファイルを列挙します。	list_devices(1)
`list_devices -U`	割り当て可能なデバイスを一覧表示するか、あるいは特定のユーザー ID に割り当てられているデバイスを一覧表示します。このオプションを使用すると、別のユーザーに割り当てることができるデバイスまたは割り当て済みのデバイスを確認できます。このコマンドを実行するには、ユーザーまたは役割に `solaris.device.revoke` 承認がなければなりません。
`allocate`	1 人のユーザーだけが使用できるように割り当て可能デバイスを予約します。デフォルトでは、ユーザーはデバイス割り当てを行うのに `solaris.device.allocate` 承認が必要です。ユーザー承認を必要としないように、`device_allocate` ファイルを変更することもできます。そのように変更した場合、システム上のどのユーザーでもデバイスの使用割り当てを要求できます。	allocate(1)
`deallocate`	デバイスから割り当て予約を削除します。	deallocate(1)

割り当てコマンドの承認

デフォルトでは、ユーザーが割り当て可能デバイスを予約するには solaris.device.allocate 承認を必要とします。solaris.device.allocate 承認を含める権利プロファイルを作成する方法については、「ユーザーによるデバイス割り当てを承認する方法」を参照してください。

管理者がデバイスの割り当て状態を変更するには、どのデバイスの場合でも、solaris.device.revoke 承認が必要です。たとえば、allocate および list_devices コマンドの -U オプションや、deallocate コマンドの -F オプションは、solaris.device.revoke 承認が必要です。

詳細は、「承認を必要とするコマンド」を参照してください。

割り当てエラー状態

deallocate コマンドが割り当ての解除に失敗する場合、または allocate コマンドが割り当てに失敗する場合は、デバイスは「割り当てエラー状態」になります。割り当て可能デバイスが割り当てエラー状態となった場合、そのデバイスの割り当てを強制的に解除する必要があります。割り当てエラー状態を処理できるのは、スーパーユーザーか、あるいは Device Management 権利プロファイルまたは Device Security 権利プロファイルを持った役割だけです。

F オプションを指定した -deallocate コマンドは、割り当て解除を強制します。あるいは、allocate -U を実行してデバイスを特定のユーザーに割り当てることもできます。いったんデバイスが割り当てられると、発生したエラーメッセージを調査できます。デバイスに関する問題が解決されたあとで、そのデバイスの割り当てを強制的に解除できます。

`device_maps` ファイル

デバイス割り当てを設定すると、デバイスマップが作成されます。監査サービスが有効になる際には、bsmconv コマンドによってデフォルトの /etc/security/device_maps ファイルが作成されます。この当初の device_maps ファイルは、サイトに合わせてカスタマイズできます。device_maps ファイルには、デバイス名、デバイスの種類のほか、各割り当て可能デバイスに関連付けられたデバイス特殊ファイルが記録されます。

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

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

device-name:device-type:device-list

例 4–14 `device_maps` エントリの例

次に、フロッピーディスクドライブ fd0 の device_maps ファイル内にあるエントリの例を示します。

fd0:\
        fd:\
        /dev/diskette /dev/rdiskette /dev/fd0a /dev/rfd0a \
/dev/fd0b /dev/rfd0b /dev/fd0c /dev/fd0 /dev/rfd0c /dev/rfd0:\

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

device-name: デバイスの名前を指定します。現在のデバイス名の一覧を表示する方法については、「デバイスの割り当て情報を表示する方法」を参照してください。
device-type: 汎用デバイスタイプを指定します。汎用名は、st、fd、audio などのデバイスクラス名です。device-type では、関連するデバイスが論理的にグループ化されます。
device-list: 物理デバイスに関連付けられたデバイス特殊ファイルを一覧表示します。device-list には、特定のデバイスにアクセスできるすべての特殊ファイルが含まれている必要があります。リストが不完全な場合は、悪意を持ったユーザーでも個人情報を入手または変更できます。device-list フィールドには、/dev ディレクトリに入っているデバイスファイルを指定します。

`device_allocate` ファイル

当初の /etc/security/device_allocate ファイルは、監査サービスを有効にする際に bsmconv コマンドによって作成されます。この当初の 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

device_allocate ファイル内のエントリは、デバイスが割り当て可能であると特に記述されていない限り、そのデバイスが割り当て可能であることを意味しません。上述の device_allocate ファイルの例では、オーディオデバイスエントリの第 5 フィールドにアスタリスク (*) が指定されています。第 5 フィールド内のアスタリスクは、そのデバイスが割り当て可能でないことをシステムに示します。つまり、このデバイスは使用できません。このフィールドにほかの値が入っているか、あるいは値が入っていない場合は、デバイスが使用可能であることを示します。

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

device-name;device-type;reserved;reserved;auths;device-exec

device_allocate ファイル内の行は、バックスラッシュ (\) で終了することで次の行のエントリに継続できます。コメントも挿入できます。ポンド記号 (#) を付けると、1 つ前の行末にバックスラッシュのない改行まで、それに続くすべてのテキストはコメントになります。どのフィールドでも先行ブランクと後続ブランクを使用できます。フィールドの定義は次のとおりです。

device-name: デバイスの名前を指定します。現在のデバイス名の一覧を表示する方法については、「デバイスの割り当て情報を表示する方法」を参照してください。
device-type: 汎用デバイスタイプを指定します。汎用名は、st、fd、sr などのデバイスクラス名です。device-type では、関連するデバイスが論理的にグループ化されます。デバイスを割り当て可能にするときは、device_maps ファイルの device-type フィールドからデバイス名を取得します。
reserved: reserved で示される 2 つのフィールドは、将来の使用に予約されています。
auths: デバイスが割り当て可能かどうかを示します。このフィールドにアスタリスク (*) が入っている場合は、デバイスが割り当て不可能であることを示します。承認を示す文字列が入っている場合や、空の場合は、デバイスが割り当て可能であることを示します。たとえば、auths フィールドの文字列 solaris.device.allocate は、そのデバイスを割り当てるには solaris.device.allocate 承認が必要であることを示します。このフィールドに単価記号 (@) が入っている場合は、どのユーザーでもそのデバイスを割り当てることができることを示します。
device-exec: 割り当てプロセス中にクリーンアップやオブジェクト再使用防止などの特殊処理のために呼び出されるスクリプトのパス名を指定します。device-exec スクリプトは、デバイスに対して deallocate コマンドを実行するたびに実行されます。

たとえば、sr0 デバイスについての次のエントリは、CD-ROM ドライブが solaris.device.allocate 承認を得たユーザーによって割り当て可能であることを示します。

sr0;sr;reserved;reserved;solaris.device.allocate;/etc/security/lib/sr_clean

デフォルトのデバイスと、その定義済み特性をそのまま使用することもできます。新しいデバイスをインストールしたあとで、エントリを変更できます。使用前に割り当てが必要なデバイスはすべて、そのデバイスのシステムの device_allocate ファイルと device_maps ファイルで定義する必要があります。現在、カートリッジテープドライブ、フロッピーディスクドライブ、CD-ROM ドライブ、およびオーディオチップが、割り当て可能とみなされます。これらのデバイスタイプには、デバイスクリーンスクリプトが用意されています。

注 –

Xylogics テープドライブやアーカイブテープドライブも、SCSI デバイス用の st_clean スクリプトを使用します。モデム、端末、グラフィックスタブレットなどの割り当て可能デバイスについては、独自のデバイスクリーンスクリプトを作成する必要があります。このスクリプトは、対応するデバイスタイプのオブジェクト再使用の要件を満たしている必要があります。

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

デバイス割り当てによって、いわゆるオブジェクト再使用要件の一部が満たされます。「デバイスクリーン」スクリプトは、使用可能なすべてのデータを再使用する前に物理デバイスからパージするというセキュリティー要件に対応するものです。データのクリアは、そのデバイスが別のユーザーによって割り当て可能になる前に実行されます。デフォルトでは、カートリッジテープドライブ、フロッピーディスクドライブ、CD-ROM ドライブ、オーディオデバイスは、デバイスクリーンスクリプトが必要です。このスクリプトは Solaris OS に付属しています。この節では、デバイスクリーンスクリプトが実行する処理について説明します。

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

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

SCSI ¼ インチテープ
アーカイブ ¼ インチテープ
オープンリール ½ インチテープ

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

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

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

フロッピーディスクドライブと CD-ROM ドライブ用として、次のデバイスクリーンスクリプトが提供されています。

fd_clean スクリプト – フロッピーディスクドライブ用デバイスクリーンスクリプト。
sr_clean スクリプト – CD-ROM ドライブ用デバイスクリーンスクリプト。

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

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

オーディオデバイスは、audio_clean スクリプトを使用してクリーンアップします。スクリプトは、AUDIO_GETINFO ioctl システムコールを実行してデバイスを読み取ります。AUDIO_SETINFO ioctl システムコールを実行してデバイス構成をデフォルトにリセットします。

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

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

clean-script -[I|i|f|S] device-name

デバイスクリーンスクリプトは、成功時には「0」を、失敗時には「0」より大きな値を、それぞれ返す必要があります。オプション -I、-f、および -S は、スクリプトの実行モードを決定します。

-I: システムをブートするときにだけ指定します。すべての出力は、システムコンソールに送られます。失敗した場合や、メディアを強制的に取り出せない場合は、デバイスを割り当てエラー状態にします。
-i: 出力が抑止される点を除き、-I オプションと同じです。
-f: 強制的なクリーンアップを行うときに指定します。このオプションは対話型であり、ユーザーがプロンプトに応答するものとみなします。このオプションが付いたスクリプトは、クリーンアップの一部に失敗した場合に、クリーンアップ全体を完了しようとします。
-S: 標準クリーンアップを行うときに指定します。このオプションは対話型であり、ユーザーがプロンプトに応答するものとみなします。

第 5 章基本監査報告機能の使用方法 (作業)

この章では、システム上のファイルの目録を作成する方法と、それらの目録を使用してシステムの整合性をチェックする方法について説明します。基本監査報告機能 (BART) を使用すると、一定期間にわたってシステムのファイルレベルチェックを行い、システムを包括的に検証できます。

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

基本監査報告機能 (概要)

BART は、完全にファイルシステムレベルで稼働するファイル追跡ツールです。BART を使用すると、配備済みのシステムにインストールされているソフトウェアスタックのコンポーネントについての情報をすばやく簡単に、かつ確実に収集できます。このツールには、時間のかかる管理作業を簡易化し、システムネットワークの管理に伴う負担を大幅に減らす効果があります。

BART を使用することで管理者は、既知のベースラインと比較し、ファイルレベルで見てどのような変化がシステムに起きたかを確認できます。BART はベースラインの作成に使用できるほか、インストールと構成がすべて完了しているシステムの目録を制御するためにも使用できます。作成したこのベースラインをあとでシステムのスナップショットと比較すれば、システムのインストール以後にシステムで発生したファイルレベルの変化を示すレポートが生成されます。

bart コマンドは、標準の UNIX コマンドです。bart コマンドの出力は、あとで処理できるようにファイルにリダイレクトできます。

BART の機能

BART は、強力で柔軟、かつシンプルな構文に重点を置いて設計されています。このツールは、異なる時点で特定のシステムの目録を生成するのに利用できます。システムファイルの検証が必要になった場合には、新旧の目録を比較してレポートを生成できます。また、複数の類似したシステムの目録を生成し、システム同士の比較も行えます。BART と既存の監査ツールの違いは、追跡の対象となる情報と、レポートされる情報の両方に関して BART は柔軟であることです。

BART には、ほかにも次のようなメリットや利用法があります。

ファイルレベルで Solaris ソフトウェアを実行しているシステムを効率良く簡単にカタログ化できます。
どのファイルを監視するかを決定でき、必要に応じてプロファイルの変更も可能です。この柔軟性のおかげでローカルなカスタマイズを監視でき、ソフトウェアの再構成も簡単に効率良く行えます。
信頼できるソフトウェアだけをシステムで稼働させることができます。
一定期間におけるシステムのファイルレベルの変化を監視できます (ファイルレベルの監視を行うと、破損ファイルや異常なファイルを見つけやすくなる)。
システムパフォーマンスの問題の解決に役立ちます。

BART コンポーネント

BART には、主要コンポーネントが 2 つ、オプションコンポーネントが 1 つ存在します。これらを次に示します。

BART 目録
BART レポート
BART 規則ファイル

BART 目録

bart create コマンドを使用して、特定の時点におけるシステムのファイルレベルスナップショットを作成できます。このコマンドでは、ファイルのカタログと、「目録」と呼ばれるファイル属性が出力されます。目録には、システム上のすべてのファイルまたは特定のファイルについての情報が示されます。これはファイルの属性についての情報が入ったものであり、MD5 チェックサムなどの一意の識別情報も含めることができます。MD5 チェックサムについての詳細は、md5(3EXT) のマニュアルページを参照してください。目録は、保存して、クライアントシステムとサーバーシステムの間で転送できます。

注 –

ファイルシステムのタイプが同じである場合を除き、BART がファイルシステムの境界を越えることはありません。この制約があるため、bart create コマンドの出力を予測しやすくなります。たとえば、引数を指定せずに bart create コマンドを実行すると、ルート (/) ディレクトリの下のすべてのファイルシステムがカタログ化されます。しかし、NFS ファイルシステム、TMPFS ファイルシステム、マウントされた CD-ROM はカタログ化されません。目録を作成するときは、ネットワーク上のファイルシステムは監査の対象としないでください。ネットワーク化されたファイルシステムを BART で監視すると、リソースを大量に消費し、ほとんど価値のない目録が生成されます。

BART 目録の詳細は、「BART 目録のファイル形式」を参照してください。

BART レポート

このレポートツールの入力情報は 3 つあります。比較される目録 2 つと、ユーザーによって任意に指定される規則ファイル 1 つです。規則ファイルは、どのような相違が監視されるかを指定するものです。

2 つの目録、制御目録とテスト目録の比較には、bart compare コマンドを使用します。これらの目録は、bart create コマンドで使用するものと同じファイルシステム、オプション、および規則ファイルで用意する必要があります。

bart compare コマンドで出力されるのは、ファイルごとに 2 つの目録の相違を示したレポートです。「相違」は、両方の目録のためにカタログ化されている特定のファイルの属性変化です。2 つの目録間でファイルエントリの追加または削除があった場合も相違とみなされます。

相違を報告するときの制御レベルは 2 つあります。

目録を生成する時点
レポートを生成する時点

目録の生成は 2 つの目録間の相違を報告するよりも負担が大きいため、これらのレベルの制御は計画的に行われます。目録の作成が終わると、さまざまな規則ファイルを使用して bart compare コマンドを実行し、異なる視点から目録を比較できます。

BART レポートの詳細は、「BART レポート」を参照してください。

BART 規則ファイル

規則ファイルは、bart コマンドへの入力情報として任意に指定できるテキストファイルです。このファイルは、取り込みについての規則と除外についての規則を使用します。規則ファイルは、カスタム目録とカスタムレポートの作成に使用されます。このファイルには、どのファイル群をカタログ化するか、特定のファイル群のどの属性を監視するかを指定できます。目録を比較する場合、目録間の相違を報告するには規則ファイルが役立ちます。規則ファイルを使用することで、システム上のファイルについての特定の情報を効率良く収集できます。

規則ファイルは、テキストエディタで作成できます。次に、規則ファイルを使用して行える作業を示します。

bart create コマンドを使用し、システム上の全ファイルまたは特定のファイルについての情報を列挙する目録を作成します。
bart compare コマンドを使用し、ファイルシステムの特定の属性を監視するレポートを生成します。

注 –

目的に合わせて、複数の複数の規則ファイルを作成できます。しかし、規則ファイルを使用して目録を作成する場合は、それらの目録を比較する際に同じ規則ファイルを使用する必要があります。規則ファイルを使用して作成された目録を比較する時に同じ規則ファイルを使用しないと、bart compare コマンドは不正な相違を多数表示します。

規則ファイルには、ユーザーエラーの結果として構文エラーなどのあいまいな情報も含めることができます。規則ファイルに誤った情報が含まれている場合は、それらのエラーも報告されます。

規則ファイルを使用してシステム上の特定のファイルやファイル属性を監視する場合は、計画が必要です。規則ファイルを作成する前に、システム上のどのファイルとファイル属性を監視するかを決定してください。何を達成するかに基づき、目録の作成、目録の比較、あるいはこれら双方の目的に規則ファイルを利用できます。

BART 規則ファイルの詳細は、「BART 規則ファイルの書式」と、bart_rules(4) のマニュアルページを参照してください。

BART の使用方法 (作業マップ)

タスク	説明	参照先
目録を作成します。	システムにインストールされているファイルごとにそれらの情報を表示する目録を取得します。	「目録を作成する方法」
カスタム目録を作成します。	システムにインストールされている特定のファイルについての情報を次に示す方法のいずれかで表示する目録を取得します。サブツリーを指定するファイル名を指定する規則ファイルを使用する	「目録をカスタマイズする方法」
同一システムの目録を一定期間で比較します。あるいは、異なるシステムの目録を制御システムの目録と比較します。	一定期間における同一システムの変化を比較するレポートを取得します。あるいは、1 つまたは複数のシステムを制御システムと比較するレポートを取得します。	「一定期間内で同一システムの目録を比較する方法」「異なるシステムの目録を制御システムの目録と比較する方法」
(省略可能) BART レポートをカスタマイズします。	次に示す方法のいずれかでカスタム BART レポートを取得します。属性を指定する規則ファイルを使用する	「ファイル属性を指定して BART レポートをカスタマイズする方法」「規則ファイルを使用して BART レポートをカスタマイズする方法」

BART の使用方法 (作業)

bart コマンドは、通常のユーザーとしても、スーパーユーザーとしても、あるいは Primary Administrator 役割を引き受けたユーザーとしても実行できます。ただし、bart コマンドを通常のユーザーとして実行する場合は、アクセス権のあるファイルのカタログ化と監視しか行えません (たとえば、自分のホーム内のファイルに関する情報のみ)。スーパーユーザーとして bart コマンドを実行する利点は、作成する目録に隠しファイルやプライベートファイルについての情報が含まれることです。これらの情報を監視することもあるでしょう。アクセス権を制限したファイル (/etc/passwd ファイルや /etc/shadow ファイル) に関する情報のカタログ化と監視が必要な場合は、bart コマンドをスーパーユーザーとして実行するか、あるいは同等の役割を引き受けてください。役割に基づくアクセス制御の実行についての詳細は、「RBAC の構成 (作業マップ)」を参照してください。

BART におけるセキュリティー上の考慮事項

bart コマンドをスーパーユーザーとして実行した場合、その出力は誰にでも読み取れます。この出力には、プライベートであることを意図するファイル名も含まれる可能性があります。bart コマンドの実行時にスーパーユーザーになる場合には、出力を適切に保護してください。たとえば、アクセス権を制限した状態で出力ファイルを生成するオプションを使用します。

注 –

この章に示されている作業と例は、スーパーユーザーによって実行された bart コマンドを示しています。特に明記しない限り、bart コマンドをスーパーユーザーとして実行するかどうかは任意に選択できます。

目録を作成する方法

システムの目録は、Solaris ソフトウェアの初期インストールが終わった直後に作成できます。このタイプの目録は、一定期間における同一システムの変化を比較するためのベースラインとなります。あるいは、この目録を使用し、異なるシステムの目録と比較することもできます。たとえば、ネットワーク上の各システムのスナップショットを作成し、各テスト目録を制御目録と比較する場合、テストシステムをベースライン構成と一致させるために必要な作業をすばやく判断できます。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

Solaris ソフトウェアのインストール後に制御目録を作成し、その出力をファイルにリダイレクトします。
# bart create options > control-manifest
-R

目録の検査対象としてルートディレクトリを指定します。規則で指定されるパスはすべて、このディレクトリからの相対パスとなるように変換されます。目録で報告されるパスはすべて、このディレクトリからの相対パスとなります。

-I

カタログ化される個々のファイルの一覧 (コマンド行上で指定されるか、あるいは標準入力から読み取られる) を受け入れます。

-r

この目録の規則ファイルの名前です。– を付けて -r オプションを使用すると、規則ファイルが標準入力から読み取られます。

-n

ファイルリストに挙げられたすべての通常ファイルの署名を無効にします。このオプションは、パフォーマンスを上げる目的で使用できます。また、(システムログファイルの場合のように) ファイルリストの内容が変わる予定がある場合にも使用できます。

目録の内容を確認します。

あとで利用できるように目録を保存します。

目録にわかりやすい名前をつけてください。たとえば、システム名と目録が作成された日付を組み合わせます。

例 5–1 システム上のファイルごとに情報を一覧表示する目録を作成する

オプションをまったく指定せずに bart create コマンドを実行すると、システムにインストールされているファイルごとに情報がカタログ化されます。このタイプの目録は、元になるイメージから多数のシステムをインストールする場合のベースラインとして使用してください。また、同一のインストールが行われたかを確認する場合に、このタイプの目録を使用して比較を行うこともできます。

次に例を示します。

# bart create
! Version 1.0
! Thursday, December 04, 2003 (16:17:39)
# Format:
#fname D size mode acl dirmtime uid gid
#fname P size mode acl mtime uid gid
#fname S size mode acl mtime uid gid
#fname F size mode acl mtime uid gid contents
#fname L size mode acl lnmtime uid gid dest
#fname B size mode acl mtime uid gid devnode
#fname C size mode acl mtime uid gid devnode
/ D 1024 40755 user::rwx,group::r-x,mask:r-x,other:r-x 3fd9ea47 0 0
/.java D 512 40755 user::rwx,group::r-x,mask:r-x,other:r-x 3f8dc04d 0 10
/.java/.userPrefs D 512 40700 user::rwx,group::---,mask:---
other:--- 3f8dc06b 010
/.java/.userPrefs/.user.lock.root F 0 100600 user::rw-
group::---,mask:---,other:--- 3f8dc06b 0 10 -
/.java/.userPrefs/.userRootModFile.root F 0 100600 user::rw-,
group::---,mask:---,other:--- 3f8dc0a1 0 10 -
.
.
.
/var/sadm/pkg/SUNWdtmad/install/depend F 932 100644 user::rw-,
group::r--,mask:r--,other:r-- 3c23a19e 0 0 -
/var/sadm/pkg/SUNWdtmad/pkginfo F 594 100644 user::rw-
group::r--,mask:r--,other:r-- 3f81e416 0 0 -
/var/sadm/pkg/SUNWdtmad/save D 512 40755 user::rwx,group::r-x
mask:r-x,other:r-x 3f81e416 0 0
/var/sadm/pkg/SUNWdtmaz D 512 40755 user::rwx,group::r-x
mask:r-x,other:r-x 3f81e41b 0 0
/var/sadm/pkg/TSIpgxw/save D 512 40755 user::rwx
group::r-x,mask:r-x,other:r-x 3f81e892 0 0
.
.
.

各目録は、ヘッダーとエントリから構成されます。目録ファイルの各エントリは、ファイルタイプに応じて単一の行に示されます。たとえば、上記の出力における各目録エントリでは、タイプ F はファイルを示し、タイプ D はディレクトリを示します。また、サイズ、内容、ユーザー ID、グループ ID、およびアクセス権も表示されます。特殊文字を正しく処理するため、出力内のファイルエントリはコード化されたバージョンのファイル名でソートされます。この結果、すべてのエントリがファイル名をキーにして昇順に並べられます。標準でないファイル名 (改行文字やタブ文字が埋め込まれたものなど) については、ソート前にそれらの非標準文字が引用符で囲まれます。

! で始まる行には、目録についてのメタデータが示されてます。目録バージョン行には、目録の仕様バージョンが示されます。日付行には、目録が作成された日付が日付形式で示されます。date(1) のマニュアルページを参照してください。一部の行は、目録比較ツールによって無視されます。無視される行には、空の行や、空白しか入っていない行、# から始まるコメントなどがあります。

目録をカスタマイズする方法

目録は、次に示す方法のいずれかでカスタマイズできます。

サブツリーを指定する

システム上の個々のサブツリーに目録を 1 つ作成するという方法を採ると、大きなディレクトリのすべての内容にそれぞれ目録を作成するよりも、特定のファイルの変化を効率良く監視できます。この方法では、システム上の特定のサブツリーのベースライン目録を作成し、その後そのサブツリーのテスト目録を定期的に作成できます。制御目録とテスト目録の比較には、bart compare コマンドを使用します。このオプションを使用すると、重要なファイルシステムを効率良く監視し、侵入者によって攻撃されたファイルがないかを確認できます。
ファイル名を指定する

全システムをカタログ化する目録の作成は時間がかかり、ディスクスペースや負担も大きくなるため、システム上の特定のファイルまたは特定のファイル群についての情報だけを表示する場合は、この bart コマンドオプションを使用することを推奨します。
規則ファイルを使用する

規則ファイルは、単一のシステム上の特定のファイルと特定のサブツリーに関する情報を表示するカスタム目録を作成する場合に利用できます。規則ファイルは、特定のファイル属性の監視にも使用できます。規則ファイルを使用して目録の作成と比較を行うと、複数のファイルまたはサブツリーの複数の属性を指定するという柔軟さが得られます。しかし、コマンド行では、作成する各目録または生成するレポートの全ファイルに適用される汎用的な属性定義しか指定できません。

どのファイルのカタログ化および監視を行うのかを決定します。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

Solaris ソフトウェアのインストール後、次に示すオプションのいずれかを使用してカスタム目録を作成します。
- サブツリーを指定する。
  # bart create -R root-directory
- ファイル名 (1 つまたは複数) を指定する。
  # bart create -I filename...
  次に例を示します。
  # bart create -I /etc/system /etc/passwd /etc/shadow
- 規則ファイルを使用する。
  # bart create -r rules-file

目録の内容を確認します。

あとで利用できるように目録を保存します。

例 5–2 サブツリーを指定して目録を作成する

この例は、/etc/ssh サブツリーだけに含まれるファイルの情報が入った目録を作成する方法を示しています。

# bart create -R /etc/ssh
! Version 1.0
! Saturday, November 29, 2003 (14:05:36)
# Format:
#fname D size mode acl dirmtime uid gid
#fname P size mode acl mtime uid gid
#fname S size mode acl mtime uid gid
#fname F size mode acl mtime uid gid contents
#fname L size mode acl lnmtime uid gid dest
#fname B size mode acl mtime uid gid devnode
#fname C size mode acl mtime uid gid devnode
/ D 512 40755 user::rwx,group::r-x,mask:r-x,other:r-x 3f81eab9 0 3
/ssh_config F 861 100644 user::rw-,group::r--,mask:r--,
other:r-- 3f81e504 0 3 422453ca0e2348cd9981820935600395
/ssh_host_dsa_key F 668 100600 user::rw-,group::---,mask:---,
other:--- 3f81eab9 0 0 5cc28cdc97e833069fd41ef89e4d9834
/ssh_host_dsa_key.pub F 602 100644 user::rw-,group::r--,mask:r--,
other:r-- 3f81eab9 0 0 16118c736995a4e4754f5ab4f28cf917
/ssh_host_rsa_key F 883 100600 user::rw-,group::---,mask:---,
other:--- 3f81eaa2 0 0 6ff17aa968ecb20321c448c89a8840a9
/ssh_host_rsa_key.pub F 222 100644 user::rw-,group::r--,mask:r--,
other:r-- 3f81eaa2 0 0 9ea27617efc76058cb97aa2caa6dd65a
.
.
.

例 5–3 ファイル名を指定することによって目録をカスタマイズする

この例は、システム上の /etc/passwd ファイルと /etc/shadow ファイルについての情報だけを表示する目録を作成する方法を示しています。

# bart create -I /etc/passwd /etc/shadow
! Version 1.0
! Monday, December 15, 2003 (16:28:55)
# Format:
#fname D size mode acl dirmtime uid gid
#fname P size mode acl mtime uid gid
#fname S size mode acl mtime uid gid
#fname F size mode acl mtime uid gid contents
#fname L size mode acl lnmtime uid gid dest
#fname B size mode acl mtime uid gid devnode
#fname C size mode acl mtime uid gid devnode
/etc/passwd F 542 100444 user::r--,group::r--,mask:r--,
other:r-- 3fcfd45b 0 3 d6
84554f85d1de06219d80543174ad1a
/etc/shadow F 294 100400 user::r--,group::---,mask:---,
other:--- 3f8dc5a0 0 3 fd
c3931c1ae5ee40341f3567b7cf15e2

比較として、同じシステム上の /etc/passwd ファイルと /etc/shadow ファイルに対して ls -al コマンドを実行した場合の標準出力を次に示します。

# ls -al /etc/passwd
-r--r--r--   1 root     sys          542 Dec  4 17:42 /etc/passwd

# ls -al /etc/shadow
-r--------   1 root     sys          294 Oct 15 16:09 /etc/shadow

例 5–4 規則ファイルを使用して目録をカスタマイズする

この例は、/etc ディレクトリ内のファイルだけをカタログ化するために規則ファイルを使用して目録を作成する方法を示しています。この規則ファイルには、/etc/system ファイルの acl 属性の変化を監視するために bart compare コマンドによって使用される指示語も含まれます。

テキストエディタを使用し、/etc ディレクトリ内のファイルだけをカタログ化する規則ファイルを作成します。
# List information about all the files in the /etc directory. CHECK all /etc # Check only acl changes in the /etc/system file IGNORE all CHECK acl /etc/system
規則ファイルの作成についての詳細は、「BART 規則ファイル」を参照してください。

作成した規則ファイルを使用して制御目録を作成します。

# bart create -r etc.rules-file > etc.system.control-manifest
! Version 1.0
! Thursday, December 11, 2003 (21:51:32)
# Format:
#fname D size mode acl dirmtime uid gid
#fname P size mode acl mtime uid gid
#fname S size mode acl mtime uid gid
#fname F size mode acl mtime uid gid contents
#fname L size mode acl lnmtime uid gid dest
#fname B size mode acl mtime uid gid devnode
#fname C size mode acl mtime uid gid devnode
/etc/system F 1883 100644 user::rw-,group::r--,mask:r--,
other:r-- 3f81db61 0 3

システムに発生した変化を監視する時点でテスト目録を作成します。このテスト目録は、同じ bart オプションと同じ規則ファイルを使って制御目録と同じように用意してください。
同じ規則ファイルを使用し、目録を比較します。

一定期間内で同一システムの目録を比較する方法

この作業は、一定期間内で同一のシステムに起きるファイルレベルの変化を監視する場合に行なってください。このタイプの目録は、セキュリティー侵害を検出して破損したファイルや異常な状態のファイルを見つけたり、システムのパフォーマンスの問題を解決したりするのに便利です。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

Solaris ソフトウェアのインストール後、システム上で監視するファイルの制御目録を作成します。
# bart create -R /etc > control-manifest

システムの変化を監視する任意の時点で、制御目録と同様の指定でテスト目録を作成します。
# bart create -R /etc > test-manifest

制御目録をテスト目録と比較します。
# bart compare options control-manifest test-manifest > bart-report
-r

この比較の規則ファイルの名前です。– を付けて -r オプションを使用するのは、指示語が標準入力から読み取られることを意味します。

-i

ユーザーは、コマンド行から汎用指示語 IGNORE を設定できます。

-p

プログラムによる解析に対して地域対応化されていない標準的な出力を生成するプログラムモードです。

control-manifest

制御システムの bart create コマンドからの出力です。

test-manifest

テストシステムの bart create コマンドからの出力です。

BART レポートを調べ、異常がないかを確認します。

例 5–5 同一システムの目録を一定期間で比較する

この例では、一定期間に /etc ディレクトリに発生した変化を監視します。このタイプの比較を行うと、システム上の重要ファイルが攻撃されていないかをすばやく確認できます。

制御目録を作成します。

# bart create -R /etc > system1.control.121203
! Version 1.0
! Friday, December 12, 2003 (08:34:51)
# Format:
#fname D size mode acl dirmtime uid gid
#fname P size mode acl mtime uid gid
#fname S size mode acl mtime uid gid
#fname F size mode acl mtime uid gid contents
#fname L size mode acl lnmtime uid gid dest
#fname B size mode acl mtime uid gid devnode
#fname C size mode acl mtime uid gid devnode
/ D 4096 40755 user::rwx,group::r-x,mask:r-x,other:r-x 3fd9dfb4 0 3
/.cpr_config F 2236 100644 user::rw-,group::r--,mask:r--,other:r--
3fd9991f 0 0
67cfa2c830b4ce3e112f38c5e33c56a2
/.group.lock F 0 100600 user::rw-,group::---,mask:---,other:--- 3f81f14d
0 1 d41
d8cd98f00b204e9800998ecf8427e
/.java D 512 40755 user::rwx,group::r-x,mask:r-x,other:r-x 3f81dcb5 0 2
/.java/.systemPrefs D 512 40755 user::rwx,group::r-x,mask:r-x,
other:r-x 3f81dcb7
.
.
.

/etc ディレクトリの変化を監視する時点で、テスト目録を作成します。

# bart create -R /etc > system1.test.121503
Version 1.0
! Monday, December 15, 2003 (08:35:28)
# Format:
#fname D size mode acl dirmtime uid gid
#fname P size mode acl mtime uid gid
#fname S size mode acl mtime uid gid
#fname F size mode acl mtime uid gid contents
#fname L size mode acl lnmtime uid gid dest
#fname B size mode acl mtime uid gid devnode
#fname C size mode acl mtime uid gid devnode
/ D 4096 40755 user::rwx,group::r-x,mask:r-x,other:r-x 3fd9dfb4 0 3
/.cpr_config F 2236 100644 user::rw-,group::r--,mask:r--,other:r--
3fd9991f 0 0
67cfa2c830b4ce3e112f38c5e33c56a2
/.group.lock F 0 100600 user::rw-,group::---,mask:---,other:---
3f81f14d 0 1 d41d8cd98f00b204e9800998ecf8427e
/.java D 512 40755 user::rwx,group::r-x,mask:r-x,other:r-x 3f81dcb5 0 2
/.java/.systemPrefs D 512 40755 user::rwx,group::r-x,mask:r-x,
other:r-x 3f81dcb70 2
/.java/.systemPrefs/.system.lock F 0 100644 user::rw-,group::r--
,mask:r--,other:
r-- 3f81dcb5 0 2 d41d8cd98f00b204e9800998ecf8427e
/.java/.systemPrefs/.systemRootModFile F 0 100644 user::rw-,
group::r--,mask:r--,
other:r-- 3f81dd0b 0 2 d41d8cd98f00b204e9800998ecf8427e
.
.
.

制御目録をテスト目録と比較します。

# bart compare system1.control.121203 system1.test.121503
/vfstab:
  mode  control:100644  test:100777
  acl  control:user::rw-,group::r--,mask:r--,other:r--  test:user::rwx,
group::rwx,mask:rwx,other:rwx

上記の出力は、制御目録が作成されたあとに vfstab ファイルのアクセス権が変化したことを示しています。このレポートは、所有権、日付、内容などのファイル属性が変化していないかを確認するために使用できます。このタイプの情報をすぐに利用できるようにしておくと、ファイルを改ざんした可能性がある人物や、変化が起きた時点などを追跡しやすくなります。

異なるシステムの目録を制御システムの目録と比較する方法

システム同士の比較を行い、ベースラインシステムとほかのシステムの間にファイルレベルの相違がないかをすばやく確認できます。たとえば、ベースラインシステムに特定バージョンの Solaris ソフトウェアをインストールした場合で、ほかのシステムにも同一のパッケージがインストールされているかどうかを知りたいときには、それらのシステムの目録を作成し、続いてテスト目録を制御目録と比較できます。このタイプの比較では、制御システムと比較される各テストシステムについてファイルの内容の相違がすべて一覧表示されます。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

Solaris ソフトウェアのインストール後、制御目録を作成します。
# bart create options > control-manifest

制御目録を保存します。

テストシステムで、同じ bart オプションを使用して目録を作成し、出力をファイルにリダイレクトします。
# bart create options > test1-manifest
テスト目録に識別しやすい意味のある名前を付けます。

目録を比較する準備が整うまで、このテスト目録をシステムの中心的な場所に保存しておきます。

目録を比較する時点で、制御目録をテスト目録の場所へコピーするか、あるいはテスト目録を制御システムへコピーします。

次に例を示します。

# cp control-manifest /net/test-server/bart/manifests

テストシステムが NFS マウントされた状態でない場合は、FTP などの信頼性のある方法によって制御目録をテストシステムにコピーしてください。

制御目録をテスト目録と比較し、出力をファイルにリダイレクトします。
# bart compare control-manifest test1-manifest > test1.report

BART レポートを調べ、異常がないかを確認します。

制御目録と比較を行いたいテスト目録ごとに手順 4 から 9 を繰り返します。

テストシステムごとに、同じ bart オプションを使用してください。

例 5–6 異なるシステムの目録を制御システムの目録と比較する

この例では、制御目録を異なるシステムのテスト目録と比較することによって /usr/bin ディレクトリの内容に起きた変化を監視する方法について説明します。

制御目録を作成します。

# bart create -R /usr/bin > control-manifest.121203
!Version 1.0
! Friday, December 12, 2003 (09:19:00)
# Format:
#fname D size mode acl dirmtime uid gid
#fname P size mode acl mtime uid gid
#fname S size mode acl mtime uid gid
#fname F size mode acl mtime uid gid contents
#fname L size mode acl lnmtime uid gid dest
#fname B size mode acl mtime uid gid devnode
#fname C size mode acl mtime uid gid devnode
/ D 13312 40755 user::rwx,group::r-x,mask:r-x,other:r-x 3fd9e925 0 2
/.s F 14200 104711 user::rwx,group::--x,mask:--x,other:--x
3f8dbfd6 0 1 8ec7e52d8a35ba3b054a6394cbf71cf6
/ControlPanel L 28 120777 - 3f81dc71 0 1 jre/bin/ControlPanel
/HtmlConverter L 25 120777 - 3f81dcdc 0 1 bin/HtmlConverter
/acctcom F 28300 100555 user::r-x,group::r-x,mask:r-x,other:r-x
3f6b5750 0 2 d6e99b19c847ab4ec084d9088c7c7608
/activation-client F 9172 100755 user::rwx,group::r-x,mask:r-x,
other:r-x 3f5cb907 0 1 b3836ad1a656324a6e1bd01edcba28f0
/adb F 9712 100555 user::r-x,group::r-x,mask:r-x,other:r-x
3f6b5736 0 2 5e026413175f65fb239ee628a8870eda
/addbib F 11080 100555 user::r-x,group::r-x,mask:r-x,other:r-x
3f6b5803 0 2 a350836c36049febf185f78350f27510
.
.
.

制御システムと比較するシステムごとにテスト目録を作成します。

# bart create -R /usr/bin > system2-manifest.121503
! Version 1.0
! Friday, December 15, 2003 (13:30:58)
# Format:
#fname D size mode acl dirmtime uid gid
#fname P size mode acl mtime uid gid
#fname S size mode acl mtime uid gid
#fname F size mode acl mtime uid gid contents
#fname L size mode acl lnmtime uid gid dest
#fname B size mode acl mtime uid gid devnode
#fname C size mode acl mtime uid gid devnode
/ D 13312 40755 user::rwx,group::r-x,mask:r-x,other:r-x 3fd9ea9c 0 2
/.s F 14200 104711 user::rwx,group::--x,mask:--x,other:--x
3f8dbfd6 0 1 8ec7e52d8a35ba3b054a6394cbf71cf6
/ControlPanel L 28 120777 - 3f81dc71 0 1 jre/bin/ControlPanel
/HtmlConverter L 25 120777 - 3f81dcdc 0 1 bin/HtmlConverter
/acctcom F 28300 100555 user::r-x,group::r-x,mask:r-x,other:
r-x 3f6b5750 0 2 d6e99b19c847ab4ec084d9088c7c7608
.
.
.

目録を比較する時点で、その目録を同じ場所にコピーします。
# cp control-manifest /net/system2.central/bart/manifests

制御目録をテスト目録と比較します。

# bart compare control-manifest  system2.test > system2.report
/su:
  gid  control:3  test:1
/ypcat:
  mtime  control:3fd72511  test:3fd9eb23

上記の出力は、/usr/bin ディレクトリの su ファイルのグループ ID が制御システムのグループ ID と同じでないことを示しています。この情報は、異なるバージョンのソフトウェアがテストシステムにインストールされていないかということや、誰かがファイルを改ざんしていないかということなどの確認に便利です。

ファイル属性を指定して BART レポートをカスタマイズする方法

ここでは、コマンド行でファイル属性を指定することによって BART レポートをカスタマイズする方法を説明します。この作業はオプション (省略可能) です。システム上の全ファイルまたは特定のファイルについての情報を一覧表示するベースライン目録を作成すると、特定のディレクトリ、サブディレクトリ、またはファイル (1 つまたは複数) に起きた変化を監視する任意の時点で各種の属性を指定して bart compare コマンドを実行できます。コマンド行で各種のファイル属性を指定し、同一目録についてさまざまな比較を行うことができます。

監視するファイル属性を決定します。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

Solaris ソフトウェアのインストール後、制御目録を作成します。

変化を監視する時点で、テスト目録を作成します。

このテスト目録は制御目録と同様に作成してください。

目録を比較します。

次に例を示します。
# bart compare -i dirmtime,lnmtime,mtime control-manifest.121503 \ test-manifest.010504 > bart.report.010504
コンマは、コマンド行構文で指定する各属性を区切るために使用します。

BART レポートを調べ、異常がないかを確認します。

規則ファイルを使用して BART レポートをカスタマイズする方法

ここでは、bart compare コマンドの入力情報として規則ファイルを指定することにより BART レポートをカスタマイズする方法を説明します。この作業もオプション (省略可能) です。規則ファイルを使用すると、BART レポートをカスタマイズし、1 つ以上のファイルまたはサブツリーの複数の属性を柔軟に指定できます。また、異なる複数の規則ファイルを使用することで、同じ目録についてさまざまな比較を行えます。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

監視するファイルとファイル属性を決定します。

テキストエディタを使用し、適切な指示語を指定して規則ファイルを作成します。

Solaris ソフトウェアのインストール後、作成済みの規則ファイルを使用して制御目録を作成します。
# bart create -r rules-file > control-manifest

制御目録と同様に指定してテスト目録を作成します。
# bart create -r rules-file > test-manifest

同じ規則ファイルを使用して、制御目録をテスト目録と比較します。
# bart compare -r rules-file control-manifest test-manifest > bart.report

BART レポートを調べ、異常がないかを確認します。

例 5–7 規則ファイルを使用して BART レポートをカスタマイズする

次に示す規則ファイルには、bart create コマンドと bart compare コマンドの両方に適用される指示語が含まれています。この規則ファイルは、/usr/bin ディレクトリの内容についての情報を一覧表示するように bart create コマンドに指示します。さらに、このディレクトリのサイズと内容の変化だけを追跡するように bart compare コマンドに指示します。

# Check size and content changes in the /usr/bin directory.
# This rules file only checks size and content changes.
# See rules file example.

IGNORE all
CHECK size contents
/usr/bin

作成した規則ファイルを使用して制御目録を作成します。
# bart create -r bartrules.txt > usr_bin.control-manifest.121003
/usr/bin ディレクトリの変化を監視する時点で、テスト目録を作成します。
# bart create -r bartrules.txt > usr_bin.test-manifest.121103

同じ規則ファイルを使用して目録を比較します。

# bart compare -r bartrules.txt usr_bin.control-manifest \
usr_bin.test-manifest

bart compare コマンドの出力を調べます。
/usr/bin/gunzip: add /usr/bin/ypcat: delete

上記の出力では、bart compare コマンドによって /usr/bin ディレクトリにおける相違が報告されます。この出力は、/usr/bin/ypcat ファイルが削除されたことと、/usr/bin/gunzip ファイルが追加されたことを示しています。

BART 目録、BART 規則ファイル、BART レポート (参考情報)

この節では次の参考情報を示します。

BART 目録のファイル形式

目録ファイルの各エントリは、ファイルタイプに応じて単一の行に示されます。各エントリは、ファイルの名前である fname で始まります。ファイル名に使用された特殊文字が引き起こす解析上の問題を防ぐため、ファイル名はコード化されます。詳細は、「BART 規則ファイルの書式」を参照してください。

後続のフィールドは、次のファイル属性を表します。

type

ファイルの種類であり、次のような値となります。

B: ブロックデバイスノード
C: キャラクタデバイスノード
D: ディレクトリ
F: ファイル
L: シンボリックリンク
P: パイプ
S: ソケット

size

ファイルサイズ (バイト)。

mode

ファイルのアクセス権を示す 8 進の数値。

acl

ファイルの ACL 属性。ACL 属性を持つファイルの場合、acltotext() の出力が入ります。

uid

このエントリの所有者の、数値で示したユーザー ID。

gid

このエントリの所有者の、数値で示したグループ ID。

dirmtime

ディレクトリに最後に変化が起きた時点。1970 年 1 月 1 日の 00:00:00 UTC から数えた秒数で示されます。

lnmtime

リンクに最後に変化が起きた時点。1970 年 1 月 1 日の 00:00:00 UTC から数えた秒数で示されます。

mtime

ファイルに最後に変化が起きた時点。1970 年 1 月 1 日の 00:00:00 UTC から数えた秒数で示されます。

contents

ファイルのチェックサム値。この属性が指定されるのは通常ファイルのみです。コンテキストのチェックを無効にした場合と、チェックサムが計算できない場合は、このフィールドの値は – になります。

dest

シンボリックリンクのリンク先。

devnode

デバイスノードの値。この属性が使用されるのは、キャラクタデバイスファイルとブロックデバイスファイルのみです。

BART 目録についての詳細は、bart_manifest(4) のマニュアルページを参照してください。

BART 規則ファイルの書式

bart コマンドの入力ファイルはテキストファイルです。これらのファイルは、目録に含められるファイルと、レポートに含められるファイル属性を指定する行から構成されます。この同じ入力ファイルは、両方の BART 機能で使用できます。#、空の行、空白を含む行は、ツールが無視します。

入力ファイルには、次に示す 3 種類の指示語が指定されます。

オプションのパターンマッチング修飾子を持つ subtree 指示語
CHECK 指示語
IGNORE 指示語

例 5–8 規則ファイルの書式

<Global CHECK/IGNORE Directives>
<subtree1> [pattern1..]
<IGNORE/CHECK Directives for subtree1>

<subtree2> [pattern2..]
<subtree3> [pattern3..]
<subtree4> [pattern4..]
<IGNORE/CHECK Directives for subtree2, subtree3, subtree4>

注 –

すべての指示語は指定された順に読み取られますが、あとから指定された指示語が先に指定された指示語に優先して読み取られる可能性があります。

行ごとに subtree 指示語が 1 つ存在します。この指示語は、絶対パス名で始まり、そのあとに 0 個以上のパターンマッチング文が続く必要があります。

規則ファイルの属性

bart コマンドは、CHECK 文と IGNORE 文を使用して追跡または無視の対象となる属性を定義します。各属性にはキーワードが関連付けられます。

属性「キーワード」を次に示します。

acl
all
contents
dest
devnode
dirmtime
gid
lnmtime
モード
mtime
size
type
uid

キーワード all は、すべてのファイル属性を意味します。

引用構文

BART が規則ファイルに使用する記述言語は、標準に準拠していないファイル名を表現する標準の UNIX 引用構文です。埋め込まれたタブ、スペース、改行、特殊文字は、ツールがファイル名を読み取ることができるようにそれらの 8 進形式にコード化されます。この変動的な引用構文では、埋め込みのキャリッジリターンを含むファイル名などがコマンドパイプラインで正しく処理されません。規則記述言語を使用することで、シェル構文だけでは表現が難しい効率の悪い複雑なファイル名フィルタリング基準を表現できます。

BART 規則ファイルや、BART で使用される引用構文についての詳細は、bart_rules(4) のマニュアルページを参照してください。

BART レポート

デフォルトモードでは、次の例に示すように bart compare コマンドは、ディレクトリ変更のタイムスタンプ (dirmtime) を除きシステムにインストールされているすべてのファイルをチェックします。

CHECK all
IGNORE	dirmtime

規則ファイルを指定すると、汎用指示語である CHECK all と IGNORE dirmtime がこの順で規則ファイルの先頭に自動的に付けられます。

BART の出力

次の終了値が返されます。

0: 成功
1: ファイル処理時の致命的でないエラー (アクセス権問題など)
>1: 致命的なエラー (無効なコマンド行オプションなど)

レポーティングメカニズムとして、詳細出力と、プログラムを考慮した出力の 2 種類を利用できます。

詳細出力はデフォルトの出力であり、地域対応化され、複数の行にわたって表示されます。詳細出力は国際化されたもので、ユーザーが内容を読み取ることができます。bart compare コマンドは、2 つのシステム目録を比較する時に、ファイル間の相違を示すリストを生成します。

次に例を示します。
filename attribute control:xxxx test:yyyy
filename

制御目録とテスト目録で相違があるファイルの名前。

attribute

比較された目録間で相違があるファイル属性の名前。xxxx は制御目録の属性値で、yyyy はテスト目録の属性値です。同じファイルの複数の属性に相違が見つかった場合、別々の行にそれぞれの相違が示されます。

次に、bart compare コマンドのデフォルト出力の例を示します。この例では、/etc/passwd ファイルでの属性の相違がチェックされています。この出力から、size、mtime、および contents 属性に変化があったことがわかります。
/etc/passwd: size control:74 test:81 mtime control:3c165879 test:3c165979 contents control:daca28ae0de97afd7a6b91fde8d57afa test:84b2b32c4165887355317207b48a6ec7
-bart compare コマンドの実行時に p オプションを指定すると、プログラムを考慮した出力が生成されます。この出力は、プログラム化された操作に適したフォームで生成されます。「プログラムを考慮した出力」はほかのプログラムで簡単に解析が可能であり、ほかのツールに対する入力情報として使用されるように設計されています。

次に例を示します。
filename attribute control-val test-val [attribute control-val test-val]*
filename

デフォルト形式における filename 属性に同じ

attribute control-val test-val

各ファイルの制御目録とテスト目録間で異なるファイル属性の説明

bart コマンドでサポートされる属性の一覧は、「規則ファイルの属性」を参照してください。

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

第 6 章ファイルアクセスの制御 (作業)

この章では、Solaris オペレーティングシステム (Solaris OS) におけるファイル保護の方法について説明します。また、システムに悪影響を与える可能性のあるアクセス権が設定されたファイルからシステムを保護する方法についても説明します。

注 –

アクセス制御リスト (ACL) を使って ZFS ファイルを保護する方法については、『Oracle Solaris ZFS 管理ガイド』の第 8 章「ACL による Oracle Solaris ZFS ファイルの保護」を参照してください。

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

UNIX アクセス権によるファイル保護

ファイルは、UNIX ファイルアクセス権と ACL を通して保護することができます。スティッキービットが設定されたファイルと、実行可能なファイルは、特殊なセキュリティー対策が必要です。

ファイルの監視と保護を行うコマンド

この表は、ファイルとディレクトリの監視と保護を行うコマンドについて説明したものです。

表 6–1 ファイルとディレクトリの保護を行うコマンド


コマンド	説明	マニュアルページ
`ls`	ディレクトリ内のファイルとファイル情報を表示します。	ls(1)
`chown`	ファイルの所有権を変更します。	chown(1)
`chgrp`	ファイルのグループ所有権を変更します。	chgrp(1)
`chmod`	ファイルのアクセス権を変更します。記号モード (文字と記号) または絶対モード (8 進数) を使用して、ファイルのアクセス権を変更できます。	chmod(1)

ファイルとディレクトリの所有権

従来の UNIX ファイルアクセス権では、次に示す 3 つのユーザークラスに所有権を割り当てることができます。

ユーザー – ファイルまたはディレクトリの所有者。通常はファイルを作成したユーザーです。ファイルの所有者は、そのファイルの読み取り、書き込み (ファイルを変更する)、または実行 (コマンドの場合) が行えるユーザーを決定できます。
グループ – ユーザーグループのメンバー。
その他 – ファイル所有者ではなくグループメンバーでもないその他の全ユーザー。

ファイルアクセス権の割り当てや変更が行えるのは、通常、そのファイルの所有者だけです。しかし、ファイルの所有権の変更は、管理権限のあるユーザー (スーパーユーザーなど) または役割 (Primary Administrator 役割など) によっても行えます。システムポリシーを上書きする方法については、例 6–2 を参照してください。

ファイルは、7 つの形式のいずれかになります。各形式は、次のように記号で示されます。

- (マイナス記号): テキストまたはプログラム
b: ブロック型特殊ファイル
c: 文字型特殊ファイル
d: ディレクトリ
l: シンボリックリンク
s: ソケット
D: ドア
P: 名前付きパイプ (FIFO)

UNIX ファイルアクセス権

次の表に、各ユーザークラスに与えることができる、ファイルまたはディレクトリのアクセス権を示します。

表 6–2 ファイルとディレクトリのアクセス権


記号	アクセス権	オブジェクト	説明
`r`	読み取り	ファイル	ファイルの内容を開いて読み込むことができます。
		ディレクトリ	ディレクトリ内のファイルを一覧表示できます。
`w`	書き込み	ファイル	ファイルの内容の変更またはファイルの削除を行えます。
		ディレクトリ	ディレクトリに対してファイルまたはリンクを追加できます。また、ディレクトリ内のファイルまたはリンクの削除も行えます。
`x`	実行	ファイル	ファイルがプログラムまたはシェルスクリプトの場合、そのファイルを実行できます。また、`exec(2)` システム呼び出しの 1 つを使用してそのプログラムを実行することもできます。
		ディレクトリ	ディレクトリ内のファイルを開いたり、実行したりできます。また、ディレクトリを作成し、その下にサブディレクトリを作成できます。
`-`	拒否	ファイルとディレクトリ	ファイルの読み込み、書き込み、または実行を行うことができません。

これらのファイルアクセス権は、通常のファイルと特殊ファイル (デバイス、ソケット、名前付きパイプ (FIFO) など) の両方に適用されます。

シンボリックリンクには、そのリンクが指すファイルのアクセス権が適用されます。

ディレクトリとそのサブディレクトリ内のファイルは、そのディレクトリに対するファイルアクセス権を制限することで保護できます。ただし、スーパーユーザーはシステム上のすべてのファイルとディレクトリにアクセスできます。

特殊なファイルアクセス権 (`setuid`、`setgid`、スティッキービット)

実行可能ファイルと公開ディレクトリには、 3 種類の特殊なアクセス権 (setuid、setgid、およびスティッキービット) を設定できます。これらのアクセス権を設定すると、その実行可能ファイルを実行するユーザーは、そのファイルの所有者 (またはグループ) の ID を持つことができます。

特殊なアクセス権はセキュリティー上の問題を引き起こすため、設定するときは十分な注意が必要です。たとえば、ユーザー ID (UID) を 0 (root の UID) に設定するプログラムを実行すれば、ユーザーはスーパーユーザー権限を取得できます。また、すべてのユーザーは、所有するファイルに対して特殊なアクセス権を設定できるため、これもセキュリティー上の問題の原因となります。

setuid アクセス権や setgid アクセス権を不正に使用してスーパーユーザー権限が取得されていないか、システムを監視する必要があります。疑わしいアクセス権によって、管理プログラムの所有権が root や bin ではなく一般ユーザーに付与されていることが考えられます。この特殊なアクセス権を使用しているファイルをすべて検索し、リストする方法は、「特殊なファイルアクセス権が設定されたファイルを見つける方法」を参照してください。

`setuid` アクセス権

setuid アクセス権を実行可能ファイルに設定すると、このファイルを実行するプロセスにはその実行可能ファイルを実行しているユーザーではなく、ファイルの所有者に基づいてアクセス権が与えられます。この特殊なアクセス権を使用すると、通常は所有者しか利用できないファイルやディレクトリにアクセスできます。

たとえば、passwd コマンドの setuid アクセス権によってユーザーはパスワードを変更できます。次に、setuid アクセス権のある passwd コマンドの例を示します。

-r-sr-sr-x   3 root     sys       28144 Jun 17 12:02 /usr/bin/passwd

この特殊なアクセス権は、プロセスの実行が終了したあとでも、高度な知識のあるユーザーは setuid プロセスによって与えられたアクセス権を維持する手段を見つけることができるため、セキュリティー上の危険が存在します。

注 –

プログラムから予約済み UID (0 から 99) で setuid アクセス権を使用しても、実効 UID は正しく設定されない場合があります。シェルスクリプトを使用するか、setuid アクセス権では予約済み UID を使用しないようにしてください。

`setgid` アクセス

setgidアクセス権は setuid アクセス権に似ています。プロセスの実効グループ ID (GID) はファイルを所有するグループに変更され、ユーザーにはそのグループに与えられたアクセス権に基づくアクセス権が与えられます。/usr/bin/mail コマンドには、次のように setgid アクセス権が設定されています。

-r-x--s--x   1 root   mail     67504 Jun 17 12:01 /usr/bin/mail

setgidアクセス権がディレクトリに適用されると、このディレクトリ内で作成されたファイルはディレクトリが所属するグループに含まれることになります。生成するプロセスが所属するグループに含まれるわけではありません。ディレクトリに対する書き込み権および実行権を持つユーザーは、そのディレクトリにファイルを作成できます。ただし、作成したファイルはユーザーのグループではなくディレクトリを所有するグループに割り当てられます。

setgidアクセス権を使用して不正にスーパーユーザー権限が取得されていないか、システムを監視する必要があります。疑わしいアクセス権によって、このようなプログラムへのグループアクセス権が、root や bin ではなく、意外なグループに与えられることがあります。このようなアクセス権を使用しているファイルをすべて検索し、一覧表示する方法は、「特殊なファイルアクセス権が設定されたファイルを見つける方法」を参照してください。

スティッキービット

「スティッキービット」は、ディレクトリ内のファイルを保護するアクセス権ビットです。ディレクトリにスティッキービットが設定されている場合、そのファイルを削除できるのはその所有者、ディレクトリの所有者、または特権を持つユーザーだけです。特権を持つユーザーの例として、root ユーザーや Primary Administrator 役割が挙げられます。スティッキービットにより、ユーザーは /tmp などの公開ディレクトリからほかのユーザーのファイルを削除できなくなります。

drwxrwxrwt 7  root  sys   400 Sep  3 13:37 tmp

TMPFS ファイルシステム上で公開ディレクトリを設定するときには、スティッキービットを手動で設定してください。手順については、例 6–5 を参照してください。

`umask` のデフォルト値

ファイルやディレクトリを作成するときには、デフォルトのアクセス権が設定されます。このシステムデフォルトは変更が可能です。テキストファイルのアクセス権は 666 であり、すべてのユーザーに読み取り権と書き込み権を与えます。ディレクトリと実行可能ファイルのアクセス権は 777 で、すべてのユーザーに読み取り権、書き込み権、および実行権を与えます。一般にユーザーは、自分の /etc/profile ファイル、.cshrc ファイル、または .login ファイルを手動で指定し、システムのデフォルトに優先させます。

umask コマンドによって割り当てられる値は、デフォルトから差し引かれます。この処理には、chmod コマンドでアクセス権を与えるのと同じ方法でアクセス権を拒否する効果があります。たとえば、chmod 022 コマンドはグループとその他のユーザーに書き込み権を与えますが、umask 022 コマンドはグループとその他のユーザーの書き込み権を拒否します。

次の表に、代表的な umask の設定とその設定が実行可能ファイルに与える影響を示します。

表 6–3 各セキュリティーレベルの umask 設定


セキュリティーレベル	`umask` 設定	許可されないアクセス権
緩やか (`744`)	`022`	グループとその他のユーザーによる `w`
中程度 (`740`)	`027`	グループによる `w`、その他のユーザーによる `rwx`
中程度 (`741`)	`026`	グループによる `w`、その他のユーザーによる `rw`
厳しい (`700`)	`077`	グループとその他のユーザーによる `rwx`

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

ファイルアクセス権を設定するモード

chmod コマンドを使用すると、ファイルのアクセス権を変更できます。ファイルまたはディレクトリの所有者、あるいはスーパーユーザーだけがそのアクセス権を変更できます。

chmod コマンドを使用して、次のどちらかのモードでアクセス権を設定できます。

絶対モード – ファイルアクセス権を表す数値を使用します。絶対モードを使用してアクセス権を変更するときは、3 つ 1 組のアクセス権を 8 進数で表します。絶対モードは、アクセス権の設定に一番多く使用されている方法です。
記号モード – 英字と記号の組み合わせを使用して、アクセス権を追加または削除します。

次の表に、絶対モードでファイルのアクセス権を設定するための 8 進数値を示します。これらの数字を 3 つ組み合わせて、所有者、グループ、その他のユーザーのファイルアクセス権をこの順に設定します。たとえば、値 644 は、所有者に対して読み取り権と書き込み権を設定し、グループとその他のユーザーに対しては読み取り専用権を設定します。

表 6–4 絶対モードによるファイルのアクセス権の設定


8 進数値	ファイルのアクセス権	設定されるアクセス権
`0`	`---`	なし
`1`	`--x`	実行権のみ
`2`	`-w-`	書き込み権のみ
`3`	`-wx`	書き込み権と実行権
`4`	`r--`	読み取り権のみ
`5`	`r-x`	読み取り権と実行権
`6`	`rw-`	読み取り権と書き込み権
`7`	`rwx`	読み取り権、書き込み権、実行権

次の表に、記号モードでファイルのアクセス権を設定するための記号の一覧を示します。記号では、アクセス権を設定または変更できる対象ユーザー、実行される操作、あるいは割り当てるまたは変更するアクセス権を指定できます。

表 6–5 記号モードによるファイルのアクセス権の設定


記号	機能	説明
`u`	`<対象ユーザー>`	ユーザー (所有者)
`g`	`<対象ユーザー>`	グループ
`o`	`<対象ユーザー>`	その他のユーザー
`a`	`<対象ユーザー>`	すべて
`=`	`オペレータ`	割り当て
`+`	`オペレータ`	追加
`-`	`オペレータ`	削除
`r`	`アクセス権 (アクセス権ビット)`	読み取り
`w`	`アクセス権 (アクセス権ビット)`	書き込み
`x`	`アクセス権 (アクセス権ビット)`	実行
`l`	`アクセス権 (アクセス権ビット)`	強制ロック、`setgid` ビットはオン、グループ実行ビットはオフ
`s`	`アクセス権 (アクセス権ビット)`	`setuid` または `setgid` ビットはオン
`t`	`アクセス権 (アクセス権ビット)`	スティッキービットはオン、その他の実行ビットはオン

機能列に <対象ユーザー> <操作> <アクセス権> の順で、ファイルまたはディレクトリのアクセス権を変更する記号を指定します。

who: アクセス権を変更する対象となるユーザーを指定します。
operator: 実行する操作を指定します。
permissions: 変更するアクセス権を指定します。

絶対モードまたは記号モードで、ファイルに特殊なアクセス権を設定できます。しかし、ディレクトリに setuid アクセス権を設定する場合と、ディレクトリからこのアクセス権を削除する場合は、記号モードを使用する必要があります。絶対モードでは、3 つ 1 組のアクセス権の左端に新しい 8 進数値を追加して、特殊なアクセス権を設定します。次の表に、ファイルに特殊なアクセス権を設定する 8 進数値を示します。

表 6–6 絶対モードによる特殊なファイルアクセス権の設定


8 進数値	特殊なファイルアクセス権
`1`	スティッキービット
`2`	`setgid`
`4`	`setuid`

アクセス制御リストによる UFS ファイルの保護

従来の UNIX ファイル保護機能は、ファイルの所有者、ファイルグループ、その他のユーザーという 3 つのユーザークラスに読み取り権、書き込み権、実行権を提供します。UFS ファイルシステムでは、アクセス制御リスト (ACL) により次のことが可能となり、ファイルセキュリティーを管理するレベルがさらに詳細になります。

ファイル所有者、グループ、その他のユーザー、特定のユーザーおよびグループにファイルアクセス権を定義します
これらの各カテゴリにデフォルトのアクセス権を定義します

注 –

ZFS ファイルシステムの ACL および NFSv4 ファイルの ACL については、『Oracle Solaris ZFS 管理ガイド』の第 8 章「ACL による Oracle Solaris ZFS ファイルの保護」を参照してください。

たとえば、グループ内のすべてのユーザーがファイルを読み取れるようにする場合は、そのファイルにグループの読み取り権を設定すればすみます。その場合に、そのグループ内の 1 人のユーザーだけに書き込み権を与えたいとします。標準の UNIX ではファイルセキュリティーをこのように設定することはできませんが、ACL では可能です。

ACL エントリはファイルの ACL を定義する手段であり、UFS ファイルシステムでは、エントリは setfacl コマンドを使って設定されます。UFS ACL エントリは、次のようにコロンで区切ったフィールドで構成されます。

entry-type:[uid|gid]:perms

entry-type: ファイルのアクセス権を設定する ACL エントリの種類です。たとえば、entry-type は user (ファイルの所有者) または mask (ACL マスク) に設定できます。ACL エントリの一覧については、表 6–7 と表 6–8 を参照してください。
uid: ユーザー名またはユーザー ID (UID) です。
gid: グループ名またはグループ ID (GID) です。
perms: entry-type に設定するアクセス権を表します。perms は、記号文字 rwx または 8 進数の数字で指定できます。これらは chmod コマンドに使用するのと同じ数字です。

次に、ユーザー stacey の読み取り権と書き込み権を設定する ACL エントリの例を示します。

user:stacey:rw-

注意 –

ACL などの UFS ファイルシステム属性は UFS ファイルシステムだけでサポートされます。そのため、/tmp ディレクトリ (通常は、TMPFS ファイルシステムとしてマウントされている) で ACL エントリを持つファイルを復元またはコピーすると、その ACL エントリは失われます。UFS ファイルを一時的に格納するには、/var/tmp ディレクトリを使用してください。

UFS ファイルの ACL エントリ

次の表は、ファイルに ACL を設定するときに使用する有効な ACL エントリの一覧です。最初の 3 つの ACL エントリは、基本的な UNIX のファイル保護機能を提供します。

表 6–7 UFS ファイルの ACL エントリ


ACL エントリ	説明
`u[ser]::perms`	所有者のアクセス権。
`g[roup]::perms`	グループのアクセス権。
`o[ther]:perms`	所有者やグループのメンバー以外のユーザーのアクセス権。
`m[ask]:perms`	ACL マスク。マスクエントリは、ユーザー (所有者以外) とグループに許可される最大アクセス権を示します。マスクは、すべてのユーザーとグループのアクセス権を即時に変更する手段です。たとえば、`mask:r--` マスクエントリは、ユーザーとグループが書き込み権および実行権を持つことがアカウントに示されていても、読み取り権しか使用できないことを意味します。
`u[ser]:uid:perms`	特定のユーザーのアクセス権。`uid` には、ユーザー名または UID の数値を指定できます。
`g[roup]:gid:perms`	特定のグループのアクセス権。`gid` には、グループ名または GID の数値を指定できます。

UFS ディレクトリの ACL エントリ

表 6–7 に示した ACL エントリのほかに、ディレクトリにはデフォルトの ACL エントリも設定できます。デフォルトの ACL エントリを持つディレクトリ内で作成されたファイルまたはディレクトリは、デフォルトの ACL エントリと同じ ACL エントリを持つことになります。表 6–8 は、ディレクトリに使用するデフォルトの ACL エントリの一覧です。

ディレクトリ上の特定のユーザーおよびグループに対してデフォルトの ACL エントリを初めて設定するときは、所有者、グループ、その他のユーザー、および ACL マスクにもデフォルトの ACL エントリを設定する必要があります。これらのエントリは、必ず設定しなければなりません。これらは、次の表に示された最初の 4 つのデフォルト ACL エントリに相当します。

表 6–8 UFS ディレクトリのデフォルト ACL エントリ


デフォルトの ACL エントリ	説明
`d[efault]:u[ser]::perms`	所有者のデフォルトアクセス権。
`d[efault]:g[roup]::perms`	グループのデフォルトアクセス権。
`d[efault]:o[ther]:perms`	所有者やグループのメンバー以外のユーザーのデフォルトアクセス権。
`d[efault]:m[ask]:perms`	デフォルトの ACL マスク。
`d[efault]:u[ser]:uid:perms`	特定のユーザーのデフォルトアクセス権。`uid` には、ユーザー名または UID の数値を指定できます。
`d[efault]:g[roup]:gid:perms`	特定のグループのデフォルトアクセス権。`gid` には、グループ名または GID の数値を指定できます。

UFS ACL を制御するコマンド

次のコマンドは、UFS ファイルまたはディレクトリに設定される ACL の管理に使用されます。

setfacl コマンド: ACL エントリの設定、追加、変更、および削除を行います。詳細は、setfacl(1) のマニュアルページを参照してください。
getfacl コマンド: ACL エントリを表示します。詳細は、getfacl(1) のマニュアルページを参照してください。

実行可能ファイルを原因とするセキュリティーへの悪影響を防止する

セキュリティーのバグの多くは、デフォルトで読み取り権、書き込み権、および実行権が設定された実行可能スタックで発生します。実行可能スタックには実行権が割り当てられていますが、ほとんどのプログラムは実行可能スタックがなくても正しく機能します。

noexec_user_stack 変数を使うと、スタックを実行可能として割り当てるかどうかを指定できます。この変数は、Solaris 2.6 から利用可能です。デフォルトでは、この変数は 0 に設定されるため (64 ビットアプリケーションを除く)、プログラムは ABI に準拠して動作します。この変数が 0 以外の値に設定された場合、システムはシステム中のすべてのプロセスのスタックに読み取り権と書き込み権のマークを付けますが、実行権のマークは付けません。

この変数が設定されている場合、プログラムがスタック上でコードを実行しようとすると SIGSEGV シグナルが送信されます。このシグナルが送信されると、通常、プログラムはコアダンプして終了します。このようなプログラムは、違反しているプログラム名、プロセス ID、およびプログラムを実行した実ユーザー ID を含む警告メッセージも生成します。次に例を示します。

a.out[347] attempt to execute code on stack by uid 555

メッセージは、syslog kern 機能が notice レベルの設定されているときに、syslog デーモンによってログに記録されます。このログへの記録は、デフォルトで syslog.conf ファイルに設定されていて、メッセージがコンソールと /var/adm/messages ファイルの両方に送信されることを意味します。詳細は、syslogd(1M) および syslog.conf(4) のマニュアルページを参照してください。

syslog メッセージは、潜在的なセキュリティーの問題を調べるときに役立ちます。また、このメッセージは、この変数を設定したために正しく動作しなくなった、実行可能スタックに依存するプログラムを確認するのにも役立ちます。メッセージを記録しない場合、システム管理者は、/etc/system ファイルで noexec_user_stack_log 変数を 0 に設定します。メッセージが記録されなくなりますが、SIGSEGV シグナルは送られるので、実行中のプログラムはコアダンプを生成して終了します。

mprotect() 関数を使用すれば、プログラムのスタックが実行可能であることを明示的にマーク付けできます。詳細は、mprotect(2) のマニュアルページを参照してください。

ハードウェアの制限のため、実行可能スタックの問題を捕えて報告する機能は、ほとんどの x86 ベースシステムで利用できません。AMD64 プロダクトファミリ内のシステムであれば、実行可能スタックの問題を捕えて報告できます。

ファイルの保護 (作業マップ)

次の作業マップは、ファイル保護に関連した作業の説明箇所を示しています。

タスク	説明	参照先
UNIX アクセス権を使用してファイルを保護します	ファイルの UNIX アクセス権を表示します。UNIX アクセス権を使用してファイルを保護します	「UNIX アクセス権によるファイルの保護 (作業マップ)」
ACL を使用してファイルを保護します	ACL を追加することで、UNIX アクセス権よりも細かいレベルでファイルを保護します。	「ACL による UFS ファイルの保護 (作業マップ)」
セキュリティーリスクのあるファイルからシステムを保護します	不審な所有権が設定された実行可能ファイルを見つけます。システムに損傷を与えかねないファイルを無効にします。	「セキュリティーリスクのあるプログラムからの保護 (作業マップ)」

UNIX アクセス権によるファイルの保護 (作業マップ)

次の作業マップは、ファイルアクセス権の一覧表示、ファイルアクセス権の変更、特殊なファイルアクセス権によるファイルの保護などの作業操作について説明した箇所を示しています。

作業

参照先

ファイル情報を表示します

「ファイル情報を表示する方法」

ファイル所有権を変更します

「ファイルの所有者を変更する方法」

「ファイルのグループ所有権を変更する方法」

ファイルアクセス権を変更します

「ファイルアクセス権を記号モードで変更する方法」

「ファイルアクセス権を絶対モードで変更する方法」

「特殊なファイルアクセス権を絶対モードで変更する方法」

ファイル情報を表示する方法

ls コマンドを使用して、ディレクトリ内のすべてのファイルに関する情報を表示します。

次のコマンドを入力すると、現在のディレクトリ内のすべてのファイルの一覧が長形式で表示されます。
% ls -la
-l

ユーザー所有権、グループ所有権、ファイルのアクセス権などを長形式で表示します。

-a

ドット (.) で始まる隠しファイルを含め、すべてのファイルを表示します。

例 6–1 ファイル情報を表示する

次の例では、/sbin ディレクトリ内のファイルを部分的に表示しています。

% cd /sbin
% ls -la
total 13456
drwxr-xr-x   2 root     sys          512 Sep  1 14:11 .
drwxr-xr-x  29 root     root        1024 Sep  1 15:40 ..
-r-xr-xr-x   1 root     bin       218188 Aug 18 15:17 autopush
lrwxrwxrwx   1 root     root          21 Sep  1 14:11 bpgetfile -> ...
-r-xr-xr-x   1 root     bin       505556 Aug 20 13:24 dhcpagent
-r-xr-xr-x   1 root     bin       456064 Aug 20 13:25 dhcpinfo
-r-xr-xr-x   1 root     bin       272360 Aug 18 15:19 fdisk
-r-xr-xr-x   1 root     bin       824728 Aug 20 13:29 hostconfig
-r-xr-xr-x   1 root     bin       603528 Aug 20 13:21 ifconfig
-r-xr-xr-x   1 root     sys       556008 Aug 20 13:21 init
-r-xr-xr-x   2 root     root      274020 Aug 18 15:28 jsh
-r-xr-xr-x   1 root     bin       238736 Aug 21 19:46 mount
-r-xr-xr-x   1 root     sys         7696 Aug 18 15:20 mountall
   .
   .
   .

それぞれの行には、ファイルについての情報が次の順で表示されています。

ファイルの形式 – たとえば、d。ファイル形式の一覧は、「ファイルとディレクトリの所有権」を参照してください。
アクセス権 – たとえば、r-xr-xr-x。詳細は、「ファイルとディレクトリの所有権」を参照してください。
ハードリンクの数 – たとえば、2。
ファイルの所有者 – たとえば、root。
ファイルのグループ – たとえば、bin。
バイト数で示したファイルサイズ – たとえば、7696。
ファイルの作成日時、またはファイルが最後に変更された日時 – たとえば、Aug 18 15:20。
ファイルの名前 – たとえば、mountall。

ファイルの所有者を変更する方法

ファイル所有者、Primary Administrator 役割、またはスーパーユーザーは、任意のファイルの所有権を変更できます。

ファイルのアクセス権を表示します。

% ls -l example-file
-rw-r--r--   1 janedoe   staff   112640 May 24 10:49 example-file

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

ファイルの所有者を変更します。
# chown stacey example-file

ファイルの所有者が変更されていることを確認します。

# ls -l example-file
-rw-r--r--   1 stacey   staff   112640 May 26 08:50 example-file

例 6–2 ほかのユーザーが所有しているファイルの所有権を特定のユーザーが変更できるようにする

セキュリティー上の考慮事項 – rstchown 変数の設定をゼロに変更してシステムセキュリティーポリシーを上書きする場合は、それ相応の理由がなければなりません。システムにアクセスするユーザーは誰でもシステム上の任意のファイルの所有権を変更できるようになります。

この例では、rstchown 変数の値は、/etc/system ファイル内でゼロに設定されます。この設定によりファイルの所有者は、chown コマンドを使用してファイルの所有権をほかのユーザーに変更できます。所有者は chgrp コマンドを使用し、ファイルのグループ所有権を所有者自身が属していないグループに設定することもできます。変更は、システムの再起動時に適用されます。

set rstchown = 0

詳細は、chown(1) および chgrp(1) のマニュアルページを参照してください。

NFS マウントされたファイルシステムでは、所有権とグループの変更に関する制限がほかにもあります。NFS マウントされたシステムに対するアクセスの制限については、『Solaris のシステム管理 (ネットワークサービス)』の第 6 章「ネットワークファイルシステムへのアクセス (リファレンス)」を参照してください。

ファイルのグループ所有権を変更する方法

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

ファイルのグループ所有権を変更します。
$ chgrp scifi example-file
グループの設定については、『Solaris のシステム管理 (基本編)』の第 4 章「ユーザーアカウントとグループの管理 (概要)」を参照してください。

ファイルのグループ所有権が変更されていることを確認します。
$ ls -l example-file -rw-r--r-- 1 stacey scifi 112640 June 20 08:55 example-file
また、例 6–2 も参照してください。

ファイルアクセス権を記号モードで変更する方法

ファイルまたはディレクトリの所有者でない場合は、スーパーユーザーになるか、同等の役割を引き受けます。

現在の所有者またはスーパーユーザーだけが、chmod コマンドを使用してファイルまたはディレクトリの所有者を変更できます。

アクセス権を記号モードで変更します。
% chmod who operator permissions filename
who

アクセス権を変更する対象となるユーザーを指定します。

operator

実行する操作を指定します。

permissions

変更するアクセス権を指定します。有効な記号の一覧は、表 6–5 を参照してください。

filename

ファイルまたはディレクトリを指定します。

ファイルのアクセス権が変更されていることを確認します。
% ls -l filename

例 6–3 アクセス権を記号モードで変更する

次の例では、その他のユーザーから読み取り権を削除します。

% chmod o-r example-file1

次の例では、ユーザー、グループ、およびその他のユーザーに、読み取り権と実行権を追加します。

$ chmod a+rx example-file2

次の例では、グループに読み取り権、書き込み権、および実行権を割り当てます。

$ chmod g=rwx example-file3

ファイルアクセス権を絶対モードで変更する方法

ファイルまたはディレクトリの所有者でない場合は、スーパーユーザーになるか、同等の役割を引き受けます。

現在の所有者またはスーパーユーザーだけが、chmod コマンドを使用してファイルまたはディレクトリの所有者を変更できます。

アクセス権を絶対モードで変更します。
% chmod nnn filename
nnn

所有者、グループ、その他のユーザーのアクセス権をこの順序で表す 8 進数値を指定します。有効な 8 進数値の一覧は、表 6–4 を参照してください。

filename

ファイルまたはディレクトリを指定します。

注 –
chmod コマンドを使用して ACL エントリを持つファイルのグループアクセス権を変更する場合、グループアクセス権と ACL マスクの両方が新しいアクセス権に変更されます。新しい ACL マスクのアクセス権は、そのファイル上に ACL エントリを持つほかのユーザーおよびグループのアクセス権を変更する場合があるので注意が必要です。getfacl コマンドを使用して、すべての ACL エントリに適切なアクセス権が設定されていることを確認してください。詳細は、getfacl(1) のマニュアルページを参照してください。

ファイルのアクセス権が変更されていることを確認します。
% ls -l filename

例 6–4 アクセス権を絶対モードで変更する

次の例では、公開ディレクトリのアクセス権が、744 (読み取り / 書き込み / 実行; 読み取り専用; 読み取り専用) から 755 (読み取り / 書き込み / 実行; 読み取り / 実行; 読み取り / 実行) に変更されます。

# ls -ld public_dir
drwxr--r--  1 ignatz   staff    6023 Aug  5 12:06 public_dir
# chmod 755 public_dir
# ls -ld public_dir
drwxr-xr-x  1 ignatz   staff    6023 Aug  5 12:06 public_dir

次の例では、実行可能シェルスクリプトのアクセス権が、読み取り/書き込みから、読み取り/書き込み/実行に変更されます。

% ls -l my_script
-rw------- 1 ignatz   staff    6023 Aug  5 12:06 my_script
% chmod 700 my_script
% ls -l my_script
-rwx------ 1 ignatz   staff    6023 Aug  5 12:06 my_script

特殊なファイルアクセス権を絶対モードで変更する方法

ファイルまたはディレクトリの所有者でない場合は、スーパーユーザーになるか、同等の役割を引き受けます。

現在の所有者またはスーパーユーザー能力を持つユーザーだけが、chmod コマンドを使用してファイルまたはディレクトリの所有者を変更できます。

特殊なアクセス権を絶対モードで変更します。
% chmod nnnn filename
nnnn

ファイルまたはディレクトリのアクセス権を変更する 8 進数値を指定します。一番左端の 8 進数値で、ファイルに特殊なアクセス権を設定します。特殊なアクセス権に有効な 8 進数値の一覧は、表 6–6 を参照してください。

filename

ファイルまたはディレクトリを指定します。

注 –
chmod コマンドを使用して ACL エントリを持つファイルのグループアクセス権を変更する場合、グループアクセス権と ACL マスクの両方が新しいアクセス権に変更されます。新しい ACL マスクのアクセス権は、そのファイル上に ACL エントリを持つ追加ユーザーおよびグループのアクセス権を変更する場合があるので注意が必要です。getfacl コマンドを使用して、すべての ACL エントリに適切なアクセス権が設定されていることを確認してください。詳細は、getfacl(1) のマニュアルページを参照してください。

ファイルのアクセス権が変更されていることを確認します。
% ls -l filename

例 6–5 絶対モードによる特殊なファイルアクセス権の設定

次の例は、dbprog ファイルに setuid のアクセス権を設定します。

# chmod 4555 dbprog
# ls -l dbprog
-r-sr-xr-x   1 db     staff        12095 May  6 09:29 dbprog

次の例では、dbprog2 ファイルに setgid のアクセス権を設定します。

# chmod 2551 dbprog2
# ls -l dbprog2
-r-xr-s--x   1 db     staff       24576 May  6 09:30 dbprog2

次の例では、public_dir ディレクトリにスティッキービットのアクセス権を設定します。

# chmod 1777 public_dir
# ls -ld public_dir
drwxrwxrwt   2 ignatz   staff          512 May 15 15:27 public_dir

ACL による UFS ファイルの保護 (作業マップ)

次の作業マップは、UFS ファイルの ACL を表示する、ACL を変更する、ほかのファイルへ ACL をコピーするといった作業について説明した箇所を示しています。

作業	参照先
ファイルに ACL が存在するかを確認します	「ファイルに ACL が設定されているかどうかを検査する方法」
ファイルに ACL を追加します	「ファイルに ACL エントリを追加する方法」
ACL をコピーします	「ACL をコピーする方法」
ACL を変更します	「ファイルの ACL エントリを変更する方法」
ファイルから ACL を削除します	「ファイルから ACL エントリを削除する方法」
ファイルの ACL を表示します	「ファイルの ACL エントリを表示する方法」

ファイルに ACL が設定されているかどうかを検査する方法

ファイルに ACL が設定されているかをチェックします。
% ls -l filename
filename には、ファイルまたはディレクトリを指定します。

出力のモードフィールドの右側にプラス記号 (+) が表示されているときは、そのファイルに ACL が設定されています。

注 –
UNIX ファイルアクセス権を超える ACL エントリを追加しない限り、ファイルの ACL は「弱い」とみなされ、プラス記号 (+) は表示されません。

例 6–6 ファイルに ACL が設定されているかどうかを検査する

次の例では、ch1.sgm ファイルに ACL が設定されています。ACL は、モードフィールドの右側にあるプラス記号 (+) で示されています。

% ls -l ch1.sgm
-rwxr-----+  1 stacey   techpubs      167 Nov 11 11:13 ch1.sgm

ファイルに ACL エントリを追加する方法

setfacl コマンドを使用してファイルの ACL を設定します。
% setfacl -s user::perms,group::perms,other:perms,mask:perms,acl-entry-list filename ...
-s

ファイルに対して ACL を設定します。すでに ACL が設定されている場合、新しい ACL に置き換えます。このオプションには、少なくとも user::、group::、および other:: のエントリを指定する必要があります。

user::perms

所有者のアクセス権を指定します。

group::perms

グループメンバーのアクセス権を指定します。

other:perms

所有者またはグループのメンバー以外のユーザーのアクセス権を指定します。

mask:perms

ACL マスクのアクセス権を指定します。マスクは、ユーザー (所有者以外) とグループに許される最大アクセス権を示します。

acl-entry-list

ファイルまたはディレクトリ上で特定のユーザーとグループに設定する 1 つまたは複数の ACL エントリのリストを指定します。ディレクトリ上でデフォルトの ACL エントリを設定することもできます。有効な ACL エントリについては、表 6–7 と表 6–8 を参照してください。

filename ...

ACL を設定する 1 つまたは複数のファイルまたはディレクトリを指定します。filename が複数ある場合は、スペースで区切ります。

注意 –
すでにファイル上に ACL が存在する場合、-s オプションを指定すると、ACL 全体が新しい ACL に置き換えられます。

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

ACL (ACL エントリ) がファイルに設定されたことを確認します。
% getfacl filename
詳細は、「ファイルに ACL が設定されているかどうかを検査する方法」を参照してください。

例 6–7 ファイルの ACL を設定する

次の例では、ch1.sgm ファイルのアクセス権を設定しています。所有者には読み取り権と書き込み権が設定され、グループには読み取り専用権が設定され、その他のユーザーには何も設定されません。また、ユーザー anusha にはこのファイルの読み取り権および書き込み権が与えられ、ACL マスクには読み取り権および書き込み権が設定されます。これは、ユーザーやグループは実行権を持たないことを意味します。

% setfacl -s user::rw-,group::r--,other:---,mask:rw-,user:anusha:rw- ch1.sgm
% ls -l
total 124
-rw-r-----+  1 stacey  techpubs   34816 Nov 11 14:16 ch1.sgm
-rw-r--r--   1 stacey  techpubs   20167 Nov 11 14:16 ch2.sgm
-rw-r--r--   1 stacey  techpubs    8192 Nov 11 14:16 notes
% getfacl ch1.sgm
# file: ch1.sgm
# owner: stacey
# group: techpubs
user::rw-
user:anusha:rw-    #effective:rw-
group::r--         #effective:r--
mask:rw-
other:---

次の例では、ch2.sgm ファイルのアクセス権を設定します。所有者には読み取り権、書き込み権、および実行権が設定され、グループには読み取り専用権が設定され、その他のユーザーには何も設定されません。また、ACL マスクには読み取り権が設定されます。さらに、ユーザー anusha には読み取り権と書き込み権が与えられます。ただし、ACL マスクの設定により、anusha のアクセス権は読み取り専用です。

% setfacl -s u::7,g::4,o:0,m:4,u:anusha:7 ch2.sgm
% getfacl ch2.sgm
# file: ch2.sgm
# owner: stacey
# group: techpubs
user::rwx
user:anusha:rwx         #effective:r--
group::r--              #effective:r--
mask:r--
other:---

ACL をコピーする方法

getfacl の出力先を変更することにより、ファイルの ACL をほかのファイルへコピーします。
% getfacl filename1 | setfacl -f - filename2
filename1

ACL のコピー元ファイルを指定します

filename2

ACL のコピー先ファイルを指定します

例 6–8 ACL をコピーする

次の例では、ch2.sgm の ACL が ch3.sgm にコピーされます。

% getfacl ch2.sgm | setfacl -f - ch3.sgm

ファイルの ACL エントリを変更する方法

setfacl コマンドを使用してファイルの ACL エントリを変更します。
% setfacl -m acl-entry-list filename ...
-m

既存の ACL エントリを変更します。

acl-entry-list

ファイルまたはディレクトリで変更する 1 つまたは複数の ACL エントリのリストを指定します。ディレクトリのデフォルト ACL エントリを変更することもできます。有効な ACL エントリについては、表 6–7 と表 6–8 を参照してください。

filename ...

1 つまたは複数のファイルまたはディレクトリを空白で区切って指定します。

ファイルの ACL エントリが変更されたことを確認します。
% getfacl filename

例 6–9 ファイルの ACL エントリを変更する

次の例では、ユーザー anusha のアクセス権を読み取りおよび書き込みに変更します。

% setfacl -m user:anusha:6 ch3.sgm
% getfacl ch3.sgm
# file: ch3.sgm
# owner: stacey
# group: techpubs
user::rw-				
user::anusha:rw-        #effective:r--
group::r-               #effective:r--
mask:r--
other:r-

次の例では、book ディレクトリのデフォルトアクセス権を変更します。グループ staff のデフォルトのアクセス権を読み取りに変更し、さらに、ACL マスクのデフォルトアクセス権を読み取りおよび書き込みに変更します。

% setfacl -m default:group:staff:4,default:mask:6 book

ファイルから ACL エントリを削除する方法

ファイルから ACL エントリを削除します。
% setfacl -d acl-entry-list filename ...
-d

指定した ACL エントリを削除します。

acl-entry-list

ファイルまたはディレクトリから (アクセス権を指定せずに) 削除する ACL エントリのリストを指定します。特定のユーザーとグループの ACL エントリとデフォルトの ACL エントリ以外は削除できません。有効な ACL エントリについては、表 6–7 と表 6–8 を参照してください。

filename ...

1 つまたは複数のファイルまたはディレクトリを空白で区切って指定します。

setfacl -s コマンドを使用してファイルのすべての ACL エントリを削除してから、指定した新しい ACL エントリで置き換えることもできます。

ファイルから ACL エントリが削除されたことを確認します。
% getfacl filename

例 6–10 ファイルから ACL エントリを削除する

次の例では、ch4.sgm ファイルからユーザー anusha を削除します。

% setfacl -d user:anusha ch4.sgm

ファイルの ACL エントリを表示する方法

getfacl コマンドを使用してファイルの ACL エントリを表示します。
% getfacl [-a | -d] filename ...
-a

指定したファイルまたはディレクトリのファイル名、所有者、グループ、ACL エントリを表示します。

-d

指定したディレクトリのファイル名、所有者、グループ、デフォルトの ACL エントリ (存在する場合) を表示します。

filename ...

1 つまたは複数のファイルまたはディレクトリを空白で区切って指定します。

複数のファイル名をコマンド行に指定した場合は、各 ACL エントリの間に空白行が表示されます。

例 6–11 ファイルの ACL エントリを表示する

次の例は、ch1.sgm ファイルのすべての ACL エントリを示します。ユーザーエントリとグループエントリの隣りの #effective: は、ACL マスクによって変更されたあとのアクセス権の設定を示します。

% getfacl ch1.sgm

# file: ch1.sgm
# owner: stacey
# group: techpubs
user::rw-
user:anusha:r-        #effective:r--
group::rw-            #effective:rw-
mask:rw-
other:---

次の例は、book ディレクトリのデフォルトの ACL エントリを示します。

% getfacl -d book

# file: book
# owner: stacey
# group: techpubs
user::rwx
user:anusha:r-x       #effective:r-x
group::rwx            #effective:rwx
mask:rwx
other:---
default:user::rw-
default:user:anusha:r--
default:group::rw-
default:mask:rw-
default:other:---

セキュリティーリスクのあるプログラムからの保護 (作業マップ)

次の作業マップは、リスクのある実行ファイルをシステム内に見つける作業や、プログラムが実行可能スタックを不正利用しないように防ぐ作業などの操作を説明した箇所を示しています。

タスク	説明	参照先
特殊なアクセス権を持つファイルを見つけます	`setuid` ビットがセットされているが、`root` ユーザーによって所有されていないというファイルを見つけます。	「特殊なファイルアクセス権が設定されたファイルを見つける方法」
実行可能スタックがオーバーフローしないように防ぎます	プログラムが実行可能スタックを不正に利用しないように防ぎます。	「プログラムが実行可能スタックを使用できないようにする方法」
実行可能スタックのメッセージがログに記録されるのを防ぎます	実行可能スタックのメッセージのログ記録を無効にします。	例 6–13

特殊なファイルアクセス権が設定されたファイルを見つける方法

管理者はシステムを監視し、プログラム上で承認を得ることなく setuid アクセス権および setgid アクセス権が使用されていないかをチェックする必要があります。setuid アクセス権と setgid アクセス権を使用すると、通常のユーザーでもスーパーユーザー権限を取得できてしまいます。疑わしい実行可能ファイルによって、所有権が root または bin ではなく、通常のユーザーに与えられることがあります。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

find コマンドを使用して setuid アクセス権が設定されているファイルを検索します。
# find directory -user root -perm -4000 -exec ls -ldb {} \; >/tmp/filename
find directory

指定したディレクトリから始めて、マウントされているすべてのパスを検査します。ディレクトリとしてルート (/)、sys、bin、または mail を指定できます。

-user root

root が所有するファイルを表示します。

-perm -4000

アクセス権が 4000 に設定されているファイルだけを表示します。

-exec ls -ldb

find コマンドの出力を ls -ldb 形式で表示します。

>/tmp/filename

find コマンドの結果が書き込まれるファイルです。

結果を /tmp/filename に出力します。
# more /tmp/filename
setuid アクセス権の詳細については、「setuid アクセス権」を参照してください。

例 6–12 `setuid` アクセス権が設定されているファイルを検索する

次の例の出力は、rar というユーザーが /usr/bin/sh のコピーを作成し、そのアクセス権を root への setuid に設定したことを示しています。この結果、/usr/rar/bin/sh プログラムは root アクセス権で実行されます。

この出力は、将来の参考にするため、/tmp ディレクトリからファイルを移動することで保存されました。

# find / -user root -perm -4000 -exec ls -ldb {} \; > /var/tmp/ckprm
# cat /var/tmp/ckprm
-r-sr-xr-x 1 root bin 38836 Aug 10 16:16 /usr/bin/at
-r-sr-xr-x 1 root bin 19812 Aug 10 16:16 /usr/bin/crontab
---s--x--x 1 root sys 46040 Aug 10 15:18 /usr/bin/ct
-r-sr-xr-x 1 root sys 12092 Aug 11 01:29 /usr/lib/mv_dir
-r-sr-sr-x 1 root bin 33208 Aug 10 15:55 /usr/lib/lpadmin
-r-sr-sr-x 1 root bin 38696 Aug 10 15:55 /usr/lib/lpsched
---s--x--- 1 root rar 45376 Aug 18 15:11 /usr/rar/bin/sh
-r-sr-xr-x 1 root bin 12524 Aug 11 01:27 /usr/bin/df
-rwsr-xr-x 1 root sys 21780 Aug 11 01:27 /usr/bin/newgrp
-r-sr-sr-x 1 root sys 23000 Aug 11 01:27 /usr/bin/passwd
-r-sr-xr-x 1 root sys 23824 Aug 11 01:27 /usr/bin/su
# mv /var/tmp/ckprm /export/sysreports/ckprm

プログラムが実行可能スタックを使用できないようにする方法

実行可能スタックのセキュリティーリスクについては、「実行可能ファイルを原因とするセキュリティーへの悪影響を防止する」を参照してください。

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

/etc/system ファイルを編集し、次の行を追加します。
set noexec_user_stack=1

システムを再起動します。
# init 6

例 6–13 実行可能スタックメッセージのログ記録を無効にする

この例では、実行可能スタックメッセージのログ記録が無効にされ、続いてシステムの再起動が行われます。

# cat /etc/system
set noexec_user_stack=1
set noexec_user_stack_log=0
# init 6

第 7 章自動セキュリティー拡張ツールの使用 (手順)

この章では、自動セキュリティー拡張ツール (ASET) を使用して、システムファイルおよびディレクトリへのアクセスを監視または制限する方法について説明します。

この章で説明する手順は次のとおりです。

ASET よりも広汎なツールとしては、Sun Security Toolkit を使用してください。Sun Security Toolkit は、Solaris システムの強化と最小化のためのフレームワークを提供します。このキットには、プロファイリングツール、レポートツール、取り消し機能などが含まれます。このツールキットは無料であり、Sun の Web サイト http://www.sun.com/software/security/jass からダウンロードできます。この Web サイトでは、関連するオンラインドキュメントもリンクされています。

自動セキュリティー拡張ツール (ASET)

Solaris オペレーティングシステムには、ASET が組み込まれています。ASET を使用すると、ほかの場合には手動で実行する作業が自動的に実行され、システムのセキュリティーを監視して制御できます。

ASET セキュリティーパッケージには、システムのセキュリティーを制御して監視できるように、自動管理ツールが組み込まれています。ASET を実行するセキュリティーレベルには、低レベル、中レベル、または高レベルを指定できます。上のレベルほど、ASET のファイル制御機能が増え、ファイルアクセスは減少し、システムセキュリティーが厳しくなります。

ASET には 7 つのタスクがあり、各タスクがシステムファイルに対して特定の検査と調整を行います。ASET のタスクはファイルのアクセス権を厳しくし、重要なシステムファイルの内容にセキュリティー上の弱点がないかどうかを確認して、重要な領域を監視します。ASET では、ゲートウェイシステムとして機能するシステムにファイアウォールシステムの基本要件を適用し、ネットワークも保護できます。詳細は、「ファイアウォールの設定」を参照してください。

ASET は、構成用のマスターファイルを使用します。マスターファイルやレポートなどの ASET ファイルは、/usr/aset ディレクトリにあります。これらのファイルは、サイトの特定の要件に合わせて変更できます。

各タスクは、検出されたセキュリティー上の弱点と、タスクがシステムファイルに対して行った変更を示すレポートを生成します。最上位のセキュリティーレベルで実行すると、ASET はシステムセキュリティー上のすべての弱点を変更しようとします。潜在的なセキュリティー問題を解決できない場合、ASET は問題の存在を報告します。

ASET セッションを起動するには、/usr/aset/aset コマンドを対話的に使用します。ASET を定期的に実行する場合は、crontab ファイルにエントリを指定します。

ASET のタスクはディスクをかなり使用するため、通常の動作の妨げになることがあります。システム性能への影響を最小限度に抑えるために、24 時間ごとまたは 48 時間ごとに深夜など、システムの稼働レベルがもっとも低いときに ASET を実行するようにスケジュールしてください。

ASET のセキュリティーレベル

ASET は、低、中、高の 3 つのセキュリティーレベルのいずれかで動作するように設定できます。上のレベルほど、ASET のファイル制御機能が増え、ファイルアクセスが減少し、システムのセキュリティーが厳しくなります。これらの機能には、ユーザーによるファイルアクセスを制限せずにシステムセキュリティーを監視する最低レベルから、システムが完全にセキュリティー保護される最高レベルまで、アクセス権が段階的に厳しくなります。

次の表で、この 3 つのセキュリティーレベルの概要について説明します。

セキュリティーレベル	説明
低	システムファイルの属性が標準リリース値に設定されることが保証されます。ASET は複数の検査を実行し、セキュリティー上の潜在的な弱点を報告します。低レベルでは、ASET は動作せず、システムサービスは影響を受けません。
中	ほとんどの環境で十分にセキュリティーが制御されます。ASET はシステムファイルとパラメータの設定の一部を変更し、システムアクセスを制限し、セキュリティー上の攻撃によるリスクを減らします。ASET は、セキュリティー上の弱点と、アクセスを制限するために行った変更を報告します。中レベルでは、ASET はシステムサービスに影響しません。
高	システムに高度なセキュリティーが適用されます。ASET は多数のシステムファイルとパラメータの設定を調整して、アクセス権を最小限度に抑えます。ほとんどのシステムアプリケーションとコマンドは、正常に機能します。ただし、高レベルでは、セキュリティーがほかのシステムの動作より優先されます。

注 –

管理者がセキュリティーレベルを下げない限り、ASET によってファイルのアクセス権が変更されてファイルの安全性が低くなるということはありません。管理者が意図的にシステムを ASET 実行前の設定に戻すという場合もあります。

ASET のタスク一覧

この節では、ASET のタスクについて説明します。管理者は、ASET の各タスクを理解しておく必要があります。ASET の目的と処理、ASET が影響を与えるシステムコンポーネントなどを理解することで、レポート内容を判断し、効果的に活用できます。

ASET のレポートファイルには、各 ASET タスクで検出された問題をできるだけ詳細に記述するメッセージが含まれています。これらのメッセージによって、問題を診断して解決できます。ただし、ASET を活用するには、システム管理とシステム構成要素を全般的に理解していることが前提となります。システム管理者になったばかりのユーザーは、ほかの Solaris システム管理マニュアルを参照することをお勧めします。また、関連するマニュアルページを参照して、ASET 管理の概要を把握するとよいでしょう。

taskstat ユーティリティーは、完了したタスクとまだ実行中のタスクを識別します。完了したタスクごとにレポートファイルが生成されます。taskstat ユーティリティーの詳細は、taskstat(1M) を参照してください。

システムファイルのアクセス権の調整

このタスクでは、システムファイルのアクセス権を指定したセキュリティーレベルに設定します。このタスクは、システムのインストール時に実行されます。以前に設定したレベルをあとから変更する場合は、このタスクを再度実行してください。低セキュリティーレベルでは、アクセス権は開放型の情報共有環境に適した値に設定されています。中セキュリティーレベルでは、アクセス権はほとんどの環境に十分なセキュリティーが適用される程度に厳しくなります。高セキュリティーレベルでは、アクセス権がもっとも厳しく制限されます。

このタスクによってシステムファイルのアクセス権やパラメータの設定に加えられた変更は、tune.rpt ファイル内にレポートされます。ASET がアクセス権を設定するときに調整するファイルの例は、「調整ファイルの例」を参照してください。

システムファイルの確認

このタスクでは、システムファイルが検査され、各ファイルと、マスターファイル内のそれらの記述とが比較されます。マスターファイルは、ASET がこのタスクを実行するときに初めて作成されます。マスターファイルには、指定したセキュリティーレベルの checklist によって適用されるシステムファイル設定が含まれています。

ファイルが確認されるディレクトリのリストは、セキュリティーレベルごとに定義されます。デフォルトのリストを使用するか、レベルごとに異なるディレクトリを指定してリストを変更できます。

ファイルごとに次の条件が確認されます。

所有者とグループ
アクセス権ビット
サイズとチェックサム
リンク数
最終変更時刻

ASET によって矛盾が見つかると、cklist.rpt ファイルに記録されます。このファイルには、システムファイルのサイズ、アクセス権、およびチェックサムの値について、マスターファイルと比較した結果が入っています。

ユーザーとグループの確認

このタスクでは、ユーザーアカウントとグループの整合性と完全性が確認されます。このタスクは、passwd ファイルと group ファイル内の定義を使用します。ローカルパスワードファイルと、NIS または NIS+ パスワードファイルが検査されます。NIS+ のパスワードファイルの問題はレポートされますが、解決はされません。

このタスクでは、次の違反が検査されます。

重複名または重複 ID
正確でない形式のエントリ
パスワードが付いていないアカウント
無効なログインディレクトリ
アカウント nobody
空のグループパスワード
NIS サーバーまたは NIS+ サーバー上の /etc/passwd ファイル内のプラス記号 (+)

矛盾は、usrgrp.rpt ファイル内にレポートされます。

システム構成ファイルの確認

このタスクでは、ASET はあらゆるシステムテーブルを検査します。テーブルのほとんどは /etc ディレクトリに入っています。

次のシステム構成ファイルが検査されます。

/etc/default/login
/etc/hosts.equiv
/etc/inetd.conf
/etc/aliases
/var/adm/utmpx
/.rhosts
/etc/vfstab
/etc/dfs/dfstab
/etc/ftpd/ftpusers

ASET は、これらのファイルに関して各種の検査と変更を実行し、問題を sysconf.rpt ファイル内にレポートします。

環境変数の確認

このタスクでは、スーパーユーザー用とその他のユーザー用の PATH 環境変数と UMASK 環境変数がどのように設定されているかを検査します。この検査のために、/.profile、/.login、および /.cshrc ファイルがチェックされます。

環境のセキュリティー状況を検査した結果は、env.rpt ファイル内にレポートされます。

`eeprom` の確認

このタスクでは、eeprom セキュリティーパラメータの値が検査され、適切なセキュリティーレベルに設定されていることを確認します。eeprom セキュリティーパラメータは、none、command、または full に設定できます。

ASET はこの設定を変更しませんが、推奨値を eeprom.rpt ファイル内にレポートします。

ファイアウォールの設定

このタスクでは、システムをネットワークリレーとして安全に使用できることが保証されます。「ファイアウォールシステム」で説明しているように、このタスクでは、ファイアウォール専用システムが設定され、内部ネットワークが外部の公共ネットワークから保護されます。このファイアウォールシステムでは、ネットワークが 2 つに分割されます。このとき、分割された各ネットワークは、互いに信頼されないネットワークとして通信します。ファイアウォールの設定タスクによって、インターネットプロトコル (IP) パケットを転送できなくなります。ファイアウォールによって、ルーティング情報も外部ネットワークから見えないように隠されます。

ファイアウォールのタスクはすべてのセキュリティーレベルで実行されますが、ファイアウォールとしての本来の機能は最上位レベルでのみ動作します。ASET を高セキュリティーレベルで実行するときでも、システムにはファイアウォール保護が不要であることがわかった場合は、asetenv ファイルを編集してファイアウォールタスクをはずすことができます。

行われた変更はすべて firewall.rpt ファイル内にレポートされます。

ASET 実行ログ

ASET を対話形式またはバックグラウンドで実行すると、実行ログが生成されます。デフォルトでは、ASET はログファイルを標準出力に生成します。実行ログは、ASET が指定された時刻に実行されたことを確認するもので、実行エラーメッセージも含まれています。aset -n コマンドを使用すると、ログを指定したユーザーに電子メールで配信できます。ASET オプションの一覧は、aset(1M) のマニュアルページを参照してください。

ASET 実行ログファイルの例

ASET running at security level low

Machine=example; Current time = 0325_08:00


aset: Using /usr/aset as working directory

Executing task list...
        firewall
        env
        sysconfig
        usrgrp
        tune
        cklist
        eeprom
All tasks executed. Some background tasks may still be running.

Run /usr/aset/util/taskstat to check their status:
     $/usr/aset/util/taskstat     aset_dir
Where aset_dir is ASET's operating directory, currently=/usr/aset

When the tasks complete, the reports can be found in:
     /usr/aset/reports/latest/*.rpt
You can view them by:
more /usr/aset/reports/latest/*.rpt

実行ログはまず、ASET が実行されたシステムと時刻を示します。次に、開始したタスクの一覧を表示します。

「ASET のタスク一覧」で説明しているように、ASET はこれらのタスクごとにバックグラウンド処理を呼び出します。タスクは開始されると実行ログに一覧表示されます。この一覧は、タスクの完了を示しているわけではありません。バックグラウンドタスクの状態を確認するには、taskstat コマンドを使用します。

ASET レポート

ASET タスクから生成されたすべてのレポートファイルは、ディレクトリ /usr/aset/reports の下のサブディレクトリに入っています。この節では、/usr/aset/reports ディレクトリの構造と、レポートファイルを管理するためのガイドラインについて説明します。

ASET は、指定されたサブディレクトリにレポートファイルを格納し、レポートの生成日時を反映させます。この規則によって、ASET を実行するたびに変わるシステムの状態が記録されたレコードを順番に追跡できます。これらのレポートを監視し、比較して、システムセキュリティーの状況を判断できます。

次の図に reports ディレクトリ構造の例を示します。

図 7–1 ASET `reports` ディレクトリの構造

/usr/aset ディレクトリの下にある reports ディレクトリの例です。

この例では、2 つのレポートサブディレクトリを示しています。

0124_01:00
0125_01:00

サブディレクトリ名は、レポートの生成日時を示します。各レポートサブディレクトリ名の形式は次のとおりです。

monthdate_hour:minute

この場合、month、date、hour、minute は、いずれも 2 桁の数値です。たとえば、0125_01:00 は 1 月 25 日の午前 1 時を表します。

2 つのレポートサブディレクトリには、それぞれ ASET を 1 度実行して、生成されたレポートの集合が含まれています。

latest ディレクトリは、常に最新レポートが入っているサブディレクトリを指すシンボリックリンクです。したがって、/usr/aset/reports/latest ディレクトリに移動すると、ASET で生成された最新レポートを見ることができます。このディレクトリには、最後に ASET を実行した各タスクのレポートファイルが入っています。

ASET レポートファイルの形式

各レポートファイルには、レポートを生成したタスクに基づいて名前が付けられます。次の表にタスクとそのレポートのリストを示します。

表 7–1 ASET のタスクと生成されるレポート


タスク	レポート
システムファイルのアクセス権の調整 (`tune`)	`tune.rpt`
システムファイルの確認 (`cklist`)	`cklist.rpt`
ユーザーとグループの確認 (`usrgrp`)	`usrgrp.rpt`
システム構成ファイルの確認 (`sysconf`)	`sysconf.rpt`
環境変数の確認 (`env`)	`env.rpt`
`eeprom` の確認 (`eeprom`)	`eeprom.rpt`
ファイアウォールの設定 (`firewall`)	`firewall.rpt`

各レポートファイル内で、メッセージの前後はバナー行で囲まれています。ASET の構成要素を誤って削除したり損傷したりすると、タスクが途中で終了することがあります。このような場合、通常はレポートファイルの末尾の方に、途中で終了した理由を示すメッセージが記録されています。

次にレポートファイル usrgrp.rpt の例を示します。

*** Begin User and Group Checking ***
 
Checking /etc/passwd ...
Warning! Password file, line 10, no passwd
:sync::1:1::/:/bin/sync
..end user check; starting group check ...
Checking /etc/group...
*** End User And group Checking ***

ASET レポートファイルの検査

ASET を最初に実行したときまたは再構成したときは、レポートファイルを詳細に検査する必要があります。再構成には、asetenv ファイル、masters サブディレクトリのマスターファイルを変更したり、ASET が動作するセキュリティーレベルを変更したりすることが含まれます。

このレポートには、ASET の再構成によって発生したエラーがすべて記録されます。レポートを詳しく確認すると、問題が発生した時点で対処して解決できます。

ASET レポートファイルの比較

構成上の変更やシステム更新がない期間中にレポートファイルを監視すると、レポートの内容が安定することがわかります。予期しなかった情報がレポートに含まれる場合は、diff ユーティリティーを使用してレポートを比較できます。

ASET マスターファイル

ASET のマスターファイル tune.high、tune.low、tune.med、およびuid_aliases は、ディレクトリ /usr/aset/masters に入っています。ASET は、マスターファイルを使用してセキュリティーレベルを定義します。詳細は、asetmasters(4) のマニュアルページを参照してください。

調整ファイル

tune.low、tune.med、tune.high マスターファイルでは、利用できる ASET セキュリティーレベルが定義されます。各ファイルでは、各レベルのシステムファイルの属性が指定され、比較と参照に使用されます。

`uid_aliases` ファイル

uid_aliases ファイルには、同じユーザー ID (UID) を共有する複数のユーザーアカウントの一覧が入っています。このような複数のユーザーアカウントがあると責任の所在があいまいになるため、通常は ASET が警告を出します。uid_aliases ファイル内で例外を一覧すると、この規則に例外を設けることができます。重複する UID を持つ passwd ファイル内のエントリを uid_aliases ファイル内で指定しておくと、これらのエントリは ASET でレポートされません。

複数のユーザーアカウントで同じ UID を共有しないでください。他の方法で目的を達成することを検討する必要があります。たとえば、複数のユーザーにアクセス権一式を共有させたい場合は、グループアカウントを作成できます。役割を作成することも可能です。UID の共有は、最後の手段としてほかの方法では目的を達成できない場合にだけ使用すべきです。

UID_ALIASES 環境変数を使用すると、別の別名ファイルを指定できます。デフォルトファイルは /usr/aset/masters/uid_aliases です。

確認リストファイル

システムファイルの確認に使用されるマスターファイルは、初めて ASET を実行するときか、セキュリティーレベルの変更後に ASET を実行するときに生成されます。

次の環境変数には、このタスクで確認するファイルを定義します。

CKLISTPATH_LOW
CKLISTPATH_MED
CKLISTPATH_HIGH

ASET 環境ファイル (`asetenv`)

環境ファイル asetenv には、ASET タスクに影響する環境変数の一覧が入っています。一部の環境変数を変更すると、ASET の動作を修正することができます。asetenv ファイルの詳細は、asetenv(4) のマニュアルページを参照してください。

ASET の構成

この節では、ASET を構成する方法と、ASET が稼働する環境について説明します。

ASET の管理と構成は最小限ですみ、ほとんどの場合はデフォルト値で実行できます。ただし、ASET の処理や動作に影響する一部のパラメータを調整して、その特長を最大限に発揮させることができます。デフォルト値を変更する前に、ASET の機能と、ASET がシステムの構成要素に及ぼす影響を理解しておく必要があります。

ASET は、次の 4 つの構成ファイルに依存してタスクの動作を制御します。

/usr/aset/asetenv
/usr/aset/masters/tune.low
/usr/aset/masters/tune.med
/usr/aset/masters/tune.high

環境ファイルの変更 (`asetenv`)

/usr/aset/asetenv ファイルには、2 つのメインセクションがあります。

ユーザーが構成可能な環境変数セクション
内部環境変数セクション

ユーザーが構成可能なパラメータセクションは変更できます。ただし、内部環境変数セクションの設定は内部使用だけに限られ、変更できません。

ユーザーが構成可能なセクションのエントリを編集して、次の操作を行うことができます。

実行するタスクを選択する
システムファイルの確認タスク用のディレクトリを指定する
ASET の実行スケジュールを指定する
UID 別名ファイルを指定する
確認対象を NIS+ テーブルまで拡張する

実行するタスクの選択: `TASKS`

ASET が実行する各タスクでは、システムセキュリティーの特定の領域が監視されます。ほとんどのシステム環境では、すべてのタスクでバランスがとれたセキュリティー範囲を提供する必要があります。ただし、1 つまたは複数のタスクを除外しても構いません。

たとえば、ファイアウォールタスクはすべてのセキュリティーレベルで実行されますが、本来の機能は最上位レベルでのみ動作します。ASET を高セキュリティーレベルで実行する場合でも、ファイアウォール保護は不要なときがあります。

管理者は、ファイアウォール機能を使用しないで高セキュリティーレベルで実行するように ASET を設定できます。このためには、asetenv ファイル内で環境変数の TASKS の一覧を編集します。デフォルトでは、TASKS の一覧にはすべての ASET タスクが含まれています。特定のタスクを削除するには、このファイルからそのタスクに関連する変数を削除します。この場合は、一覧から firewall 環境変数を削除することになります。次の一覧に ASET を実行すると、除外したタスクは実行されません。

次の例では、すべての ASET タスクが含まれる TASKS 一覧が表示されます。

TASKS=”env sysconfig usrgrp tune cklist eeprom firewall”

システムファイル確認タスクのディレクトリの指定: `CKLISTPATH`

システムファイル確認では、選択したシステムディレクトリ内のファイルの属性が確認されます。次の環境変数を使用して、どのディレクトリを確認するかを定義できます。

CKLISTPATH_LOW 変数は、低セキュリティーレベルで確認されるディレクトリを定義します。CKLISTPATH_MED と CKLISTPATH_HIGH 環境変数は、それぞれ中セキュリティーレベルと高セキュリティーレベルで同じように機能します。

セキュリティーレベルの低い環境変数を定義したディレクトリの一覧は、次にセキュリティーレベルの高い環境変数を定義したディレクトリの一覧のサブセットである必要があります。たとえば、CKLISTPATH_LOW に指定したディレクトリはすべて CKLISTPATH_MED に含めます。同様に、CKLISTPATH_MED に指定したディレクトリはすべて CKLISTPATH_HIGH に含めます。

これらのディレクトリに対して実行される確認は再帰的ではありません。ASET では、環境変数に明示的に指定されているディレクトリだけが確認されます。ASET では、そのサブディレクトリは確認されません。

これらの環境変数の定義を編集して、ASET に確認させたいディレクトリを追加または削除できます。これらの確認リストは、通常は毎日変更がないシステムファイルにのみ便利なことに注意してください。たとえば、一般にユーザーのホームディレクトリは動的な変化が大きすぎるので、確認リストの候補にはなりません。

ASET の実行スケジュールの指定: `PERIODIC_SCHEDULE`

ASET は対話形式で実行できます。また、-p オプションを使用して、ASET タスクの実行を指定した時刻に要求することもできます。ASET は、システム需要が少ないときに定期的に実行できます。たとえば、ASET は PERIODIC_SCHEDULE を照会して、ASET タスクの実行頻度と実行時刻を判断します。ASET を定期的に実行するように設定する方法については、「ASET を定期的に実行する方法」を参照してください。

PERIODIC_SCHEDULE の形式は、crontab エントリの形式と同じです。詳細は、crontab(1) のマニュアルページを参照してください。

別名ファイルの指定: `UID_ALIASES`

UID_ALIASES 変数は、共有 UID がリストされる別名ファイルを指定します。デフォルトファイルは /usr/aset/masters/uid_aliases です。

確認範囲を NIS+ テーブルまで拡張: `YPCHECK`

YPCHECK 環境変数は、ASET でシステム構成ファイルテーブルも確認するかどうかを指定します。YPCHECK はブール型変数です。YPCHECK には true または false しか指定できません。デフォルト値は false で、NIS+ テーブルの確認は無効になっています。

この環境変数の機能を理解するために、passwd ファイルに与える影響を考えてみてください。false に設定すると、ASET はローカルの passwd ファイルを確認します。true に設定すると、NIS+ の passwd テーブル内でシステムのドメインも確認されます。

注 –

ASET ではローカルファイルが自動的に修復されますが、NIS+ テーブル内の潜在的な問題はレポートされるだけです。NIS+ テーブルの変更は行いません。

調整ファイルの変更

ASET は、3 つのマスター調整ファイル tune.low、tune.med、tune.high を使用して、重要なシステムファイルへのアクセス制限を緩めたり厳しくしたりします。この 3 つのマスターファイルは /usr/aset/masters ディレクトリにあり、環境に合わせて調整できます。詳細は、「調整ファイルの例」を参照してください。

tune.low ファイルは、アクセス権をデフォルトのシステム設定に適した値に設定します。tune.med ファイルは、これらのアクセス権をさらに制限し、tune.low に含まれていないエントリを追加します。tune.high ファイルは、アクセス権をさらに厳しく制限します。

注 –

調整ファイル内の設定を変更するには、ファイルのエントリを追加または削除します。アクセス権を現在の設定よりも制限が緩やかになるような値に設定しても意味がありません。システムセキュリティーを下位レベルに下げない限り、ASET がアクセス権の制限を緩和したことになりません。

ASET で変更されたシステムファイルの復元

ASET を初めて実行すると、元のシステムファイルが保存され保管されます。aset.restore ユーティリティーは、これらのファイルを復元します。また、ASET を定期的に実行するようにスケジュール指定している場合は、そのスケジュールを解除します。aset.restore コマンドは、ASET の操作ディレクトリ /usr/aset に入っています。

システムファイルに適用した変更は、aset.restore コマンドを実行すると失われます。

aset.restore コマンドは、次のような場合に使用します。

ASET の変更を削除して元のシステムを復元する場合。

ASET を永久に無効にする場合は、以前にスーパーユーザーの crontab に aset コマンドが追加されていれば、cron スケジュールから ASET を削除できます。cron を使用して自動実行を削除する方法については、「ASET の定期的な実行を停止する方法」を参照してください。
ASET を短期間実行したあとに、元のシステム状態を復元する場合。
一部の主要なシステム機能が正常に動作せず、ASET が原因だと思われる場合。

NFS システムを使用するネットワーク操作

通常、ネットワークの一部となっているシステム上でも、ASET はスタンドアロンモードで使用されます。スタンドアロンシステムのシステム管理者は、システムのセキュリティーを守る必要があるため、ASET の稼働と管理を通してシステム保護に当たります。

また、ASET は NFS 分散環境でも使用できます。ネットワーク管理者は、すべてのクライアントの各種管理タスクのインストール、実行、管理を担当します。複数のクライアントシステムにわたって ASET を管理しやすくするため、すべてのクライアントに一括して適用されるような構成変更を行えます。変更を一括して適用すると、各システムにログインして構成変更を繰り返す必要がなくなります。

ネットワークシステム上で ASET の設定方法を決めるときには、セキュリティー制御を誰に行わせるかを考える必要があります。たとえば、ユーザーに各自のシステムにおけるセキュリティーの一部を制御させることができます。また、セキュリティー制御の責任を 1 つにまとめることもできます。

各セキュリティーレベルの一括構成の提供

複数のネットワーク構成を設定する場合があります。たとえば、低セキュリティーレベルに設定したクライアント用に 1 つ、中レベルのクライアント用に 1 つ、さらに高レベルのクライアント用に 1 つのネットワーク構成を設定できます。

セキュリティーレベルごとに個別の ASET ネットワーク構成を作成する場合は、サーバー上に 3 つの ASET 構成を作成できます。この場合、レベルごとに 1 つずつ構成を作成することになります。各構成を該当するセキュリティーレベルのクライアントにエクスポートします。3 つの構成すべてに共通の ASET 構成要素は、リンクを使用して共有できます。

ASET レポートの収集

管理者は、サーバー上に ASET 構成要素を集中できるだけでなく、サーバー上に集中ディレクトリを設定してすべてのレポートを収集できます。クライアントは、スーパーユーザー特権のあるなしにかかわらずサーバーにアクセスできます。収集メカニズムを設定する方法については、「サーバー上で ASET レポートを収集する方法」を参照してください。

サーバー上でレポートを収集するように設定すると、すべてのクライアントに関するレポートを 1 箇所で検討できます。この方法は、クライアントがスーパーユーザー特権を持っているかどうかに関係なく使用できます。また、ユーザーに各自の ASET レポートを監視させたい場合は、ローカルシステム上にレポートディレクトリを残しておくこともできます。

ASET 環境変数

次の表にASET 環境変数と各変数で指定する値を示します。

ASETDIR: ASET の作業ディレクトリを指定します
ASETSECLEVEL: セキュリティーレベルを指定します
PERIODIC_SCHEDULE: 定期的なスケジュールを指定します
TASKS: 実行する ASET タスクを指定します
UID_ALIASES: 別名ファイルを指定します
YPCHECK: NIS マップと NIS+ テーブルを確認するかどうかを指定します
CKLISTPATH_LOW: 低セキュリティー用のディレクトリリストです
CKLISTPATH_MED: 中セキュリティー用のディレクトリリストです
CKLISTPATH_HIGH: 高セキュリティー用のディレクトリリストです

次の節で示す環境変数は、/usr/aset/asetenv ファイルにあります。ASETDIR と ASETSECLEVEL 変数はオプションです。これらの変数は、シェルから /usr/aset/aset コマンドを使用しなければ設定できません。他の環境変数は、ファイルを編集して設定できます。

`ASETDIR` 環境変数

ASETDIR は、ASET の作業ディレクトリを指定します。

C シェルからは、次のように入力します。

% setenv ASETDIR pathname

Bourne シェルまたは Korn シェルからは、次のように入力します。

$ ASETDIR=pathname
$ export ASETDIR

pathname には ASET 作業ディレクトリの完全パス名を設定します。

`ASETSECLEVEL` 環境変数

ASETSECLEVEL 変数は、ASET タスクが実行されるセキュリティーレベルを指定します。

C シェルからは、次のように入力します。

% setenv ASETSECLEVEL level

Bourne シェルまたは Korn シェルからは、次のように入力します。

$ ASETSECLEVEL=level
$ export ASETSECLEVEL

上記のコマンドで、level を次のいずれかに設定できます。

low: 低セキュリティーレベル
med: 中セキュリティーレベル
high: 高セキュリティーレベル

`PERIODIC_SCHEDULE` 環境変数

PERIODIC_SCHEDULE の値の形式は、crontab ファイルと同じです。変数の値は二重引用符で囲んだ 5 つのフィールドからなる文字列として指定します。各フィールドは次のように 1 つの空白文字で区切ります。

"minutes hours day-of-month month day-of-week"

minutes hours: 開始時刻を (0 から 59) と時間 (0 から 23) で指定します。
day-of-month: ASET を実行する日付を 1 から 31 の値で指定します。
month: ASET を実行する月を 1 から 12 の値で指定します。
day-of-week: ASET を実行する曜日を 0 から 6 の値で指定します。日曜日が 0 になります。

ASET の定期的なスケジュールを作成するときは、次の規則が適用されます。

どのフィールドも、値のリストをコンマで区切って指定できます。
値を数値または範囲として指定できます。範囲は、一対の数値をハイフンで結合して指定します。範囲に含まれるすべての時刻に ASET タスクを実行することを示します。
どのフィールドも、値としてアスタリスク(*) を指定できます。アスタリスクを指定すると、そのフィールドで使用できるすべての値を指定したことになります。

PERIODIC_SCHEDULE 変数のデフォルトエントリでは、ASET が毎日深夜 12:00 に実行されます。

PERIODIC_SCHEDULE=”0 0 * * *”

`TASKS` 環境変数

TASKS 変数は、ASET で実行されるタスクを一覧表示します。デフォルトでは、7 つのタスクが次のようにすべて一覧されます。

TASKS=”env sysconfig usrgrp tune cklist eeprom firewall”

`UID_ALIASES` 環境変数

UID_ALIASES 変数は、別名ファイルを指定します。別名ファイルがあると、ASET は使用可能な複数の別名の一覧をこのファイル内で照会します。書式は UID_ALIASES=pathname です。pathname は、別名ファイルのフルパス名です。

デフォルトは次のとおりです。

UID_ALIASES=${ASETDIR}/masters/uid_aliases

`YPCHECK` 環境変数

YPCHECK 変数は、システムテーブルを確認するタスクを拡張して NIS または NIS+ テーブルを含めます。YPCHECK 変数はブール変数なので、true または false に設定されます。

デフォルトは false で、ローカルシステムテーブルが確認されます。

YPCHECK=false

`CKLISTPATH_level` 環境変数

3 つの確認リストパス変数は、システムファイルの確認タスクで確認されるディレクトリを一覧表示します。次の変数の定義は、デフォルトで設定されます。これらの定義は、さまざまなレベルの変数の関係を示しています。

CKLISTPATH_LOW=${ASETDIR}/tasks:${ASETDIR}/util:${ASETDIR}/masters:/etc
CKLISTPATH_MED=${CKLISTPATH_LOW}:/usr/bin:/usr/ucb
CKLISTPATH_HIGH=${CKLISTPATH_MED}:/usr/lib:/sbin:/usr/sbin:/usr/ucblib

確認リストパス環境変数の値は、シェルパス変数の値と似ています。シェルパス変数と同様に、確認リストパス環境変数はディレクトリ名のリストです。ディレクトリ名はコロンで区切ります。等号 (=) を使用すると、変数名にその値を設定できます。

ASET ファイルの例

この節では、調整ファイルや別名ファイルなどの ASET ファイルの例を示します。

調整ファイルの例

ASET は 3 つの調整ファイルを管理します。調整ファイル内の各エントリは 1 行に入っています。エントリ内のフィールドの順序は次のとおりです。

pathname mode owner group type

pathname: ファイルのフルパス名
mode: アクセス権の設定を表す 5 桁の数値
owner: ファイルの所有者
group: ファイルのグループ
type: ファイルの形式

調整ファイルを編集するときは、次の規則が適用されます。

アスタリスク (*) や疑問符 (?) などの標準シェルワイルドカード文字をパス名に使用することにより、複数のファイルを参照できます。詳細は、sh(1) のマニュアルページを参照してください。
mode は、もっとも制限が緩やかな値を表します。現在の設定が指定した値よりもすでに厳しく制限されている場合、ASET はアクセス権の設定を緩和しません。たとえば、指定した値が 00777 の場合、00777 は常に現在の設定よりも緩やかな制限を表すため、アクセス権は変更されません。

このプロセスは、ASET がモード設定をどのように処理するかというものです。セキュリティーレベルのレベルが低いものに変更されるか、あるいは管理者が ASET を削除する場合は、別のプロセスとなります。セキュリティーレベルを前回の実行時よりも下げるときや、ASET が最初に実行される前の状態のシステムファイルを復元するときには、ASET は操作の内容を認識して保護レベルを下げます。
owner と group には、数値 ID ではなく名前を使用する必要があります。
owner、group、type の代わりに疑問符 (?) を使用すると、ASET がこれらのパラメータの既存の値を変更しないようにします。
type には、symlink (シンボリックリンク)、ディレクトリ、またはファイルを指定できます。
セキュリティーレベルが高くなるほど、調整ファイルは下位レベルよりも緩やかなファイルアクセス権にリセットされます。また、上位セキュリティーレベルになるほど、一覧に多数のファイルが追加されます。
1 つのファイルで複数の調整ファイルエントリを照合できます。たとえば、etc/passwd は etc/pass* エントリと /etc/* エントリに一致します。
2 つのエントリのアクセス権が異なる場合は、ファイルアクセス権はもっとも厳しいアクセス権を表す値に設定されます。次の例では、/etc/passwd ファイルのアクセス権は 00755 に設定されますが、これは 00755 は 00770 よりも厳密な制限であることを表します。
/etc/pass* 00755 ? ? file /etc/* 00770 ? ? file
2 つのエントリの owner 指定または group 指定が異なる場合は、最後のエントリが優先されます。次の例では、/usr/sbin/chroot の所有者が root に設定されます。
/usr/sbin/chroot 00555 bin bin file /usr/sbin/chroot 00555 root bin file

別名ファイルの例

別名ファイルには、同じユーザー ID を共有する別名の一覧が含まれています。

各エントリの書式は次のとおりです。

uid=alias1 =alias2=alias3 =...

uid: 共有 UID。
aliasn: UID を共有するユーザーアカウント。

たとえば、次のエントリでは UID 0を一覧表示しています。この UID は、sysadm および root アカウントによって共有されています。

0=root=sysadm

ASET の実行 (作業マップ)

作業	説明	参照先
ASET をコマンド行から実行します	指定する ASET レベルにあるシステムを保護します。実行ログを表示して変化を確認します	「ASET を対話的に実行する方法」
定期的に ASET をバッチモードで実行します	cron ジョブを設定し、ASET がシステムを保護するようにします。	「ASET を定期的に実行する方法」
バッチモードによる ASET の実行を停止します	ASET cron ジョブを削除します。	「ASET の定期的な実行を停止する方法」
ASET レポートをサーバーに保存します	監視のためにクライアントから ASET レポートを収集し、中心的な場所に保存します。	「サーバー上で ASET レポートを収集する方法」

ASET で変数を設定する方法は、「ASET 環境変数」を参照してください。ASET を構成する方法は、「ASET の構成」を参照してください。

ASET を対話的に実行する方法

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、「RBAC の構成 (作業マップ)」を参照してください。

aset コマンドを使用して ASET を対話的に実行します。
# /usr/aset/aset -l level -d pathname
level

セキュリティーレベルを指定します。有効な値は low、medium、または high です。デフォルト設定は low です。セキュリティーレベルの詳細は、「ASET のセキュリティーレベル」を参照してください。

pathname

ASET の作業ディレクトリを指定します。デフォルトは /usr/aset です。

画面に表示される ASET 実行ログを見て、ASET が動作していることを確認します。

実行ログメッセージは、動作しているタスクを示します。

例 7–1 ASET を対話的に実行する

次の例では、デフォルトの作業ディレクトリを使用して低セキュリティーレベルで ASET を実行します。

# /usr/aset/aset -l low
======= ASET Execution Log =======
 
ASET running at security level low
 
Machine = jupiter; Current time = 0111_09:26
 
aset: Using /usr/aset as working directory
 
Executing task list ...
	firewall
	env
	sysconf
	usrgrp
	tune
	cklist
	eeprom
 
All tasks executed. Some background tasks may still be running.
 
Run /usr/aset/util/taskstat to check their status:
 /usr/aset/util/taskstat [aset_dir]
 
where aset_dir is ASET's operating
directory,currently=/usr/aset.
 
When the tasks complete, the reports can be found in:
 /usr/aset/reports/latest/*.rpt
 
You can view them by:
 more /usr/aset/reports/latest/*.rpt

ASET を定期的に実行する方法

スーパーユーザーになるか、同等の役割を引き受けます。

役割には、認証と特権コマンドが含まれます。役割の詳細については、「RBAC の構成 (作業マップ)」を参照してください。

必要であれば、ASET を定期的に実行する時刻を設定します。

システム需要が少ないときに ASET を実行します。/usr/aset/asetenv ファイル内の PERIODIC_SCHEDULE 環境変数を使用して、ASET を定期的に実行する時刻を設定します。デフォルトでは、時刻は深夜に設定されます。

別の時刻を設定する場合は、/usr/aset/asetenv ファイル内の PERIODIC_SCHEDULE 変数を編集します。PERIODIC_SCHEDULE 変数の設定の詳細は、「PERIODIC_SCHEDULE 環境変数」を参照してください。

aset コマンドを使用してエントリを crontab ファイルに追加します。
# /usr/aset/aset -p
-p オプションは、決めた時刻に ASET の実行を開始するように /usr/aset/asetenv ファイル内の PERIODIC_SCHEDULE 環境変数に設定した行を crontab ファイルに挿入します。

次のコマンドを実行すると crontab エントリが表示され、ASET の実行スケジュールを確認できます。
# crontab -l root

ASET の定期的な実行を停止する方法

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

crontab ファイルを編集します。
# crontab -e root

ASET エントリを削除します。

変更を保存して終了します。

crontab エントリを表示して、ASET エントリが削除されていることを確認します。
# crontab -l root

サーバー上で ASET レポートを収集する方法

Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

サーバー上でディレクトリを設定します。
1. /usr/aset ディレクトリに移動します。
  mars# cd /usr/aset
2. rptdir ディレクトリを作成します。
  mars# mkdir rptdir
3. rptdir ディレクトリに移動して、client_rpt ディレクトリを作成します。
  
  これにより、クライアント用のサブディレクトリ client_rpt が作成されます。レポートを収集するクライアントごとに、この手順を繰り返します。
  mars# cd rptdir mars# mkdir client_rpt
  次の例では、ディレクトリ all_reports とサブディレクトリ pluto_rpt および neptune_rpt が作成されます。
  mars# cd /usr/aset mars# mkdir all_reports mars# cd all_reports mars# mkdir pluto_rpt mars# mkdir neptune_rpt

client_rpt ディレクトリを /etc/dfs/dfstab ファイルに追加します。

このディレクトリには、読み取り権と書き込み権があります。

たとえば、dfstab ファイル内の次のエントリは、読み取り権と書き込み権によって共有されます。
share -F nfs -o rw=pluto /usr/aset/all_reports/pluto_rpt share -F nfs -o rw=neptune /usr/aset/all_reports/neptune_rpt

dfstab ファイル内のリソースをクライアントが利用できるようにします。
# shareall

各クライアント上でクライアントのサブディレクトリを、マウントポイント /usr/aset/masters/reports にサーバーからマウントします。
# mount server:/usr/aset/client_rpt /usr/aset/masters/reports

/etc/vfstab ファイルを編集して、ブート時にディレクトリを自動的にマウントするようにします。

neptune 上の /etc/vfstab 内の次のエントリ例には、mars からマウントされるディレクトリ /usr/aset/all_reports/neptune_rpt と、neptune 上のマウントポイント /usr/aset/reports が一覧されています。ブート時には、vfstab 内に一覧されたディレクトリが自動的にマウントされます。
mars:/usr/aset/all_reports/neptune.rpt /usr/aset/reports nfs - yes hard

ASET の問題の障害追跡

この節では、ASET によって生成されるエラーメッセージについて説明します。

ASET のエラーメッセージ

ASET failed: no mail program found.

原因:

ASET は実行ログをユーザーに送るように指示されましたが、メールプログラムが見つかりません。

対処方法:

メールプログラムをインストールしてください。

Usage: aset [-n user[@host]] in /bin/mail or /usr/ucb/mail.

Cannot decide current and previous security levels.

原因:

ASET は、今回と前回の呼び出しのセキュリティーレベルを判別できません。

対処方法:

現在のセキュリティーレベルがコマンド行オプションまたは ASETSECLEVEL 環境変数によって設定されているかどうかを確認してください。また、ASETDIR/archives/asetseclevel.arch の最終行に、以前のセキュリティーレベルが正しく反映されているかどうかを確認してください。これらの値が設定されていないか正しくない場合は、正しい値を入力してください。

ASET working directory undefined.

To specify, set ASETDIR environment variable or use command line option -d.

ASET startup unsuccessful.

原因:

ASET の作業ディレクトリが定義されていないか、正しく定義されていません。

対処方法:

ASETDIR 環境変数または -d コマンド行オプションを使用してエラーを訂正してから、ASET を再起動してください。

ASET working directory $ASETDIR missing.

ASET startup unsuccessful.

原因:

ASET の作業ディレクトリが定義されていないか、正しく定義されていません。ASETDIR 変数または -d コマンド行オプションによって、存在しないディレクトリが参照されている可能性があります。

対処方法:

正しいディレクトリ、つまり ASET ディレクトリ階層が入っているディレクトリが正しく参照されているかどうかを確認してください。

Cannot expand $ASETDIR to full pathname.

原因:

ASET が ASETDIR 変数または -d コマンド行オプションで指定されたディレクトリ名を完全パス名に展開できません。

対処方法:

ディレクトリ名が正しいか確認します。ユーザーがアクセス権を持つ既存のディレクトリをそのディレクトリが参照しているか確認してください。

aset: invalid/undefined security level.

To specify, set ASETSECLEVEL environment variable or use command line option -l, with argument= low/med/high.

原因:

セキュリティーレベルが定義されていないか、正しく定義されていません。low、med、または high の値以外は定義できません。

対処方法:

ASETSECLEVEL 変数または -l コマンド行オプションを使用して、low、med、または high のいずれかの値を指定してください。

ASET environment file asetenv not found in $ASETDIR.

ASET startup unsuccessful.

原因:

ASET は asetenv ファイルを作業ディレクトリ内で見つけることができません。

対処方法:

ASET の作業ディレクトリ内に asetenv ファイルが入っているかどうかを確認してください。このファイルの詳細は、asetenv(4) のマニュアルページを参照してください。

filename doesn't exist or is not readable.

原因:

filename で指定されたファイルが存在しないか、読み取れません。この問題は、-u オプションを使用している場合に発生します。このオプションは確認するユーザーの一覧が入ったファイルを指定するために使用します。

対処方法:

-u オプションの引数が存在することと、その引数が読み取り可能であるかを確認してください。

ASET task list TASKLIST undefined.

原因:

asetenv ファイル内で定義されているはずの ASET タスクリストが定義されていません。asetenv ファイルが無効である可能性があります。

対処方法:

asetenv ファイルを検査してください。タスクリストが User Configurable セクションで定義されているかどうかを確認します。また、ファイルの他の部分をチェックして、ファイルが変更されていないことを確認します。有効な asetenv ファイルの内容については、asetenv(4) のマニュアルページを参照してください。

ASET task list $TASKLIST missing.

ASET startup unsuccessful.

原因:

asetenv ファイル内で定義されているはずの ASET タスクリストが定義されていません。asetenv ファイルが無効である可能性があります。

対処方法:

Schedule undefined for periodic invocation.

No tasks executed or scheduled. Check asetenv file.

原因:

-p オプションを使用して ASET のスケジュール指定が要求されましたが、環境変数 PERIODIC_SCHEDULE が asetenv ファイル内で定義されていません。

対処方法:

asetenv ファイルの User Configurable セクションをチェックして、変数が定義されていることを確認してください。また、変数の書式が正しいかも確認してください。

Warning! Duplicate ASET execution scheduled.

Check crontab file.

原因:

ASET のスケジュールが複数回指定されています。つまり、ASET スケジュールがまだ有効な間に別のスケジュールを指定するように要求されています。複数のスケジュールが必要な場合は、このメッセージはエラーを示すものではなく、警告メッセージとなります。複数のスケジュールが必要な場合は、crontab コマンドを使用して、正しいスケジュール書式を使用する必要があります。詳細は、crontab(1) のマニュアルページを参照してください。

対処方法:

crontab コマンドを使用して、正しいスケジュールが有効になっていることを検証してください。ASET に関して不要な crontab エントリがないかどうかを確認してください。

パート II システム、ファイル、およびデバイスのセキュリティー

第 2 章 マシンセキュリティーの管理 (概要)

Solaris 10 リリースにおけるマシンセキュリティーの向上

コンピュータシステムへのアクセスを制御する

物理的なセキュリティーの管理

ログイン制御の管理

パスワード情報の管理

ローカルパスワード

NIS パスワードおよび NIS+ パスワード

LDAP パスワード

パスワードの暗号化

パスワードアルゴリズムの識別子

policy.conf ファイルのアルゴリズム構成

特別なシステムログイン

遠隔ログイン

ダイヤルアップログイン

デバイスアクセスの制御

デバイスポリシー (概要)

デバイス割り当て (概要)

マシンリソースへのアクセス制御

スーパーユーザーの制限と監視

役割によるアクセス制御を構成してスーパーユーザーを置き換える

マシンリソースの意図しない使用の防止

PATH 変数の設定

ユーザーに制限付きシェルを割り当てる

ファイル内のデータへのアクセス制限

setuid 実行可能ファイルの制限

自動セキュリティー拡張ツールの使用

Sun Security Toolkit の使用

netservices limited 構成の使用

Solaris のリソース管理機能の使用

Solaris ゾーンの使用

マシンリソースの使用状況の監視

ファイルの整合性の監視

ファイルアクセスの制御

暗号化によるファイルの保護

アクセス制御リストの使用

マシン間でのファイルの共有

共有ファイルへの root アクセスの制限

ネットワークアクセスの制御

ネットワークセキュリティー機構

図 2–1 遠隔操作のセキュリティー制限

遠隔アクセスの認証と承認

ファイアウォールシステム

暗号化システムとファイアウォールシステム

セキュリティー問題の報告

第 3 章 システムアクセスの制御 (作業)

システムアクセスの制御 (作業マップ)

ログインとパスワードの保護 (作業マップ)

ログインとパスワードのセキュリティー

ユーザーのログイン状態を表示する方法

例 3–1 ユーザーのログイン状態を表示する

パスワードを持たないユーザーを表示する方法

例 3–2 パスワードを持たないユーザーを表示する

ユーザーのログインを一時的に無効にする方法

例 3–3 ユーザーログインを無効にする

ログイン失敗操作を監視する方法

すべてのログイン失敗操作を監視する方法

例 3–4 ログインが 3 回失敗したあとのアクセス操作を記録する

例 3–5 ログイン操作が 3 回失敗したあとで接続を遮断する

ダイヤルアップパスワードを作成する方法

ダイヤルアップログインを一時的に無効にする方法

パスワードアルゴリズムの変更 (作業マップ)

パスワード暗号化のデフォルトアルゴリズムを変更する

パスワード暗号化のアルゴリズムを指定する方法

例 3–6 パスワードの暗号化に Blowfish アルゴリズムを使用する

NIS ドメイン用の新しいパスワードアルゴリズムを指定する方法

NIS+ ドメイン用の新しいパスワードアルゴリズムを指定する方法

LDAP ドメイン用の新しいパスワードアルゴリズムを指定する方法

Sun 以外のパスワード暗号化モジュールをインストールする方法

スーパーユーザーの監視と制限 (作業マップ)

スーパーユーザーの監視と制限

su コマンドを使用するユーザーを監視する方法

注意事項

スーパーユーザーのログインを制限し監視する方法

例 3–7 スーパーユーザーのアクセス試行のログを作成する

注意事項

SPARC: システムハードウェアに対するアクセスの制御 (作業マップ)

システムハードウェアアクセスの制御

ハードウェアアクセスのパスワードを必須にする方法

第 2 章マシンセキュリティーの管理 (概要)

`policy.conf` ファイルのアルゴリズム構成

`PATH` 変数の設定

`setuid` 実行可能ファイルの制限

`netservices limited` 構成の使用

共有ファイルへの `root` アクセスの制限

第 3 章システムアクセスの制御 (作業)

`su` コマンドを使用するユーザーを監視する方法

第 4 章デバイスアクセスの制御 (作業)

`/dev/*` デバイスから IP MIB-II 情報を取得する方法

`device_maps` ファイル

例 4–14 `device_maps` エントリの例

`device_allocate` ファイル

第 5 章基本監査報告機能の使用方法 (作業)