このパートでは、Solaris 7 環境においてシステムセキュリティを管理する方法について説明します。次の章が含まれます。
ファイル、システム、およびネットワークのセキュリティの概要について説明します。 |
|
ファイル情報を表示し、ファイルの所有権とアクセス権を変更し、特殊なアクセス権を設定する手順を説明します。 |
|
ログイン状態をチェックし、ダイヤルアップパスワードを設定し、root へのアクセスを制限し、root アクセスと su コマンドの試行を監視する手順を説明します。 |
|
Kerberos ログイン認証と Pluggable Authentication Module (PAM) を設定する手順を説明します。 |
|
自動セキュリティ拡張ツール (ASET) についての概要と、ASET を対話形式で、または定期的に (cron ジョブを使用して) 実行する手順を説明します。クライアントの ASET レポートをサーバー上で収集する方法についても説明します。 |
システム情報のセキュリティを保つことは、重要なシステム管理作業です。この章では、ファイルレベル、システムレベル、およびネットワークレベルでシステムセキュリティを管理する方法について説明します。
この章の内容は以下のとおりです。
ファイルレベルでは、SunOS 5.7 オペレーティングシステムにいくつかの標準セキュリティ機能が組み込まれているため、ファイル、ディレクトリ、およびデバイスの保護に使用できます。システムレベルとネットワークレベルでは、セキュリティの内容はほぼ同じです。サイトでは、1 台のサーバーに接続された多数のシステムを 1 つの大規模で多面的なシステムと見なすことができます。システム管理者は、この大規模なシステム、つまりネットワークシステムのセキュリティ管理に責任があります。ネットワークの外側からの侵入を防ぐことだけでなく、ネットワーク内部のシステムのデータの完全性を確保することも重要です。
システムセキュリティの設定手順については、次の項目を参照してください。
防御の第 1 歩は、システムへのアクセスを制御することです。次の方法でシステムへのアクセスを制御または監視できます。
サイトの物理的なセキュリティの管理
ログイン制御の管理
ファイル内のデータへのアクセス制限
ネットワーク制御の管理
システムの使用状況の監視
正しいパス変数の設定
ファイルの保護
スーパーユーザー (root) ログインの追跡
ファイアウォールのインストール
自動セキュリティ拡張ツール (ASET) の使用
システムへのアクセスを制御するには、コンピュータ環境の物理的なセキュリティを管理しなければなりません。たとえば、システムにログイン後そのままそこから離れてしまうと、そのシステムを使用できるユーザーであれば誰でもオペレーティングシステムとネットワークにアクセスできます。コンピュータの周囲に注意して、許可されていないアクセスから物理的に保護する必要があります。
システムやネットワークへの許可されていないログインも制限する必要がありますが、この作業はパスワードとログイン制御を使用して実行できます。システム上のすべてのアカウントには、パスワードを設定しなければなりません。アカウントにパスワードを設定しないと、ユーザー名を推測できるユーザーであれば誰でもネットワーク全体にアクセスできることになります。
Solaris 7 システムソフトウェアでは、特定のシステムデバイスの制御をユーザーのログインアカウントに制限しています。/etc/logindevperm を編集しない限り、スーパーユーザーまたはコンソールユーザーとして実行中のプロセス以外は、システムのマウス、キーボード、フレームバッファにアクセスできません。詳細は、logindevperm(4) のマニュアルページを参照してください。
ログイン制限を設定したら、システム上のデータへのアクセスを制御できます。一部のユーザーには特定のファイルの読み取りを許可し、他のユーザーには特定のファイルを変更または削除するアクセス権を与えることができます。誰にも見せたくないデータがある場合もあります。ファイルのアクセス権の設定方法については、第 13 章「ファイルのセキュリティの適用手順」を参照してください。
通常、コンピュータは「ネットワーク」と呼ばれるシステム構成の一部です。ネットワーク上では、接続されているシステムは、そのネットワークに接続されている他のシステムと情報を交換し、相手のデータや他の資源にアクセスできます。ネットワーク化することによって、コンピュータの処理能力と性能が高まります。しかし、コンピュータのセキュリティが危険にさらされる可能性もあります。
たとえば、ネットワーク内では、個々のシステムは情報を共有できるように開放されています。また、多数の人々がネットワークにアクセスするので、特にパスワードの誤用などのユーザーエラーを通じて、不要なアクセスが発生する可能性も大きくなります。
システム管理者は、次のようにシステムのあらゆる側面に注意してシステムの活動を監視する必要があります。
通常の負荷はどの程度か
誰がシステムへのアクセス権を持っているか
各ユーザーはいつシステムにアクセスするか
この種の情報を把握していれば、ツールを使用してシステムの使用状況を監査し、各ユーザーの活動を監視できます。セキュリティ違反が疑われる場合は、監視作業が特に役立ちます。
パス変数を正しく設定することが重要です。正しく設定しないと、他人が持ち込んだプログラムを偶然に実行して、データやシステムを破壊する可能性があります。この種のプログラムはセキュリティ上の危険を招くので、「トロイの木馬」と呼ばれます。たとえば、公共のディレクトリの中に別の su プログラムを入れておくと、システム管理者が気づかずに実行してしまう可能性があります。この種のスクリプトは通常の su コマンドとまったく同じに見えます。実行後はスクリプトそのものが削除されるので、実際に「トロイ」の木馬を実行してしまったのかを調べるのは困難です。
パス変数は、ログイン時に起動ファイル .login、.profile、.cshrc により自動的に設定されます。カレントディレクトリ (.) への検索パスを最後に指定すれば、この種のトロイの木馬を実行するのを防ぐことができます。root のパス変数には、カレントディレクトリを指定しないでください。ASET ユーティリティは起動ファイルを検査して、パス変数が正しく設定されているかと、ドット (.) エントリが入っていないかを確認します。
SunOS 5.7 オペレーティングシステムはマルチユーザーシステムなので、ファイルシステムの保護は、システムの最も基本的で重要な問題です。ファイルの保護には、従来の UNIX のファイル保護と、より確実なアクセス制御リスト (ACL) の両方が使用できます。
また、多くの実行可能プログラムは、スーパーユーザー (root) として実行されなければ適切に動作しません。これらの実行可能プログラムは、ユーザー ID を 0 に設定して (setuid=0) 実行します。これらのプログラムを実行するユーザーは、root ID を使用するため、プログラムがセキュリティを念頭において作成されていない場合には、セキュリティ上の問題が発生する可能性があります。
setuid を root に設定した状態で把握されている実行可能プログラムを除き、setuid プログラムを使用不可にするか、少なくとも使用を最小限度に制限しておく必要があります。
ネットワークを保護するには、ファイアウォール、つまりセキュリティ保護ゲートウェイシステムを使用する方法もあります。ファイアウォールは 2 つのネットワークを分離する専用システムで、各ネットワークは相手に対し信頼されない (untrusted) ネットワークとしてアクセスします。内部ネットワークと、内部ネットワークユーザーに通信させたいインターネットなどの外部ネットワークとの間に、このような設定を必ず行うようにしてください。
ファイアウォールは、一部の内部ネットワーク間でも有効です。たとえば、ファイアウォール、つまりセキュリティ保護ゲートウェイコンピュータは、ゲートウェイコンピュータがパケットの発信元または宛先アドレスでない限り、2 つのネットワーク間でパケットを送信しません。また、ファイアウォールは、特定のプロトコルについてのみパケットを転送するように設定する必要があります。たとえば、パケットでメールを転送できるが、telnet や rlogin は転送できないようにできます。ASET ユーティリティは、高度なセキュリティを適用して実行すると、インターネットプロトコル (IP) パケットの転送機能を無効にします。
セキュリティ違反が発生したと思われる場合は、Computer Emergency Response Team/Coordination Center (CERT/CC) に連絡できます。これは、カーネギーメロン大学の Software Engineering Institute に Defense Advanced Research Projects Agency (DARPA) の後援で設立されたプロジェクトです。CERT/CC はセキュリティ問題の解決を支援できます。また、特定のニーズに合った他の Computer Emergency Response Team を紹介することもできます。CERT/CC に連絡するには、24 時間のホットライン に電話する方法と、電子メールを cert@cert.sei.cmu.edu に送る方法があります。
SunOS 5.7 オペレーティングシステムはマルチユーザーシステムです。これは、システムにログインしたユーザーであれば、アクセス権を持っている限り誰でも他のユーザーのファイルを読み取って使用できることを意味します。表 12-1 では、ファイルシステム管理コマンドについて説明します。ファイルのセキュリティについては、第 13 章「ファイルのセキュリティの適用手順」を参照してください。
表 12-1 は、ファイルやディレクトリに使用できるファイル管理コマンドを示します。
表 12-1 ファイル管理コマンド
コマンド |
説明 |
---|---|
ディレクトリ内のファイルとファイル情報を表示する |
|
ファイルの所有権を変更する |
|
ファイルのグループ所有権を変更する |
|
ファイルのアクセス権を変更する。記号モード (英字と記号) または絶対モード (8 進数) を使用して、ファイルのアクセス権を変更できる |
重要なファイルをアクセスできないディレクトリに格納し (700 モード)、そのファイルを他のユーザーが読み取れないようにすると (600 モード)、ほとんどの場合はセキュリティが保たれます。しかし、他人がユーザーのパスワードや root パスワードを推測して発見すれば、そのファイルを読み書きできます。また、重要なファイルは、システムファイルのバックアップをテープにとるたびに、バックアップテープ上に保存されます。
SunOS オペレーティングシステムの従来の UNIX ファイル保護機能では不十分な場合は、ACL によりファイルアクセス権の制御が強化されます。従来の UNIX ファイル保護機能は、所有者、グループ、その他という 3 つのユーザークラスに読み取り権、書き込み権、実行権を提供します。ACL を使用すると、所有者、所有者のグループ、その他、特定のユーザーおよびグループのファイルアクセス権を定義でき、またこれらのカテゴリごとにデフォルトのアクセス権を定義できるため、ファイルのセキュリティが強化されます。ACL を設定する個々の手順については、「アクセス制御リスト (ACL)」を参照してください。
表 12-2 に、ファイルやディレクトリに対して使用できる ACL コマンドを示します。
表 12-2 ACL コマンド
コマンド |
説明 |
---|---|
setfacl(1) |
ACL エントリの設定、追加、変更、削除を行う |
getfacl(1) |
ACL エントリを表示する |
この節では、侵入者がシステムにログインするのを防ぐ方法、パスワードファイルを管理する方法、重要なシステムファイルとプログラムに対する許可されていないスーパーユーザーアクセスを防ぐ方法など、システムを許可されていないアクセスから保護する方法について説明します。
システム上で 2 つのセキュリティバリアを設定できます。第 1 のセキュリティバリアはログインプログラムです。このバリアをクリアしてシステムにアクセスするには、ローカルシステムまたはネームサービス (NIS または NIS+) で認識されるユーザー名と対応するパスワードを入力しなければなりません。
第 2 のセキュリティバリアは、システムファイルとプログラムをスーパーユーザーしか変更または削除できないように設定することです。root になろうとするユーザーは、スーパーユーザーのユーザー名とその正しいパスワードを入力しなければなりません。
ユーザーがシステムにログインすると、ログインプログラムは /etc/nsswitch.conf ファイル内の情報に従って、該当するデータベースを照会します。このファイル内のエントリには、files (/etc 内のファイルを示す)、nis (NIS データベースを示す)、nisplus (NIS+ データベースを示す) を含めることができます。このファイルについては、『Solaris ネーミングの管理』または nsswitch.conf(4) のマニュアルページを参照してください。
ログインプログラムは、入力されたユーザー名とパスワードを確認します。ユーザー名がパスワードファイルに入っていない場合や、パスワードがユーザー名と一致していない場合は、システムへのアクセスが拒否されます。ユーザーがパスワードファイルから名前を入力し、パスワードがその名前の正しいパスワードであるときは、そのユーザーにシステムへのアクセス権が与えられます。
システムにアクセスするには、従来のユーザーログインを使用する方法と、root ログインを使用する方法の 2 つが一般的です。また、多数の特別な「システム」ログインを使用すると、ユーザーは root アカウントを使用しなくても管理コマンドを実行できます。管理者は、これらのログインアカウントにパスワードを割り当てます。
表 12-3 に、システムのログインアカウントとその用途を示します。システムログインは特殊な機能を実行し、それぞれに固有のグループ識別子番号 (GID) が付いています。これらの各ログインには固有のパスワードを設定し、必要のある人だけに知らせるようにしてください。
表 12-3 システムログイン
ログインアカウント |
GID |
用途 |
---|---|---|
root |
0 |
ほぼ無制限で、他のすべてのログイン、保護、アクセス権より優先する。root アカウントはシステム全体へのアクセス権を持つ。root ログインのパスワードはきわめて厳密に保護する必要がある |
daemon |
1 |
バックグラウンド処理を制御する |
bin |
2 |
ほとんどのコマンドを所有する |
sys |
3 |
多数のシステムファイルを所有する |
adm |
4 |
特定の管理ファイルを所有する |
lp |
71 |
プリンタ用のオブジェクトとスプールデータファイルを所有する |
uucp |
5 |
UNIX 間のコピープログラム、UUCP 用のオブジェクトとスプールデータファイルを所有する |
nuucp |
9 |
システムにログインしてファイル転送を開始するためにリモートシステムで使用される |
また、パスワードが必要な eeprom のセキュリティも設定する必要があります。詳細は、eeprom(1M) のマニュアルページを参照してください。
ユーザーはシステムにログインするときに、ユーザー名とパスワードの両方を入力しなければなりません。ログイン名は公開されますが、パスワードは秘密にしてユーザー以外には知られないようにします。また、ユーザーが各自のパスワードを慎重に選択し、頻繁に変更するようにしなければなりません。
パスワードは、最初にユーザーアカウントを設定するときに作成されます。ユーザーアカウントの機密性を保つために、パスワードの有効期間を設定し、ユーザーに各自のパスワードを定期的に変更させたり、パスワードをロックしてユーザーアカウントを使用できないようにすることもできます。パスワードの設定と管理については、『Solaris のシステム管理 (第 1 巻)』の「ユーザーアカウントとグループの管理の概要」を参照してください。
ネットワークで NIS+ を使用している場合、パスワード情報は NIS+ データベースに格納されます。NIS+ データベース内の情報は、アクセス権を許可されたユーザーを制限することによって保護できます。ユーザーアカウントマネージャまたは passwd(1) コマンドを使用すると、ユーザーの NIS+ パスワードを変更できます。
ネットワークで NIS を使用している場合、パスワードは NIS パスワードマップに格納されます。NIS では、パスワードの有効期間を指定できません。Solstice ユーザーマネージャまたは passwd(1) コマンドを使用すると、ユーザーの NIS パスワードを変更できます。
ネットワークで /etc 内のファイルを使用している場合、パスワード情報はシステムの /etc/passwd ファイルと /etc/shadow ファイルに格納されます。ユーザー名と他の情報は別の「シャドウ」ファイル /etc/shadow に格納されます。これは、ユーザーが暗号化されたパスワードにアクセスするのを防ぐセキュリティ上の手段です。/etc/passwd ファイルは、マシンにログインするユーザーであれば誰でも使用できますが、/etc/shadow ファイルを読み取ることができるのはスーパーユーザーだけです。Solstice AdminSuite のユーザーマネージャ、Admintool、または passwd(1) コマンドを使用すると、ローカルシステム上でユーザーのパスワードを変更できます。
標準シェルを使用すると、ユーザーはファイルを開く、コマンドを実行するなどの操作を行うことができます。制限付きセルを使用すると、ユーザーによるディレクトリの変更やコマンドの実行を制限できます。制限付きシェル (rsh) は、ディレクトリ /usr/lib に入っています (これはリモートシェル /usr/sbin/rsh ではないので注意してください)。制限付きシェルには、通常のシェルに比べて次のような違いがあります。
ユーザーはホームディレクトリに制限されます (cd を使用してディレクトリを変更できません)。
ユーザーはシステム管理者が設定した PATH 内でしかコマンドを使用できません (PATH 変数を変更できません)。
ユーザーはホームディレクトリとそのサブディレクトリ内のファイルにしかアクセスできません (完全パス名でコマンドやファイルを指定できません)。
ユーザーは > または >> を使用して出力をリダイレクトできません。
制限付きシェルを使用すると、システム管理者はユーザーによるシステムファイルの操作を制限できます。このシェルは、主として特定の作業を実行しなければならないユーザーを設定するためのものです。ただし、rsh は完全にセキュリティ保護されてはおらず、あくまでも経験の少ないユーザーが問題を起こさないようにするために使用します。
制限付きシェルについては、sh(1) のマニュアルページを参照してください。
システムには、スーパーユーザーモードに対して root パスワードが必要です。デフォルトの構成では、ユーザーはリモートのシステムに root としてログインできません。リモートログインするとき、ユーザーは自分のユーザー名でログインしてから、su コマンドを使用してスーパーユーザーにならなければなりません。これによって、管理者は、システム上でスーパーユーザー特権を使用している人を追跡できます。
スーパーユーザーになりたい場合などは、su コマンドを使用して別のユーザーに変更する必要があります。セキュリティ上の理由から、su コマンドを使用中のユーザー、特にスーパーユーザーのアクセス権を取得しようとしているユーザーを監視する必要があります。
詳細は、「su コマンドを使用中のユーザーを監視する方法」を参照してください。
ネットワーク上でのアクセスが容易になるほど、ネットワークシステムにとっては利点が増えます。ただし、データや資源に自由にアクセスして共有できる状況では、セキュリティ上の問題が生じます。一般にネットワークのセキュリティは、リモートシステムからの操作を制限またはブロックすることを指しています。図 12-1 に、リモート操作に適用できるセキュリティ制限を示します。
ファイアウォールシステムを設定すると、ネットワーク内のリソースを外部のアクセスから保護できます。「ファイアウォールシステム」は、内部ネットワークと外部ネットワークの間の防壁として機能するセキュリティ保護ホストです。
ファイアウォールには 2 つの機能があります。ネットワーク間でデータを渡すゲートウェイとして機能する一方で、データが勝手にネットワークを出入りしないようにブロックする防壁として機能します。ファイアウォールは、内部ネットワーク上のユーザーに対して、ファイアウォールシステムにログインしてリモートネットワーク上のホストにアクセスするように要求します。また、外部ネットワーク上のユーザーは、内部ネットワーク上のホストにアクセスする前に、ファイアウォールシステムにログインしなければなりません。
さらに、内部ネットワークから送信されるすべての電子メールは、ファイアウォールシステムに送信されてから、外部ネットワーク上のホストに転送されます。ファイアウォールシステムは、すべての着信電子メールを受信して、内部ネットワーク上のホストに配信します。
ファイアウォールは、アクセス権のないユーザーが内部ネットワーク上のホストにアクセスする行為を防止します。ファイアウォールに適用される厳密で確実なセキュリティを管理しなければなりませんが、ネットワーク上の他のホストのセキュリティはもっと緩やかでもかまいません。ただし、ファイアウォールシステムを突破できる侵入者は、内部ネットワーク上の他のすべてのホストへのアクセスを取得できる可能性があります。
ファイアウォールシステムに「信頼される (trusted) ホスト」が含まれるべきではありません (「信頼されるホスト」とは、ユーザーがパスワードを入力しなくてもログインできるホストです)。ファイアウォールシステムは、ファイルシステムを共有してはならず、他のサーバーからファイルシステムをマウントしてはなりません。
自動セキュリティ拡張ツール (ASET) を使用すると、システムをファイアウォールにして高度なセキュリティを確保できます。詳細は、第 16 章「自動セキュリティ拡張ツールの使用手順」を参照してください。
ほとんどのローカルエリアネットワークでは、データはパケットと呼ばれるブロック単位でコンピュータ間で転送されます。アクセス権のないユーザーは、「パケットスマッシング」という方法により、データを損傷または破壊する可能性があります。パケットスマッシングでは、パケットは宛先に到達する前に捕捉され、その内容になんらかのデータが挿入されてから、元のコースに送り返されます。ローカルエリアネットワーク上では、パケットはサーバーを含むすべてのシステムに同時に到達するので、パケットスマッシングは不可能です。ただし、ゲートウェイ上ではパケットスマッシングが可能なので、ネットワーク上のすべてのゲートウェイを保護しなければなりません。
最も危険なのは、データの完全性に影響するような攻撃です。この種の攻撃を受けると、パケットの内容が変更されたり、ユーザーが偽装されたりします。会話を記録したり、後からユーザーを偽装せずに再生したりするなどの盗聴だけの場合、データの完全性は損なわれません。ただし、この種の攻撃はプライバシーに影響を及ぼします。ネットワーク上でやりとりされるデータを暗号化すると、重要な情報のプライバシーを保護できます。
「認証」とは、リモートシステムにアクセスできるユーザーを特定の人に限定する方法で、システムレベルまたはネットワークレベルで設定できます。ユーザーがリモートシステムにアクセスした後は、「承認」という方法でそのユーザーがリモートシステム上で実行できる操作が制限されます。表 12-4 に、ネットワーク上のシステムを許可されていない使い方から保護できる認証と承認の種類を示します。
表 12-4 認証と承認の種類
種類 |
説明 |
参照先 |
---|---|---|
NIS+ |
NIS+ ネームサービスは、認証と承認をネットワークレベルで提供できる | |
リモートログインプログラム |
リモートログインプログラム (rlogin、rcp、ftp) を使用すると、ユーザーはネットワーク経由でリモートシステムにログインし、その資源を使用できる。「信頼される (trusted) ホスト」の場合、認証は自動的に処理されるが、それ以外の場合は自分自身を認証するように求められる | |
Secure RPC |
Secure RPC を使用すると、リモートシステム上で要求を出したユーザーの認証が行われ、ネットワーク環境のセキュリティが高まる。Secure RPC には、UNIX、DES、または Kerberos 認証システムを使用できる |
『NFS の管理』 |
|
Secure RPC を使用すると、NFS 環境に Secure NFS というセキュリティを追加できる | |
DES 暗号化 |
データ暗号化規格 (DES) 暗号化機能は 56 ビットのキーを使用して、秘密鍵を暗号化する | |
Diffie-Hellman 認証 |
この認証方法は、送信側のシステムの共通鍵を使用して現在の時刻を暗号化する機能を利用する。受信側のシステムは、現在の時刻で復号化およびチェックできる | |
Kerberos Version 4 |
Kerberos は DES 暗号化を使用して、システムのログイン時にユーザーを認証する | |
Solstice AdminSuite |
Solstice AdminSuite 製品には、認証機構と承認機構が組み込まれており、AdminSuite を使用してシステムをリモート管理できる |
ネットワークファイルサーバーは、どのファイルを共有できるかを制御できます。また、共有ファイルにアクセスできるクライアント、それらのクライアントに許されるアクセスのタイプも制御できます。一般に、ファイルサーバーは、すべてのクライアントまたは特定のクライアントに、読み書きまたは読み取り専用権を与えることができます。アクセス制御は、share コマンドで資源を利用可能にするときに指定します。
サーバーでは、/etc/dfs/dfstab ファイルを使用して、ネットワーク上のクライアントに利用させることができるファイルシステムを表示できます。ファイルの共有の詳細は、『NFS の管理』を参照してください。
一般的にスーパーユーザーは、ネットワーク上で共有されるファイルシステムにはスーパーユーザーとしてアクセスできません。サーバーが特別にスーパーユーザー特権を与えなければ、クライアントにスーパーユーザーとしてログインしたユーザーは、そのクライアントにリモートでマウントされたファイルへのスーパーユーザーアクセスを取得できません。NFS システムは、要求側のユーザー ID をユーザー名 nobody のユーザー ID に変更してスーパーユーザーアクセスを提供します。一般に、nobody のユーザー ID は 60001 です。ユーザー nobody のアクセス権は、特定のファイルに関して公共 (つまり、資格を持たないユーザー) に与えられるものと同じです。たとえば、ファイルの実行しか公共に許可していなければ、ユーザー nobody はそのファイルを実行することしかできません。
NFS サーバーは、share コマンドの root=hostname オプションを使用して、共有ファイルシステムのスーパーユーザー特権をホスト単位で与えることができます。
Secure RPC を実行したくない場合は、代わりに Solaris の「特権付きポート」機構を使用できます。特権付きポートは、1024 未満のポート番号を持つスーパーユーザーによって設定されます。クライアントシステムは、クライアントの資格を認証した後で、特権付きポート経由でサーバーへの接続を設定します。その後、サーバーは接続のポート番号を検査してクライアントの資格を確認します。
ただし、Solaris 以外のクライアントは、特権付きポート経由で通信できないことがあります。その場合は、次のようなエラーメッセージが表示されます。
"Weak Authentication NFS request from unprivileged port" |
ASET セキュリティパッケージには、システムのセキュリティを制御して監視できるように、自動管理ツールが組み込まれています。ASET を実行するセキュリティレベルとして、低、中、または高レベルを指定できます。上のレベルほど、ASET のファイル制御機能が増え、ファイルアクセスが減少し、システムセキュリティが厳しくなります。
詳細は、第 16 章「自動セキュリティ拡張ツールの使用手順」を参照してください。
この章では、ファイルにセキュリティを適用する手順について説明します。この章で説明する手順は次のとおりです。
この節では、ファイルのセキュリティを構成する機能について説明します。
各ファイルには、セキュリティのレベルを指定する 3 つのユーザークラスがあります。
ファイルやディレクトリの所有者 - 通常は、ファイルを作成したユーザーです。ファイルの所有者は、ファイルの読み取り権、書き込み権 (変更する権利)、または実行権 (コマンドの場合) を与えるユーザーを決定できます。
グループのメンバー
ファイルやグループの所有者以外のすべてのユーザー
ファイルのアクセス権を割り当てたり変更したりできるのは、スーパーユーザーかそのファイルの所有者だけです。
表 13-1 に、各ユーザークラスに与えることができるファイルのアクセス権を示します。
表 13-1 ファイルのアクセス権
記号 |
アクセス権 |
指定されたユーザーが実行できる操作 |
---|---|---|
r |
読み取り |
ファイルを開いて内容を読み取る |
w |
書き込み |
ファイルに書き込んだり (その内容を変更したり)、追加したり、削除したりできる |
x |
実行 |
ファイルを実行できる (プログラムまたはシェルスクリプトの場合)、あるいは exec(1) システムコールの 1 つを使用してファイルを実行できる |
- |
拒否 |
ファイルを読み取ったり、書き込んだり、実行したりできない |
これらのファイルアクセス権は、通常のファイルと同様にデバイス、ソケット、名前付きパイプ (FIFO) などの特殊ファイルにも適用できます。
シンボリックリンクには、そのリンクが指すファイルのアクセス権が適用されます。
表 13-2 に、各ユーザークラスに与えることができるディレクトリのアクセス権を示します。
表 13-2 ディレクトリのアクセス権
記号 |
アクセス権 |
指定されたユーザーが実行できる操作 |
---|---|---|
r |
読み取り |
ディレクトリ内のファイルを表示できる |
w |
書き込み |
ディレクトリ内のファイルやリンクを追加または削除できる |
x |
実行 |
ディレクトリ内のファイルを開いたり実行したりできる。また、ディレクトリを作成し、その下にサブディレクトリを作成できる |
ディレクトリへアクセスできないようにすると、そのディレクトリ (およびすべてのサブディレクトリ) 内のファイルを保護できます。ただし、スーパーユーザーはシステム上のすべてのファイルとディレクトリにアクセスできます。
実行可能ファイルと公共ディレクトリには、3 種類の特殊なアクセス権を設定できます。これらのアクセス権を設定すると、その実行可能ファイルを実行するユーザーは、そのファイルの所有者 (またはグループ) のユーザー ID を持つことができます。
特殊なアクセス権はセキュリティ上の問題を引き起こすため、特殊なアクセス権を設定するときは十分な注意が必要です。たとえば、ユーザーはユーザー ID が root に設定されているプログラムを実行することにより、スーパーユーザーのアクセス権を取得できます。また、すべてのユーザーは、所有するファイルに対して特殊なアクセス権を設定できるので、これもセキュリティ上の問題の原因となります。
setuid や setgid アクセス権を使用して、不正にスーパーユーザー権限が取得されていないかどうか絶えずシステムを監視しなければなりません。これらのアクセス権を使用しているすべてのプログラムを、ファイルシステム内で検索し、そのリストを出力する方法については、「setuid アクセス権が設定されているファイルを検索する方法」を参照してください。この種のプログラムの所有権を bin や sys 以外のユーザーに与えているものが出力中にあれば、そのプログラムはセキュリティに違反している可能性があります。
set-user 識別 (setuid) アクセス権を実行可能ファイルに設定すると、このファイルを実行するプロセスには、その実行可能ファイルを実行しているユーザーではなく、ファイルの所有者 (通常は root) に基づいてアクセス権が与えられます。このため、通常は所有者しか利用できないファイルやディレクトリにユーザーがアクセスできます。たとえば次に示すように、passwd コマンドは root の setuid アクセス権が設定されているので、ユーザーは root の権限でパスワードを変更できます。
-r-sr-sr-x 1 root sys 10332 May 3 08:23 /usr/bin/passwd |
これは、プロセスの実行が終了した後でも、高度な知識のあるユーザーは setuid プロセスによって与えられたアクセス権を維持する手段を見つけることができるため、セキュリティ上危険であることを示しています。
プログラムから予約済み UID (0 - 99) で setuid アクセス権を使用しても、実効 UID は正しく設定されない場合があります。シェルスクリプトを代わりに使用するか、setuid アクセス権では予約済み UID を使用しないようにしてください。
set-group 識別 (setgid) アクセス権は setuid に似ていますが、プロセスの実効グループ ID (GID) はファイルのグループ所有者に変更され、ユーザーにはそのグループに与えられたアクセス権に基づくアクセス権が与えられます。/usr/bin/mail プログラムには setgid アクセス権が設定されています。
-r-x--s--x 1 bin mail 62504 May 3 07:58 /usr/bin/mail |
setgid アクセス権がディレクトリに適用されると、このディレクトリ内で作成されたファイルは、生成するプロセスが所属するグループではなく、ディレクトリが所属するグループに含まれることになります。ディレクトリ内で書き込み権と実行権を持つユーザーは、そこでファイルを作成できます。ただし、そのファイルは、そのユーザーのグループではなく、ディレクトリのグループに所属することになります。
管理者は、setuid アクセス権や setgid アクセス権の認証されていない使用によってスーパーユーザー特権が獲得されないようにシステムを監視しなければなりません。ファイルシステムを検索して、このようなアクセス権を使用しているすべてのプログラムのリストを出力する方法については、「setuid アクセス権が設定されているファイルを検索する方法」を参照してください。このようなプログラムの所有権が、bin や sys ではなく、一般ユーザーになっているものが疑わしいと考えられます。これらのアクセス権を設定できるのは、スーパーユーザーだけです。
「スティッキビット」は、ディレクトリ内のファイルを保護するアクセス権ビットです。ディレクトリにスティッキビットが設定されている場合、そのファイルを削除できるのはその所有者、ディレクトリの所有者、または root だけです。これにより、ユーザーは /tmp などの公共ディレクトリから他のユーザーのファイルを削除できなくなります。
drwxrwxrwt 7 sys sys 517 Mar 6 02:01 tmp |
TMPFS ファイルシステム上で公共ディレクトリを設定するときには、スティッキビットを手作業で設定してください。
ファイルやディレクトリを作成するときには、デフォルトのアクセス権が設定されます。これらのデフォルトのアクセス権は、システムファイル /etc/profile、.cshrc、または .login ファイル内の umask(1) の値によって決定されます。デフォルトでは、システムはテキストファイルのアクセス権を 666 に設定してユーザー、グループ、その他に読み取り権と書き込み権を与え、ディレクトリまたは実行可能ファイルに対しては 777 に設定します。
umask によって割り当てられる値は、デフォルトから差し引かれます。これには、chmod がアクセス権を与えるのと同じ方法で拒否する効果があります。たとえば、コマンド chmod 022 はグループとその他に書き込み権を与えますが、umask 022 はグループとその他の書き込み権を拒否します。
表 13-3 に、典型的な umask の設定とその設定が実行可能ファイルに与える影響を示します。
表 13-3 各種セキュリティレベルの umask 設定
セキュリティレベル |
umask |
使用できないユーザー |
---|---|---|
緩やか (744) |
022 |
グループとその他による w |
中程度 (740) |
027 |
グループによる w、その他による rwx |
中程度 (741) |
026 |
グループによる w、その他による rw |
厳しい (700) |
077 |
グループとその他による rwx |
この節では、ファイルの情報を表示する方法について説明します。
ls コマンドを使用して、ディレクトリ内のすべてのファイルに関する情報を表示します。
$ ls -la
-l |
長形式で表示する |
-a |
ドット (.) で始まるファイルを含め、すべてのファイルを表示する |
表示画面の各行には、ファイルに関して次の情報が表示されます。
ファイル形式
ファイルには 6 つの形式があります。表 13-4 にファイル形式を示します。
表 13-4 ファイル形式
記号 |
形式 |
---|---|
- |
テキストまたはプログラム |
d |
ディレクトリ |
b |
ブロック型特殊ファイル |
c |
キャラクタ型特殊ファイル |
p |
名前付きパイプ (FIFO) |
l |
シンボリックリンク |
ハードリンク数
ファイルの所有者
ファイルのグループ
ファイルのバイト数
ファイルの作成日または前回の変更日
ファイル名
次の例では、/sbin ディレクトリ内のファイルが部分的に表示されています。
$ cd /sbin $ ls -la total 11652 drwxrwxr-x 2 root sys 512 Jun 2 11:47 ./ drwxr-xr-x 30 root root 512 Jun 3 14:13 ../ -r-xr-xr-x 1 bin bin 199224 May 6 21:23 autopush* lrwxrwxrwx 1 root root 21 Jun 2 11:47 bpgetfile -> ... -r-xr-xr-x 1 bin bin 467856 May 6 21:23 dhcpagent* -r-xr-xr-x 1 bin bin 430172 May 6 21:23 dhcpinfo* -r-xr-xr-x 1 bin bin 251500 May 6 21:23 fdisk* -r-xr-xr-x 1 bin bin 762136 May 6 21:29 hostconfig* -r-xr-xr-x 1 bin bin 533272 May 6 21:30 ifconfig* -r-xr-xr-x 1 root sys 515296 May 6 21:25 init* -r-xr-xr-x 2 bin root 256272 May 6 21:27 jsh* -r-xr-xr-x 1 bin bin 223448 May 7 20:06 mount* -r-xr-xr-x 1 root sys 6935 Jan 1 1970 mountall* . . .
この節では、ファイルの所有権を変更する方法について説明します。
デフォルトでは、所有者は chown コマンドを使用して、ファイルやディレクトリの所有者を変更できません。ただし、システム管理者が次の行をシステムの /etc/system ファイルに追加して、システムをリブートすれば、所有者は chown コマンドを使用できるようになります。
set rstchown = 0
詳細は、chown(1) のマニュアルページを参照してください。また、NFS マウントされているファイルシステム上で所有者を変更するときは、他にも制約があるので注意してください。
chown コマンドを使用してファイルの所有者を変更します。
$ chown newowner filename
newowner |
ファイルまたはディレクトリの新しい所有者のユーザー名または UID を指定する |
filename |
ファイルまたはディレクトリを指定する |
ファイルの所有者が変更されていることを確認します。
$ ls -l filename
次の例は、myfile の所有権をユーザー rimmer に設定します。
$ chown rimmer myfile $ ls -l myfile -rw-r--r-- 1 rimmer scifi 112640 May 24 10:49 myfile
デフォルトでは、所有者は chgrp コマンドを使用しても、ファイルのグループをその所有者が属するグループ以外には変更できません。たとえば、ファイルの所有者が staff と sysadm グループだけに属する場合、所有者は、ファイルのグループを staff か sysadm グループ以外には変更できません。
ただし、システム管理者が次の行をシステムの /etc/system ファイルに追加して、システムをリブートすれば、所有者は、ファイルのグループを、所有者が属していないグループにも変更できるようになります。
set rstchown = 0
詳細は、chgrp(1) のマニュアルページを参照してください。また、NFS マウントされているファイルシステムでグループを変更するときは、他にも制約があるので注意してください。
chgrp コマンドを使用して、ファイルのグループ所有者を変更します。
$ chgrp group filename
group |
ファイルまたはディレクトリの新しいグループ名を指定する |
filename |
ファイルまたはディレクトリを指定する |
グループアカウントの編集方法については、第 13 章「ファイルのセキュリティの適用手順」を参照してください。
ファイルのグループ所有権が変更されていることを確認します。
$ ls -l filename
次の例は、myfile のグループ所有権をグループ scifi に設定します。
$ chgrp scifi myfile $ ls -l myfile -rwxrw-- 1 rimmer scifi 12985 Nov 12 16:28 myfile
chmod コマンドを使用すると、ファイルのアクセス権を変更できます。ファイルまたはディレクトリの所有者、あるいはスーパーユーザーだけがそのアクセス権を変更できます。
chmod コマンドを使用して、次のどちらかのモードでアクセス権を設定できます。
絶対モード - ファイルのアクセス権を表す数値を使用します。これは、アクセス権を設定するときに最も一般的に使用される方法です。絶対モードを使用してアクセス権を変更するときは、3 つ 1 組のアクセス権を 8 進数で表します。
表 13-5 に、絶対モードでファイルのアクセス権を設定するための 8 進数値を示します。これらの数字を 3 つ組み合せて、所有者、グループ、その他のファイルアクセス権をこの順に設定します。たとえば、値 644 は、所有者に対して読み取り権と書き込み権を設定し、グループとその他に対しては読み取り権だけを設定します。
表 13-5 絶対モードによるファイルのアクセス権の設定
8 進数値 |
ファイルのアクセス権 |
設定されるアクセス権 |
---|---|---|
0 |
--- |
なし |
1 |
--x |
実行権のみ |
2 |
-w- |
書き込み権のみ |
3 |
-wx |
書き込み権と実行権 |
4 |
r-- |
読み取り権のみ |
5 |
r-x |
読み取り権と実行権 |
6 |
rw- |
読み取り権と書き込み権 |
7 |
rwx |
読み取り権、書き込み権、実行権 |
ファイルには、絶対モードまたは記号モードで特殊アクセス権を設定できます。絶対モードでは、3 つ 1 組のアクセス権の左端に新しい 8 進数値を追加して、特殊アクセス権を設定します。表 13-6 に、ファイルに特殊アクセス権を設定する 8 進数値を示します。
表 13-6 絶対モードによる特殊アクセス権の設定
8 進数値 |
特殊アクセス権の設定 |
---|---|
1 |
スティッキビット |
2 |
setguid |
4 |
setuid |
表 13-7 に、記号モードでファイルのアクセス権を設定するための記号を示します。記号では、アクセス権を設定または変更できる対象ユーザー、実行される操作、あるいは割り当てるまたは変更するアクセス権を指定できます。
表 13-7 記号モードによるファイルのアクセス権の設定
記号 |
機能 |
説明 |
---|---|---|
u |
対象ユーザー |
ユーザー (所有者) |
g |
対象ユーザー |
グループ |
o |
対象ユーザー |
その他 |
a |
対象ユーザー |
すべて |
= |
操作 |
割り当て |
+ |
操作 |
追加 |
- |
操作 |
削除 |
r |
アクセス権 |
読み取り |
w |
アクセス権 |
書き込み |
x |
アクセス権 |
実行 |
l |
アクセス権 |
強制ロック、setgid ビットはオン、グループ実行ビットはオフ |
s |
アクセス権 |
setuid または setgid ビットはオン |
S |
アクセス権 |
suid ビットはオン、ユーザー実行ビットはオフ |
t |
アクセス権 |
スティッキビットはオン、その他の実行ビットはオン |
T |
アクセス権 |
スティッキビットはオン、その他の実行ビットはオフ |
機能列の「対象ユーザー」、「操作」、および「アクセス権」を順番に連結した文字列によって、ファイルまたはディレクトリのアクセス権を変更する記号を指定します。
対象ユーザー |
アクセス権を変更する対象となるユーザーを指定する |
操作 |
実行する操作を指定する |
アクセス権 |
変更するアクセス権を指定する |
ファイルまたはディレクトリの所有者でない場合は、スーパーユーザーになります。
現在の所有者またはスーパーユーザーだけが、chmod コマンドを使用してファイルまたはディレクトリのアクセス権を変更できます。
chmod コマンドを使用してアクセス権を絶対モードで変更します。
$ chmod nnn filename
nnn |
ファイル所有者、ファイルグループ、その他のアクセス権をこの順序で表す 8 進数値を指定する。有効な 8 進数値については、表 13-5 を参照 |
filename |
ファイルまたはディレクトリを指定する |
chmod を使用して ACL エントリを持つファイルのファイルグループアクセス権を変更する場合、ファイルグループアクセス権と ACL マスクの両方が新しいアクセス権に変更されます。新しい ACL マスクアクセス権は、そのファイル上に ACL エントリを持つ追加ユーザーおよびグループの実効アクセス権を変更する場合があるので注意が必要です。getfacl(1) コマンドを使用して、適切なアクセス権がすべての ACL エントリに設定されていることを確認してください。
ファイルのアクセス権が変更されていることを確認します。
$ ls -l filename
次の例は、公共ディレクトリのアクセス権を 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 コマンドを使用して特殊アクセス権を絶対モードで変更します。
$ chmod nnnn filename
nnnn |
ファイルまたはディレクトリのアクセス権を変更する 8 進数値。左端の 8 進数値で、ファイルの特殊アクセス権を設定する。特殊アクセス権に有効な 8 進数値のリストについては、表 13-6 を参照 |
filename |
ファイルまたはディレクトリを指定する |
chmod を使用して ACL エントリを持つファイルのファイルグループアクセス権を変更する場合、ファイルグループアクセス権と ACL マスクの両方が新しいアクセス権に変更されます。新しい ACL マスクアクセス権は、そのファイル上に ACL エントリを持つ追加ユーザーおよびグループの実効アクセス権を変更する場合があるので注意が必要です。getfacl(1) コマンドを使用して、適切なアクセス権がすべての ACL エントリに設定されていることを確認してください。
ファイルのアクセス権が変更されていることを確認します。
$ ls -l filename
次の例は、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
次の例は、pubdir ディレクトリにスティッキビットアクセス権を設定します。
$ chmod 1777 pubdir
ファイルまたはディレクトリの所有者でない場合は、スーパーユーザーになります。
現在の所有者またはスーパーユーザーだけが、chmod コマンドを使用してファイルまたはディレクトリの所有者を変更できます。
chmod コマンドを使用してアクセス権を記号モードで変更します。
$ chmod who operator permission filename
who operator permission |
who では、アクセス権を変更するユーザーを指定し、operator では実行する操作を指定し、permission では変更後のアクセス権を指定する。有効な記号については、表 13-7 を参照 |
filename |
ファイルまたはディレクトリを指定する |
ファイルのアクセス権が変更されていることを確認します。
$ ls -l filename
次の例は、その他のユーザーの読み取り権を削除します。
$ chmod o-r filea
次の例は、ユーザー、グループ、その他のユーザーの読み取り権と実行権を追加します。
$ chmod a+rx fileb
次の例は、グループに読み取り権、書き込み権、実行権を割り当てます。
$ chmod g=rwx filec
setuid や setgid アクセス権を使用して、不正にスーパーユーザー権限が取得されていないかどうか絶えずシステムを監視しなければなりません。この種のプログラムの所有権を bin や sys 以外のユーザーに与えているものが出力中にあれば、そのプログラムはセキュリティに違反している可能性があります。
find コマンドを使用して setuid アクセス権が設定されているファイルを検索します。
# find directory -user root -perm -4000 -exec ls -ldb {}¥; >/tmp/filename
結果を /tmp/filename に出力する。
setuid については、「setuid アクセス権」を参照してください。
# find / -user root -perm -4000 -exec ls -ldb { }¥; > /tmp/ckprm # cat /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 #
アクセス権のないユーザー (rar) が /usr/bin/sh の個人用コピーを作成し、setuid としてのアクセス権を root に設定しています。これは、rar は /usr/rar/bin/sh を実行して特権付きユーザーになれることを意味します。この出力を参考のために保存したい場合は、ファイルを /tmp ディレクトリの外へ移動してください。
セキュリティのバグの多くは、デフォルトの実行可能スタックのアクセス権が読み取り可能、書き込み可能、および実行可能に設定されたときに発生します。実行権が設定されたスタックは SPARC ABI と Intel ABI によって許可されていますが、ほとんどのプログラムは、実行可能スタックを使用しなくても正常に機能します。
Solaris 2.6 リリースより、noexec_user_stack 変数が利用できるようになりました。この変数によって、システム管理者は、スタックを実行可能としてマッピングするかどうかを指定できます。デフォルトではこの変数はゼロで、ABI 準拠の動作を提供します。この変数がゼロ以外に設定された場合、システムはシステム中のすべてのプロセスのスタックに読み取り可能と書き込み可能のマークをつけますが、実行可能のマークは付けません。
この変数が設定されている場合、プログラムがスタック上でコードを実行しようとすると SIGSEGV シグナルが送信されます。通常、このシグナルが送信されると、プログラムはコアダンプして終了します。このようなプログラムは、違反しているプログラム名、プロセス ID、およびプログラムを実行した実ユーザー ID を含む警告メッセージも生成します。たとえば、次のとおりです。
a.out[347] attempt to execute code on stack by uid 555 |
メッセージは、syslog kern 機能が notice レベルに設定されているときに、syslogd(1M) デーモンによってログに記録されます。このログへの記録は、デフォルトで syslog.conf(4) ファイルに設定されていて、メッセージがコンソールと /var/adm/messages ファイルの両方に送信されることを意味します。
このメッセージは、潜在的なセキュリティの問題を調べるときに役立ちます。また、この変数を設定することによって、正しく動作しなくなった、実行可能スタックに依存する有効なプログラムを確認するのにも役立ちます。メッセージを記録しない場合、管理者は、/etc/system ファイルで noexec_user_stack_log 変数をゼロに設定して無効にします。この場合でも実行プログラムは、SIGSEGV シグナルによってコアダンプします。
プログラムのスタックが実行可能であると明示的にマークを付ける場合は、mprotect(2) を使用します。
ハードウェアの制限のため、実行可能スタックの問題を捕捉して報告する機能は、sun4m、sun4d、および sun4u プラットフォームでしか利用できません。
従来の UNIX ファイル保護機能は、所有者、グループ、その他という 3 つのユーザークラスに読み取り権、書き込み権、実行権を提供します。ACL を使用すると、所有者、所有者のグループ、その他、特定のユーザーおよびグループのファイルアクセス権を定義でき、またこれらのカテゴリごとにデフォルトのアクセス権を定義できるため、ファイルのセキュリティが強化されます。
たとえば、グループ内のすべてのユーザーがファイルを読み取れるようにしたい場合は、単にそのファイルにグループの読み取り権を設定します。そして、そのグループ内の 1 人のユーザーだけに書き込み権を与えたいとすると、標準の UNIX ではこのようなファイルセキュリティを設定できませんが、ACL ではこれが可能です。
ACL エントリはファイルの ACL を定義する手段であり、setfacl(1) コマンドにより設定します。ACL エントリは、次のようにコロンで区切ったフィールドからなっています。
entry_type:[uid|gid]:perms |
entry_type |
ファイルのアクセス権を設定する ACL エントリのタイプ。たとえば、entry_type は user (ファイルの所有者) または mask (ACL マスク) に設定できる |
uid |
ユーザー名または識別番号 |
gid |
グループ名または識別番号 |
perms |
entry_type に設定するアクセス権を表す。perms は、記号文字 rwx または番号 (chmod コマンドに使用するのと同じアクセス権番号) で指定できる |
次の例に、ユーザー nathan の読み取り権および書き取り権を設定する ACL エントリを示します。
user:nathan:rw- |
ACL などの UFS ファイルシステム属性は UFS ファイルシステムだけでサポートされます。つまり、/tmp ディレクトリ (通常は、TMPFS ファイルシステムとしてマウントされている) で ACL エントリを持つファイルを復元またはコピーすると、その ACL エントリは失われます。UFS ファイルの一時的な格納には、/var/tmp ディレクトリを使用してください。
表 13-8 に、有効な ACL エントリを示します。最初の 3 つの ACL エントリは、基本的な UNIX のファイル保護機能を提供します。
表 13-8 ファイルの ACL エントリ
表 13-8 に示した ACL エントリの他に、ディレクトリにはデフォルトの ACL エントリも設定できます。デフォルトの ACL エントリを持つディレクトリ内で作成されたファイルまたはディレクトリは、デフォルトの ACL エントリと同じ ACL エントリを持つことになります。表 13-9 に、ディレクトリのデフォルト ACL エントリを示します。
ディレクトリ上で特定のユーザーとグループのデフォルトの ACL エントリを初めて設定するときは、ファイル所有者、ファイルグループ、その他、およびACL マスクにデフォルトの ACL エントリも設定しなければなりません (表 13-9 の最初の 4 つのデフォルト ACL エントリでは、この設定は必須です)。
表 13-9 ディレクトリのデフォルト ACL エントリ
setfacl コマンドを使用してファイルの ACL エントリを設定します。
$ setfacl -s user::perms,group::perms,other:perms,mask:perms,acl_entry_list filename ...
-s |
ファイルに対して ACL を設定する。すでに ACL が設定されている場合、新しい ACL に置き換える。このオプションには、少なくともファイル所有者、ファイルグループ、およびその他のエントリを指定する必要がある |
user::perms |
ファイル所有者のアクセス権を指定する |
group::perms |
ファイルグループのアクセス権を指定する |
other:perms |
ファイル所有者またはファイルグループのメンバー以外のユーザーのアクセス権を指定する |
mask:perms |
ACL マスクのアクセス権。マスクは、ユーザー (所有者以外) とグループに許される最大アクセス権を示す |
acl_entry_list |
ファイルまたはディレクトリ上で特定のユーザーとグループに関して設定する 1 つ以上の ACL エントリのリスト。ディレクトリ上でデフォルトの ACL エントリを設定することもできる。有効な ACL エントリについては、表 13-8 と表 13-9 を参照 |
filename |
ACL を設定するファイルまたはディレクトリ |
ファイルに ACL が設定されたかどうかを確認する方法については、「ファイルに ACL が設定されているかどうかをチェックする方法」を参照してください。ファイルにどの ACL エントリが設定されているかを確認するには、getfacl コマンドを使用します。
$ getfacl filename
すでにファイル上に ACL が存在する場合、-s オプションを指定すると、ACL 全体が新しい ACL に置き換えられます。
次の例は、ch1.doc ファイルで、ファイルの所有者に読み取り/書き込み権、ファイルグループに読み取り権のみ、その他のユーザーにアクセス権「なし」を設定します。また、ユーザー george には、このファイルの読み取り権/書き込み権が与えられ、ACL マスクに読み取り権/書き込み権が設定されます。これは、ユーザーやグループは実行権を持たないことを意味します。
$ setfacl -s user::rw-,group::r--,other:---,mask:rw-,user:george:rw- ch1.doc $ ls -l total 124 -rw-r-----+ 1 nathan sysadmin 34816 Nov 11 14:16 ch1.doc -rw-r--r-- 1 nathan sysadmin 20167 Nov 11 14:16 ch2.doc -rw-r--r-- 1 nathan sysadmin 8192 Nov 11 14:16 notes $ getfacl ch1.doc # file: ch1.doc # owner: nathan # group: sysadmin user::rw- user:george:rw- #effective:rw- group::r-- #effective:r-- mask:rw- other:---
次の例は、ch2.doc ファイルで、ファイル所有者に読み取り権/書き込み権/実行権、ファイルグループに読み取り権のみ、その他のユーザーにアクセス権「なし」を設定し、ACL マスクに読み取り権を設定します。さらに、ユーザー george には読み取り権/書き込み権が与えられます。ただし、ACL マスクの設定により、george の実効アクセス権は読み取りだけです。
$ setfacl -s u::7,g::4,o:0,m:4,u:george:7 ch2.doc $ getfacl ch2.doc # file: ch2.doc # owner: nathan # group: sysadmin user::rwx user:george:rwx #effective:r-- group::r-- #effective:r-- mask:r-- other:---
getfacl の出力先を変更することにより、ファイルの ACL を他のファイルへコピーできます。
$ getfacl filename1 | setfacl --f - filename2
file1 |
ACL のコピー元ファイルを指定する |
file2 |
ACL のコピー先ファイルを指定する |
次の例は、ACL を ch2.doc から ch3.doc へコピーします。
$ getfacl ch2.doc | setfacl -f - ch3.doc
ls コマンドを使用して、ファイルに ACL が設定されているかどうかをチェックします。
$ ls -l filename
filename |
チェックするファイルまたはディレクトリを指定する |
モードフィールドの右側の「+」は、ファイルに ACL が設定されていることを示します。
さらにユーザーやグループの ACL エントリをファイルに追加しないかぎり、ファイルの ACL は「弱い」とみなされ、「+」は表示されません。
次の例は、モードフィールドの右側に + が付いているため、ch1.doc に ACL が設定されていることを示します。
$ ls -l ch1.doc -rwxr-----+ 1 nathan sysadmin 167 Nov 11 11:13 ch1.doc
setfacl コマンドを使用してファイルの ACL エントリを変更します。
$ setfacl -m acl_entry_list filename1 [filename2...]
-m |
既存の ACL エントリを変更する |
acl_entry_list |
ファイルまたはディレクトリで変更する 1 つ以上の ACL エントリのリスト。ディレクトリのデフォルト ACL エントリを変更することもできる。有効な ACL エントリについては、表 13-8 と表 13-9 を参照を指定する |
filename ... |
ファイルまたはディレクトリを指定する |
ファイルの ACL エントリが追加または変更されたことを確認するには、getfacl コマンドを使用します。
$ getfacl filename
次の例は、ch3.doc ファイルのユーザー george のアクセス権を読み取り権/書き込み権に変更します。
$ setfacl -m user:george:6 ch3.doc $ getfacl ch3.doc # file: ch3.doc # owner: george # group: staff user::rw- user::george:rw- #effective:rw- group::r- #effective:r-- mask:r-- other:r--
次の例は、book ディレクトリに関して、グループ staff のデフォルトのアクセス権を読み取りに変更し、デフォルトの ACL マスクを読み取り権/書き込み権に変更します。
$ setfacl -m default:group:staff:4,default:mask:6 book
setfacl コマンドを使用してファイルから ACL エントリを削除します。
$ setfacl -d acl_entry_list filename1 ...
-d |
指定した ACL エントリを削除する |
acl_entry_list |
ファイルまたはディレクトリから (アクセス権を指定せずに) 削除する ACL エントリのリスト。特定のユーザーとグループの ACL エントリとデフォルトの ACL エントリ以外は削除できない。有効な ACL エントリについては、表 13-8 と表 13-9 を参照 |
filename ... |
ファイルまたはディレクトリを指定する |
setfacl -s コマンドを使用すると、ファイルからすべての ACL エントリを削除して、新たに指定した ACL エントリに置き換えることができます。
ファイルから ACL エントリが削除されたことを確認するには、getfacl コマンドを使用します。
$ getfacl filename
次の例は、ユーザー george を ch4.doc ファイルから削除します。
$ setfacl -d user:george ch4.doc
getfacl コマンドを使用してファイルの ACL エントリを表示します。
$ getfacl [-a | -d] filename1 ...
-a |
指定したファイルまたはディレクトリのファイル名、ファイル所有者、ファイルグループ、ACL エントリを表示する |
-d |
指定したディレクトリのファイル名、ファイル所有者、ファイルグループ、デフォルトの ACL エントリを表示する |
filename ... |
ファイルまたはディレクトリを指定する |
コマンド行で複数のファイル名を指定すると、各 ACL エントリはブランク行で区切られます。
次の例は、ch1.doc ファイルのすべての ACL エントリを示します。ユーザーエントリとグループエントリの隣の #effective: は、ACL マスクによって変更された後のアクセス権の設定を示します。
$ getfacl ch1.doc # file: ch1.doc # owner: nathan # group: sysadmin user::rw- user:george:r-- #effective:r-- group::rw- #effective:rw- mask:rw- other:---
次の例は、book ディレクトリのデフォルトの ACL エントリを示します。
$ getfacl -d book # file: book # owner: nathan # group: sysadmin user::rwx user:george:r-x #effective:r-x group::rwx #effective:rwx mask:rwx other:--- default:user::rw- default:user:george:r-- default:group::rw- default:mask:rw- default:other:---
この章では、システムにセキュリティを適用する手順について説明します。この章で説明する手順は次のとおりです。
システムにセキュリティを適用する概要については、「システムのセキュリティ」を参照してください。
この節では、ユーザーのログイン情報を表示する方法について説明します。
logins コマンドを使用してユーザーのログイン状態を表示します。
# logins -x -l username
-x |
ログイン状態情報の拡張セットを表示する |
-l username |
指定するユーザーのログイン状態を表示する。username はユーザーのログイン名。複数のログイン名は、コンマで区切って指定する |
logins(1M) コマンドは、ローカルの /etc/passwd ファイルと NIS または NIS+ パスワードデータベースを使用して、ユーザーのログイン状態を表示します。
次の例には、ユーザー rimmer のログイン状態が表示されています。
# logins -x -l rimmer rimmer 500 staff 10 Arnold J. Rimmer /export/home/rimmer /bin/sh PS 010170 10 7 -1
rimmer |
ユーザーのログイン名を示す |
500 |
UID (ユーザー ID) を示す |
staff |
ユーザーの一次グループを示す |
10 |
GID (グループ ID) を示す |
Arnold J. Rimmer |
コメントを示す |
/export/home/rimmer |
ユーザーのホームディレクトリを示す |
/bin/sh |
ログインシェルを示す |
PS 010170 10 7 -1 |
次のパスワードの有効日数情報を示す o パスワードの最終変更日 o 次に変更するまでに必要な日数 o 変更しないで使用できる日数 o 警告期間 |
ユーザー全員が有効なパスワードを持っているかどうかを確認する必要があります。
スーパーユーザーになります。
logins コマンドを使用して、パスワードを持っていないユーザーを表示します。
# logins -p
-p |
パスワードを持っていないユーザーのリストを表示する |
logins コマンドは、ローカルの /etc/passwd ファイルと NIS または NIS+ パスワードデータベースを使用して、ユーザーのログイン状態を表示します。
次の例には、パスワードを持っていないユーザー pmorph が表示されています。
# logins -p pmorph 501 other 1 Polly Morph #
ユーザーのログインを一時的に無効にするには、次のようにします。
/etc/nologin ファイルを作成します。
システムを実行レベル 0 (シングルユーザーモード) にします。システムをシングルユーザーモードに移行する方法については、『Solaris のシステム管理 (第 1 巻)』の「システムのシャットダウンの手順」の節を参照してください。
このファイルを作成する目的は、システムシャットダウンや定期保守のためにシステムが一定の時間利用できなくなるときに、ユーザーのログインを禁止して、ユーザーに通知することです。
このファイルが存在するシステムにユーザーがログインしようとすると、nologin(4) ファイルの内容が表示されて、ユーザーのログインは中断されます。スーパーユーザーのログインは影響を受けません。
スーパーユーザーになります。
エディタを使用して、/etc/nologin ファイルを作成します。
# vi /etc/nologin
システムの利用に関するメッセージを入力します。
ファイルを閉じて、保存します。
この例は、システムが利用できないことをユーザーに通知する方法を示しています。
# vi /etc/nologin (ここでシステムメッセージを追加する。) # cat /etc/nologin ***No logins permitted.*** ***The system will be unavailable until 12 noon.*** |
root 専用の読み取り権と書き込み権を使用して /var/adm/loginlog ファイルを作成すると、失敗したログイン操作を保存できます。loginlog ファイルを作成した後は、操作に 5 回以上失敗すると、失敗したログイン操作がすべてこのファイルに自動的に書き込まれます。詳細は、「失敗したログイン操作を保存する方法」を参照してください。
loginlog ファイルには、失敗した操作ごとに 1 つずつエントリが入っています。各エントリには、ユーザーのログイン名、tty デバイス、操作の失敗回数が入っています。4 回以下の失敗であれば、ログに記録されません。
loginlog ファイルは急激に大きくなることがあります。このファイル内の情報を使用し、ファイルが大きくなりすぎないようにするには、ファイルの内容をときどきチェックして消去しなければなりません。このファイルが多数の作業を示す場合は、コンピュータシステムに誰かが侵入しようとした可能性があります。このファイルの詳細は、loginlog(4) のマニュアルページを参照してください。
/var/adm ディレクトリ内で loginlog ファイルを作成します。
# touch /var/adm/loginlog
loginlog ファイル上で root 用の読み取り権と書き込み権を設定します。
# chmod 600 /var/adm/loginlog
loginlog ファイル上でグループのメンバーシップを sys に変更します。
# chgrp sys /var/adm/loginlog
ログが機能していることを確認するには、loginlog ファイルを作成した後で、間違ったパスワードを使用してシステムに 5 回ログインします。次に、/var/adm/loginlog ファイルを表示します。
# more /var/adm/loginlog pmorph:/dev/pts/4:Mon Jun 8 11:08:27 1998 pmorph:/dev/pts/4:Mon Jun 8 11:08:49 1998 pmorph:/dev/pts/4:Mon Jun 8 11:09:03 1998 pmorph:/dev/pts/4:Mon Jun 8 11:09:22 1998 pmorph:/dev/pts/4:Mon Jun 8 11:09:36 1998 #
モデムやダイヤルアップポートを通じてシステムにアクセスするユーザーに「ダイヤルアップパスワード」を要求して、パスワード機構にセキュリティ層を追加できます。ダイヤルアップパスワードは、ユーザーがシステムへのアクセス権を取得する前に入力しなければならないパスワードです。
スーパーユーザー以外はダイヤルアップパスワードを作成または変更できません。システムの完全性を確保するために、月に一度はパスワードを変更する必要があります。この機構の最も有効な使用方法は、ゲートウェイシステムへのアクセス権を取得するためのダイヤルアップパスワードを要求することです。
ダイヤルアップパスワードの作成には、/etc/dialups と /etc/d_passwd という 2 つのファイルが必要です。/etc/dialups には、ダイヤルアップパスワードが必要なポートのリストが入っています。/etc/d_passwd には、ダイヤルアップパスワードとして暗号化されたパスワードを要求するシェルプログラムのリストが入っています。
dialups(4) ファイルには、次のような端末装置のリストが含まれます。
/dev/term/a /dev/term/b |
d_passwd(4) ファイルには 2 つのフィールドがあります。1 つのフィールドはパスワードを要求するログインシェルで、もう 1 つのフィールドは暗号化されたパスワードです。/etc/dialups ファイルと /etc/d_passwd ファイルは次のように使用されます。
ユーザーが /etc/dialups にリストされたポート上でログインしようとすると、ログインプログラムは /etc/passwd に格納されたユーザーのログインエントリを検索し、ログインシェルを /etc/d_passwd 内のエントリと比較します。これらのエントリによって、ユーザーがダイヤルアップパスワードを入力する必要があるかどうかが決まります。
/usr/lib/uucp/uucico:encrypted_password: /usr/bin/csh:encrypted_password: /usr/bin/ksh:encrypted_password: /usr/bin/sh:encrypted_password: |
図 14-1 に、基本的なダイヤルアップパスワードシーケンスを示します。
ほとんどのユーザーはログインするときにシェルを実行しているので、すべてのシェルプログラムのエントリが /etc/d_passwd 内に必要です。この種のプログラムは、uucico、sh、ksh、csh などです。一部のユーザーがログインシェルから何か実行する場合は、そのログインシェルもファイルに含めてください。
ユーザーのログインプログラム (/etc/passwd 内で指定) が /etc/d_passwd 内で見つからない場合や、/etc/passwd 内のログインシェルフィールドが空 (NULL) の場合は、/usr/bin/sh のパスワードエントリが使用されます。
/etc/passwd 内のユーザーのログインシェルが /etc/d_passwd 内で見つからない場合、そのユーザーはデフォルトのパスワードを入力しなければなりません。デフォルトのパスワードは /usr/bin/sh のエントリです。
/etc/passwd 内のログインシェルフィールドが空の場合、そのユーザーはデフォルトのパスワード (/usr/bin/sh のエントリ) を入力しなければなりません。
/etc/d_passwd に /usr/bin/sh のエントリがない場合、/etc/passwd 内のログインシェルフィールドが空のユーザー、または /etc/d_passwd 内のエントリと一致しないユーザーには、ダイヤルアップパスワードの入力を促すパスワードは表示されません。
最初にダイヤルアップパスワードを設定するときには、少なくとも 1 つの端末にログインしている状態で、別の端末上でパスワードをテストしてください。余分のパスワードをインストールし、ログアウトして新しいパスワードをテストする間にミスすると、元どおりログインできなくなることがあります。まだ別の端末にログインしていれば、元に戻ってミスを訂正できます。
スーパーユーザーになります。
ダイヤルアップパスワード保護が必要なすべてのポートなど、端末装置のリストが入った /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
暗号化パスワードを作成します。
user-name.temp ファイルから /etc/d_passwd ファイルに暗号化パスワードをコピーします。
ログインシェルごとに別のパスワードを作成するか、共通のパスワードを使用できます。
スーパーユーザーアカウントは、基本的な機能を実行するためにオペレーティングシステムに使用され、オペレーティングシステム全体を広範囲に制御します。また、スーパーユーザーアカウントは重要なシステムプログラムにアクセスして実行できます。このため、スーパーユーザーによって実行されるプログラムの場合、セキュリティ上の制約はほとんどありません。
/etc/default/login ファイルを通じて特定の装置へのスーパーユーザーアクセスを制限すると、システム上のスーパーユーザーアカウントを保護できます。たとえば、スーパーユーザーアクセスをコンソールに限定しておけば、コンソールからしかスーパーユーザーとしてシステムにログインできなくなります。誰かがシステムにリモートログインして管理作業を実行する場合は、まず自分のユーザーログインを使用してログインしてから、su(1M) コマンドを使用してスーパーユーザーにならなければなりません。詳細は、「スーパーユーザー (root) ログインをコンソールに制限する方法」を参照してください。
システムをインストールするときには、コンソールへのスーパーユーザーログインはデフォルトで制限されます。
/etc/default/login ファイルを編集します。
次の行のコメントを解除します。
CONSOLE=/dev/console
このシステムにリモートログインするユーザーは、まず自分のユーザーログインを使用してログインしてから、su コマンドを使用してスーパーユーザーにならなければなりません。
このシステムにスーパーユーザーとしてリモートログインして、操作が失敗することを確認してください。
su コマンドの試行に対する監視は /etc/default/su ファイルを通じて開始できます。このファイルを通じて、/var/adm/sulog ファイルを使用可能にし、su コマンドを使用して別のユーザーに変更されるたびに監視できます。詳細は、「su コマンドを使用中のユーザーを監視する方法」を参照してください。
sulog ファイルには、ユーザーをスーパーユーザーに切り替えるコマンドではなく、su コマンドのすべての使用状況がリストされます。各エントリは、コマンドが入力された日時、su コマンドの成否 (+ または -)、コマンドが実行されたポート、およびユーザー名と切り替え後の識別名を示します。
/etc/default/su ファイルを通じて、リモートシステムから su コマンドを使用してスーパーユーザーアクセス権を取得しようとする操作が発生するたびにコンソールに表示されるようにシステムを設定することもできます。これは、現在作業中のシステム上で誰かがスーパーユーザーアクセス権を取得しようとした場合に、それを即座に検出する優れた方法です。詳細は、「コンソールへのスーパーユーザー (root) アクセス操作を表示する方法」を参照してください。
/etc/default/su ファイルを編集します。
次の行のコメントを解除します。
SULOG=/var/adm/sulog
/etc/default/su ファイルを変更し終わったら、su コマンドを何度か使用して /var/adm/sulog ファイルを表示します。su コマンドを使用した時刻ごとにエントリが表示されます。
# more /var/adm/sulog SU 12/20 16:26 + pts/0 nathan-root SU 12/21 10:59 + pts/0 nathan-root SU 01/12 11:11 + pts/0 root-joebob SU 01/12 14:56 + pts/0 pmorph-root SU 01/12 14:57 + pts/0 pmorph-root
/etc/default/su ファイルを編集します。
次の行のコメントを解除します。
CONSOLE=/dev/console
su コマンドを使用してスーパーユーザーになり、システムコンソールにメッセージが出力されるかどうかを確認してください。
この章の最初の節では、Secure RPC で使用できる認証機構について説明します。Diffie-Hellman 認証と Kerberos Version 4 認証がサポートされます。2 番目の節では、Pluggable Authentication Module (PAM) フレームワークについて説明します。PAM は、認証サービスを「プラグイン」する方法を提供して、複数の認証サービスを使用できるようにします。
この章で説明する手順は次のとおりです。
Secure RPC は、ホストと、要求を依頼したユーザーの両方を認証する認証方法です。Secure RPC は、Diffie-Hellman 認証か Kerberos 認証のどちらかを使用します。これらの認証機構は両方とも DES 暗号化を使用します。Secure RPC を使用するアプリケーションには、NFS と NIS+ ネームサービスがあります。
NFS ソフトウェアを使用すると、複数のホストがネットワーク上でファイルを共有できます。NFS システムでは、サーバーは、複数のクライアントから利用できるデータと資源を格納します。クライアントは、サーバーがクライアントにエクスポートしたファイルシステムにアクセスできます。クライアントマシンにログインしたユーザーは、ファイルシステムをサーバーからマウントすることによって、そのファイルシステムにアクセスできます。このとき、クライアントマシン上のユーザーには、ファイルはクライアントのローカルファイルシステム上にあるように見えます。NFS 環境の最も一般的な使用形態として、システムを各オフィスにインストールして、すべてのユーザーファイルを 1 箇所で集中管理する方法が挙げられます。 mount -nosuid オプションなどのいくつかの NFS 機能を使用すると、権限のないユーザーがデバイスやファイルシステムにアクセスすることを禁止できます。
NFS 環境では Secure RPC を使用して、要求を出したユーザーをネットワーク上で認証します。これを Secure NFS と呼びます。認証機構 AUTH_DH
は、Diffie-Hellman 認証で DES 暗号化を使用し、許可されたアクセスを確認します。AUTH_DH
機構は、AUTH_DES
とも呼びます。AUTH_KERB4
機構は、Kerberos 認証で DES 暗号化を使用します。この機構は、AUTH_KERB
とも呼びます。
『NFS の管理』には、Secure NFS を設定および管理する方法が説明されています。NIS+ テーブルの設定と cred テーブルへの名前の入力は、『Solaris ネーミングの管理』で説明しています。RPC 認証に含まれる手順の概要については、「Diffie-Hellman 認証の実装」を参照してください。
Data Encryption Standard (DES) 暗号化機能は 56 ビットの鍵を使用して、秘密鍵を暗号化します。資格を持つ 2 人のユーザー (主体) が同じ DES 鍵を知っている場合、彼らはその鍵を使用してテキストを暗号化または復号化することによって、プライベートに通信できます。DES は比較的高速な暗号化機構です。DES チップは暗号化をより高速にします。しかし、チップがなくても、ソフトウェアが実行します。
DES 鍵だけを使用する危険性とは、十分な時間をかけて、同じ鍵を使用して暗号化した暗号テキストメッセージを十分に収集すれば、鍵を発見し、メッセージを復号化できることです。この理由のため、Secure NFS などのセキュリティシステムは鍵を頻繁に変更します。
Diffie-Hellman のユーザー認証方法は簡単には破られません。クライアントとサーバーは、それぞれ独自の非公開鍵 (秘密鍵とも呼ぶ) を持っていて、共通鍵が利用できるように公開鍵と組み合わせて使用します。クライアントとサーバーはお互いにこの共通鍵を使用し、両者で合意された暗号化復号化機能 (DES など) を使用して通信します。この方法は、以前の Solaris リリースの DES 認証と同じです。
認証は、送信側のシステムの共通鍵を使用して現在の時刻を暗号化する機能を利用します。受信側のシステムは、その現在の時刻を復号し、自分の時刻と照合します。クライアントとサーバーで時刻が同期していることを確認してください。
公開鍵と非公開鍵は、NIS または NIS+ のデータベースに格納されます。NIS では、publickey マップに鍵を格納します。NIS+ では、cred テーブルに鍵を格納します。これらのファイルには、すべてのユーザーの公開鍵と非公開鍵が入っています。
システム管理者は、NIS または NIS+ のテーブルを設定して、ユーザーごとに公開鍵と非公開鍵を生成する義務があります。公開鍵は、ユーザーのパスワードで暗号化されて格納されます。これによって、その公開鍵はそのユーザーだけが知っていることになります。
この節では、DH 認証 (AUTH_DH
) を使用するクライアントサーバーセッションにおける一連のトランザクションを説明します。
トランザクションの前に、管理者は newkey コマンドか nisaddcred コマンドを使用して、公開鍵と秘密鍵を生成します (各ユーザーは一意の公開鍵と秘密鍵を持ちます)。公開鍵は公開データベースに格納されます。秘密鍵は、暗号化された形式で、同じデータベースに格納されます。鍵のペアを変更するには、chkey コマンドを使用します。
通常、ログインパスワードは Secure RPC パスワードと同じです。この場合、keylogin は必要ありません。パスワードが異なる場合、ユーザーはログインしてから明示的に keylogin を実行しなければなりません。
keylogin プログラムは、Secure RPC パスワードを求めるプロンプトをユーザーに出して、そのパスワードを使用して秘密鍵を復号します。keylogin プログラムは、復号した秘密鍵をキーサーバーというプログラムに渡します (キーサーバーは、すべてのコンピュータ上にローカルインスタンスを持つ RPC サービスです)。キーサーバーは、復号された秘密鍵を保存して、ユーザーがサーバーで Secure RPC トランザクションを発行するのを待ちます。
パスワードが同じ場合は、ログインプロセスが秘密鍵をキーサーバーに渡します。パスワードが異なる必要があり、ユーザーが常に keylogin を実行しなければならない場合は、keylogin プログラムをユーザーの環境の構成ファイル (‾/.login、‾/.cshrc、‾/.profile など) に入れておいて、ユーザーがログインするたびに自動的に実行されるようにします。
ユーザーがサーバーとのトランザクションを開始すると、次の動作が行われます。
キーサーバーはランダムに対話鍵を生成します。
カーネルはこの対話鍵を使用して、クライアントのタイムスタンプを暗号化します (他の動作も行います)。
キーサーバーは公開鍵データベースでサーバーの公開鍵を検索します (publickey(4) のマニュアルページを参照してください)。
キーサーバーはクライアントの秘密鍵とサーバーの公開鍵を使用して、共通鍵を作成します。
キーサーバーは共通鍵を使用して対話鍵を暗号化します。
次に、暗号化したタイムスタンプと暗号化した対話鍵を含む伝送データがサーバーに送信されます。伝送データには資格とベリファイアが含まれます。資格は、次の 3 つの構成要素を持ちます。
クライアントのネット名
共通鍵で暗号化された対話鍵
対話鍵で暗号化された「ウィンドウ」
この場合の「ウィンドウ」とは、クライアントが主張する、サーバーの時刻とクライアントのタイムスタンプとの許容されるべき差のことです。サーバーの時刻とクライアントのタイムスタンプとの間の差がウィンドウより大きい場合、サーバーはクライアントの要求を拒否します。クライアントは RPC セッションを開始する前にサーバーと同期を取るため、通常の状態では、このような事態は発生しません。
暗号化されたタイムスタンプ
指定したウィンドウの暗号化されたベリファイアから 1 を引いた値
ウィンドウベリファイアが必要な理由は次の場合です。誰かが別のユーザーになりすまそうとして、資格とベリファイアの暗号化されたフィールドに書き込む代わりに、ランダムなビットだけを埋め込むプログラムを書いたと仮定します。サーバーはこの対話鍵をなんらかのランダム鍵に復号化し、それを使用してウィンドウとタイムスタンプを復号化しようと試みます。その結果、乱数が生成されるだけです。しかし、数千回の試行を重ねるうちには、このランダムなウィンドウタイムスタンプのペアが認証システムを通過することが十分ありえます。ウィンドウベリファイアは、正しい資格の解読をより困難にします。
サーバーがクライアントから伝送データを受信すると、次の動作が行われます。
サーバーのローカルなキーサーバーが、公開鍵データベースでクライアントの公開鍵を検索します。
キーサーバーは、クライアントの公開鍵とサーバーの秘密鍵を使用して、共通鍵を計算します。この共通鍵はクライアントが計算したものと同じです。共通鍵を計算するためには、どちらか一方の秘密鍵を知っている必要があるため、これを行えるのはサーバーとクライアントだけです。
カーネルは共通鍵を使用して、対話鍵を復号します。
カーネルはキーサーバーを呼び出して、復号された対話鍵によりクライアントのタイムスタンプを復号します。
サーバーは、クライアントのタイムスタンプを復号した後、次の 4 種類の情報を資格テーブルに格納します。
クライアントのコンピュータ名
対話鍵
ウィンドウ
クライアントのタイムスタンプ
サーバーは、最初の 3 つの情報を将来の使用のために格納します。サーバーはタイムスタンプを格納して、同じタイムスタンプが再度使用できないようにします。サーバーは、最後に参照したタイムスタンプよりも時間的に後のタイムスタンプだけを受け付けるため、同じタイムスタンプのトランザクションはすべて拒否されることが保証されます。
この手順において暗黙的に仮定されているのは呼び出し側の名前であり、何らかの方法でこの名前を認証しなければなりません。キーサーバーは、この目的には DES 認証を使用できません。DES 認証を使用すれば、デッドロックが発生するからです。キーサーバーは、 UID ごとに秘密鍵を格納し、ローカルの root プロセスへの要求だけを許可することによってこの問題を解決します。
サーバーは、ベリファイアをクライアントに返します。ベリファイアは、次の構成要素を持ちます。
サーバーが自分の資格キャッシュに記録するインデックス ID
対話鍵によって暗号化された、クライアントのタイムスタンプから 1 を引いたもの
タイムスタンプから 1 を引く理由は、これを無効化して、クライアントのベリファイアとして再利用できないようにするためです。
クライアントがベリファイアを受信し、そのサーバーを認証します。クライアントは、このベリファイアを送信できるのはサーバーだけであることを知っています。その理由は、クライアントが送信したタイムスタンプの内容を知っているのはサーバーだけだからです。
一番目以降のすべてのトランザクションごとに、クライアントは 2 番目のトランザクションでインデックス ID をサーバーに返し、もう 1 つの暗号化されたタイムスタンプを送信します。サーバーは、クライアントのタイムスタンプから 1 を引いたものを対話鍵で暗号化して、返送します。
Kerberos は、マサチューセッツ工科大学 (MIT) で開発された認証システムです。Kerberos は DES 暗号化を使用して、システムのログイン時にユーザーを認証します。認証は、送信側のシステムが共通鍵を使用して現在の時刻を暗号化する機能を利用します。受信側のシステムは、その現在の時刻を復号し、自分の時刻と照合します。Kerberos Version 4 は、Solaris 2.6 リリースでサポートされています。
Kerberos は、ユーザーのログインパスワードを認証することによって動作します。ユーザーは、kinit コマンドを入力します。このコマンドは、Kerberos 認証サーバーから、セッション時間 (デフォルトのセッション時間は 8 時間) の間だけ有効であるチケットを取得します。ユーザーがログアウトするとき、このチケットは (kdestroy コマンドで) 削除できます。
Kerberos ソフトウェアは、MIT プロジェクト Athena から入手できます。Kerberos ソフトウェアは SunOS 5.x ソフトウェアの一部ではありません。SunOS 5.x ソフトウェアが提供するものは、次のとおりです。
クライアントがチケットを作成、取得、および確認するために使用するコマンドと API
Secure RPC の認証オプション
クライアント側デーモン kerbd(1M)
「NFS による Kerberos 認証の実装」に、Kerberos 認証手順の動作の概要を示します。
Solaris は、Kerberos 機能に接続できる機能を提供します。Solaris は Kerberos パッケージを提供しません。ただし、ユーザー名として anonymous を、パスワードとして電子メールのアドレスを使用することによって、athena-dist.mit.edu から Kerberos 4 のソースを ftp で入手できます。このソースは、ディレクトリ pub/kerberos にあります。
次の手順では、MIT プロジェクト Athena から公開されている Kerberos キー配布センターのソースを使用して、Kerberos キー配布センター (KDC) がすでにネットワーク上にインストールされていると仮定しています。
/usr/sbin/kerbd デーモンが NFS クライアントとサーバー上で動作していなければなりません。
このデーモンは、通常、inetd によって必要に応じて起動されます。rpcinfo コマンドを使用すれば、kerbd サービスが登録されていることを確認できます。kerbd はユーザーモードデーモンです。kerbd は、カーネル RPC および KDC とインターフェースを取ります。kerbd は、認証チケットを生成してその妥当性を検査します。
システム管理者は、Kerberos 認証を使用するように NFS サーバーを設定します。
MIT Kerberos ソフトウェアは、Kerberos サーバー上で Kerberos キー配布センター (KDC) に主体名を登録するのに使用されます。次のエントリが必要です。
root.hostname (NFS クライアントごとに必要)
nfs.hostname (NFS サーバーごとに必要)
ユーザーは、共有ファイルシステムをマウントします。
共有ファイルシステムをマウントするために、クライアント上のユーザーは、クライアント上で root 用のチケットを取得しなければなりません。
ユーザーは、kinit コマンドを使用して、Kerberos サービスにログインします。
Kerberos 認証サーバーは、要求を認証して、チケット譲与サービス用のチケットを与えます。
ユーザーは、マウント済みディレクトリにアクセスします。
kerbd デーモンは、クライアントのために、ファイルシステムをエクスポートしている NFS サーバー用のチケットを自動的に取得します。この時点で、2 つの有効なチケットがあります。オリジナルのチケット譲与チケットと、サーバー用のチケットです。
ユーザーは、セッションの終わりにチケットを削除して、誤用と悪用を防ぎます。
kdestroy コマンドは、チケットを含むファイルにゼロを書き込むことによって、ユーザーのアクティブな Kerberos 認証チケットを削除します。kdestroy コマンドを .logout ファイルに置いておけば、システムからログアウトするときに、すべての kdestroy チケットを自動的に破壊できます。
セッションが終了する前にチケットが削除されていた場合、ユーザーは kinit コマンドで新しいチケットを要求しなければなりません。
システム管理者は、ネットワークを安全にするためのポリシーをネットワーク上に実装できます。必要なセキュリティのレベルはサイトによって異なります。この節では、ネットワークセキュリティに関連するいくつかの作業手順を説明します。
スーパーユーザーになります。
keyserv デーモン (キーサーバー) が動作していることを確認します。
# ps -ef | grep keyserv root 100 1 16 Apr 11 ? 0:00 /usr/sbin/keyserv root 2215 2211 5 09:57:28 pts/0 0:00 grep keyserv
キーサーバーが動作していない場合は、キーサーバーを起動します。
# /usr/sbin/keyserv |
NIS+ セキュリティの詳細は、『Solaris ネーミングの管理』を参照してください。
スーパーユーザーになります。
/etc/nsswitch.conf ファイルを編集して、次の行を追加します。
publickey: nisplus
NIS+ クライアントを起動します。
# nisinit -cH hostname
hostname は、そのテーブルにクライアントマシン用のエントリを持つ、信頼されている NIS+ サーバー名です。
次のコマンドを入力して、クライアントを cred テーブルに追加します。
# nisaddcred local # nisaddcred des
keylogin コマンドを使用して、設定を確認します。
パスワードを求めるプロンプトが出たら、この手順は成功です。
次の例は、ホスト pluto を使用して、earth を NIS+ クライアントとして設定しています。警告は無視できます。keylogin コマンドが受け付けられて、earth が Secure NIS+ クライアントとして正しく設定されていることを確認しています。
# nisinit -cH pluto NIS Server/Client setup utility. This machine is in the North.Abc.COM. directory. Setting up NIS+ client ... All done. # nisaddcred local # nisaddcred des DES principal name : unix.earth@North.Abc.COM Adding new key for unix.earth@North.Abc.Com (earth.North.Abc.COM.) Network password: xxx <Press Return> Warning, password differs from login password. Retype password: xxx <Press Return> # keylogin Password: #
次のコマンドを入力して、ユーザーを root マスターサーバー上の cred テーブルに追加します。
# nisaddcred -p unix.UID@domainname -P username.domainname. des
この場合、「username-domainname」はドット (.) で終了しなければなりません。
次の例は、DES セキュリティ認証をユーザー george に与えています。
# nisaddcred -p unix.1234@North.Abc.com -P george.North.Abc.COM. des DES principal name : unix.1234@North.Abc.COM Adding new key for unix.1234@North.Abc.COM (george.North.Abc.COM.) Password: Retype password: # rlogin rootmaster -l george # keylogin Password: #
クライアント上でスーパーユーザーになります。
/etc/nsswitch.conf ファイルを編集して、次の行を追加します。
publickey: nis |
newkey コマンドを使用して、新しい鍵ペアを作成します。
# newkey -h hostname
hostname は、クライアント名です。
次の例は、earth を Secure NIS クライアントとして設定しています。
# newkey -h earth Adding new key for unix.earth@North.Abc.COM New Password: Retype password: Please wait for the database to get updated... Your new key has been successfully stored away. #
サーバーにスーパーユーザーとしてログインします。
ユーザー用の新しい鍵を作成できるのは、NIS+ サーバーにログインしたシステム管理者だけです。
ユーザー用の新しい鍵を作成します。
# newkey -u username
username はユーザー名です。システムはパスワードを求めるプロンプトを出します。システム管理者は汎用パスワードも入力できます。非公開鍵は汎用パスワードで暗号化されて格納されます。
# newkey -u george Adding new key for unix.12345@Abc.North.Acme.COM New Password: Retype password: Please wait for the database to get updated... Your new key has been successfully stored away. #
ログインして chkey -p コマンドを入力するように、ユーザーに伝えます。
これによって、そのユーザーは自分だけが知っているパスワードを使用して、自分の非公開鍵を再び暗号化できます。
earth% chkey -p Updating nis publickey database. Reencrypting key for unix.12345@Abc.North.Acme.COM Please enter the Secure-RPC password for george: Please enter the login password for george: Sending key change request to pluto... #
chkey コマンドを使用すると、新しい鍵ペアをユーザーに作成できます。
Diffie-Hellman の publickey 認証がネットワークで有効にされていなければなりません。「Diffie-Hellman 認証明に NIS+ 資格を設定する方法」と 「Diffie-Hellman 認証で NIS 資格を設定する方法」を参照してください。
スーパーユーザーになります。
Diffie-Hellman 認証でファイルシステムをマウントします。
# mount -F nfs -o sec=dh server:resource mountpoint
システム管理者は、ネットワークを安全にするためのポリシーをネットワーク上に実装できます。必要なセキュリティのレベルはサイトによって異なります。この節では、ネットワークセキュリティに関連するいくつかの作業手順を説明します。
Kerberos Version 4 認証がネットワークで有効にされていなければなりません。
アクセスする必要がある NFS ファイルシステムがマウントされていない場合、マウントする前に、クライアント上でスーパーユーザー用のチケットを取得する必要があります。
スーパーユーザーになります。
クライアント上で Kerberos チケットを取得します。
# kinit root.hostname
hostname はクライアントシステム名です。
# kinit root.earth Password: #
/etc/srvtab 構成ファイルにクライアント用のエントリ root.hostname が入力されている場合、ksrvtgt コマンドを使用して、スーパーユーザー用のチケットを取得できます。この場合、スーパーユーザーのパスワードを指定する必要はありません。/etc/srvtab ファイルの初期化については、MIT のマニュアルを参照してください。
# ksrvtgt root.earth #
Kerberos サービスにログインするには、kinit -l username コマンドを使用します。
earth% kinit -l username |
kinit コマンドは、チケットの生存期間 (-l オプションを指定した場合) とパスワードを求めるプロンプトを出します。冗長モード (-v オプション) を使用すれば、チケットの状態が出力されます。
earth% kinit -l jjones SunOS (earth) Kerberos Initialization for "jjones" Kerberos ticket lifetime (minutes): 480 Password: earth%
klist と入力します。
earth% klist Ticket file: /tmp/tkt8516 Principal: jjones@North.Abc.COM Issued Expires Principal Jan 14 20:40:54 Jan 15:04:40:54 krbtgt.North.Abc.COM@North.Abc.COM
cd /mountpoint と入力します。
他のマウント済みディレクトリと同様に、マウント済みディレクトリにアクセスします。ls コマンドでディレクトリ中のファイルをリストしたり、klist コマンドで Kerberos チケットをリストしたりできます。
次の例では、ユーザー jjones はマウント済みの mntkrb ディレクトリに移動して、このディレクトリ内のファイルをリストしています。
kerbd デーモンは、ユーザーの代わりに、ファイルシステムをエクスポートしている NFS サーバー用のチケットを自動的に取得します。この時点で、2 つの有効なチケットがあります。オリジナルのチケット譲与チケットとサーバー用のチケットです。klist でこれら 2 つのチケットをリストします。
earth% cd /mntkrb earth% ls -l /mntkrb -rw-r--r-- 1 marks staff 29 Jul 14 12:22 sports drwxr-xr-x 3 jjones staff 512 Sep 13 13:44 market earth% klist Ticket file: /tmp/tkt8516 Principal: jjones@North.Abc.COM Issued Expires Principal Jan 14 20:40:54 Jan 15:04:40:54 krbtgt.North.Abc.COM@North.Abc.COM Jan 14 20:43:21 Jan 15:04:43:21 nfs.pluto@North.Abc.COM
kdestroy を入力します。
セッションが終了するときは、Kerberos チケットを削除します。これは、認証されていないユーザーがアクセスできないようにするためです。Kerberos 認証を再発行するには、kinit コマンドを使用します。
次の例は、Kerberos チケットを削除する方法を示しています。削除後、ユーザーが Kerberos で保護されたディレクトリに移動したり、そのディレクトリの内容をリストしたりしようとすると、チケットサーバーがアクセスを拒否します。
earth% kdestroy Tickets destroyed earth% ls /mntkrb Can't get Kerberos key: No ticket file (tf_util) NFS getattr failed for server pluto: RPC: Authentication error can not access directory /mntkrb.
Pluggable Authentication Module (PAM) フレームワークを使用すると、login、ftp、telnet などのシステムに入るためサービスを変更しなくても、新しい認証技術を「プラグイン」できるようになります。また、PAM を使用すれば、 UNIX ログインを DCE や Kerberos のような他のセキュリティ機構と統合できます。また、アカウント、セッション、およびパスワードの管理機構もプラグインできます。
PAM フレームワークを使用すると、システム管理者は任意のシステムに入るため、サービス (ftp、login、telnet、rsh など) とユーザー認証用を組み合わせることができます。次に PAM の利点をいくつか挙げます。
エンドユーザーにも使いやすい
機構が異なってもパスワードが同じであれば、パスワードを再入力する必要がない
各認証方法に関連するパスワードが異なっている場合でも、パスワードマッピング機能により、複数の認証方法で 1 つのパスワードを使用する機能
ユーザーが複数のコマンドを入力しなくても、複数の認証方法のパスワードを求めるプロンプトを出す機能
オプションパラメタをユーザー認証サービスに渡す機能
PAM は、実行時に取り外しが可能なモジュールを使用して、システムに入るためのサービスに認証を提供します。これらのモジュールは、その機能に基づき、4 つの異なるタイプに分かれます。認証、アカウント管理、セッション管理、およびパスワード管理です。スタッキング機能によって、複数のサービス経由でユーザーを認証できます。また、パスワードマッピング機能によって、ユーザーは複数のパスワードを覚えておく必要がありません。
モジュールタイプはモジュールのインターフェースを定義するため、PAM モジュールのタイプを理解することは重要です。実行時 PAM モジュールには、次の 4 つのタイプがあります。
「認証モジュール」は、ユーザーの認証を提供して、資格を設定、更新、または削除できます。認証モジュールは、ユーザーの識別に役立つ管理ツールを提供します。
「アカウントモジュール」は、パスワードの有効期限、アカウントの有効期限、およびアクセス時間制限をチェックします。アカウントモジュールは、認証モジュールでユーザーを識別した後に、そのユーザーにアクセス権を与えるべきかどうかを決定します。
「セッションモジュール」は、認証セッションの開閉を管理します。セッションモジュールは、動作を記録したり、セッション終了後のクリーンアップを実行したりできます。
「パスワードモジュール」によって、実際のパスワードを変更できます。
PAM フレームワークは、「スタッキング機能」を使用して、複数のサービスでユーザーを認証する方法を提供します。構成によって、認証方法ごとにパスワードを求めるプロンプトをユーザーに出すことも可能です。認証サービスが使用される順序は、PAM 構成ファイルで決定されます。
スタッキング機能をを使った方法では、ユーザーが複数のパスワードを覚えておかなければなりません。「パスワードマッピング機能」を使用すれば、主要パスワードから他のパスワードを復号できるので、ユーザーは複数のパスワードを覚えたり入力したりする必要はありません。各認証機構間でパスワードの同期を取るためのオプションもあります。スタック内で使用される最も安全性の低いパスワードによって各機構のセキュリティが制限されてしまうので、この方法はセキュリティの危険性を増大してしまうことに注意してください。
PAM ソフトウェアは、ライブラリ、いくつかのモジュール、および構成ファイルからなります。いくつかのシステムに入るためのコマンドまたはデーモンの新しいバージョンは、PAM インタフェースを利用できます。
図 15-1 は、アプリケーション、PAM ライブラリ、pam.conf ファイル、および PAM モジュール間の関係を示しています。
アプリケーション (ftp、telnet、および login) は、PAM ライブラリを使用して、適切なモジュールにアクセスします。pam.conf ファイルは、使用するモジュールを定義して、各アプリケーションがモジュールを使用する順番を定義します。モジュールからの応答は、ライブラリ経由でアプリケーションに戻されます。
次の節では、この関係について説明します。
PAM ライブラリ /usr/lib/libpam は、適切なモジュールをロードして、スタッキング手順を管理するためのフレームワークを提供します。また、すべてのモジュールを取り外すことができる汎用構造も提供します。
各 PAM モジュールは、特定の機構を実装します。PAM 認証を設定するときは、モジュールとモジュールタイプの両方を指定する必要があります。モジュールタイプは、モジュールが実行する処理を定義します。複数のモジュールタイプ (auth、account、session、または password) を各モジュールに関連付けることができます。
次のリストで各 PAM モジュールについて説明します。
pam_unix モジュール /usr/lib/security/pam_unix.so.1 は、認証、アカウント管理、セッション管理、およびパスワード管理に使用できます。このモジュールでは、4 種類すべてのモジュールタイプの定義が使用できます 。このモジュールは、UNIX パスワードを認証に使用します。Solaris 環境では、パスワードを取得するための適切なネームサービスの選択は、/etc/nsswitch.conf ファイルで制御されます。詳細は、pam_unix(5) のマニュアルページを参照してください。
dial_auth モジュール /usr/lib/security/pam_dial_auth.so.1 は、認証だけに使用できます のマニュアルページを参照してください)。このモジュールは、/etc/dialups ファイルと /etc/d_passwd ファイルに格納されたデータを認証するのに使用します。このモジュールは主に login で使用されます。詳細については、pam_dial_auth(5) のマニュアルページを参照してください。
rhosts_auth モジュール /usr/lib/security/pam_rhosts_auth.so.1 も、認証だけに使用できます。このモジュールは、‾/.rhosts ファイルと /etc/hosts.equiv ファイルに格納されたデータを ruserok 経由で使用します。このモジュールは、主に rlogin コマンドと rsh コマンドで使用されます 。詳細については、pam_rhosts_auth(5) のマニュアルページを参照してください。
セキュリティ上の理由から、これらのモジュールファイルの所有者は root でなければならず、また、その書き込み権を group と other に与えてはなりません。ファイルの所有者が root でない場合、PAM はモジュールをロードしません。
PAM 構成ファイル /etc/pam.conf は、使用する認証サービスとそれらを使用する順序を決定します。このファイルを編集すれば、システムに入るためのアプリケーションごとに認証機構を選択できます。
PAM 構成ファイルは、次の構文のエントリからなります。
service_name module_type control_flag module_path module_options |
service_name |
サービス名 (たとえば、ftp、login、telnet など) |
module_type |
サービスのモジュールタイプ |
control_flag |
モジュールの継続または失敗の意味を決定する |
module_path |
サービス機能を実装するライブラリオブジェクトのパス |
module_options |
サービスモジュールに渡される特定のオプション |
pam.conf ファイルにコメントを追加するには、その行を # (ポンド記号) で始めます。フィールドを区切るには、空白を使用します。
次の 3 つの状態のいずれかが存在する場合、PAM 構成ファイル内のエントリは無視されます。(1) 行のフィールド数が 4 つより少ない。(2) module_type または control_flag に無効な値が指定されている。(3) 指定したモジュールが見つからない。
表 15-1 は、有効なサービス名、そのサービスで使用できるモジュールタイプ、およびサービス名に関連するデーモンまたはコマンドを示しています。
サービスごとに適切でないモジュールタイプもいくつかあります。たとえば、password モジュールタイプは、passwd コマンドだけに指定できます。このコマンドは認証には関連しないので、このコマンドに関連する auth モジュールタイプはありません。
表 15-1 /etc/pam.conf の有効なサービス名
サービス名 |
デーモンまたはコマンド |
モジュールタイプ |
---|---|---|
dtlogin |
/usr/dt/bin/dtlogin |
auth、account、session |
ftp |
/usr/sbin/in.ftpd |
auth、account、session |
init |
/usr/sbin/init |
session |
login |
/usr/bin/login |
auth、account、session |
passwd |
/usr/bin/passwd |
password |
rexd |
/usr/sbin/rpc.rexd |
auth |
rlogin |
/usr/sbin/in.rlogind |
auth、account、session |
rsh |
/usr/sbin/in.rshd |
auth、account、session |
sac |
/usr/lib/saf/sac |
session |
su |
/usr/bin/su |
auth、account、session |
telnet |
/usr/sbin/in.telnetd |
auth、account、session |
ttymon |
/usr/lib/saf/ttymon |
session |
uucp |
/usr/sbin/in.uucpd |
auth、account、session |
認証プロセス中にモジュールの処理を継続するか失敗するかを決定するには、エントリごとに 4 つの制御フラグの 1 つを選択しなければなりません。制御フラグは、各モジュールで正常終了と異常終了がどのように処理されるかを示します。これらのフラグはすべてのモジュールに適用されますが、次の説明では、これらのフラグは認証モジュールで使用されていると仮定します。制御フラグは、次のとおりです。
required - 最終的に成功を返すためには、このモジュールが正常終了を返さなければなりません。
すべてのモジュールに required フラグを付けた場合、ユーザーの認証が成功するには、すべてのモジュールの認証が成功しなければなりません。
一部のモジュールが失敗した場合、最初に失敗したモジュールのエラー値が報告されます。
required フラグを付けたモジュールが失敗しても、スタック中のすべてのモジュールは継続して処理されますが、異常終了が返されます。
どのモジュールにも required フラグを付けなかった場合、ユーザーの認証が成功するには、そのサービスの少なくとも 1 つのエントリが成功しなければなりません。
requisite - 後続の認証が行われるには、このモジュールが正常終了を返さなければなりません。
requisite フラグの付いたモジュールが失敗した場合、すぐにエラーがアプリケーションに返され、それ以上認証は行われません。スタック中で、このモジュールより前に required というラベルの付いたモジュールが失敗していなければ、このモジュールからのエラーが返されます。このモジュールより前に、required というラベルの付いたモジュールが失敗している場合は、required モジュールからのエラーメッセージが返されます。
optional - このモジュールが失敗した場合、このスタック内の他のモジュールが正常終了を戻せば、最終的に成功が返される可能性があります。
optional フラグは、スタック内の 1 つのモジュールが成功すればユーザーの認証が成功するときに使用します。このフラグは、この認証機構が成功することが重要でない場合だけに使用します。
ユーザーが作業をするためには、特定の機構に関連する許可を取得する必要がある場合、そのモジュールに optional フラグを付けてはなりません。
sufficient - このモジュールが成功すると、スタック内の残りのモジュールは required フラグが付いていてもスキップされます。
sufficient フラグは、1 つの認証が成功すれば、ユーザーにアクセス権を与えてもかまわないことを示します。
これらのフラグの詳細は、デフォルトの /etc/pam.conf ファイルについて説明している 「PAM の構成」を参照してください。
次の例は、汎用 pam.conf ファイルを示しています。
# PAM configuration # Authentication management # login auth required /usr/lib/security/pam_unix.so.1 login auth required /usr/lib/security/pam_dial_auth.so.1 rlogin auth sufficient /usr/lib/security/pam_rhost_auth.so.1 rlogin auth required /usr/lib/security/pam_unix.so.1 dtlogin auth required /usr/lib/security/pam_unix.so.1 telnet auth required /usr/lib/security/pam_unix.so.1 su auth required /usr/lib/security/pam_unix.so.1 ftp auth required /usr/lib/security/pam_unix.so.1 uucp auth required /usr/lib/security/pam_unix.so.1 rsh auth required /usr/lib/security/pam_rhost_auth.so.1 OTHER auth required /usr/lib/security/pam_unix.so.1 # # Account management # login account required /usr/lib/security/pam_unix.so.1 rlogin account required /usr/lib/security/pam_unix.so.1 dtlogin account required /usr/lib/security/pam_unix.so.1 telnet account required /usr/lib/security/pam_unix.so.1 ftp account required /usr/lib/security/pam_unix.so.1 OTHER account required /usr/lib/security/pam_unix.so.1 # # Session management # login session required /usr/lib/security/pam_unix.so.1 rlogin session required /usr/lib/security/pam_unix.so.1 dtlogin session required /usr/lib/security/pam_unix.so.1 telnet session required /usr/lib/security/pam_unix.so.1 uucp session required /usr/lib/security/pam_unix.so.1 OTHER session required /usr/lib/security/pam_unix.so.1 # # Password management # passwd password required /usr/lib/security/pam_unix.so.1 OTHER password required /usr/lib/security/pam_unix.so.1
この汎用 pam.conf ファイルは、次の内容を指定しています。
login を実行するとき、pam_unix モジュールと pam_dial_auth モジュールの両方による認証が成功しなければなりません。
rlogin を実行するとき、pam_unix モジュールによる認証が失敗した場合は、pam_rhost_auth モジュールによる認証が成功しなければなりません。
sufficient 制御フラグは、rlogin の場合は、pam_rhost_auth モジュールによる認証が成功すれば十分であり、次のエントリが無視されることを示しています。
認証を必要とする他のほとんどのコマンドの場合、pam_unix モジュールによる認証が成功しなければなりません。
rsh の場合、pam_rhost_auth モジュールによる認証が成功しなければなりません。
OTHER サービス名を使用すれば、認証を必要とするがこのファイルには含まれていない他のコマンドに対するデフォルトとして設定できます。OTHER オプションを使用すると、同じモジュールを使用する多数のコマンドを 1 つのエントリだけでカバーできるので、ファイルの管理が簡単になります。また、OTHER サービス名を「すべてを捕捉する」と言う意味で使用すると、1 つのモジュールですべてのアクセスをカバーできます。通常、OTHER エントリは、各モジュールタイプのセクションの最後に指定します。
ファイル内の残りのエントリは、アカウント、セッション、およびパスワードの管理を制御します。
デフォルトサービス名 OTHER を使用すると、汎用 PAM 構成ファイルは、次のように簡単になります。
# PAM configuration # # Authentication management # login auth required /usr/lib/security/pam_unix.so.1 login auth required /usr/lib/scurty/pam_dial_auth.so.1 rlogin auth sufficient /usr/lib/security/pam_unix.so.1 rlogin auth required /usr/lib/security/pam_rhost_auth.so.1 rsh auth required /usr/lib/security/pam_rhost_auth.so.1 OTHER auth required /usr/lib/security/pam_unix.so.1 # # Account management # OTHER account required /usr/lib/security/pam_unix.so.1 # # Session management # OTHER session required /usr/lib/security/pam_unix.so.1 # # Password management # OTHER password required /usr/lib/security/pam_unix.so.1
通常、module_path のエントリには「ルートからのパス名」を指定します。module_path に入力したファイル名がスラッシュ (/) で始まらない場合、そのファイル名の前にパス /usr/lib/security/ が付きます。モジュールが他のディレクトリにある場合は、フルパスを使用しなければなりません。
module_options の値については、そのモジュールのマニュアルページ (たとえば、pam_unix(5)) を参照してください。
pam_unix モジュールでサポートされている use_first_pass オプションと try_first_pass オプションを使用すると、ユーザーは認証用の同じパスワードを再入力しなくても再利用できます。
login が pam_local と pam_unix の両方による認証を指定した場合、ユーザーは、モジュールごとにパスワードを入力するようにプロンプトが表示されます。パスワードが同じ場合、use_first_pass モジュールオプションを使用すれば、パスワードの入力を求めるプロンプトは 1 度だけ表示されます。そのパスワードを両方のモジュールで使用して、ユーザーを認証します。パスワードが異なる場合、認証は失敗します。通常、このオプションは、次に示すように、optional 制御フラグといっしょに使用して、依然としてユーザーのログインが可能なようにします。
# Authentication management # login auth required /usr/lib/security/pam_unix.so.1 login auth optional /usr/lib/security/pam_local.so.1 use_first_pass
try_first_pass モジュールオプションを代わりに使用すると、パスワードが一致しなかった場合またはエラーが発生した場合、ローカルモジュールは、2 番目のパスワードを求めるプロンプトを表示します。必要なすべてのツールにアクセスするために、ユーザーが両方の認証方法を必要とする場合、このオプションを使用すると 1 つのタイプの認証だけでアクセスできるので、ユーザーが混乱する場合があります。
この節では、PAM のフレームワークを完全に機能させるために必要な作業について説明します。特に、PAM 構成ファイルに関連するセキュリティのいくつかの問題について注意する必要があります。
どのように PAM を使用すればユーザーのサイトに最適であるかを決定するために、次の問題から始めます。
何が必要か、特にどのモジュールを選択するかを決定します。
特別な注意が必要なサービスを確認します。適宜、OTHER を使用します。
モジュールを実行する順番を決定します。
そのモジュールに対する制御フラグを選択します。
モジュールに必要な任意のオプションを選択します。
ここで、構成ファイルを変更する前に考慮すべき問題を示します。
すべてのアプリケーションを指定しなくてもいいように、モジュールタイプごとに OTHER エントリを使用します。
sufficient 制御フラグと optional 制御フラグのセキュリティの意味を考慮します。
モジュールに関連するマニュアルページを参照して、各モジュールがどのように機能するか、どのオプションが使用できるか、およびスタック中のモジュール間の相互作用を理解します。
PAM 構成ファイルの構成を間違えたり壊したりすると、スーパーユーザーでもログインできなくなる可能性があります。sulogin は PAM を使用しないので、スーパーユーザーは、マシンをシングルユーザーモードでブートして問題を解決しなければなりません。
/etc/pam.conf ファイルの変更後、スーパーユーザーとしてログインしている間にできるだけ調査します。変更によって影響を受けるコマンドは、すべてテストします。たとえば、新しいモジュールを telnet サービスに追加した場合、telnet コマンドを使用して、行なった変更が期待どおりに動作しているかどうかを確認します。
スーパーユーザーになります。
使用される制御フラグやオプションを決定します。
モジュールについては、「PAM モジュール」を参照してください。
新しいモジュールを /usr/lib/security にコピーします。
モジュールファイルの所有者が root で、そのアクセス権が 555 になるように、アクセス権を設定します。
PAM 構成ファイル /etc/pam.conf を編集して、このモジュールを適切なサービスに追加します。
構成ファイルが間違って構成されていた場合などのために、システムをリブートする前にテストすることは非常に重要です。システムをリブートする前に、rlogin、su、および telnet を実行します。サービスが、システムがブートするときだけに生成されるデーモンの場合は、システムをリブートしなければ、モジュールが正しく追加されていることを確認できません。
PAM 構成ファイルから「rlogin auth rhosts_auth.so.1」エントリを削除します。これによって、rlogin セッション中、‾/.rhosts ファイルは読み込まれなくなります。したがって、リモートシステムからローカルシステムへの認証されていないアクセスを防ぐことができます。‾/.rhosts ファイルまたは /etc/hosts.equiv ファイルの存在またはその内容にかかわらず、すべての rlogin アクセスにはパスワードが必要になります。
‾/.rhosts ファイルへの認証されていない他のアクセスを防ぐには、rsh サービスも無効にする必要があります。サービスを無効にする最良の方法は、/etc/inetd.conf からサービスエントリを削除することです。PAM 構成ファイルを変更しても、サービスを無効にはできません。
/etc/syslog.conf を編集して、次の PAM のエラー報告に関するエントリを追加します。
syslog デーモンを再起動するか、SIGHUP シグナルをこのデーモンに送信して、PAM のエラー報告を有効にします。
次の例では、警戒メッセージはすべてコンソールに表示されます。致命的なメッセージは root に電子メールで送信されます。情報メッセージとデバッグ用メッセージは、/var/log/pamlog ファイルに追加されます。
auth.alert /dev/console auth.crit 'root' auth.info;auth.debug /var/log/pamlog
ログ内の各行は、タイムスタンプ、メッセージを生成したシステム名とメッセージ自身からなります。pamlog ファイルには、大量の情報が記録される可能性があります。
この章では、自動セキュリティ拡張ツール (ASET) を使用して、システムファイルおよびディレクトリへのアクセスを監視または制限する方法について説明します。
この章で説明する手順は次のとおりです。
SunOS 5.7 システムソフトウェアには、自動セキュリティ拡張ツール (ASET) が組み込まれています。ASET を使用すると、他の場合には手作業で実行する作業が自動的に実行され、システムのセキュリティを監視して制御できます。
ASET セキュリティパッケージには、システムのセキュリティを制御して監視できるように、自動管理ツールが組み込まれています。ASET を実行するとセキュリティレベルとして、低、中、または高レベルを指定できます。上のレベルほど、ASET のファイル制御機能が増え、ファイルアクセスが減少し、システムセキュリティが厳しくなります。
ASET に関連して 7 つのタスクがあり、それぞれがシステムファイルに対して特定のチェックと調整を行います。ASET のタスクはファイルのアクセス権を厳格にし、重要なシステムファイルの内容にセキュリティ上の弱点がないかどうかをチェックし、重要な領域を監視します。ASET は、ゲートウェイシステムとして機能するシステムにファイアウォールシステムの基本要件を適用し、ネットワークを保護できます (詳細は、「ファイアウォールの設定」を参照してください)。
ASET は、構成用のマスタファイルを使用します。マスタファイルやレポートなどの ASET ファイルは、ディレクトリ /usr/aset にあります。これらのファイルは、サイトの特定の要件に合わせて変更できます。
各タスクは、検出されたセキュリティ上の弱点と、システムファイルに対して行なった変更を示すレポートを生成します。上位のセキュリティレベルで実行すると、ASET はシステムセキュリティ上の弱点をすべて変更しようとします。潜在的なセキュリティ問題を解決できなければ、ASET は問題の存在を報告します。
/usr/aset コマンドを対話的に実行すると、ASET セッションを開始できます。また、crontab ファイルにエントリを追加すると、ASET を定期的に実行するように設定できます。
ASET のタスクはディスクをかなり使用するため、通常の活動の妨げになることがあります。システム性能に及ぼす影響を最小限度に抑えるために、24 時間ごとまたは 48 時間ごとに深夜など、システムの稼働レベルが最も低いときに ASET を実行するようにスケジュールしてください。
ASET は、低、中、高の 3 つのセキュリティレベルのいずれかで動作するように設定できます。上のレベルほど、ASET のファイル制御機能が増え、ファイルアクセスが減少し、システムのセキュリティが厳しくなります。これらの機能には、ユーザーによるファイルアクセスを制限せずにシステムセキュリティを監視する最低レベルから、システムが完全にセキュリティ保護される最高レベルまで、アクセス権が段階的に厳格になります。
次に、この 3 つのセキュリティレベルについて説明します。
低セキュリティ - このレベルでは、ファイルシステムの属性が標準リリース値に設定されることが保証されます。ASET は複数のチェックを実行し、セキュリティ上の潜在的な弱点を報告します。このレベルでは、ASET は動作せず、システムサービスは影響を受けません。
中セキュリティ - このレベルでは、ほとんどの環境で十分にセキュリティが制御されます。ASET はシステムファイルとパラメタの設定の一部を変更し、システムアクセスを制限し、セキュリティ上の攻撃によるリスクを減少させます。ASET は、セキュリティ上の弱点と、アクセスを制限するために行なった変更を報告します。このレベルでは、ASET はシステムサービスに影響しません。
高セキュリティ - このレベルでは、システムに高度なセキュリティが適用されます。ASET は多数のシステムファイルとパラメタの設定を調整して、アクセス権を最小限度に抑えます。ほとんどのシステムアプリケーションとコマンドは引き続き正常に機能しますが、このレベルではシステム動作よりもセキュリティ上の検討事項が優先されます。
セキュリティレベルを下げるか、システムを ASET 実行前の設定に意図的に戻さなければ、ASET によってファイルのアクセス権が緩められることはありません。
この節では、ASET のタスクについて説明します。レポートを解釈して活用するには、各 ASET のタスク、つまり、その目的、実行される処理、および影響を受けるシステム構成要素を理解しておく必要があります。
ASET のレポートファイルには、各 ASET タスクで検出された問題をできるだけ詳細に記述するメッセージが入っています。これらのメッセージを調べると、問題を診断して解決できます。ただし、ASET を活用するには、システム管理とシステム構成要素を全般的に理解していることが前提となります。管理者になったばかりの方は、他の SunOS 5.x システム管理マニュアルと関連するマニュアルページを参照して、ASET の管理の概要を把握してください。
taskstat ユーティリティは、完了したタスクとまだ実行中のタスクを識別します。完了したタスクごとにレポートファイルが生成されます。taskstat ユーティリティの詳細は、taskstat(1M) のマニュアルページを参照してください。
このタスクでは、システムファイルのアクセス権が指定したセキュリティレベルに設定されます。このタスクは、システムをインストールするときに実行されます。以前に設定したレベルを後から変更したい場合は、このタスクをもう一度実行してください。低セキュリティレベルでは、アクセス権は開放型の情報共有環境に適した値に設定されています。中セキュリティレベルでは、アクセス権はほとんどの環境に十分なセキュリティが適用される程度に厳格です。高セキュリティレベルでは、アクセスが厳しく制限されます。
このタスクによってシステムファイルのアクセス権やパラメタの設定に加えられた変更は、tune.rpt ファイル内でレポートされます。アクセス権を設定するときに ASET が参照するファイルの例については、「調整ファイル」を参照してください。
このタスクでは、システムファイルが検査され、マスタファイル内にリストされたファイルの記述と比較されます。マスタファイルは、ASET がこのタスクを実行すると初めて作成されます。マスタファイルには、指定したセキュリティレベル checklist によって適用されるシステムファイル設定が入っています。
ファイルがチェックされるディレクトリのリストは、セキュリティレベルごとに定義されます。デフォルトのリストを使用するか、レベルごとに異なるディレクトリを指定して変更できます。
ファイルごとに次の基準がチェックされます。
所有者とグループ
アクセス権ビット
サイズとチェックサム
リンク数
最終変更時刻
矛盾が見つかると、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/utmp
/var/adm/utmpx
/.rhosts
/etc/vfstab
/etc/dfs/dfstab
/etc/ftpusers
ASET は、これらのファイルに関して各種のチェックと変更を実行し、すべての問題を sysconf.rpt ファイル内でレポートします。
このタスクでは、root 用とその他ユーザー用の PATH 環境変数と UMASK 環境変数が /.profile、/.login、/.cshrc ファイル内でどのように設定されているかがチェックされます。
環境のセキュリティ状況をチェックした結果は、env.rpt ファイル内でレポートされます。
このタスクでは、eeprom セキュリティパラメタの値がチェックされ、適切なセキュリティレベルに設定されているかどうかが確認されます。eeprom セキュリティパラメタは、none、command、または full に設定できます。
ASET はこの設定を変更しませんが、推奨値を eeprom.rpt ファイル内でレポートします。
このタスクでは、システムをネットワークリレーとして安全に使用できることが保証されます。「ファイアウォールシステム」で説明したように、ファイアウォール専用システムが設定され、内部ネットワークが外部の公共ネットワークから保護されます。ファイアウォールシステムは、相互に信頼されない (untrusted) システムとしてアクセスし合う 2 つのネットワークを分離します。ハードウェアの設定作業によって、インターネットプロトコル (IP) パケットを転送できなくなり、ルーティング情報は外部ネットワークから隠されます。
ファイアウォールのタスクはすべてのセキュリティレベルで実行されますが、ファイアウォールとしての本来の機能は最上位レベルでのみ動作します。ASET を高セキュリティレベルで実行したいが、システムにはファイアウォール保護が不要であることがわかった場合は、asetenv ファイルを編集してファイアウォールタスクを除去できます。
行われた変更はすべて firewall.rpt ファイル内にレポートされます。
ASET を対話形式またはバックグラウンドで実行すると、実行ログが生成されます。デフォルトでは、ASET はログファイルを標準出力に生成します。実行ログは、ASET が指定された時刻に実行されたことを確認するもので、実行エラーメッセージも入っています。aset -n コマンドを使用すると、ログを指定したユーザーに電子メールで配信できます。ASET オプションのリストについては、aset(1M) のマニュアルページを参照してください。
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
第 1 のログは、ASET が実行されたシステムと時刻を示します。その後に、開始された各タスクがリストされています。
「ASET のタスク」で説明しているように、ASET はこれらのタスクごとにバックグラウンドプロセスを呼び出します。タスクは開始されると実行ログにリストされますが、これはタスクの完了を示しているわけではありません。バックグラウンドタスクの状態をチェックするには、taskstat ユーティリティを使用します。
ASET タスクから生成されたすべてのレポートファイルは、ディレクトリ /usr/aset/reports の下のサブディレクトリに入っています。この節では、/usr/aset/reports ディレクトリの構造と、レポートファイルを管理するためのガイドラインについて説明します。
ASET はレポートファイルを指定されたサブディレクトリに格納し、レポートの生成日時を反映させます。このため、ASET を実行するたびに変化するシステムの状態を示すレコードを順番に追跡できます。これらのレポートを監視し、比較して、システムセキュリティの状況を判断できます。
図 16-1 に 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 で実行された各タスクのレポートファイルが入っています。
各レポートファイルは、それを生成したタスクから取った名前が付けられます。表 16-1 にタスクとそのレポートのリストを示します。
表 16-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 を実行するか構成し直したら、レポートファイルを詳しく検査する必要があります (構成し直す作業には、サブディレクトリ masters 内の asetenv ファイルやマスタファイルの変更や、ASET が動作するセキュリティレベルの変更が含まれます)。レポートには、構成し直したために発生したエラーが記録されます。レポートを詳しく検査すると、問題が発生した時点で対処して解決できます。
構成上の変更やシステム更新がない期間中にレポートファイルを監視すると、レポートの内容が安定状態になり、予期しない情報が入っていてもわずかであることがわかります。diff ユーティリティを使用して、レポートを比較できます。
ASET のマスタファイル、tune.high、tune.low、tune.med、uid_aliases は、ディレクトリ /usr/aset/masters に入っています。ASET は、マスタファイルを使用してセキュリティレベルを定義します。
tune.low、tune.med、tune.high マスタファイルでは、利用できる ASET セキュリティレベルが定義されます。各ファイルでは、各レベルのシステムファイルの属性が指定され、比較と参照に使用されます。
uid_aliases ファイルには、同じ ID を共有する複数のユーザーアカウントのリストが入っています。この種のアカウントがあると責任の所在があいまいになるので、通常は ASET が警告を出します。uid_aliases ファイル内で例外をリストすると、この規則に例外を設けることができます。重複するユーザー ID を持つ passwd ファイル内のエントリを uid_aliases ファイル内で指定しておくと、これらのエントリは ASET でレポートされません。
複数のユーザーアカウント (パスワードエントリ) に同じユーザー ID を共有させないでください。他の方法で目的を達成することを検討する必要があります。たとえば、複数のユーザーにアクセス権一式を共有させたい場合は、グループアカウントを作成できます。ユーザー ID の共有は最後の手段であり、どうしても必要で、他の方法では目的を達成できない場合にだけに使用します。
環境変数 UID_ALIASES を使用すると、別の別名ファイルを指定できます。デフォルトは /usr/aset/masters/uid_aliases です。
システムファイルのチェックリストに使用されるマスターファイルは、初めて ASET を実行するときか、セキュリティレベルの変更後に ASET を実行するときに生成されます。
このタスクでチェックされるファイルは、次の環境変数で定義されます。
CKLISTPATH_LOW
CKLISTPATH_MED
CKLISTPATH_HIGH
環境ファイル asetenv には、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
/usr/aset/asetenv ファイルは、次の 2 つの主要セクションに分かれています。
ユーザーが構成できるパラメタセクション
内部環境変数セクション
ユーザーが構成できるパラメタセクションは変更できます。しかし、内部環境変数セクションの設定は内部使用専用で変更できません。
ユーザーが構成できるパラメタセクション内のエントリを編集して、次の作業を実行できます。
実行するタスクを選択する。
チェックリストタスク用のディレクトリを指定する。
ASET の実行スケジュールを指定する。
別名ファイルを指定する。
チェック対象を NIS+ テーブルまで拡張する。
ASET が実行する各タスクでは、システムセキュリティの特定の領域が監視されます。ほとんどのシステム環境では、すべてのタスクでバランスがとれたセキュリティ範囲を提供する必要があります。ただし、1 つ以上のタスクを除外してもかまいません。
たとえば、ファイアウォールタスクはすべてのセキュリティレベルで実行されますが、本来の機能は最上位レベルでのみ動作します。ASET を高セキュリティレベルで実行したいが、ファイアウォール保護は不要な場合があります。
asetenv ファイル内で環境変数の TASKS リストを編集すると、ファイアウォール機能を使用しないで高レベルで実行するように ASET を設定できます。デフォルトでは、TASKS リストにはすべての ASET タスクが入っています (次の例を参照してください)。タスクを削除するには、そのタスクの設定をファイルから削除します。この場合は、リストから firewall 環境変数を削除することになります。次回に ASET を実行すると、除外したタスクは実行されません。
TASKS="env sysconfig usrgrp tune cklist eeprom firewall"
システムファイルチェックでは、選択したシステムディレクトリ内のファイルの属性がチェックされます。次のチェックリストパス環境変数を使用して、どのディレクトリをチェックするかを定義できます。
CKLISTPATH_LOW
CKLISTPATH_MED
CKLISTPATH_HIGH
CKLISTPATH_LOW 変数は、低セキュリティレベルでチェックされるディレクトリを定義します。CKLISTPATH_MED と CKLISTPATH_HIGH 環境変数は、中程度と高度のセキュリティレベルに同じように機能します。
低セキュリティレベルの変数で定義したディレクトリリストは、1 つ上位レベルで定義するディレクトリリストのサブセットにする必要があります。たとえば、CKLISTPATH_LOW に定義したすべてのディレクトリを CKLISTPATH_MED に含め、CKLISTPATH_MED に指定したすべてのディレクトリを CKLISTPATH_HIGH に含めます。
これらのディレクトリに対して実行されるチェックは再帰的ではありません。ASET は変数内に明示的にリストされたディレクトリのみをチェックします。そのサブディレクトリはチェックされません。
これらの変数の定義を編集して、ASET にチェックさせたいディレクトリを追加または削除できます。これらのチェックリストは、一般に毎日変化しないシステムファイルにのみ有効なので注意してください。たとえば、ユーザーのホームディレクトリは動的な変化が大きすぎるので、チェックリストの候補にはならないのが普通です。
ASET を起動するときには、対話形式で起動する方法と、-p オプションを使用して ASET タスクをスケジュール指定した時刻と期間に実行する方法があります。ASET は、システム需要が少ないときに定期的に実行できます。たとえば、ASET は PERIODIC_SCHEDULE を照会して、ASET タスクの実行頻度と実行時刻を判断します。ASET を定期的に実行するように設定する方法については、「ASET を定期的に実行する方法」を参照してください。
PERIODIC_SCHEDULE の形式は、crontab エントリの形式と同じです。詳細は、crontab(1) のマニュアルページを参照してください。
UID_ALIASES 変数は、共有ユーザー ID がリストされる別名ファイルを指定します。 デフォルトは /usr/aset/masters/uid_aliases です。
YPCHECK 環境変数は、ASET でシステム構成ファイルテーブルもチェックするかどうかを指定します。YPCHECK はブール型変数なので、true または false しか指定できません。デフォルト値は false で、NIS+ テーブルのチェックは無効になっています。
この変数の機能を理解するために、passwd ファイルに与える影響を考えてみてください。この変数を false に設定すると、ASET はローカルの passwd ファイルをチェックします。true に設定すると、NIS+ の passwd ファイル内でシステムのドメインもチェックされます。
ASET ではローカルテーブルが自動的に修復されますが、NIS+ テーブル内の潜在的な問題はレポートされるだけで変更されません。
ASET は、3 つのマスタ調整ファイル、tune.low、tune.med、tune.high を使用して、重要なシステムファイルへのアクセス制限を緩めたり厳しくしたりします。この 3 つのマスタファイルは /usr/aset/masters ディレクトリに入っており、環境に合わせて調整できます。詳細は、「調整ファイル」を参照してください。
tune.low ファイルは、アクセス権をデフォルトのシステム設定に適した値に設定します。tune.med ファイルは、これらのアクセス権をさらに制限し、tune.low に含まれていないエントリを追加します。tune.high ファイルは、アクセス権をさらに厳しく制限します。
調整ファイル内の設定を変更するには、ファイルのエントリを追加または削除します。アクセス権を現在の設定よりも制限が緩やかになるような値に設定できません。システムセキュリティを下位レベルに下げない限り、ASET はアクセス権の制限を緩和しません。
ASET を初めて実行すると、元のシステムファイルが保存され保管されます。aset.restore ユーティリティは、これらのファイルを復元します。また、ASET を定期的に実行するようにスケジュール指定している場合は、そのスケジュールを解除します。aset.restore ユーティリティは、ASET の動作ディレクトリ /usr/aset に入っています。
システムファイルに対して行われた変更は、aset.restore を実行すると失われます。
次の場合に aset.restore を使用してください。
ASET の変更を削除して元のシステムを復元したい場合。ASET を永久に無効にしたい場合は、以前に root の crontab に aset コマンドが追加されていれば、cron スケジュールから削除できます。cron を使用して自動実行を削除する方法については、「ASET の定期的な実行を中止する方法」を参照してください。
ASET を短期間実行した後に、元のシステム状態を復元する場合
一部の主要なシステム機能が正常に動作せず、ASET が原因だと思われる場合
通常、ネットワークの一部となっているシステム上でも、ASET はスタンドアロンモードで使用されます。スタンドアロンシステムのシステム管理者は、システムのセキュリティとシステムを保護する ASET の実行と管理を担当することになります。
また、ASET は NFS 分散環境でも使用できます。ネットワーク管理者は、すべてのクライアントの各種管理タスクのインストール、実行、管理を担当します。複数のクライアントシステム間で ASET を管理しやすくするために、構成変更を行なってすべてのクライアントに一括して適用すれば、各システムにログインしてプロセスを繰り返す必要がなくなります。
ネットワークシステム上で ASET の設定方法を決めるときには、ユーザーに各自のシステム上でセキュリティをどのように制御させるかと、セキュリティ制御に関する責任をどの程度集中させるかを検討する必要があります。
複数のネットワーク構成を設定したい場合があります。たとえば、低セキュリティレベルに指定したクライアント用に 1 つ、中レベルのクライアント用に 1 つ、さらに高レベルのクライアント用に 1 つというように設定できます。
セキュリティレベルごとに別の ASET ネットワーク構成を作成したい場合は、サーバー上でレベルごとに 1 つずつ合計 3 つの ASET 構成を作成できます。各構成を該当するセキュリティレベルのクライアントにエクスポートすることになります。3 つの構成すべてに共通の ASET 構成要素は、リンクを使用して共有できます。
スーパーユーザー特権を持つか持たないかに関係なく、クライアントにアクセスされるサーバー上に ASET 構成要素を集中できるだけでなく、サーバー上でディレクトリを設定して、各種クライアント上で実行中のタスクによって生成されるすべてのレポートを収集できます。収集機構を設定する方法については、「サーバー上でレポートを収集する方法」を参照してください。
サーバー上でレポートを収集するように設定すると、すべてのクライアントに関するレポートを 1 箇所で検討できます。この方法は、クライアントがスーパーユーザー特権を持っているかどうかに関係なく使用できます。また、ユーザーに各自の ASET レポートを監視させたい場合は、ローカルシステム上にレポートディレクトリを残しておいてもかまいません。
表 16-2 に ASET 環境変数と各変数で指定する値を示します。
表 16-2 環境変数とその意味
環境変数 |
指定内容 |
---|---|
ASETDIR (以下を参照) |
ASET の作業ディレクトリ |
ASETSECLEVEL (以下を参照) |
セキュリティレベル |
PERIOD_SCHEDULE |
定期的なスケジュール |
TASKS |
実行するタスク |
UID_ALIASES |
別名ファイル |
YPCHECK |
チェックを NIS と NIS+ まで拡張する |
CKLISTPATH_LOW |
低セキュリティ用のディレクトリリスト |
CKLISTPATH_MED |
中セキュリティ用のディレクトリリスト |
CKLISTPATH_HIGH |
高セキュリティ用のディレクトリリスト |
次に示す環境変数は、ファイル /usr/aset/asetenv に入っています。ASETDIR 変数と ASETSECLEVEL 変数はオプションで、aset コマンドを使用してシェルからでなければ設定できません。他の環境変数は、ファイルを編集して設定できます。次に、各変数について説明します。
ASETDIR は、ASET の作業ディレクトリを指定します。
% setenv ASETDIR pathname
Bourne シェルまたは Korn シェルからは、次のように入力します。
$ ASETDIR=pathname $ export ASETDIR
pathname を ASET 作業ディレクトリの完全パス名に設定してください。
ASETSECLEVEL は、ASET タスクが実行されるセキュリティレベルを指定します。
C シェルから次のように入力します。
% setenv ASETSECLEVEL level
Bourne シェルまたは Korn シェルから、次のように入力します。
$ ASETSECLEVEL=level export ASETSECLEVEL
上記のコマンドで、level を次のいずれかに設定できます。
low |
低セキュリティレベル |
med |
中セキュリティレベル |
high |
高セキュリティレベル |
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 です。 |
次の規則が適用されます。
どのフィールドでも、値のリストをコンマで区切って指定できます。
値を数値または範囲として指定できます。範囲とは、1 対の数値をハイフンで結合したものです。範囲は、範囲に含まれるすべての時刻に ASET タスクを実行することを示します。
どのフィールドでも、値としてアスタリスク (*) を指定できます。アスタリスクは、そのフィールドに有効なすべての値を指定します。
PERIODIC_SCHEDULE 変数のデフォルトエントリでは、ASET が毎日午前 12:00 に実行されます。
PERIODIC_SCHEDULE="0 0 * * *"
TASKS 変数は、ASET で実行されるタスクをリストします。デフォルトでは、7 つのタスクがすべてリストされます。
TASKS="env sysconfig usrgrp tune cklist eeprom firewall"
UID_ALIASES 変数は、別名ファイルを指定します。別名ファイルがあると、ASET は使用可能な複数の別名のリストをこのファイル内で照会します。形式は UID_ALIASES=pathname です。pathname は、別名ファイルの完全パス名です。
デフォルトは次のとおりです。
UID_ALIASES=${ASETDIR}/masters/uid_aliases
YPCHECK 変数は、システムテーブルをチェックするタスクを拡張して NIS または NIS+ テーブルを含めます。これはブール変数なので、true または false に設定できます。
デフォルトは false で、ローカルシステムテーブルがチェックされます。
YPCHECK=false
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 は 3 つの調整ファイルを管理します。3 つの調整ファイル内のエントリについては、表 16-4 で説明しています。
表 16-4 調整ファイルのエントリ形式
エントリ |
説明 |
---|---|
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 (シンボリックリンク)、directory、または file (他のすべて) を指定できます。
セキュリティレベルが高くなるほど、調整ファイルは下位レベルよりも緩やかなファイルアクセス権にリセットされます。また、上位レベルになるほど、リストに多数のファイルが追加されます。
1 つのファイルで複数の調整ファイルエントリを照合できます。たとえば、etc/passwd は etc/pass* エントリと /etc/* エントリに一致します。
2 つのエントリのアクセス権が異なる場合は、ファイルアクセス権は最も厳しいアクセス権を表す値に設定されます。次の例では、/etc/passwd のアクセス権は 00755 に設定されますが、これは 00755 は 00770 よりも厳密な制限であることを表します。
/etc/pass* 00755 ? ? file /etc/* 00770 ? ? file
2 つのエントリの owner 指定または group 指定が異なる場合は、最後のエントリが優先されます。次の例は、tune.low ファイルの最初の数行を示します。
/ 02755 root root directory /bin 00777 root bin symlink /sbin 02775 root sys directory /usr/sbin 02775 root bin directory /etc 02755 root sys directory /etc/chroot 00777 bin bin symlink
別名ファイルには、同じユーザー ID を共有する別名のリストが入っています。
各エントリの書式は次のとおりです。
uid=alias1=alias2=alias3=...
uid |
共有ユーザー ID |
aliasn |
ユーザー ID を共有するユーザーアカウント |
たとえば、次のエントリでは、sysadm と root に共有されるユーザー ID 0 を示しています。
この節では、ASET を対話的にまたは定期的に実行する方法について説明します。
aset コマンドを使用して ASET を対話的に実行します。
# /usr/aset/aset -l level -d pathname
level |
セキュリティレベルを指定する。有効な値は low、medium、または high。デフォルト設定は low。セキュリティレベルについては、「ASET のセキュリティレベル」を参照 |
pathname |
ASET の作業ディレクトリを指定する。デフォルトは /usr/aset |
画面に表示される ASET 実行ログを見て、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 を定期的に実行したい時刻を設定します。
システム需要が少ないときに ASET を実行してください。/usr/aset/asetenv ファイル内の PERIODIC_SCHEDULE 環境変数を使用して、ASET を定期的に実行する時刻を設定します。デフォルトでは、この時刻は 24 時間ごとに真夜中に設定されています。
別の時刻を設定したい場合は、/usr/aset/asetenv ファイル内で PERIODIC_SCHEDULE 変数を編集します。PERIODIC_SCHEDULE 変数の設定の詳細は、「PERIODIC_SCHEDULE 変数」を参照してください。
aset コマンドを使ってエントリを crontab ファイルに追加します。
# /usr/aset/aset -p
-p |
/usr/aset/asetenv ファイル内の PERIODIC_SCHEDULE 環境変数で決めた時刻に ASET の実行を開始する行を crontab ファイルに挿入する |
次のコマンドを実行すると crontab エントリが表示され、ASET の実行スケジュールを確認できます。
# crontab -l root
crontab ファイルを編集します。
# crontab -e root
ASET エントリを削除します。
変更結果を保存して終了します。
crontab エントリを表示して、ASET エントリが削除されていることを確認します。
# crontab -l root
スーパーユーザーになります。
サーバー上でディレクトリを作成します。
/usr/aset ディレクトリに移動します。
mars# cd /usr/aset
rptdir ディレクトリを作成します。
mars# mkdir rptdir
rptdir ディレクトリに移動して、client_rpt ディレクトリを作成します。
mars# cd rptdir mars# mkdir client_rpt
このコマンドによって、クライアント用のサブディレクトリ (<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 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. |
意味 |
対処方法 |
---|---|
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 コマンド行オプションを使用して、3 つの値のいずれかを指定してください。 |
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 ファイルが無効である可能性がある。 |
asetenv ファイルを検査してください。タスクリストが User Configurable セクションで定義されているかどうかを確認します。また、ファイルの他の部分をチェックして、ファイルが変更されていないことを確認します。正常な asetenv ファイルの内容については、asetenv(4) のマニュアルページを参照してください。 |
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 のスケジュールが複数回指定されている。つまり、スケジュールがまだ有効な間に別のスケジュールを指定するように要求されている。複数のスケジュールはエラーであるとは限らず、複数のスケジュールが必要な場合は crontab(1) のスケジュール書式を使用するので、通常はこの指定が不要であることを示す警告にすぎない。 |
crontab(1) コマンドインタフェースを使って、正しいスケジュールが有効になっているかどうかを検査してください。ASET に関して不要な crontab エントリがないかどうかを確認してください。 |