パート IV システムセキュリティの管理

このパートでは、Solaris 7 環境においてシステムセキュリティを管理する方法について説明します。次の章が含まれます。

第 12 章 システムセキュリティの管理の概要

システム情報のセキュリティを保つことは、重要なシステム管理作業です。この章では、ファイルレベル、システムレベル、およびネットワークレベルでシステムセキュリティを管理する方法について説明します。

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

• 「システムセキュリティ作業の参照先」

• 「コンピュータシステムへのアクセスを許可する」

• 「ファイルのセキュリティ」

• 「システムのセキュリティ」

• 「ネットワークのセキュリティ」

ファイルレベルでは、SunOS 5.7 オペレーティングシステムにいくつかの標準セキュリティ機能が組み込まれているため、ファイル、ディレクトリ、およびデバイスの保護に使用できます。システムレベルとネットワークレベルでは、セキュリティの内容はほぼ同じです。サイトでは、1 台のサーバーに接続された多数のシステムを 1 つの大規模で多面的なシステムと見なすことができます。システム管理者は、この大規模なシステム、つまりネットワークシステムのセキュリティ管理に責任があります。ネットワークの外側からの侵入を防ぐことだけでなく、ネットワーク内部のシステムのデータの完全性を確保することも重要です。

システムセキュリティ作業の参照先

システムセキュリティの設定手順については、次の項目を参照してください。

• 第 13 章「ファイルのセキュリティの適用手順」

• 第 14 章「システムのセキュリティの手順」

• 第 15 章「認証サービスの使用手順」

• 第 16 章「自動セキュリティ拡張ツールの使用手順」

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

防御の第 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 は、ファイルやディレクトリに使用できるファイル管理コマンドを示します。

ファイルの暗号化

重要なファイルをアクセスできないディレクトリに格納し (700 モード)、そのファイルを他のユーザーが読み取れないようにすると (600 モード)、ほとんどの場合はセキュリティが保たれます。しかし、他人がユーザーのパスワードや root パスワードを推測して発見すれば、そのファイルを読み書きできます。また、重要なファイルは、システムファイルのバックアップをテープにとるたびに、バックアップテープ上に保存されます。

アクセス制御リスト (ACL)

SunOS オペレーティングシステムの従来の UNIX ファイル保護機能では不十分な場合は、ACL によりファイルアクセス権の制御が強化されます。従来の UNIX ファイル保護機能は、所有者、グループ、その他という 3 つのユーザークラスに読み取り権、書き込み権、実行権を提供します。ACL を使用すると、所有者、所有者のグループ、その他、特定のユーザーおよびグループのファイルアクセス権を定義でき、またこれらのカテゴリごとにデフォルトのアクセス権を定義できるため、ファイルのセキュリティが強化されます。ACL を設定する個々の手順については、「アクセス制御リスト (ACL)」を参照してください。

表 12-2 に、ファイルやディレクトリに対して使用できる 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) が付いています。これらの各ログインには固有のパスワードを設定し、必要のある人だけに知らせるようにしてください。

また、パスワードが必要な eeprom のセキュリティも設定する必要があります。詳細は、eeprom(1M) のマニュアルページを参照してください。

パスワード情報の管理

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

パスワードは、最初にユーザーアカウントを設定するときに作成されます。ユーザーアカウントの機密性を保つために、パスワードの有効期間を設定し、ユーザーに各自のパスワードを定期的に変更させたり、パスワードをロックしてユーザーアカウントを使用できないようにすることもできます。パスワードの設定と管理については、『Solaris のシステム管理 (第 1 巻)』の「ユーザーアカウントとグループの管理の概要」を参照してください。

NIS+ パスワードファイル

ネットワークで NIS+ を使用している場合、パスワード情報は NIS+ データベースに格納されます。NIS+ データベース内の情報は、アクセス権を許可されたユーザーを制限することによって保護できます。ユーザーアカウントマネージャまたは passwd(1) コマンドを使用すると、ユーザーの NIS+ パスワードを変更できます。

NIS パスワードファイル

ネットワークで NIS を使用している場合、パスワードは NIS パスワードマップに格納されます。NIS では、パスワードの有効期間を指定できません。Solstice ユーザーマネージャまたは passwd(1) コマンドを使用すると、ユーザーの NIS パスワードを変更できます。

/etc ディレクトリ内のファイル

ネットワークで /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 パスワードが必要です。デフォルトの構成では、ユーザーはリモートのシステムに root としてログインできません。リモートログインするとき、ユーザーは自分のユーザー名でログインしてから、su コマンドを使用してスーパーユーザーにならなければなりません。これによって、管理者は、システム上でスーパーユーザー特権を使用している人を追跡できます。

スーパーユーザーまたは他のユーザーに切り替えようとするユーザーの監視

スーパーユーザーになりたい場合などは、su コマンドを使用して別のユーザーに変更する必要があります。セキュリティ上の理由から、su コマンドを使用中のユーザー、特にスーパーユーザーのアクセス権を取得しようとしているユーザーを監視する必要があります。

詳細は、「su コマンドを使用中のユーザーを監視する方法」を参照してください。

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

ネットワーク上でのアクセスが容易になるほど、ネットワークシステムにとっては利点が増えます。ただし、データや資源に自由にアクセスして共有できる状況では、セキュリティ上の問題が生じます。一般にネットワークのセキュリティは、リモートシステムからの操作を制限またはブロックすることを指しています。図 12-1 に、リモート操作に適用できるセキュリティ制限を示します。

図 12-1 リモート操作のセキュリティ制限

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

ファイアウォールシステムを設定すると、ネットワーク内のリソースを外部のアクセスから保護できます。「ファイアウォールシステム」は、内部ネットワークと外部ネットワークの間の防壁として機能するセキュリティ保護ホストです。

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

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

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

ファイアウォールシステムに「信頼される (trusted) ホスト」が含まれるべきではありません (「信頼されるホスト」とは、ユーザーがパスワードを入力しなくてもログインできるホストです)。ファイアウォールシステムは、ファイルシステムを共有してはならず、他のサーバーからファイルシステムをマウントしてはなりません。

自動セキュリティ拡張ツール (ASET) を使用すると、システムをファイアウォールにして高度なセキュリティを確保できます。詳細は、第 16 章「自動セキュリティ拡張ツールの使用手順」を参照してください。

パケットスマッシング

ほとんどのローカルエリアネットワークでは、データはパケットと呼ばれるブロック単位でコンピュータ間で転送されます。アクセス権のないユーザーは、「パケットスマッシング」という方法により、データを損傷または破壊する可能性があります。パケットスマッシングでは、パケットは宛先に到達する前に捕捉され、その内容になんらかのデータが挿入されてから、元のコースに送り返されます。ローカルエリアネットワーク上では、パケットはサーバーを含むすべてのシステムに同時に到達するので、パケットスマッシングは不可能です。ただし、ゲートウェイ上ではパケットスマッシングが可能なので、ネットワーク上のすべてのゲートウェイを保護しなければなりません。

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

認証と承認

「認証」とは、リモートシステムにアクセスできるユーザーを特定の人に限定する方法で、システムレベルまたはネットワークレベルで設定できます。ユーザーがリモートシステムにアクセスした後は、「承認」という方法でそのユーザーがリモートシステム上で実行できる操作が制限されます。表 12-4 に、ネットワーク上のシステムを許可されていない使い方から保護できる認証と承認の種類を示します。

ファイルの共有

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

サーバーでは、/etc/dfs/dfstab ファイルを使用して、ネットワーク上のクライアントに利用させることができるファイルシステムを表示できます。ファイルの共有の詳細は、『NFS の管理』を参照してください。

スーパーユーザー (root) アクセスの制限

一般的にスーパーユーザーは、ネットワーク上で共有されるファイルシステムにはスーパーユーザーとしてアクセスできません。サーバーが特別にスーパーユーザー特権を与えなければ、クライアントにスーパーユーザーとしてログインしたユーザーは、そのクライアントにリモートでマウントされたファイルへのスーパーユーザーアクセスを取得できません。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 を実行するセキュリティレベルとして、低、中、または高レベルを指定できます。上のレベルほど、ASET のファイル制御機能が増え、ファイルアクセスが減少し、システムセキュリティが厳しくなります。

詳細は、第 16 章「自動セキュリティ拡張ツールの使用手順」を参照してください。

第 13 章 ファイルのセキュリティの適用手順

この章では、ファイルにセキュリティを適用する手順について説明します。この章で説明する手順は次のとおりです。

• 「ファイル情報を表示する方法」

• 「ファイルの所有者を変更する方法」

• 「ファイルのグループ所有権を変更する方法」

• 「アクセス権を絶対モードで変更する方法」

• 「特殊アクセス権を絶対モードで設定する方法」

• 「アクセス権を記号モードで変更する方法」

• 「setuid アクセス権が設定されているファイルを検索する方法」

• 「プログラムが実行可能スタックを使用できないようにする方法」

• 「実行可能スタックのメッセージ記録を無効にする方法」

• 「ファイルの ACL を設定する方法」

• 「ACL をコピーする方法」

• 「ファイルに ACL が設定されているかどうかをチェックする方法」

• 「ファイルの ACL エントリを変更する方法」

• 「ファイルから ACL エントリを削除する方法」

• 「ファイルの ACL エントリを表示する方法」

ファイルのセキュリティに関する機能

この節では、ファイルのセキュリティを構成する機能について説明します。

ユーザークラス

各ファイルには、セキュリティのレベルを指定する 3 つのユーザークラスがあります。

• ファイルやディレクトリの所有者 - 通常は、ファイルを作成したユーザーです。ファイルの所有者は、ファイルの読み取り権、書き込み権 (変更する権利)、または実行権 (コマンドの場合) を与えるユーザーを決定できます。

• グループのメンバー

• ファイルやグループの所有者以外のすべてのユーザー

ファイルのアクセス権を割り当てたり変更したりできるのは、スーパーユーザーかそのファイルの所有者だけです。

ファイルのアクセス権

表 13-1 に、各ユーザークラスに与えることができるファイルのアクセス権を示します。

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

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

ディレクトリのアクセス権

表 13-2 に、各ユーザークラスに与えることができるディレクトリのアクセス権を示します。

ディレクトリへアクセスできないようにすると、そのディレクトリ (およびすべてのサブディレクトリ) 内のファイルを保護できます。ただし、スーパーユーザーはシステム上のすべてのファイルとディレクトリにアクセスできます。

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

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

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

setuid や setgid アクセス権を使用して、不正にスーパーユーザー権限が取得されていないかどうか絶えずシステムを監視しなければなりません。これらのアクセス権を使用しているすべてのプログラムを、ファイルシステム内で検索し、そのリストを出力する方法については、「setuid アクセス権が設定されているファイルを検索する方法」を参照してください。この種のプログラムの所有権を bin や sys 以外のユーザーに与えているものが出力中にあれば、そのプログラムはセキュリティに違反している可能性があります。

setuid アクセス権

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 を使用しないようにしてください。

setgid アクセス権

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 ファイルシステム上で公共ディレクトリを設定するときには、スティッキビットを手作業で設定してください。

デフォルトの umask

ファイルやディレクトリを作成するときには、デフォルトのアクセス権が設定されます。これらのデフォルトのアクセス権は、システムファイル /etc/profile、.cshrc、または .login ファイル内の umask(1) の値によって決定されます。デフォルトでは、システムはテキストファイルのアクセス権を 666 に設定してユーザー、グループ、その他に読み取り権と書き込み権を与え、ディレクトリまたは実行可能ファイルに対しては 777 に設定します。

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

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

ファイル情報の表示

この節では、ファイルの情報を表示する方法について説明します。

ファイル情報を表示する方法

ls コマンドを使用して、ディレクトリ内のすべてのファイルに関する情報を表示します。

$ ls -la

表示画面の各行には、ファイルに関して次の情報が表示されます。

• ファイル形式

  ファイルには 6 つの形式があります。表 13-4 にファイル形式を示します。

  表 13-4 ファイル形式

  記号	形式
  -	テキストまたはプログラム
  d	ディレクトリ
  b	ブロック型特殊ファイル
  c	キャラクタ型特殊ファイル
  p	名前付きパイプ (FIFO)
  l	シンボリックリンク

• アクセス権 (表 13-1 と表 13-2 を参照)

• ハードリンク数

• ファイルの所有者

• ファイルのグループ

• ファイルのバイト数

• ファイルの作成日または前回の変更日

• ファイル名

例 - ファイル情報を表示する

次の例では、/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*
   .
   .
   .

ファイルの所有権の変更

この節では、ファイルの所有権を変更する方法について説明します。

ファイルの所有者を変更する方法

1. スーパーユーザーになります。

   デフォルトでは、所有者は chown コマンドを使用して、ファイルやディレクトリの所有者を変更できません。ただし、システム管理者が次の行をシステムの /etc/system ファイルに追加して、システムをリブートすれば、所有者は chown コマンドを使用できるようになります。

   set rstchown = 0

   詳細は、chown(1) のマニュアルページを参照してください。また、NFS マウントされているファイルシステム上で所有者を変更するときは、他にも制約があるので注意してください。

2. chown コマンドを使用してファイルの所有者を変更します。

      $ chown newowner   filename
   

   newowner	ファイルまたはディレクトリの新しい所有者のユーザー名または UID を指定する
   filename	ファイルまたはディレクトリを指定する

3. ファイルの所有者が変更されていることを確認します。

      $ ls -l filename
   

例 - ファイルの所有者を変更する

次の例は、myfile の所有権をユーザー rimmer に設定します。

$ chown rimmer myfile
$ ls -l myfile
-rw-r--r--   1 rimmer   scifi   112640 May 24 10:49 myfile

ファイルのグループ所有権を変更する方法

1. スーパーユーザーになります。

   デフォルトでは、所有者は chgrp コマンドを使用しても、ファイルのグループをその所有者が属するグループ以外には変更できません。たとえば、ファイルの所有者が staff と sysadm グループだけに属する場合、所有者は、ファイルのグループを staff か sysadm グループ以外には変更できません。

   ただし、システム管理者が次の行をシステムの /etc/system ファイルに追加して、システムをリブートすれば、所有者は、ファイルのグループを、所有者が属していないグループにも変更できるようになります。

   set rstchown = 0

   詳細は、chgrp(1) のマニュアルページを参照してください。また、NFS マウントされているファイルシステムでグループを変更するときは、他にも制約があるので注意してください。

2. chgrp コマンドを使用して、ファイルのグループ所有者を変更します。

      $ chgrp group filename
   

   group	ファイルまたはディレクトリの新しいグループ名を指定する
   filename	ファイルまたはディレクトリを指定する

   グループアカウントの編集方法については、第 13 章「ファイルのセキュリティの適用手順」を参照してください。

3. ファイルのグループ所有権が変更されていることを確認します。

      $ 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 は、所有者に対して読み取り権と書き込み権を設定し、グループとその他に対しては読み取り権だけを設定します。

ファイルには、絶対モードまたは記号モードで特殊アクセス権を設定できます。絶対モードでは、3 つ 1 組のアクセス権の左端に新しい 8 進数値を追加して、特殊アクセス権を設定します。表 13-6 に、ファイルに特殊アクセス権を設定する 8 進数値を示します。

表 13-7 に、記号モードでファイルのアクセス権を設定するための記号を示します。記号では、アクセス権を設定または変更できる対象ユーザー、実行される操作、あるいは割り当てるまたは変更するアクセス権を指定できます。

機能列の「対象ユーザー」、「操作」、および「アクセス権」を順番に連結した文字列によって、ファイルまたはディレクトリのアクセス権を変更する記号を指定します。

アクセス権を絶対モードで変更する方法

1. ファイルまたはディレクトリの所有者でない場合は、スーパーユーザーになります。

   現在の所有者またはスーパーユーザーだけが、chmod コマンドを使用してファイルまたはディレクトリのアクセス権を変更できます。

2. chmod コマンドを使用してアクセス権を絶対モードで変更します。

      $ chmod nnn  filename
   

   nnn	ファイル所有者、ファイルグループ、その他のアクセス権をこの順序で表す 8 進数値を指定する。有効な 8 進数値については、表 13-5 を参照
   filename	ファイルまたはディレクトリを指定する

   ---

   注 -

   chmod を使用して ACL エントリを持つファイルのファイルグループアクセス権を変更する場合、ファイルグループアクセス権と ACL マスクの両方が新しいアクセス権に変更されます。新しい ACL マスクアクセス権は、そのファイル上に ACL エントリを持つ追加ユーザーおよびグループの実効アクセス権を変更する場合があるので注意が必要です。getfacl(1) コマンドを使用して、適切なアクセス権がすべての ACL エントリに設定されていることを確認してください。

   ---

3. ファイルのアクセス権が変更されていることを確認します。

      $ 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

特殊アクセス権を絶対モードで設定する方法

1. ファイルまたはディレクトリの所有者でない場合は、スーパーユーザーになります。

   現在の所有者またはスーパーユーザーだけが、chmod コマンドを使用してファイルまたはディレクトリの所有者を変更できます。

2. chmod コマンドを使用して特殊アクセス権を絶対モードで変更します。

      $ chmod  nnnn  filename
   

   nnnn	ファイルまたはディレクトリのアクセス権を変更する 8 進数値。左端の 8 進数値で、ファイルの特殊アクセス権を設定する。特殊アクセス権に有効な 8 進数値のリストについては、表 13-6 を参照
   filename	ファイルまたはディレクトリを指定する

   ---

   注 -

   chmod を使用して ACL エントリを持つファイルのファイルグループアクセス権を変更する場合、ファイルグループアクセス権と ACL マスクの両方が新しいアクセス権に変更されます。新しい ACL マスクアクセス権は、そのファイル上に ACL エントリを持つ追加ユーザーおよびグループの実効アクセス権を変更する場合があるので注意が必要です。getfacl(1) コマンドを使用して、適切なアクセス権がすべての ACL エントリに設定されていることを確認してください。

   ---

3. ファイルのアクセス権が変更されていることを確認します。

      $ 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

アクセス権を記号モードで変更する方法

1. ファイルまたはディレクトリの所有者でない場合は、スーパーユーザーになります。

   現在の所有者またはスーパーユーザーだけが、chmod コマンドを使用してファイルまたはディレクトリの所有者を変更できます。

2. chmod コマンドを使用してアクセス権を記号モードで変更します。

      $ chmod who operator permission filename
   

   who operator permission	who では、アクセス権を変更するユーザーを指定し、operator では実行する操作を指定し、permission では変更後のアクセス権を指定する。有効な記号については、表 13-7 を参照
   filename	ファイルまたはディレクトリを指定する

3. ファイルのアクセス権が変更されていることを確認します。

      $ ls -l filename
   

例 - アクセス権を記号モードで変更する

次の例は、その他のユーザーの読み取り権を削除します。

$ chmod o-r filea

次の例は、ユーザー、グループ、その他のユーザーの読み取り権と実行権を追加します。

$ chmod a+rx fileb

次の例は、グループに読み取り権、書き込み権、実行権を割り当てます。

$ chmod g=rwx filec

特殊なファイルアクセス権の検索

setuid や setgid アクセス権を使用して、不正にスーパーユーザー権限が取得されていないかどうか絶えずシステムを監視しなければなりません。この種のプログラムの所有権を bin や sys 以外のユーザーに与えているものが出力中にあれば、そのプログラムはセキュリティに違反している可能性があります。

setuid アクセス権が設定されているファイルを検索する方法

1. スーパーユーザーになります。

2. 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	結果がこのファイルに書き込まれる

3. 結果を /tmp/filename に出力する。

   setuid については、「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 プラットフォームでしか利用できません。

プログラムが実行可能スタックを使用できないようにする方法

1. スーパーユーザーになります。

2. /etc/system ファイルを編集して、次の行を追加します。

      set noexec_user_stack=1

3. システムをリブートします。

      # init 6
   

実行可能スタックのメッセージ記録を無効にする方法

1. スーパーユーザーになります。

2. /etc/system ファイルを編集して、次の行を追加します。

      set noexec_user_stack_log=0

3. システムをリブートします。

      # init 6
   

アクセス制御リスト (ACL)

従来の UNIX ファイル保護機能は、所有者、グループ、その他という 3 つのユーザークラスに読み取り権、書き込み権、実行権を提供します。ACL を使用すると、所有者、所有者のグループ、その他、特定のユーザーおよびグループのファイルアクセス権を定義でき、またこれらのカテゴリごとにデフォルトのアクセス権を定義できるため、ファイルのセキュリティが強化されます。

たとえば、グループ内のすべてのユーザーがファイルを読み取れるようにしたい場合は、単にそのファイルにグループの読み取り権を設定します。そして、そのグループ内の 1 人のユーザーだけに書き込み権を与えたいとすると、標準の UNIX ではこのようなファイルセキュリティを設定できませんが、ACL ではこれが可能です。

ACL エントリはファイルの ACL を定義する手段であり、setfacl(1) コマンドにより設定します。ACL エントリは、次のようにコロンで区切ったフィールドからなっています。

entry_type:[uid|gid]:perms

次の例に、ユーザー nathan の読み取り権および書き取り権を設定する ACL エントリを示します。

user:nathan:rw-

ACL などの UFS ファイルシステム属性は UFS ファイルシステムだけでサポートされます。つまり、/tmp ディレクトリ (通常は、TMPFS ファイルシステムとしてマウントされている) で ACL エントリを持つファイルを復元またはコピーすると、その ACL エントリは失われます。UFS ファイルの一時的な格納には、/var/tmp ディレクトリを使用してください。

ファイルの ACL エントリ

表 13-8 に、有効な ACL エントリを示します。最初の 3 つの ACL エントリは、基本的な UNIX のファイル保護機能を提供します。

u[ser]::perms 

g[roup]::perms 

o[ther]:perms 

m[ask]:perms 

u[ser]:uid:perms

g[roup]:gid:perms

ディレクトリの ACL エントリ

表 13-8 に示した ACL エントリの他に、ディレクトリにはデフォルトの ACL エントリも設定できます。デフォルトの ACL エントリを持つディレクトリ内で作成されたファイルまたはディレクトリは、デフォルトの ACL エントリと同じ ACL エントリを持つことになります。表 13-9 に、ディレクトリのデフォルト ACL エントリを示します。

ディレクトリ上で特定のユーザーとグループのデフォルトの ACL エントリを初めて設定するときは、ファイル所有者、ファイルグループ、その他、およびACL マスクにデフォルトの ACL エントリも設定しなければなりません (表 13-9 の最初の 4 つのデフォルト ACL エントリでは、この設定は必須です)。

d[efault]:u[ser]::perms 

d[efault]:g[roup]::perms 

d[efault]:o[ther]:perms 

d[efault]:m[ask]:perms 

d[efault]:u[ser]:uid:perms

d[efault]:g[roup]:gid:perms

ファイルの ACL を設定する方法

1. 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 を設定するファイルまたはディレクトリ

2. ファイルに ACL が設定されたかどうかを確認する方法については、「ファイルに ACL が設定されているかどうかをチェックする方法」を参照してください。ファイルにどの ACL エントリが設定されているかを確認するには、getfacl コマンドを使用します。

      $ getfacl filename
   

すでにファイル上に ACL が存在する場合、-s オプションを指定すると、ACL 全体が新しい 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:---

ACL をコピーする方法

getfacl の出力先を変更することにより、ファイルの ACL を他のファイルへコピーできます。

$ getfacl filename1 | setfacl --f - filename2

例 - ACL をコピーする

次の例は、ACL を ch2.doc から ch3.doc へコピーします。

$ getfacl ch2.doc | setfacl -f - ch3.doc

ファイルに ACL が設定されているかどうかをチェックする方法

ls コマンドを使用して、ファイルに ACL が設定されているかどうかをチェックします。

$ ls -l filename

モードフィールドの右側の「+」は、ファイルに ACL が設定されていることを示します。

さらにユーザーやグループの ACL エントリをファイルに追加しないかぎり、ファイルの ACL は「弱い」とみなされ、「+」は表示されません。

例 - ファイルに ACL が設定されているかどうかをチェックする

次の例は、モードフィールドの右側に + が付いているため、ch1.doc に ACL が設定されていることを示します。

$ ls -l ch1.doc
-rwxr-----+  1 nathan   sysadmin      167 Nov 11 11:13 ch1.doc

ファイルの ACL エントリを変更する方法

1. setfacl コマンドを使用してファイルの ACL エントリを変更します。

      $ setfacl -m acl_entry_list filename1 [filename2...]

   -m	既存の ACL エントリを変更する
   acl_entry_list	ファイルまたはディレクトリで変更する 1 つ以上の ACL エントリのリスト。ディレクトリのデフォルト ACL エントリを変更することもできる。有効な ACL エントリについては、表 13-8 と表 13-9 を参照を指定する
   filename ...	ファイルまたはディレクトリを指定する

2. ファイルの ACL エントリが追加または変更されたことを確認するには、getfacl コマンドを使用します。

      $ getfacl filename
   

例 - ファイルの ACL エントリを変更する

次の例は、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

ファイルから ACL エントリを削除する方法

1. 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 エントリに置き換えることができます。

2. ファイルから ACL エントリが削除されたことを確認するには、getfacl コマンドを使用します。

      $ getfacl filename
   

例 - ファイルから ACL エントリを削除する

次の例は、ユーザー george を ch4.doc ファイルから削除します。

$ setfacl -d user:george ch4.doc

ファイルの ACL エントリを表示する方法

getfacl コマンドを使用してファイルの ACL エントリを表示します。

$ getfacl [-a | -d] filename1 ...

コマンド行で複数のファイル名を指定すると、各 ACL エントリはブランク行で区切られます。

例 - ファイルの 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:---

第 14 章 システムのセキュリティの手順

この章では、システムにセキュリティを適用する手順について説明します。この章で説明する手順は次のとおりです。

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

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

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

• 「失敗したログイン操作を保存する方法」

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

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

• 「スーパーユーザー (root) ログインをコンソールに制限する方法」

• 「su コマンドを使用中のユーザーを監視する方法」

• 「コンソールへのスーパーユーザー (root) アクセス操作を表示する方法」

システムにセキュリティを適用する概要については、「システムのセキュリティ」を参照してください。

セキュリティ情報の表示

この節では、ユーザーのログイン情報を表示する方法について説明します。

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

1. スーパーユーザーになります。

2. 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

指定の意味

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

ユーザー全員が有効なパスワードを持っているかどうかを確認する必要があります。

1. スーパーユーザーになります。

2. logins コマンドを使用して、パスワードを持っていないユーザーを表示します。

      # logins -p
   

   -p	パスワードを持っていないユーザーのリストを表示する

   logins コマンドは、ローカルの /etc/passwd ファイルと NIS または NIS+ パスワードデータベースを使用して、ユーザーのログイン状態を表示します。

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

次の例には、パスワードを持っていないユーザー pmorph が表示されています。

# logins -p
pmorph          501     other           1       Polly Morph
# 

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

ユーザーのログインを一時的に無効にするには、次のようにします。

• /etc/nologin ファイルを作成します。

• システムを実行レベル 0 (シングルユーザーモード) にします。システムをシングルユーザーモードに移行する方法については、『Solaris のシステム管理 (第 1 巻)』の「システムのシャットダウンの手順」の節を参照してください。

/etc/nologin ファイルの作成

このファイルを作成する目的は、システムシャットダウンや定期保守のためにシステムが一定の時間利用できなくなるときに、ユーザーのログインを禁止して、ユーザーに通知することです。

このファイルが存在するシステムにユーザーがログインしようとすると、nologin(4) ファイルの内容が表示されて、ユーザーのログインは中断されます。スーパーユーザーのログインは影響を受けません。

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

1. スーパーユーザーになります。

2. エディタを使用して、/etc/nologin ファイルを作成します。

      # vi /etc/nologin
   

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

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

例 - ユーザーのログインを無効にする

この例は、システムが利用できないことをユーザーに通知する方法を示しています。

# 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) のマニュアルページを参照してください。

失敗したログイン操作を保存する方法

1. スーパーユーザーになります。

2. /var/adm ディレクトリ内で loginlog ファイルを作成します。

      # touch /var/adm/loginlog
   

3. loginlog ファイル上で root 用の読み取り権と書き込み権を設定します。

      # chmod 600 /var/adm/loginlog
   

4. loginlog ファイル上でグループのメンバーシップを sys に変更します。

      # chgrp sys /var/adm/loginlog
   

5. ログが機能していることを確認するには、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 に、基本的なダイヤルアップパスワードシーケンスを示します。

図 14-1 基本的なダイヤルアップパスワードシーケンス

/etc/d_passwd ファイル

ほとんどのユーザーはログインするときにシェルを実行しているので、すべてのシェルプログラムのエントリが /etc/d_passwd 内に必要です。この種のプログラムは、uucico、sh、ksh、csh などです。一部のユーザーがログインシェルから何か実行する場合は、そのログインシェルもファイルに含めてください。

ユーザーのログインプログラム (/etc/passwd 内で指定) が /etc/d_passwd 内で見つからない場合や、/etc/passwd 内のログインシェルフィールドが空 (NULL) の場合は、/usr/bin/sh のパスワードエントリが使用されます。

• /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:*: しか入っていない場合、ダイヤルアップログインは使用できません。

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

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

1. スーパーユーザーになります。

2. ダイヤルアップパスワード保護が必要なすべてのポートなど、端末装置のリストが入った /etc/dialups ファイルを作成します。

   /etc/dialups ファイルは次のようになります。

   /dev/term/a

   /dev/term/b

   /dev/term/c

3. ダイヤルアップパスワードを要求するログインプログラムと暗号化されたダイヤルアップパスワードが入った /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:

4. 2 つのファイルの所有権を root に設定します。

      # chown root /etc/dialups /etc/d_passwd
   

5. 2 つのファイルのグループの所有権を root に設定します。

      # chgrp root /etc/dialups /etc/d_passwd
   

6. 2 つのファイルの root の読み取り権と書き込み権を設定します。

      # chmod 600 /etc/dialups /etc/d_passwd
   

7. 暗号化パスワードを作成します。

   1. ダミーユーザーを作成します。

         # useradd user-name
      

   2. ダミーユーザーのパスワードを作成します。

         # passwd user-name
      

   3. 暗号化パスワードを取り出します。

         # grep user-name /etc/shadow > user-name.temp
      

   4. user-name.temp ファイルを編集します。

      暗号化パスワード (第 2 のフィールド) を除くすべてのフィールドを削除します。

      たとえば、次の行では、暗号化パスワードは U9gp9SyA/JlSk です。

         temp:U9gp9SyA/JlSk:7967:::::7988:

   5. ダミーユーザーを削除します。

         # userdel user-name
      

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

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

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

1. スーパーユーザーになります。

2. 次のエントリ 1 行を /etc/d_passwd ファイルに挿入します。

      /usr/bin/sh:*:

コンソールのスーパーユーザー (root) アクセスの制限

スーパーユーザーアカウントは、基本的な機能を実行するためにオペレーティングシステムに使用され、オペレーティングシステム全体を広範囲に制御します。また、スーパーユーザーアカウントは重要なシステムプログラムにアクセスして実行できます。このため、スーパーユーザーによって実行されるプログラムの場合、セキュリティ上の制約はほとんどありません。

/etc/default/login ファイルを通じて特定の装置へのスーパーユーザーアクセスを制限すると、システム上のスーパーユーザーアカウントを保護できます。たとえば、スーパーユーザーアクセスをコンソールに限定しておけば、コンソールからしかスーパーユーザーとしてシステムにログインできなくなります。誰かがシステムにリモートログインして管理作業を実行する場合は、まず自分のユーザーログインを使用してログインしてから、su(1M) コマンドを使用してスーパーユーザーにならなければなりません。詳細は、「スーパーユーザー (root) ログインをコンソールに制限する方法」を参照してください。

システムをインストールするときには、コンソールへのスーパーユーザーログインはデフォルトで制限されます。

スーパーユーザー (root) ログインをコンソールに制限する方法

1. スーパーユーザーになります。

2. /etc/default/login ファイルを編集します。

3. 次の行のコメントを解除します。

      CONSOLE=/dev/console

   このシステムにリモートログインするユーザーは、まず自分のユーザーログインを使用してログインしてから、su コマンドを使用してスーパーユーザーにならなければなりません。

4. このシステムにスーパーユーザーとしてリモートログインして、操作が失敗することを確認してください。

su コマンドを使用するユーザーの監視

su コマンドの試行に対する監視は /etc/default/su ファイルを通じて開始できます。このファイルを通じて、/var/adm/sulog ファイルを使用可能にし、su コマンドを使用して別のユーザーに変更されるたびに監視できます。詳細は、「su コマンドを使用中のユーザーを監視する方法」を参照してください。

sulog ファイルには、ユーザーをスーパーユーザーに切り替えるコマンドではなく、su コマンドのすべての使用状況がリストされます。各エントリは、コマンドが入力された日時、su コマンドの成否 (+ または -)、コマンドが実行されたポート、およびユーザー名と切り替え後の識別名を示します。

/etc/default/su ファイルを通じて、リモートシステムから su コマンドを使用してスーパーユーザーアクセス権を取得しようとする操作が発生するたびにコンソールに表示されるようにシステムを設定することもできます。これは、現在作業中のシステム上で誰かがスーパーユーザーアクセス権を取得しようとした場合に、それを即座に検出する優れた方法です。詳細は、「コンソールへのスーパーユーザー (root) アクセス操作を表示する方法」を参照してください。

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

1. スーパーユーザーになります。

2. /etc/default/su ファイルを編集します。

3. 次の行のコメントを解除します。

      SULOG=/var/adm/sulog

4. /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

コンソールへのスーパーユーザー (root) アクセス操作を表示する方法

1. スーパーユーザーになります。

2. /etc/default/su ファイルを編集します。

3. 次の行のコメントを解除します。

      CONSOLE=/dev/console

4. su コマンドを使用してスーパーユーザーになり、システムコンソールにメッセージが出力されるかどうかを確認してください。

第 15 章 認証サービスの使用手順

この章の最初の節では、Secure RPC で使用できる認証機構について説明します。Diffie-Hellman 認証と Kerberos Version 4 認証がサポートされます。2 番目の節では、Pluggable Authentication Module (PAM) フレームワークについて説明します。PAM は、認証サービスを「プラグイン」する方法を提供して、複数の認証サービスを使用できるようにします。

この章で説明する手順は次のとおりです。

• 「キーサーバーを再起動する方法」

• 「Diffie-Hellman 認証明に NIS+ 資格を設定する方法」

• 「Diffie-Hellman 認証で NIS 資格を設定する方法」

• 「Diffie-Helman 認証でファイルを共有およびマウントする方法」

• 「Kerberos 認証でファイルを共有およびマウントする方法」

• 「クライアント上でスーパーユーザー用の Kerberos チケットを取得する方法」

• 「Kerberos サービスにログインする方法」

• 「Kerberos チケットをリストする方法」

• 「Kerberos 認証でディレクトリにアクセスする方法」

• 「Kerberos チケットを削除する方法」

• 「PAM モジュールを追加する方法」

• 「PAM を使用して、リモートシステムからの認証されていないアクセスを防ぐ方法」

• 「PAM のエラー報告を有効にする方法」

Secure RPC の概要

Secure RPC は、ホストと、要求を依頼したユーザーの両方を認証する認証方法です。Secure RPC は、Diffie-Hellman 認証か Kerberos 認証のどちらかを使用します。これらの認証機構は両方とも DES 暗号化を使用します。Secure RPC を使用するアプリケーションには、NFS と NIS+ ネームサービスがあります。

NFS サービスと Secure RPC

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 認証の実装」を参照してください。

DES 暗号化

Data Encryption Standard (DES) 暗号化機能は 56 ビットの鍵を使用して、秘密鍵を暗号化します。資格を持つ 2 人のユーザー (主体) が同じ DES 鍵を知っている場合、彼らはその鍵を使用してテキストを暗号化または復号化することによって、プライベートに通信できます。DES は比較的高速な暗号化機構です。DES チップは暗号化をより高速にします。しかし、チップがなくても、ソフトウェアが実行します。

DES 鍵だけを使用する危険性とは、十分な時間をかけて、同じ鍵を使用して暗号化した暗号テキストメッセージを十分に収集すれば、鍵を発見し、メッセージを復号化できることです。この理由のため、Secure NFS などのセキュリティシステムは鍵を頻繁に変更します。

Diffie-Hellman 認証

Diffie-Hellman のユーザー認証方法は簡単には破られません。クライアントとサーバーは、それぞれ独自の非公開鍵 (秘密鍵とも呼ぶ) を持っていて、共通鍵が利用できるように公開鍵と組み合わせて使用します。クライアントとサーバーはお互いにこの共通鍵を使用し、両者で合意された暗号化復号化機能 (DES など) を使用して通信します。この方法は、以前の Solaris リリースの DES 認証と同じです。

認証は、送信側のシステムの共通鍵を使用して現在の時刻を暗号化する機能を利用します。受信側のシステムは、その現在の時刻を復号し、自分の時刻と照合します。クライアントとサーバーで時刻が同期していることを確認してください。

公開鍵と非公開鍵は、NIS または NIS+ のデータベースに格納されます。NIS では、publickey マップに鍵を格納します。NIS+ では、cred テーブルに鍵を格納します。これらのファイルには、すべてのユーザーの公開鍵と非公開鍵が入っています。

システム管理者は、NIS または NIS+ のテーブルを設定して、ユーザーごとに公開鍵と非公開鍵を生成する義務があります。公開鍵は、ユーザーのパスワードで暗号化されて格納されます。これによって、その公開鍵はそのユーザーだけが知っていることになります。

Diffie-Hellman 認証の実装

この節では、DH 認証 (AUTH_DH) を使用するクライアントサーバーセッションにおける一連のトランザクションを説明します。

公開鍵と秘密鍵の生成

トランザクションの前に、管理者は newkey コマンドか nisaddcred コマンドを使用して、公開鍵と秘密鍵を生成します (各ユーザーは一意の公開鍵と秘密鍵を持ちます)。公開鍵は公開データベースに格納されます。秘密鍵は、暗号化された形式で、同じデータベースに格納されます。鍵のペアを変更するには、chkey コマンドを使用します。

keylogin コマンドの実行

通常、ログインパスワードは Secure RPC パスワードと同じです。この場合、keylogin は必要ありません。パスワードが異なる場合、ユーザーはログインしてから明示的に keylogin を実行しなければなりません。

keylogin プログラムは、Secure RPC パスワードを求めるプロンプトをユーザーに出して、そのパスワードを使用して秘密鍵を復号します。keylogin プログラムは、復号した秘密鍵をキーサーバーというプログラムに渡します (キーサーバーは、すべてのコンピュータ上にローカルインスタンスを持つ RPC サービスです)。キーサーバーは、復号された秘密鍵を保存して、ユーザーがサーバーで Secure RPC トランザクションを発行するのを待ちます。

パスワードが同じ場合は、ログインプロセスが秘密鍵をキーサーバーに渡します。パスワードが異なる必要があり、ユーザーが常に keylogin を実行しなければならない場合は、keylogin プログラムをユーザーの環境の構成ファイル (‾/.login、‾/.cshrc、‾/.profile など) に入れておいて、ユーザーがログインするたびに自動的に実行されるようにします。

対話鍵の生成

ユーザーがサーバーとのトランザクションを開始すると、次の動作が行われます。

1. キーサーバーはランダムに対話鍵を生成します。

2. カーネルはこの対話鍵を使用して、クライアントのタイムスタンプを暗号化します (他の動作も行います)。

3. キーサーバーは公開鍵データベースでサーバーの公開鍵を検索します (publickey(4) のマニュアルページを参照してください)。

4. キーサーバーはクライアントの秘密鍵とサーバーの公開鍵を使用して、共通鍵を作成します。

5. キーサーバーは共通鍵を使用して対話鍵を暗号化します。

サーバーとの最初の接触

次に、暗号化したタイムスタンプと暗号化した対話鍵を含む伝送データがサーバーに送信されます。伝送データには資格とベリファイアが含まれます。資格は、次の 3 つの構成要素を持ちます。

• クライアントのネット名

• 共通鍵で暗号化された対話鍵

• 対話鍵で暗号化された「ウィンドウ」

この場合の「ウィンドウ」とは、クライアントが主張する、サーバーの時刻とクライアントのタイムスタンプとの許容されるべき差のことです。サーバーの時刻とクライアントのタイムスタンプとの間の差がウィンドウより大きい場合、サーバーはクライアントの要求を拒否します。クライアントは RPC セッションを開始する前にサーバーと同期を取るため、通常の状態では、このような事態は発生しません。

クライアントのベリファイアは、次の構成要素を持ちます。

• 暗号化されたタイムスタンプ

• 指定したウィンドウの暗号化されたベリファイアから 1 を引いた値

ウィンドウベリファイアが必要な理由は次の場合です。誰かが別のユーザーになりすまそうとして、資格とベリファイアの暗号化されたフィールドに書き込む代わりに、ランダムなビットだけを埋め込むプログラムを書いたと仮定します。サーバーはこの対話鍵をなんらかのランダム鍵に復号化し、それを使用してウィンドウとタイムスタンプを復号化しようと試みます。その結果、乱数が生成されるだけです。しかし、数千回の試行を重ねるうちには、このランダムなウィンドウタイムスタンプのペアが認証システムを通過することが十分ありえます。ウィンドウベリファイアは、正しい資格の解読をより困難にします。

対話鍵の復号化

サーバーがクライアントから伝送データを受信すると、次の動作が行われます。

1. サーバーのローカルなキーサーバーが、公開鍵データベースでクライアントの公開鍵を検索します。

2. キーサーバーは、クライアントの公開鍵とサーバーの秘密鍵を使用して、共通鍵を計算します。この共通鍵はクライアントが計算したものと同じです。共通鍵を計算するためには、どちらか一方の秘密鍵を知っている必要があるため、これを行えるのはサーバーとクライアントだけです。

3. カーネルは共通鍵を使用して、対話鍵を復号します。

4. カーネルはキーサーバーを呼び出して、復号された対話鍵によりクライアントのタイムスタンプを復号します。

サーバーへの情報の格納

サーバーは、クライアントのタイムスタンプを復号した後、次の 4 種類の情報を資格テーブルに格納します。

• クライアントのコンピュータ名

• 対話鍵

• ウィンドウ

• クライアントのタイムスタンプ

サーバーは、最初の 3 つの情報を将来の使用のために格納します。サーバーはタイムスタンプを格納して、同じタイムスタンプが再度使用できないようにします。サーバーは、最後に参照したタイムスタンプよりも時間的に後のタイムスタンプだけを受け付けるため、同じタイムスタンプのトランザクションはすべて拒否されることが保証されます。

この手順において暗黙的に仮定されているのは呼び出し側の名前であり、何らかの方法でこの名前を認証しなければなりません。キーサーバーは、この目的には DES 認証を使用できません。DES 認証を使用すれば、デッドロックが発生するからです。キーサーバーは、 UID ごとに秘密鍵を格納し、ローカルの root プロセスへの要求だけを許可することによってこの問題を解決します。

クライアントに返されるベリファイア

サーバーは、ベリファイアをクライアントに返します。ベリファイアは、次の構成要素を持ちます。

• サーバーが自分の資格キャッシュに記録するインデックス ID

• 対話鍵によって暗号化された、クライアントのタイムスタンプから 1 を引いたもの

タイムスタンプから 1 を引く理由は、これを無効化して、クライアントのベリファイアとして再利用できないようにするためです。

クライアントによるサーバーの認証

クライアントがベリファイアを受信し、そのサーバーを認証します。クライアントは、このベリファイアを送信できるのはサーバーだけであることを知っています。その理由は、クライアントが送信したタイムスタンプの内容を知っているのはサーバーだけだからです。

追加のトランザクション

一番目以降のすべてのトランザクションごとに、クライアントは 2 番目のトランザクションでインデックス ID をサーバーに返し、もう 1 つの暗号化されたタイムスタンプを送信します。サーバーは、クライアントのタイムスタンプから 1 を引いたものを対話鍵で暗号化して、返送します。

Kerberos Version 4

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 にあります。

NFS による Kerberos 認証の実装

次の手順では、MIT プロジェクト Athena から公開されている Kerberos キー配布センターのソースを使用して、Kerberos キー配布センター (KDC) がすでにネットワーク上にインストールされていると仮定しています。

1. /usr/sbin/kerbd デーモンが NFS クライアントとサーバー上で動作していなければなりません。

   このデーモンは、通常、inetd によって必要に応じて起動されます。rpcinfo コマンドを使用すれば、kerbd サービスが登録されていることを確認できます。kerbd はユーザーモードデーモンです。kerbd は、カーネル RPC および KDC とインターフェースを取ります。kerbd は、認証チケットを生成してその妥当性を検査します。

2. システム管理者は、Kerberos 認証を使用するように NFS サーバーを設定します。

   MIT Kerberos ソフトウェアは、Kerberos サーバー上で Kerberos キー配布センター (KDC) に主体名を登録するのに使用されます。次のエントリが必要です。

   • root.hostname (NFS クライアントごとに必要)

   • nfs.hostname (NFS サーバーごとに必要)

3. ユーザーは、共有ファイルシステムをマウントします。

   共有ファイルシステムをマウントするために、クライアント上のユーザーは、クライアント上で root 用のチケットを取得しなければなりません。

4. ユーザーは、kinit コマンドを使用して、Kerberos サービスにログインします。

   Kerberos 認証サーバーは、要求を認証して、チケット譲与サービス用のチケットを与えます。

5. ユーザーは、マウント済みディレクトリにアクセスします。

   kerbd デーモンは、クライアントのために、ファイルシステムをエクスポートしている NFS サーバー用のチケットを自動的に取得します。この時点で、2 つの有効なチケットがあります。オリジナルのチケット譲与チケットと、サーバー用のチケットです。

6. ユーザーは、セッションの終わりにチケットを削除して、誤用と悪用を防ぎます。

   kdestroy コマンドは、チケットを含むファイルにゼロを書き込むことによって、ユーザーのアクティブな Kerberos 認証チケットを削除します。kdestroy コマンドを .logout ファイルに置いておけば、システムからログアウトするときに、すべての kdestroy チケットを自動的に破壊できます。

7. セッションが終了する前にチケットが削除されていた場合、ユーザーは kinit コマンドで新しいチケットを要求しなければなりません。

Diffie-Hellman 認証の管理

システム管理者は、ネットワークを安全にするためのポリシーをネットワーク上に実装できます。必要なセキュリティのレベルはサイトによって異なります。この節では、ネットワークセキュリティに関連するいくつかの作業手順を説明します。

キーサーバーを再起動する方法

1. スーパーユーザーになります。

2. 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

3. キーサーバーが動作していない場合は、キーサーバーを起動します。

   # /usr/sbin/keyserv

Diffie-Hellman 認証明に NIS+ 資格を設定する方法

NIS+ セキュリティの詳細は、『Solaris ネーミングの管理』を参照してください。

NIS+ クライアント上で root 用の新しい鍵を設定するには

1. スーパーユーザーになります。

2. /etc/nsswitch.conf ファイルを編集して、次の行を追加します。

      publickey: nisplus

3. NIS+ クライアントを起動します。

      # nisinit -cH hostname
   

   hostname は、そのテーブルにクライアントマシン用のエントリを持つ、信頼されている NIS+ サーバー名です。

4. 次のコマンドを入力して、クライアントを cred テーブルに追加します。

      # nisaddcred local
      # nisaddcred des
   

5. keylogin コマンドを使用して、設定を確認します。

   パスワードを求めるプロンプトが出たら、この手順は成功です。

例 - NIS+ クライアント上で root 用の新しい鍵を設定する

次の例は、ホスト 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:
#

NIS+ ユーザー用の新しい鍵を設定するには

1. 次のコマンドを入力して、ユーザーを root マスターサーバー上の cred テーブルに追加します。

      # nisaddcred -p unix.UID@domainname -P username.domainname. des
   

   この場合、「username-domainname」はドット (.) で終了しなければなりません。

2. クライアントとしてログインし、keylogin コマンドを入力して、設定を確認します。

例 - NIS+ ユーザー用の新しい鍵を設定する

次の例は、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:
#

Diffie-Hellman 認証で NIS 資格を設定する方法

クライアント上でスーパーユーザー用の新しい鍵を作成するには

1. クライアント上でスーパーユーザーになります。

2. /etc/nsswitch.conf ファイルを編集して、次の行を追加します。

   publickey: nis

3. newkey コマンドを使用して、新しい鍵ペアを作成します。

      # newkey -h hostname 
   

   hostname は、クライアント名です。

例 - Diffie-Hellman セキュリティを使用するように NIS+ クライアントを設定する

次の例は、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.
#

ユーザー用の新しい鍵を作成するには

1. サーバーにスーパーユーザーとしてログインします。

   ユーザー用の新しい鍵を作成できるのは、NIS+ サーバーにログインしたシステム管理者だけです。

2. ユーザー用の新しい鍵を作成します。

      # 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.
      #

3. ログインして 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-Helman 認証でファイルを共有およびマウントする方法

前提条件

Diffie-Hellman の publickey 認証がネットワークで有効にされていなければなりません。「Diffie-Hellman 認証明に NIS+ 資格を設定する方法」と 「Diffie-Hellman 認証で NIS 資格を設定する方法」を参照してください。

Diffie-Hellman 認証でファイルシステムを共有するには

1. スーパーユーザーになります。

2. Diffie-Hellman 認証でファイルシステムを共有します。

   # share -F nfs -o sec=dh /filesystem

Diffie-Hellman 認証でファイルシステムをマウントするには

1. スーパーユーザーになります。

2. Diffie-Hellman 認証でファイルシステムをマウントします。

      # mount -F nfs -o sec=dh server:resource  mountpoint 
   

   -o sec=dh オプションは、AUTH_DH 認証でファイルシステムをマウントします。

Kerberos Version 4 認証の管理

システム管理者は、ネットワークを安全にするためのポリシーをネットワーク上に実装できます。必要なセキュリティのレベルはサイトによって異なります。この節では、ネットワークセキュリティに関連するいくつかの作業手順を説明します。

Kerberos 認証でファイルを共有およびマウントする方法

前提条件

Kerberos Version 4 認証がネットワークで有効にされていなければなりません。

Kerberos 認証でファイルシステムを共有するには

1. スーパーユーザーになります。

2. Kerberos 認証でファイルシステムを共有します。

      # share -F nfs -o sec=krb4 /filesystem
   

Kerberos 認証でファイルシステムをマウントするには

1. スーパーユーザーになります。

2. Kerberos 認証でファイルシステムをマウントします。

      # mount -F nfs -o sec=krb4 server:resource mountpoint
   

   -o sec=krb4 オプションは、AUTH_KERB 認証でファイルシステムをマウントします。

クライアント上でスーパーユーザー用の Kerberos チケットを取得する方法

アクセスする必要がある NFS ファイルシステムがマウントされていない場合、マウントする前に、クライアント上でスーパーユーザー用のチケットを取得する必要があります。

マウントしていないファイルシステム用のチケットを取得するには

1. スーパーユーザーになります。

2. クライアント上で Kerberos チケットを取得します。

      # kinit root.hostname
   

   hostname はクライアントシステム名です。

      # kinit root.earth
      Password:
      #

マウント済みファイルシステム用のチケットを取得するには

/etc/srvtab 構成ファイルにクライアント用のエントリ root.hostname が入力されている場合、ksrvtgt コマンドを使用して、スーパーユーザー用のチケットを取得できます。この場合、スーパーユーザーのパスワードを指定する必要はありません。/etc/srvtab ファイルの初期化については、MIT のマニュアルを参照してください。

1. スーパーユーザーになります。

2. マウント済みファイルシステム用のチケットを取得します。

      # ksrvtgt root.hostname
   

例 - クライアント上でスーパーユーザー用の Kerberos チケットを取得する

   # ksrvtgt root.earth
   #

Kerberos サービスにログインする方法

Kerberos サービスにログインするには、kinit -l username コマンドを使用します。

earth% kinit -l username

kinit コマンドは、チケットの生存期間 (-l オプションを指定した場合) とパスワードを求めるプロンプトを出します。冗長モード (-v オプション) を使用すれば、チケットの状態が出力されます。

例 - Kerberos サービスにログインする

earth% kinit -l jjones
SunOS (earth)
Kerberos Initialization for "jjones"
Kerberos ticket lifetime (minutes): 480
Password:
earth%

Kerberos チケットをリストする方法

klist と入力します。

例 - Kerberos チケットをリストする

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

Kerberos 認証でディレクトリにアクセスする方法

cd /mountpoint と入力します。

他のマウント済みディレクトリと同様に、マウント済みディレクトリにアクセスします。ls コマンドでディレクトリ中のファイルをリストしたり、klist コマンドで Kerberos チケットをリストしたりできます。

例 - 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

Kerberos チケットを削除する方法

kdestroy を入力します。

セッションが終了するときは、Kerberos チケットを削除します。これは、認証されていないユーザーがアクセスできないようにするためです。Kerberos 認証を再発行するには、kinit コマンドを使用します。

例 - Kerberos チケットを削除する

次の例は、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.

PAM について

Pluggable Authentication Module (PAM) フレームワークを使用すると、login、ftp、telnet などのシステムに入るためサービスを変更しなくても、新しい認証技術を「プラグイン」できるようになります。また、PAM を使用すれば、 UNIX ログインを DCE や Kerberos のような他のセキュリティ機構と統合できます。また、アカウント、セッション、およびパスワードの管理機構もプラグインできます。

PAM を使用する利点

PAM フレームワークを使用すると、システム管理者は任意のシステムに入るため、サービス (ftp、login、telnet、rsh など) とユーザー認証用を組み合わせることができます。次に PAM の利点をいくつか挙げます。

• 柔軟な構成ポリシー

  • アプリケーションごとの認証ポリシー

  • デフォルトの認証機構を選択する機能

  • 高度なセキュリティシステムにおける複数のパスワード

• エンドユーザーにも使いやすい

  • 機構が異なってもパスワードが同じであれば、パスワードを再入力する必要がない

  • 各認証方法に関連するパスワードが異なっている場合でも、パスワードマッピング機能により、複数の認証方法で 1 つのパスワードを使用する機能

  • ユーザーが複数のコマンドを入力しなくても、複数の認証方法のパスワードを求めるプロンプトを出す機能

• オプションパラメタをユーザー認証サービスに渡す機能

PAM の概要

PAM は、実行時に取り外しが可能なモジュールを使用して、システムに入るためのサービスに認証を提供します。これらのモジュールは、その機能に基づき、4 つの異なるタイプに分かれます。認証、アカウント管理、セッション管理、およびパスワード管理です。スタッキング機能によって、複数のサービス経由でユーザーを認証できます。また、パスワードマッピング機能によって、ユーザーは複数のパスワードを覚えておく必要がありません。

PAM モジュールのタイプ

モジュールタイプはモジュールのインターフェースを定義するため、PAM モジュールのタイプを理解することは重要です。実行時 PAM モジュールには、次の 4 つのタイプがあります。

• 「認証モジュール」は、ユーザーの認証を提供して、資格を設定、更新、または削除できます。認証モジュールは、ユーザーの識別に役立つ管理ツールを提供します。

• 「アカウントモジュール」は、パスワードの有効期限、アカウントの有効期限、およびアクセス時間制限をチェックします。アカウントモジュールは、認証モジュールでユーザーを識別した後に、そのユーザーにアクセス権を与えるべきかどうかを決定します。

• 「セッションモジュール」は、認証セッションの開閉を管理します。セッションモジュールは、動作を記録したり、セッション終了後のクリーンアップを実行したりできます。

• 「パスワードモジュール」によって、実際のパスワードを変更できます。

スタッキング機能

PAM フレームワークは、「スタッキング機能」を使用して、複数のサービスでユーザーを認証する方法を提供します。構成によって、認証方法ごとにパスワードを求めるプロンプトをユーザーに出すことも可能です。認証サービスが使用される順序は、PAM 構成ファイルで決定されます。

パスワードマッピング機能

スタッキング機能をを使った方法では、ユーザーが複数のパスワードを覚えておかなければなりません。「パスワードマッピング機能」を使用すれば、主要パスワードから他のパスワードを復号できるので、ユーザーは複数のパスワードを覚えたり入力したりする必要はありません。各認証機構間でパスワードの同期を取るためのオプションもあります。スタック内で使用される最も安全性の低いパスワードによって各機構のセキュリティが制限されてしまうので、この方法はセキュリティの危険性を増大してしまうことに注意してください。

PAM の機能

PAM ソフトウェアは、ライブラリ、いくつかのモジュール、および構成ファイルからなります。いくつかのシステムに入るためのコマンドまたはデーモンの新しいバージョンは、PAM インタフェースを利用できます。

図 15-1 は、アプリケーション、PAM ライブラリ、pam.conf ファイル、および PAM モジュール間の関係を示しています。

図 15-1 PAM の動作

アプリケーション (ftp、telnet、および login) は、PAM ライブラリを使用して、適切なモジュールにアクセスします。pam.conf ファイルは、使用するモジュールを定義して、各アプリケーションがモジュールを使用する順番を定義します。モジュールからの応答は、ライブラリ経由でアプリケーションに戻されます。

次の節では、この関係について説明します。

PAM ライブラリ

PAM ライブラリ /usr/lib/libpam は、適切なモジュールをロードして、スタッキング手順を管理するためのフレームワークを提供します。また、すべてのモジュールを取り外すことができる汎用構造も提供します。

PAM モジュール

各 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 構成ファイル

PAM 構成ファイル /etc/pam.conf は、使用する認証サービスとそれらを使用する順序を決定します。このファイルを編集すれば、システムに入るためのアプリケーションごとに認証機構を選択できます。

構成ファイルの構文

PAM 構成ファイルは、次の構文のエントリからなります。

service_name 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 モジュールタイプはありません。

制御フラグ

認証プロセス中にモジュールの処理を継続するか失敗するかを決定するには、エントリごとに 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.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 ファイルは、次の内容を指定しています。

1. login を実行するとき、pam_unix モジュールと pam_dial_auth モジュールの両方による認証が成功しなければなりません。

2. rlogin を実行するとき、pam_unix モジュールによる認証が失敗した場合は、pam_rhost_auth モジュールによる認証が成功しなければなりません。

3. sufficient 制御フラグは、rlogin の場合は、pam_rhost_auth モジュールによる認証が成功すれば十分であり、次のエントリが無視されることを示しています。

4. 認証を必要とする他のほとんどのコマンドの場合、pam_unix モジュールによる認証が成功しなければなりません。

5. 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 構成ファイルに関連するセキュリティのいくつかの問題について注意する必要があります。

PAM の計画

どのように PAM を使用すればユーザーのサイトに最適であるかを決定するために、次の問題から始めます。

• 何が必要か、特にどのモジュールを選択するかを決定します。

• 特別な注意が必要なサービスを確認します。適宜、OTHER を使用します。

• モジュールを実行する順番を決定します。

• そのモジュールに対する制御フラグを選択します。

• モジュールに必要な任意のオプションを選択します。

ここで、構成ファイルを変更する前に考慮すべき問題を示します。

• すべてのアプリケーションを指定しなくてもいいように、モジュールタイプごとに OTHER エントリを使用します。

• sufficient 制御フラグと optional 制御フラグのセキュリティの意味を考慮します。

• モジュールに関連するマニュアルページを参照して、各モジュールがどのように機能するか、どのオプションが使用できるか、およびスタック中のモジュール間の相互作用を理解します。

  ---

  警告 -

  PAM 構成ファイルの構成を間違えたり壊したりすると、スーパーユーザーでもログインできなくなる可能性があります。sulogin は PAM を使用しないので、スーパーユーザーは、マシンをシングルユーザーモードでブートして問題を解決しなければなりません。

  ---

/etc/pam.conf ファイルの変更後、スーパーユーザーとしてログインしている間にできるだけ調査します。変更によって影響を受けるコマンドは、すべてテストします。たとえば、新しいモジュールを telnet サービスに追加した場合、telnet コマンドを使用して、行なった変更が期待どおりに動作しているかどうかを確認します。

PAM モジュールを追加する方法

1. スーパーユーザーになります。

2. 使用される制御フラグやオプションを決定します。

   モジュールについては、「PAM モジュール」を参照してください。

3. 新しいモジュールを /usr/lib/security にコピーします。

4. モジュールファイルの所有者が root で、そのアクセス権が 555 になるように、アクセス権を設定します。

5. PAM 構成ファイル /etc/pam.conf を編集して、このモジュールを適切なサービスに追加します。

確認

構成ファイルが間違って構成されていた場合などのために、システムをリブートする前にテストすることは非常に重要です。システムをリブートする前に、rlogin、su、および telnet を実行します。サービスが、システムがブートするときだけに生成されるデーモンの場合は、システムをリブートしなければ、モジュールが正しく追加されていることを確認できません。

PAM を使用して、リモートシステムからの認証されていないアクセスを防ぐ方法

PAM 構成ファイルから「rlogin auth rhosts_auth.so.1」エントリを削除します。これによって、rlogin セッション中、‾/.rhosts ファイルは読み込まれなくなります。したがって、リモートシステムからローカルシステムへの認証されていないアクセスを防ぐことができます。‾/.rhosts ファイルまたは /etc/hosts.equiv ファイルの存在またはその内容にかかわらず、すべての rlogin アクセスにはパスワードが必要になります。

‾/.rhosts ファイルへの認証されていない他のアクセスを防ぐには、rsh サービスも無効にする必要があります。サービスを無効にする最良の方法は、/etc/inetd.conf からサービスエントリを削除することです。PAM 構成ファイルを変更しても、サービスを無効にはできません。

PAM のエラー報告を有効にする方法

1. /etc/syslog.conf を編集して、次の PAM のエラー報告に関するエントリを追加します。

   • auth.alert - 即座に修正しなければならない状態についてのメッセージ

   • auth.crit - 致命的なメッセージ

   • auth.err - エラーメッセージ

   • auth.info - 情報通知用メッセージ

   • auth.debug - デバッグ用メッセージ

2. syslog デーモンを再起動するか、SIGHUP シグナルをこのデーモンに送信して、PAM のエラー報告を有効にします。

例 - PAM のエラー報告を有効にする

次の例では、警戒メッセージはすべてコンソールに表示されます。致命的なメッセージは root に電子メールで送信されます。情報メッセージとデバッグ用メッセージは、/var/log/pamlog ファイルに追加されます。

auth.alert	/dev/console
auth.crit	'root'
auth.info;auth.debug	/var/log/pamlog

ログ内の各行は、タイムスタンプ、メッセージを生成したシステム名とメッセージ自身からなります。pamlog ファイルには、大量の情報が記録される可能性があります。

第 16 章 自動セキュリティ拡張ツールの使用手順

この章では、自動セキュリティ拡張ツール (ASET) を使用して、システムファイルおよびディレクトリへのアクセスを監視または制限する方法について説明します。

この章で説明する手順は次のとおりです。

• 「ASET を対話的に実行する方法」

• 「ASET を定期的に実行する方法」

• 「ASET の定期的な実行を中止する方法」

• 「サーバー上でレポートを収集する方法」

自動セキュリティ拡張ツール (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 のセキュリティレベル

ASET は、低、中、高の 3 つのセキュリティレベルのいずれかで動作するように設定できます。上のレベルほど、ASET のファイル制御機能が増え、ファイルアクセスが減少し、システムのセキュリティが厳しくなります。これらの機能には、ユーザーによるファイルアクセスを制限せずにシステムセキュリティを監視する最低レベルから、システムが完全にセキュリティ保護される最高レベルまで、アクセス権が段階的に厳格になります。

次に、この 3 つのセキュリティレベルについて説明します。

• 低セキュリティ - このレベルでは、ファイルシステムの属性が標準リリース値に設定されることが保証されます。ASET は複数のチェックを実行し、セキュリティ上の潜在的な弱点を報告します。このレベルでは、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 セキュリティパラメタの値がチェックされ、適切なセキュリティレベルに設定されているかどうかが確認されます。eeprom セキュリティパラメタは、none、command、または full に設定できます。

ASET はこの設定を変更しませんが、推奨値を eeprom.rpt ファイル内でレポートします。

ファイアウォールの設定

このタスクでは、システムをネットワークリレーとして安全に使用できることが保証されます。「ファイアウォールシステム」で説明したように、ファイアウォール専用システムが設定され、内部ネットワークが外部の公共ネットワークから保護されます。ファイアウォールシステムは、相互に信頼されない (untrusted) システムとしてアクセスし合う 2 つのネットワークを分離します。ハードウェアの設定作業によって、インターネットプロトコル (IP) パケットを転送できなくなり、ルーティング情報は外部ネットワークから隠されます。

ファイアウォールのタスクはすべてのセキュリティレベルで実行されますが、ファイアウォールとしての本来の機能は最上位レベルでのみ動作します。ASET を高セキュリティレベルで実行したいが、システムにはファイアウォール保護が不要であることがわかった場合は、asetenv ファイルを編集してファイアウォールタスクを除去できます。

行われた変更はすべて firewall.rpt ファイル内にレポートされます。

ASET 実行ログ

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 レポート

ASET タスクから生成されたすべてのレポートファイルは、ディレクトリ /usr/aset/reports の下のサブディレクトリに入っています。この節では、/usr/aset/reports ディレクトリの構造と、レポートファイルを管理するためのガイドラインについて説明します。

ASET はレポートファイルを指定されたサブディレクトリに格納し、レポートの生成日時を反映させます。このため、ASET を実行するたびに変化するシステムの状態を示すレコードを順番に追跡できます。これらのレポートを監視し、比較して、システムセキュリティの状況を判断できます。

図 16-1 に reports ディレクトリ構造の例を示します。

図 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 にタスクとそのレポートのリストを示します。

各レポートファイル内で、メッセージの前後はバナー行で囲まれています。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 マスタファイル

ASET のマスタファイル、tune.high、tune.low、tune.med、uid_aliases は、ディレクトリ /usr/aset/masters に入っています。ASET は、マスタファイルを使用してセキュリティレベルを定義します。

調整ファイル

tune.low、tune.med、tune.high マスタファイルでは、利用できる ASET セキュリティレベルが定義されます。各ファイルでは、各レベルのシステムファイルの属性が指定され、比較と参照に使用されます。

uid_aliases ファイル

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

ASET 環境ファイル (asetenv)

環境ファイル asetenv には、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 の実行スケジュールを指定する。

• 別名ファイルを指定する。

• チェック対象を NIS+ テーブルまで拡張する。

実行するタスクの選択：TASKS

ASET が実行する各タスクでは、システムセキュリティの特定の領域が監視されます。ほとんどのシステム環境では、すべてのタスクでバランスがとれたセキュリティ範囲を提供する必要があります。ただし、1 つ以上のタスクを除外してもかまいません。

たとえば、ファイアウォールタスクはすべてのセキュリティレベルで実行されますが、本来の機能は最上位レベルでのみ動作します。ASET を高セキュリティレベルで実行したいが、ファイアウォール保護は不要な場合があります。

asetenv ファイル内で環境変数の TASKS リストを編集すると、ファイアウォール機能を使用しないで高レベルで実行するように ASET を設定できます。デフォルトでは、TASKS リストにはすべての ASET タスクが入っています (次の例を参照してください)。タスクを削除するには、そのタスクの設定をファイルから削除します。この場合は、リストから firewall 環境変数を削除することになります。次回に ASET を実行すると、除外したタスクは実行されません。

TASKS="env sysconfig usrgrp tune cklist eeprom firewall"

チェックリストタスク用のディレクトリの指定： CKLISTPATH

システムファイルチェックでは、選択したシステムディレクトリ内のファイルの属性がチェックされます。次のチェックリストパス環境変数を使用して、どのディレクトリをチェックするかを定義できます。

• CKLISTPATH_LOW

• CKLISTPATH_MED

• CKLISTPATH_HIGH

CKLISTPATH_LOW 変数は、低セキュリティレベルでチェックされるディレクトリを定義します。CKLISTPATH_MED と CKLISTPATH_HIGH 環境変数は、中程度と高度のセキュリティレベルに同じように機能します。

低セキュリティレベルの変数で定義したディレクトリリストは、1 つ上位レベルで定義するディレクトリリストのサブセットにする必要があります。たとえば、CKLISTPATH_LOW に定義したすべてのディレクトリを CKLISTPATH_MED に含め、CKLISTPATH_MED に指定したすべてのディレクトリを CKLISTPATH_HIGH に含めます。

これらのディレクトリに対して実行されるチェックは再帰的ではありません。ASET は変数内に明示的にリストされたディレクトリのみをチェックします。そのサブディレクトリはチェックされません。

これらの変数の定義を編集して、ASET にチェックさせたいディレクトリを追加または削除できます。これらのチェックリストは、一般に毎日変化しないシステムファイルにのみ有効なので注意してください。たとえば、ユーザーのホームディレクトリは動的な変化が大きすぎるので、チェックリストの候補にはならないのが普通です。

AEST の実行スケジュールの指定： PERIODIC_SCHEDULE

ASET を起動するときには、対話形式で起動する方法と、-p オプションを使用して ASET タスクをスケジュール指定した時刻と期間に実行する方法があります。ASET は、システム需要が少ないときに定期的に実行できます。たとえば、ASET は PERIODIC_SCHEDULE を照会して、ASET タスクの実行頻度と実行時刻を判断します。ASET を定期的に実行するように設定する方法については、「ASET を定期的に実行する方法」を参照してください。

PERIODIC_SCHEDULE の形式は、crontab エントリの形式と同じです。詳細は、crontab(1) のマニュアルページを参照してください。

別名ファイルの指定： UID_ALIASES

UID_ALIASES 変数は、共有ユーザー ID がリストされる別名ファイルを指定します。 デフォルトは /usr/aset/masters/uid_aliases です。

チェック範囲を NIS+ テーブルまで拡張する： YPCHECK

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 を初めて実行すると、元のシステムファイルが保存され保管されます。aset.restore ユーティリティは、これらのファイルを復元します。また、ASET を定期的に実行するようにスケジュール指定している場合は、そのスケジュールを解除します。aset.restore ユーティリティは、ASET の動作ディレクトリ /usr/aset に入っています。

システムファイルに対して行われた変更は、aset.restore を実行すると失われます。

次の場合に aset.restore を使用してください。

• ASET の変更を削除して元のシステムを復元したい場合。ASET を永久に無効にしたい場合は、以前に root の crontab に aset コマンドが追加されていれば、cron スケジュールから削除できます。cron を使用して自動実行を削除する方法については、「ASET の定期的な実行を中止する方法」を参照してください。

• ASET を短期間実行した後に、元のシステム状態を復元する場合

• 一部の主要なシステム機能が正常に動作せず、ASET が原因だと思われる場合

NFS システムを使用するネットワーク操作

通常、ネットワークの一部となっているシステム上でも、ASET はスタンドアロンモードで使用されます。スタンドアロンシステムのシステム管理者は、システムのセキュリティとシステムを保護する ASET の実行と管理を担当することになります。

また、ASET は NFS 分散環境でも使用できます。ネットワーク管理者は、すべてのクライアントの各種管理タスクのインストール、実行、管理を担当します。複数のクライアントシステム間で ASET を管理しやすくするために、構成変更を行なってすべてのクライアントに一括して適用すれば、各システムにログインしてプロセスを繰り返す必要がなくなります。

ネットワークシステム上で ASET の設定方法を決めるときには、ユーザーに各自のシステム上でセキュリティをどのように制御させるかと、セキュリティ制御に関する責任をどの程度集中させるかを検討する必要があります。

各セキュリティレベルの一括構成の提供

複数のネットワーク構成を設定したい場合があります。たとえば、低セキュリティレベルに指定したクライアント用に 1 つ、中レベルのクライアント用に 1 つ、さらに高レベルのクライアント用に 1 つというように設定できます。

セキュリティレベルごとに別の ASET ネットワーク構成を作成したい場合は、サーバー上でレベルごとに 1 つずつ合計 3 つの ASET 構成を作成できます。各構成を該当するセキュリティレベルのクライアントにエクスポートすることになります。3 つの構成すべてに共通の ASET 構成要素は、リンクを使用して共有できます。

ASET レポートの収集

スーパーユーザー特権を持つか持たないかに関係なく、クライアントにアクセスされるサーバー上に ASET 構成要素を集中できるだけでなく、サーバー上でディレクトリを設定して、各種クライアント上で実行中のタスクによって生成されるすべてのレポートを収集できます。収集機構を設定する方法については、「サーバー上でレポートを収集する方法」を参照してください。

サーバー上でレポートを収集するように設定すると、すべてのクライアントに関するレポートを 1 箇所で検討できます。この方法は、クライアントがスーパーユーザー特権を持っているかどうかに関係なく使用できます。また、ユーザーに各自の ASET レポートを監視させたい場合は、ローカルシステム上にレポートディレクトリを残しておいてもかまいません。

環境変数

表 16-2 に ASET 環境変数と各変数で指定する値を示します。

次に示す環境変数は、ファイル /usr/aset/asetenv に入っています。ASETDIR 変数と ASETSECLEVEL 変数はオプションで、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 を次のいずれかに設定できます。

PERIODIC_SCHEDULE 変数

PERIODIC_SCHEDULE の値の形式は、crontab ファイルと同じです。変数の値は二重引用符で囲んだ 5 つのフィールドからなる文字列として指定します。各フィールドは空白文字 1 つで区切ってください。

"minutes hours day-of-month month day-of-week"

次の規則が適用されます。

• どのフィールドでも、値のリストをコンマで区切って指定できます。

• 値を数値または範囲として指定できます。範囲とは、1 対の数値をハイフンで結合したものです。範囲は、範囲に含まれるすべての時刻に 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+ テーブルを含めます。これはブール変数なので、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 つの調整ファイルを管理します。3 つの調整ファイル内のエントリについては、表 16-4 で説明しています。

次の規則が適用されます。

• パス名には、アスタリスク (*) や疑問符 (?) など、通常のシェルワイルドカード文字を使用して、複数のエントリを指定できます。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=...

たとえば、次のエントリでは、sysadm と root に共有されるユーザー ID 0 を示しています。

0=root=sysadm

ASET の実行

この節では、ASET を対話的にまたは定期的に実行する方法について説明します。

ASET を対話的に実行する方法

1. スーパーユーザーになります。

2. aset コマンドを使用して ASET を対話的に実行します。

      # /usr/aset/aset -l level -d pathname
   

   level	セキュリティレベルを指定する。有効な値は low、medium、または high。デフォルト設定は low。セキュリティレベルについては、「ASET のセキュリティレベル」を参照
   pathname	ASET の作業ディレクトリを指定する。デフォルトは /usr/aset

3. 画面に表示される 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 を定期的に実行する方法

1. スーパーユーザーになります。

2. 必要であれば、ASET を定期的に実行したい時刻を設定します。

   システム需要が少ないときに ASET を実行してください。/usr/aset/asetenv ファイル内の PERIODIC_SCHEDULE 環境変数を使用して、ASET を定期的に実行する時刻を設定します。デフォルトでは、この時刻は 24 時間ごとに真夜中に設定されています。

   別の時刻を設定したい場合は、/usr/aset/asetenv ファイル内で PERIODIC_SCHEDULE 変数を編集します。PERIODIC_SCHEDULE 変数の設定の詳細は、「PERIODIC_SCHEDULE 変数」を参照してください。

3. aset コマンドを使ってエントリを crontab ファイルに追加します。

      # /usr/aset/aset -p
   

   -p	/usr/aset/asetenv ファイル内の PERIODIC_SCHEDULE 環境変数で決めた時刻に ASET の実行を開始する行を crontab ファイルに挿入する

4. 次のコマンドを実行すると crontab エントリが表示され、ASET の実行スケジュールを確認できます。

      # crontab -l root
   

ASET の定期的な実行を中止する方法

1. スーパーユーザーになります。

2. crontab ファイルを編集します。

      # crontab -e root
   

3. ASET エントリを削除します。

4. 変更結果を保存して終了します。

5. crontab エントリを表示して、ASET エントリが削除されていることを確認します。

      # crontab -l root
   

サーバー上でレポートを収集する方法

1. スーパーユーザーになります。

2. サーバー上でディレクトリを作成します。

   1. /usr/aset ディレクトリに移動します。

         mars# cd /usr/aset
      

   2. rptdir ディレクトリを作成します。

         mars# mkdir rptdir
      

   3. rptdir ディレクトリに移動して、client_rpt ディレクトリを作成します。

      mars# cd rptdir
      mars# mkdir client_rpt
      

   4. このコマンドによって、クライアント用のサブディレクトリ (<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
      

3. 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

4. dfstab ファイル内のリソースをクライアントが利用できるようにします。

      # shareall
   

5. 各クライアント上でクライアントのサブディレクトリを、マウントポイント /usr/aset/masters/reports にサーバーからマウントします。

   # mount server:/usr/aset/client_rpt /usr/aset/masters/reports
   

6. /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.

Usage: aset [-n user[@host]] in /bin/mail or /usr/ucb/mail.
Cannot decide current and previous security levels.

ASET working directory undefined.
To specify, set ASETDIR environment variable or use command line option -d.
ASET startup unsuccessful.

ASET working directory $ASETDIR missing.
ASET startup unsuccessful.

Cannot expand $ASETDIR to full pathname.

aset: invalid/undefined security level.
To specify, set ASETSECLEVEL environment variable or use command line option 
-l, with argument= low/med/high.

ASET environment file asetenv not found in $ASETDIR.
ASET startup unsuccessful.

filename doesn't exist or is not readable.

ASET task list TASKLIST undefined.

ASET task list $TASKLIST missing.
ASET startup unsuccessful.

Schedule undefined for periodic invocation.
No tasks executed or scheduled. Check asetenv file.

Warning! Duplicate ASET execution scheduled.
Check crontab file.