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

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

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

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

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

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

• ファイルアクセスの制御

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

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

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

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

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

• ログイン制御の管理

• リソース使用の監視と制限

• ファイルの保護

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

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

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

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

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

ログイン制御の管理

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

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

• files – ローカルマシンの /etc ファイルを指定する

• nis – NIS マスターサーバーの NIS データベースを指定する

• nisplus – NIS+ root サーバーの NIS+ データベースを指定する

• ldap – LDAP サーバーの LDAP ディレクトリサービスを指定する

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

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

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

パスワード情報の管理

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

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

ローカルパスワード

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

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

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

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

LDAP パスワード

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

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

パスワードの暗号化

パスワードの強力な暗号化は攻撃に対する最初の障壁になります。Solaris 9 12/02 リリースには、4 つのパスワード暗号化モジュールがあります。MD5 モジュール群と Blowfish モジュールでは、UNIX アルゴリズムよりも強固なパスワードの暗号化が行われます。

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

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

次に、デフォルトの policy.conf ファイルを示します。

#
# Copyright 1999-2002 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#
# /etc/security/policy.conf
#
# security policy configuration for user attributes. see policy.conf(4)
#
#ident  "@(#)policy.conf        1.6     02/06/07 SMI"
#
AUTHS_GRANTED=solaris.device.cdrw
PROFS_GRANTED=Basic Solaris User

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

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

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

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

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

アルゴリズムの選択を構成するための構文については、policy.conf(4) のマニュアルページを参照してください。新しいパスワード暗号化アルゴリズムを使用する方法については、パスワード暗号化のデフォルトアルゴリズムを変更するを参照してください。

特別なシステムログイン

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

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

リモートログイン

侵入者にとって、リモートログインは魅力的な手段です。Solaris オペレーティング環境には、リモートログインを監視、制限、および無効にするコマンドがいくつもあります。手順については、ログインとパスワードのセキュリティを参照してください。

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

ダイヤルアップログイン

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

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

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

• /etc/passwd 内のユーザーのログインシェルが /etc/d_passwd 内のエントリと一致する場合、そのユーザーはダイヤルアップパスワードを入力する必要があります。

• /etc/passwd 内のユーザーのログインシェルが /etc/d_passwd 内で見つからない場合、/usr/bin/sh のパスワードエントリが使用されます。

  /etc/passwd 内のログインシェルフィールドが空の場合は、/usr/bin/sh のパスワードエントリが使用されます。

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

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

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

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

システムをスーパーユーザーモードにするには、root パスワードが必要です。デフォルトの構成では、ユーザーはリモートのシステムに root としてログインできません。リモートログインするとき、ユーザーは自分のユーザー名でログインしてから、su コマンドを使用して root になる必要があります。セキュリティ上の理由から、su コマンドを使用中のユーザー、特にスーパーユーザーのアクセス権を取得しようとしているユーザーを監視する必要があります。 スーパーユーザーを監視したり、スーパーユーザーの使用を制限する手順については、スーパーユーザーの監視と制限を参照してください。

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

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

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

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

システム管理者やユーザーによって、意図しないエラーが引き起こされるのを防止できます。たとえば、PATH 変数を正しく設定することによって、トロイの木馬の実行を防止できます。あるいは、システムのうち各人の作業に必要な部分だけをユーザーに提供することによって、ユーザーエラーを避けることができます。実際、注意深い設定を行えば、ユーザーに対して、作業を能率的に行うのに必要な部分だけを見せるようにできます。

パス変数の設定

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

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

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

制限付きシェルの割り当て

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

• ユーザーはホームディレクトリ内に限定されるため、 cd コマンドを使用してディレクトリを変更できない。したがって、システムファイルを閲覧することはできない。

• ユーザーは PATH 変数を変更できないため、システム管理者によって設定された PATH のコマンドしか使用できない。さらに、完全なパス名を使ってコマンドやスクリプトを実行することもできない。

• ユーザーは > または >> を使用して出力をリダイレクトできない。

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

制限付きシェルについては、rsh(1M) のマニュアルページを参照してください。

制限付きシェルよりさらにセキュリティを強化したシェルが Secure Shell、すなわち ssh コマンドです。Secure Shell を使用すると、セキュリティ保護されていないネットワーク上のリモートホストに、安全にアクセスすることができます。Secure Shell 上の使用方法については、第 12 章「Solaris Secure Shell の管理 (参照)」を参照してください。

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

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

ログイン制限を設定したあと、マシン上のデータへのアクセスを制御できます。一部のユーザーには特定のファイルの読み取りを許可し、別のユーザーには特定のファイルを変更または削除するアクセス権を与えることができます。誰にも見せたくないデータがある場合もあります。ファイルのアクセス権の設定方法については、第 4 章「ファイルのセキュリティの適用 (手順)」を参照してください。

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

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

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

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

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

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

リソースマネージャの使用

Solaris ソフトウェアには、リソースマネージャと呼ばれる精巧なリソース管理ツールがあります。リソースマネージャは、サービス拒否攻撃を防止する上で有効な場合があります。リソースマネージャでは、特定のプロジェクトに必要なリソースを割り当てたり、スクリプトがマシンのリソースを過度に使用するのを防止したり、プロジェクトが占有できる領域を制限したりすることができます。リソースマネージャの使用方法の説明や詳しい例については、『Solaris のシステム管理 (資源管理とネットワークサービス)』の「Solaris 9 リソースマネージャ (トピック)」を参照してください。

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

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

• 通常の負荷はどの程度か

• 誰がシステムへのアクセス権を持っているか

• 各ユーザーはいつシステムにアクセスするか

• システムでは通常どのようなプログラムを実行するか

このような情報を把握していれば、ツールを使用してマシンの使用状況を監査し、各ユーザーのアクティビティを監視できます。セキュリティ違反が疑われる場合は、監視作業が特に役立ちます。監査モジュールの詳細については、第 20 章「BSM (概要)」を参照してください。

ファイルアクセスの制御

Solaris オペレーティング環境はマルチユーザー環境です。マルチユーザー環境では、マシンにログインしているすべてのユーザーが、ほかのユーザーに属しているファイルを読み取ることができます。さらに、適切なアクセス権をもっているユーザーは、ほかのユーザーに属しているファイルを使用できます。表 2–3 は、ファイルシステムセキュリティのコマンドの一覧です。ファイルのセキュリティの作業手順については 第 4 章「ファイルのセキュリティの適用 (手順)」を参照してください。

ファイルシステムセキュリティのコマンド

次の表は、ファイルとディレクトリの監視およびセキュリティに関するコマンドの一覧です。

ファイルの暗号化

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

米国では、Solaris ソフトウェアのすべてのユーザーは、もう 1 つのセキュリティ層として暗号化キットを使用できます。この暗号化キットには crypt コマンドが組み込まれており、テキストを変換してデータを暗号化します。詳細は、crypt(1) のマニュアルページを参照してください。

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

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

• 所有者のファイルアクセス権

• 所有者のグループのファイルアクセス権

• 所有者のグループに属していないユーザーのファイルアクセス権

• 特定ユーザーのファイルアクセス権

• 特定グループのファイルアクセス権

• 以上のカテゴリそれぞれのデフォルトアクセス権

ACL を設定する手順については、アクセス制御リスト (ACL) の使用を参照してください。

次の表に、ファイルやディレクトリに対して ACL を管理するコマンドを示します。

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

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

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

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

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

NFS サーバーは、共有ファイルシステムのスーパーユーザー特権をホスト単位で与えることができます。この特権を与えるには、share コマンドの root=hostname オプションを使用します。このオプションは慎重に使用してください。

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

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

たとえば、ネットワーク内では、個々のマシンは情報を共有できるように開放されています。また、多数の人々がネットワークにアクセスするので、特にユーザーエラーを通じて、不当なアクセスが発生する可能性も大きくなります。たとえば、パスワードの不適切な扱いも不当なアクセスの原因になりえます。

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

一般にネットワークのセキュリティは、リモートシステムからの操作を制限またはブロックすることを指しています。次の図は、リモート操作に適用できるセキュリティ制限を示します。

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

リモートアクセスの認証と承認

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

Solaris システム間での特権付きポートの使用

Secure RPC を実行したくない場合は、代わりに Solaris の「特権付きポート」メカニズムを使用できます。特権付きポートには、1024 未満のポート番号が割り当てられます。クライアントシステムは、クライアントの資格を認証したあと、特権付きポートを使用してサーバーへの接続を設定します。次に、サーバーは接続のポート番号を検査してクライアントの資格を確認します。

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

“Weak Authentication
NFS request from unprivileged port”

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

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

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

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

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

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

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

ASET を使用すると、マシンをファイアウォールに強固に組み込むことができます。ASET によって、ファイアウォールシステムのセキュリティが高まります (第 8 章「自動セキュリティ拡張ツールの使用 (手順)」を参照)。同様に、IPsec もファイアウォールの保護が可能です。IPsec を使ってネットワークトラフィックを保護する方法については、『Solaris のシステム管理 (IP サービス)』の「IPsec (概要)」を参照してください。

パケットスマッシング

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

最も危険なのは、データの完全性に影響するような攻撃です。このような攻撃を受けると、パケットの内容が変更されたり、ユーザーが偽装されたりします。盗聴を伴う攻撃では、データの完全性が損なわれることはありません。盗聴者は、会話を記録して、あとで再生します。盗聴者がユーザーを偽装することはありません。盗聴攻撃によってデータの完全性が損なわれることはありませんが、プライバシが侵害されます。ネットワーク上でやりとりされるデータを暗号化すると、重要な情報のプライバシを保護できます。IP データグラムの暗号化方法については、『 Solaris のシステム管理 (IP サービス)』の「インターネットキー交換」を参照してください。

セキュリティ問題の報告

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

第 3 章 マシンのセキュリティの適用 (手順)

この章では、Solaris 環境のマシンのセキュリティを設定する手順について説明します。これらの手順の概要については、次の節を参照してください。

• マシンのセキュリティの適用 (作業マップ)

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

マシンのセキュリティの適用 (作業マップ)

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

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

この節では、ログインの制御と監視について説明します。

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. logins コマンドを使用してユーザーのログイン状態を表示します。

   # logins -x -l username

   -x	ログイン状態情報の拡張セットを表示する
   -l username	指定するユーザーのログイン状態を表示する。username はユーザーのログイン名。複数のログイン名は、コンマで区切って指定する

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

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

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

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

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

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

   # logins -p

   -p オプションを指定すると、パスワードを持たないユーザーが表示されます。logins コマンドでは、ローカルマシン上およびネットワーク上のパスワードデータベースを使用できます。このコマンドでは、ローカルの /etc/passwd ファイルを使用できます。このコマンドではまた、ネームサービスのパスワードデータベースを使ってユーザーのログイン状態を表示できます。

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

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

# logins -p
pmorph          501     other           1       Polly Morph
#

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

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

   # vi /etc/nologin

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

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

   このファイルを作成することによって、システムシャットダウンや定常的な保守の際にユーザーログインを禁止できます。nologin ファイルが存在するシステムにユーザーがログインしようとすると、このファイルの内容が表示されます。そのあとユーザーのログインは中断されます。

   スーパーユーザーのログインは影響を受けません。詳細については、nologin(4) のマニュアルページを参照してください。

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

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

# vi /etc/nologin
(ここでシステムメッセージを追加する)
 
# cat /etc/nologin 
***ログインは許可されません。***
 
***システムは AM12:00 まで利用できません。***

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

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

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. 間違ったパスワードを使用してシステムに 5 回ログインしようとしたログが記録されていることを確認します。次に、/var/adm/loginlog ファイルを表示します。

   # more /var/adm/loginlog rimmer:/dev/pts/1:Wed Jan 16 09:22:31 2002 rimmer:/dev/pts/1:Wed Jan 16 09:22:39 2002 rimmer:/dev/pts/1:Wed Jan 16 09:22:45 2002 rimmer:/dev/pts/1:Wed Jan 16 09:22:53 2002 rimmer:/dev/pts/1:Wed Jan 16 09:23:01 2002 #

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

   loginlog ファイルは急激に大きくなることがあります。このファイルを適切に使用できるように保つためには、その内容をときどき確認して消去する必要があります。loginlog ファイルに多数の操作が記録されている場合は、コンピュータシステムにだれかが侵入しようとした可能性があります。詳細は、loginlog(4) のマニュアルページを参照してください。

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

最初にダイヤルアップパスワードを設定するときには、少なくとも 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 username

   2. 一時的なユーザーのパスワードを作成します。

      # passwd username

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

      # grep username /etc/shadow> username.temp

   4. username.temp ファイルを編集します。

      暗号化パスワードを除くすべてのフィールドを削除します。2 つ目のフィールドに、暗号化パスワードが入っています。

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

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

   5. 一時的なユーザーを削除します。

      # userdel username

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

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

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

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

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

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

   /usr/bin/sh:*:

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

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

以前の Solaris リリースが動作している環境で以下の各手順を使用することはできません。この機能は、Solaris 9 12/02 以降のリリースの Solaris オペレーティング環境が動作しているマシンでのみ有効です。

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

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

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

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

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

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

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

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

この例では、CRYPT_DEFAULT 変数の値として Blowfish アルゴリズムの識別子、すなわち 2a が指定されています。パスワードの暗号化を制御する policy.conf のエントリは次のようになります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

サードパーティのパスワード暗号化モジュールをインストールする方法

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

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

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

2. /etc/security/crypt.conf ファイルを開いて、暗号化アルゴリズムのリストに新しいモジュールとモジュール識別子が含まれていることを確認します。

   次の例は、crypt_rot13 アルゴリズムをインストールしたパッケージによって変更された crypt.conf ファイルです。

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

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

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

   # Copyright 1999-2002 Sun Microsystems, Inc. All rights reserved. # ... #ident "@(#)policy.conf 1.6 02/06/07 SMI" # ... # crypt(3c) Algorithms Configuration CRYPT_ALGORITHMS_ALLOW=1,2a,md5,rot13 #CRYPT_ALGORITHMS_DEPRECATE=__unix__ CRYPT_DEFAULT=md5

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

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

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

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

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

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

   # 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-janedoe SU 01/12 14:56 + pts/0 pmorph-root SU 01/12 14:57 + pts/0 pmorph-root

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

   • コマンドが入力された日時

   • コマンドの成否

     + は成功を表します。- は失敗を表します。

   • コマンドが実行されたポート

   • ユーザー名と切り替えたユーザー ID

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

   SULOG=/var/adm/sulog

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

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

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

   CONSOLE=/dev/console

4. su コマンドを使ってスーパーユーザー になります。

   システムコンソールにメッセージが出力されるか確認します。

   この方法では、現在作業中のシステムでスーパーユーザーのアクセス権を取得しようとする人をただちに検出できます。

スーパーユーザー (root) でのリモートログインを防ぐ方法

Solaris リリースをインストールすると、デフォルトで、スーパーユーザーログインはコンソールに限定されます。

1. スーパーユーザーになるか、同等の役割を引き受けます。

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

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

   CONSOLE=/dev/console

   スーパーユーザーアクセスをコンソールに限定しておくと、コンソールからしかスーパーユーザーとしてシステムにログインできません。このシステムにリモートログインするユーザーは、まず自分のユーザーログインを使用してログインする必要があります。自分のユーザー名でログインしたあとに、su コマンドを使ってスーパーユーザーになります。

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

ハードウェアのセキュリティの適用

マシンの起動時にパスワードの入力を必須にすることによって物理マシンを保護することができます。さらに、ユーザーがアボートシーケンスを使ってウィンドウシステムを離れるのを防ぐことによってマシンを保護する方法もあります。

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

2. 端末から PROM セキュリティモードに入ります。次の行を入力します。

   # eeprom security-mode=command Changing PROM password: New password: password Retype new password: password

   値として command か full を選択します。詳細については、eeprom(1M) のマニュアルページを参照してください。

3. PROM パスワードの入力を要求されない場合は、システムがすでに PROM パスワードを持っています。PROM パスワードを変更する場合は、次のコマンドを実行します。

   # eeprom security-password=<Return キーを押す> Changing PROM password: New password: password Retype new password: password

   新しい PROM セキュリティモードとパスワードはただちに有効になりますが、それがわかるのは、ほとんどの場合、次回の起動時です。

   ---

   注意 –

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

   ---

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

マシンのアボートシーケンスを無効にするには、次の手順を使用します。デフォルトのシステム動作では、システムのアボートシーケンスは有効になっています。

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

1. スーパーユーザーになるか、同等の役割を引き受けます。

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

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

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

3. キーボードのデフォルトを更新します。

   # kbd -i

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

この章では、Solaris 環境のファイルのセキュリティを設定する手順について説明します。

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

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

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

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

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

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

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

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

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

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

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

• ACL をコピーする方法

• ファイルに ACL が設定されているかどうかを検査する方法

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

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

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

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

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

ユーザークラス

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

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

• グループ – グループのメンバー

• その他 –ファイルまたはグループの所有者以外のすべてのユーザー

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

ファイルのアクセス権

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

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

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

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

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

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

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

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

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

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

setuid アクセス権

ユーザー ID 設定 (setuid) のアクセス権を実行可能ファイルに設定すると、このファイルを実行するプロセスには、その実行可能ファイルを実行しているユーザーではなく、ファイルの所有者 (通常は root) に基づいてアクセス権が与えられます。この特殊なアクセス権を使用すると、通常は所有者しか利用できないファイルやディレクトリにアクセスできます。たとえば次に示すように、passwd コマンドは root の setuid アクセス権が設定されているので、ユーザーは root ID の権限でパスワードを変更できます。

-r-sr-sr-x   3 root     sys       104580 Sep 16 12:02 /usr/bin/passwd

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

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

setgid アクセス権

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

-r-x--s--x   1 root     mail       63628 Sep 16 12:01 /usr/bin/mail

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

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

スティッキビット

「スティッキビット」は、ディレクトリ内のファイルを保護するアクセス権ビットです。ディレクトリにスティッキビットが設定されている場合、そのファイルを削除できるのはその所有者、ディレクトリの所有者、またはスーパーユーザーだけです。この特殊なアクセス権により、ユーザーは /tmp などの公開ディレクトリから他のユーザーのファイルを削除できなくなります。

drwxrwxrwt 7  root  sys   400 Sep  3 13:37 tmp

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

デフォルトの umask 設定

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

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

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

umask 値の設定の詳細については、umask(1) のマニュアルページを参照してください。

ファイル情報の表示

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

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

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

1. 次のコマンドを入力すると、現在のディレクトリ内のすべてのファイルの一覧が長形式で表示されます。

   % ls -la

ファイルに関する次の情報が各行に表示されます。

• ファイル形式

  ファイルには 7 つの形式があります。次の表にファイル形式の一覧を示します。

  表 4–4 ファイル形式

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

• アクセス権 (パス変数の設定 と 表 4–2 を参照)

• ハードリンク数

• ファイルの所有者

• ファイルのグループ

• ファイルのバイト数

• ファイルの作成日または最終変更日

• ファイル名

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

次の例では、/sbin ディレクトリ内のファイルを部分的に表示しています。

% cd /sbin
% ls -la
total 13456
drwxr-xr-x   2 root     sys          512 Sep  1 14:11 .
drwxr-xr-x  29 root     root        1024 Sep  1 15:40 ..
-r-xr-xr-x   1 root     bin       218188 Aug 18 15:17 autopush
lrwxrwxrwx   1 root     root          21 Sep  1 14:11 bpgetfile -> ...
-r-xr-xr-x   1 root     bin       505556 Aug 20 13:24 dhcpagent
-r-xr-xr-x   1 root     bin       456064 Aug 20 13:25 dhcpinfo
-r-xr-xr-x   1 root     bin       272360 Aug 18 15:19 fdisk
-r-xr-xr-x   1 root     bin       824728 Aug 20 13:29 hostconfig
-r-xr-xr-x   1 root     bin       603528 Aug 20 13:21 ifconfig
-r-xr-xr-x   1 root     sys       556008 Aug 20 13:21 init
-r-xr-xr-x   2 root     root      274020 Aug 18 15:28 jsh
-r-xr-xr-x   1 root     bin       238736 Aug 21 19:46 mount
-r-xr-xr-x   1 root     sys         7696 Aug 18 15:20 mountall
   .
   .
   .

ファイルの所有権の変更

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

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

set rstchown = 0

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

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

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

set rstchown = 0

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

また、NFS マウントされているファイルシステム上で所有権およびグループを変更するときは、他にも制約があることに注意してください。

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

次の手順でファイルの所有権を変更します。

1. スーパーユーザーになるか、同等の役割を引き受けます。

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

   # chown new-owner filename

   new-owner	ファイルまたはディレクトリの新しい所有者のユーザー名または 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. スーパーユーザーになるか、同等の役割を引き受けます。

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

   $ chgrp group filename

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

   グループの設定については、『Solaris のシステム管理 (基本編)』の「ユーザーアカウントとグループの管理 (概要)」を参照してください。

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

   # ls -l filename

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

次の例では、myself の所有権をグループ scifi に変更します。

$ chgrp scifi myfile
$ ls -l myfile
-rwxrw-- 1 rimmer scifi 12985 Nov 12 16:28 myfile

ファイルのアクセス権の変更

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

chmod コマンドを使用して、次のどちらかのモードでアクセス権を設定できます。

• 「絶対モード」 – ファイルのアクセス権を表す数値を使用します。これは、アクセス権を設定するときに最も一般的に使用される方法です。絶対モードを使用してアクセス権を変更するときは、3 つ 1 組のアクセス権を 8 進数で表します。

• 「記号モード」 – 英字と記号の組み合わせを使用して、アクセス権を追加または削除します。

次の表に、絶対モードでファイルのアクセス権を設定するための 8 進数値を示します。これらの数字を 3 つ組み合せて、所有者、グループ、その他のユーザーのファイルアクセス権をこの順に設定します。たとえば、値 644 は、所有者に対して読み取り権と書き込み権を設定し、グループとその他のユーザーに対しては読み取り権だけを設定します。

ファイルには、絶対モードまたは記号モードで特殊なアクセス権を設定できます。ただし、絶対モードを使用してディレクトリの setuid アクセス権を設定または削除することはできません。この場合、記号モードを使用してください。絶対モードでは、3 つ 1 組のアクセス権の左端に新しい 8 進数値を追加して、特殊なアクセス権を設定します。次の表に、ファイルに特殊なアクセス権を設定する 8 進数値を示します。

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

機能列に <対象ユーザー> <操作> <アクセス権> の順で、ファイルまたはディレクトリのアクセス権を変更する記号を指定します。

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

次の手順を使用して、アクセス権を絶対モードで変更します。

1. ファイルまたはディレクトリの所有者でない場合は、スーパーユーザーになるか、同等の役割を引き受けます。

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

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

   % chmod nnn filename

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

   ---

   注 –

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

   ---

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 進数値のリストについては、表 4–6 を参照
   filename	ファイルまたはディレクトリを指定する

   ---

   注 –

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

   ---

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

次の例では、public_dir ディレクトリにスティッキビットのアクセス権を設定します。

# chmod 1777 public_dir
# ls -ld public_dir
drwxrwxrwt   2 ignatz   staff          512 May 15 15:27 public_dir

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

次の手順を使用して、アクセス権を記号モードで変更します。

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

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

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

   % chmod who operator permission filename

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

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

   % ls -l filename

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

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

% chmod o-r filea

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

$ chmod a+rx fileb

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

$ chmod g=rwx filec

特殊なアクセス権の検索

プログラムの setuid や setgid アクセス権を使用して、不正にスーパーユーザー権限が取得されていないかどうかシステムを監視する必要があります。このようなプログラムの所有権が、root や bin ではなく、一般ユーザーになっているものが疑わしいと考えられます。

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

次の手順を使用して、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 に出力する。

   # more /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 のコピーを作成し、そのアクセス権を root への setuid に設定したことを示しています。この結果、rar は /usr/rar/bin/sh を実行して特権付きユーザーになることができます。この出力を参考のために保存したい場合は、ファイルを /tmp ディレクトリ以外のファイルへ移動してください。

実行可能スタックとセキュリティ

セキュリティのバグの多くは、デフォルトで読み取り権、書き込み権、および実行権が設定された実行可能スタックで発生します。実行可能スタックには実行権が割り当てられていますが、ほとんどのプログラムは実行可能スタックがなくても正しく機能します。

noexec_user_stack 変数を使うと、スタックを実行可能として割り当てるかどうかを指定できます。この変数は、Solaris 2.6 から利用可能です。デフォルトでは、この変数は 0 に設定されるため (64 ビットアプリケーションを除く)、プログラムは ABI に準拠して動作します。この変数が 0 以外に設定された場合、システムはシステム中のすべてのプロセスのスタックに読み取り権と書き込み権のマークを付けますが、実行権のマークは付けません。

この変数が設定されている場合、プログラムがスタック上でコードを実行しようとすると SIGSEGV シグナルが送信されます。通常、このシグナルが送信されると、プログラムはコアダンプして終了します。このようなプログラムは、違反しているプログラム名、プロセス ID、およびプログラムを実行した実ユーザー ID を含む警告メッセージも生成します。次に例を示します。

a.out[347] attempt to execute code on stack by uid 555 

メッセージは、syslog kern 機能が notice レベルに設定されているときに、syslog デーモンによってログに記録されます。このログへの記録は、デフォルトで syslog.conf ファイルに設定されていて、メッセージがコンソールと /var/adm/messages ファイルの両方に送信されることを意味します。詳細は、syslogd(1M) と syslog.conf(4) のマニュアルページを参照してください。

syslog メッセージは、潜在的なセキュリティの問題を調べるときに役立ちます。また、このメッセージは、この変数を設定したために正しく動作しなくなった、実行可能スタックに依存するプログラムを確認するのにも役立ちます。メッセージを記録したくない場合、システム管理者は、/etc/system ファイルで noexec_user_stack_log 変数を 0 に設定します。メッセージが記録されなくなりますが、SIGSEGV シグナルは送られるので、実行プログラムのコアダンプは起きます。

mprotect() 関数を使用すれば、プログラムのスタックが実行可能であることを明示的にマーク付けできます。詳細は、mprotect(2) のマニュアルページを参照してください。

ハードウェアの制限のため、実行可能スタックの問題を捕捉して報告する機能は、sun4m と 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 コマンドにより設定します。ACL エントリは、次のようにコロンで区切ったフィールドで構成されます。

entry-type:[uid|gid]:perms

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

user:nathan:rw-

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

ファイルの ACL エントリ

次の表は、ファイルに ACL を設定するときに使用する有効な ACL エントリの一覧です。最初の 3 つの ACL エントリは、基本的な UNIX のファイル保護機能を提供します。

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

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

ディレクトリ上の特定のユーザーおよびグループに対してデフォルトの ACL エントリを初めて設定するときは、所有者、グループ、その他のユーザー、および ACL マスクにもデフォルトの ACL エントリを設定する必要があります。これらのエントリは、必ず設定しなければなりません。具体的には、次の表のデフォルト ACL エントリのうち、最初の 4 つを設定する必要があります。

ファイルの 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 エントリについては、表 4–8 と 表 4–9 を参照
   filename ...	ACL に設定する 1 つまたは複数のファイルまたはディレクトリを空白で区切って指定する

   ---

   注意 –

   すでにファイル上に ACL が存在する場合、-s オプションを指定すると、ACL 全体が新しい ACL に置き換えられます。

   ---

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

2. ACL (ACL エントリ) がファイルに設定されたことを確認します。

   % getfacl filename

   詳細は、ファイルに 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 をコピーする

次の例では、ch2.doc の ACL が ch3.doc にコピーされます。

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

ファイルに ACL が設定されているかどうかを検査する方法

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

% ls -l filename

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

   -m	既存の ACL エントリを変更する
   acl-entry-list	ファイルまたはディレクトリで変更する 1 つまたは複数の ACL エントリのリスト。ディレクトリのデフォルト ACL エントリを変更することもできる。有効な ACL エントリについては、表 4–8 と 表 4–9 を参照
   filename ...	1 つまたは複数のファイルまたはディレクトリを空白で区切って指定する

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

   % getfacl filename

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

次の例では、ユーザー george のアクセス権を読み取りおよび書き込みに変更します。

% setfacl -m user:george:6 ch3.doc
% getfacl ch3.doc
# file: ch3.doc
# owner: nathan
# group: staff
user::rw-				
user::george:rw-         #effective:r--
group::r-                #effective:r--
mask:r--
other:r-

次の例では、book ディレクトリのデフォルトアクセス権を変更します。グループ staff のデフォルトアクセス権を読み取りに変更し、ACL マスクのデフォルトアクセス権を読み取りおよび書き込みに変更します。

% setfacl -m default:group:staff:4,default:mask:6 book

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

1. setfacl コマンドを使用してファイルから ACL エントリを削除します。

   % setfacl -d acl-entry-list filename ...

   -d	指定した ACL エントリを削除する
   acl-entry-list	ファイルまたはディレクトリから (アクセス権を指定せずに) 削除する ACL エントリのリスト。特定のユーザーとグループの ACL エントリとデフォルトの ACL エントリ以外は削除できない。有効な ACL エントリについては、表 4–8 と 表 4–9 を参照
   filename ...	1 つまたは複数のファイルまたはディレクトリを空白で区切って指定する

   setfacl -s を使用してファイルのすべての ACL エントリを削除してから、指定した新しい ACL エントリで置き換えることもできます。

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

   % getfacl filename

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

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

% setfacl -d user:george ch4.doc

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

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

% getfacl [-a | -d] filename ...

複数のファイル名をコマンド行に指定した場合は、各 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:---

第 5 章 役割によるアクセス制御 (概要)

この章では、役割によるアクセス制御 (RBAC) について説明します。RBAC は、セキュリティ機能の 1 つで、通常はスーパーユーザーに制限されているオペレーションのアクセス権を制御します。この章の内容は以下のとおりです。

• RBAC: スーパーユーザーモデルの置き換え

• Solaris RBAC の要素

• 特権付きアプリケーション

• RBAC の役割

• RBAC の承認

• RBAC の権利プロファイル

• ネームサービスの適用範囲

RBAC の手順については、第 6 章「役割によるアクセス制御 (手順)」を参照してください。RBAC の要素とツールに関する参照については、第 7 章「役割によるアクセス制御 (参照)」を参照してください。

RBAC: スーパーユーザーモデルの置き換え

従来の UNIX システムでは、root ユーザー (スーパーユーザー) はすべての権限を持ちます。つまり、任意のファイルに対する読み取り権と書き込み権、すべてのプログラムの実行権、および任意のプロセスに終了シグナルを送信する権限があります。スーパーユーザーになるユーザーは、事実上、使用するサイトのファイアウォールを変更したり、監査トレールを変更したり、給与台帳などの機密レコードを読み取ったり、ネットワーク全体をシャットダウンしたりすることができます。

役割によるアクセス制御 (RBAC) は、スーパーユーザーモデルの権限をすべて与えるか、またはまったく与えないかの機能を置き換えます。RBAC では、基本的に最小限の特権以外は許可しません。つまり、そのユーザーに必要な特権だけを許可します。RBAC を使用すると、組織はスーパーユーザーの機能を分割して、それらを「役割」と呼ばれる特殊なユーザーアカウントに割り当てることができます。役割は、ジョブ要件に応じて、特定のユーザーに割り当てます。

役割は柔軟に設定できるため、さまざまなセキュリティポリシーに対応できます。RBAC には、簡単に設定できる次の 3 つの推奨される役割が用意されています。

• Primary Administrator – root に相当する強力な役割

• System Administrator – Primary Administrator より権限の小さな役割。セキュリティに関係しない管理を行う。この役割のユーザーは、パスワードを設定できない

• Operator – 最も権限の小さな役割。バックアップ、復元、プリンタ管理などの操作を行う

これらの役割の実装は、必須ではありません。役割は、組織のセキュリティ要件に応じて設定する機能です。役割は、セキュリティ、ネットワーク、ファイアウォールの管理など、特定の目的の管理に合わせて設定できます。担当するシステムの修正権限だけを持つ管理ユーザーという役割と 1 人の強力な管理者という役割を作成することもできます。

Solaris RBAC の要素

Solaris オペレーティング環境の RBAC モデルでは、通常のユーザーとしてログインし、役割に応じて制限された管理グラフィカルツールとコマンドを実行できる役割を引き受けます。RBAC モデルでは、これらの要素を Solaris オペレーティング環境に導入します。

• 「特権付きアプリケーション」 – システム設定よりも優先して、特定のユーザー ID (UID)、グループ ID (GID)、または承認を確認するアプリケーション (特権付きアプリケーション を参照)

• 「役割」 – 割り当てられたユーザーだけが引き受けることができる特権付きアプリケーションを実行するための特殊な ID

• 「承認」 – 通常はセキュリティポリシーによって許可されない操作を実行するために役割またはユーザーに割り当てることができる (権利プロファイルに埋め込むことができる) アクセス権

• 「権利プロファイル」 – 役割またはユーザーに割り当てることができるシステムの設定より優先されるオペレーションの集合。権利プロファイルは、承認、setuid または setgid アクセス権 (セキュリティ属性と呼ばれる) と共にコマンド、およびその他の権利プロファイルで構成される

次の図では、各 RBAC 要素の動作を示します。

図 5–1 Solaris RBAC 要素の動作

RBAC では、ユーザーに役割が割り当てられます。役割が使用する機能は、権利プロファイルと承認から取得します。通常は、論理的に関連付けられた権利プロファイルに対して、承認が割り当てられます。ただし、承認を役割に直接割り当てることもできます。

権利プロファイルと承認は、ユーザーに直接割り当てることもできます。ただし、特権が不注意に使用されると、問題が発生することがあるため、できるだけ直接割り当てないでください。

セキュリティ属性 (実 UID 、実 GID、実効 UID、実効 GID) と共にコマンドを権利プロファイルに割り当てることができます。

次の図では、Operator の役割の Printer Management 権利プロファイルを使用して、RBAC 関係の例を示します。

図 5–2 Solaris RBAC 要素の関係

Operator の役割を使用して、プリンタ管理と媒体のバックアップを実行します。ユーザー johnDoe は、Operator の役割に割り当てられているため、「Operator」パスワードを入力してその役割を引き受けることができます。

Operator 権利ファイルは、Operator の役割に割り当てられています。Operator 権利ファイルには、「Printer Management」と「Media Backup」という補助プロファイルが割り当てられています。これらの補助プロファイルは、Operator の役割の主要な作業です。

「Printer Management」権利プロファイルは、プリンタ、印刷デーモン、およびスプーラを管理するプロファイルです。「Printer Management」権利プロファイルには、solaris.admin.printer.read、solaris.admin.printer.delete、および solaris.admin.printer.modify 承認が割り当てられています。これらの承認を使用することで、プリンタキューの情報を操作できます。「Printer Management」プロファイルには、euid=0 を指定した /usr/sbin/accept、euid=lp を指定した /usr/ucb/lpq のように、セキュリティ属性を指定したコマンドが割り当てられます。

特権付きアプリケーション

「特権付きアプリケーション」とは、システムの設定より優先して指定できるアプリケーションです。

UID と GID を確認するアプリケーション

root またはその他の特定の UID または GID を確認する特権付きアプリケーションは、従来より UNIX のアプリケーションとして存在していました。RBAC 権利プロファイルメカニズムを使用すれば、特定のコマンドに UID または GID を指定することができます。任意のユーザーがアクセスできるコマンドの ID を変更する代わりに、権利プロファイルでセキュリティ属性を指定したコマンドとして実行することができます。その権利プロファイルを持つユーザーまたは役割であれば、root 以外でもプログラムを実行できます。

ID として、実 ID または実効 ID を指定できます。実効 ID を割り当てた場合は、実 ID より優先されます。実効 ID はアクセス権ビットの setuid 機能に相当し、監査上、UID を識別します。ただし、root の実 UID を要求するシェルスクリプトやプログラムのために、実 ID も設定できます。たとえば、pkgadd コマンドは、実効 UID ではなく実 UID を要求します。コマンドを実行するときに、指定した実効 UID では権限が十分でない場合は、「SMC Right Properties」ダイアログボックスの「Set Security Attributes」オプションを使用して特権を実 UID に変更する必要があります。権利プロファイルの作成または変更 を参照してください。

承認を確認するアプリケーション

RBAC には、承認を確認するコマンドも用意されています。root にはすべての承認が定義されているため、任意のアプリケーションを実行できます。現時点では、次のアプリケーションで、承認が確認されます。

• Solaris 管理コンソールのすべてのツール

• バッチジョブ関連のコマンド – at、atq、batch、crontab

• デバイス向けのコマンド – allocate、deallocate、 list_devices、 cdrw

プロファイルシェル

承認されたユーザーは、Solaris 管理コンソール起動ツールまたは「プロファイルシェル」のコマンド行から特権付きアプリケーションを取得できます。プロファイルシェルは特別な種類のシェルで、プロファイルに割り当てられている特権付きアプリケーションにアクセスできます。プロファイルシェルは、ユーザーが su を実行して役割を引き受けたときに起動されます。プロファイルシェルには、pfsh、 pfcsh、および pfksh があります。これらはそれぞれ、Bourne シェル (sh)、C シェル (csh)、および Korn シェル (ksh) に対応します。

RBAC の役割

「役割」は、特権付きアプリケーションを実行できる特別な種類のユーザーアカウントです。役割は、ユーザーアカウントと同じ方法で作成され、ホームディレクトリ、グループ、パスワードなどを持ちます。役割は、権利プロファイルとそれに割り当てられている承認により機能します。役割には継承はありません。

ユーザーが役割を引き受けると、その役割の属性がすべてのユーザー属性を置き換えます。役割の情報は、passwd、shadow、user_attr、および audit_user データベースに格納されます。役割の設定の詳細については、推奨される役割の構成、役割の作成、および 役割プロパティの変更を参照してください。

同じ役割になるすべてのユーザーは、同じ役割のホームディレクトリを持ち、同じ環境で動作し、同じファイルへのアクセス権を持ちます。ユーザーは、コマンド行から su を実行し、役割名とパスワードを指定して役割を引き受けることができます。Solaris 管理コンソールツールを開いて、役割を引き受けることもできます。

役割に直接ログインすることはできません。これは、root 役割を作成して、匿名による root ログインをできないようにするためです。詳細は、root を役割にするを参照してください。ユーザーは、最初に通常のユーザーアカウントにログインする必要があります。ほかの役割から直接役割になることはできません。ユーザーの実 UID は常に監査されます。

Solaris 9 には、事前定義の役割は用意されていません。この章の前述のとおり、3 つの推奨される役割は簡単に構成できます。

RBAC の承認

「承認」は、役割またはユーザーに許可できる個別の権限です。RBAC に準拠したアプリケーションは、ユーザーの承認を確認してから、アプリケーションまたはアプリケーション内の特定の操作に対するアクセス権を許可します。この承認の確認は、従来の UNIX アプリケーションが行なっていた UID=0 の確認に代わるものです。承認の詳細については、承認、auth_attr データベース、および 承認を必要とするコマンドを参照してください。

RBAC の権利プロファイル

「権利プロファイル」は、役割またはユーザーに割り当てることができるシステムの設定より優先されるオペレーションの集合です。権利プロファイルには、実効 UID、実効 GID、実 UID、または実 GID を定義したコマンド、承認、その他の権利プロファイルが含まれます。権利プロファイル情報は、prof_attr および exec_attr データベースに分割して格納されます。権利プロファイルの詳細は、権利プロファイルの内容、prof_attr データベース、および exec_attr データベースを参照してください。

ネームサービスの適用範囲

ネームサービスの適用範囲は、RBAC を理解する上で重要な概念です。役割の適用範囲は、個別のホスト、または ネームサービス (NIS、NIS+、LDAP など) を使用するすべてのホストに適用されます。ローカルな構成ファイルとネームサービスにより配布された構成情報の優先順位は、/etc/nsswitch.conf ファイルに指定されています。検索は、最初に一致した時点で停止します。たとえば、プロファイルが 2 つの適用範囲に存在する場合は、最初の適用範囲に含まれるエントリだけが使用されます。

第 6 章 役割によるアクセス制御 (手順)

この章では、RBAC 要素を管理するための作業手順について説明します。次に、この章で説明する作業マップを示しています。RBAC の初期設定の作業手順については、RBAC の構成 (作業マップ)を参照してください。RBAC 要素の管理全般については、第 5 章「役割によるアクセス制御 (概要)」を参照してください。

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

• RBAC の計画

• ユーザーツールコレクションを初めて使用する

• 初期ユーザーの設定

• 初期役割の設定

• root を役割にする

• 特権付きアプリケーションの使用

• 役割の作成

• 役割プロパティの変更

• 権利プロファイルの作成または変更

• ユーザーの RBAC プロパティの変更

• レガシーアプリケーションのセキュリティ保護

RBAC に関連する作業は、Solaris 管理コンソールを使用して実行することをお勧めします。RBAC 要素を管理するためのコンソールツールは、ユーザーツールコレクションに含まれています。

ローカルファイルの操作は、Solaris 管理コンソールやほかのコマンド行インタフェースを使用して行うこともできます。Solaris 管理コンソールコマンドを使用してサーバーに接続するときは、認証が要求されます。このため、Solaris 管理コンソールコマンドは、スクリプトでは使用できません。その他のコマンドは、スーパーユーザーまたは同等の役割になることを必要とし、ネームサービスのデータベースには適用できません。

また、コマンド行を使用して RBAC 情報を管理した場合は、編集がただちに有効にならないことがあります。編集を有効にするには、ネームサービスキャッシュデーモン (nscd(1M)) を停止して再起動する必要があります。

RBAC の構成 (作業マップ)

RBAC の計画

RBAC は、組織の情報資源を管理するときに、重要な役割を果たします。RBAC を計画する際には、RBAC の機能と組織のセキュリティ要件を十分に理解しておく必要があります。

RBAC の実装を計画する方法

1. RBAC の基本概念を理解します。

   第 5 章「役割によるアクセス制御 (概要)」を参照してください。RBAC を使用したシステム管理は、従来の UNIX を使用した場合と大きく異なります。実装を開始する前に、RBAC の概念を理解する必要があります。詳細は、第 7 章「役割によるアクセス制御 (参照)」を参照してください。

2. セキュリティポリシーを調査します。

   組織のセキュリティポリシーには、システムに対する潜在的な脅威を詳細に記述し、各脅威の危険性の分析結果に応じて適切な対応策を定義する必要があります。RBAC を使用したセキュリティ関連の作業とは切り離して行うことをお勧めします。推奨される役割とその構成をそのままインストールすることもできますが、セキュリティポリシーによっては RBAC の構成のカスタマイズが必要になることがあります。

3. 組織に必要な RBAC を決定します。

   組織のセキュリティ要件に応じて、さまざまなレベルの RBAC を使用できます。

   • 「RBAC を使用しない」 – すべての作業を root ユーザーとして実行できる。この例では、通常のユーザーとしてログインし、コンソールツールを選択するときに、ユーザーとして root を入力する

   • 「役割として root を使用する」 – この方式では、匿名の root ログインを防ぐために、すべてのユーザーが root としてログインできないようにする。代わりに、通常のユーザーとしてログインしてから、root 役割を引き受ける (root を役割にするを参照)

   • 「役割を 1 つだけ使用する」 – この方式では、Primary Administrator 役割だけを追加する。スーパーユーザーモデルと似た方式である

   • 「推奨される役割」 – 容易に構成可能な 3 つの推奨される役割として、Primary Administrator、System Administrator、および Operator を利用できる。 さまざまな責任レベルの管理者の業務が、推奨される役割と一致している組織の場合は、この方式が適している

   • 「カスタム役割」 – 独自の役割を作成して、組織のセキュリティ要件を満たすことができる。新しい役割は、既存またはカスタマイズした権利プロファイルに基づいて作成できる

4. 組織に適した推奨される役割を決定します。

   推奨される役割とそのデフォルトの権利プロファイルの機能を確認します。推奨される役割を構成するときは、次の 3 つの権利プロファイルを使用できます。

   • 「Primary Administrator」権利プロファイル – すべての管理タスクを実行できる役割用。ほかのユーザーに権限を与えたり、管理役割に関連付けられた権限を編集したりする。この役割のユーザーは、Primary Administrator 役割を割り当てたり、他のユーザーに権利を与えたりすることができる

   • 「System Administrator」権利プロファイル – セキュリティに関係しない管理タスクを実行できる役割用。たとえば、System Administrator は、新しいユーザーアカウントは追加できるが、パスワードを設定したりほかのユーザーに権利を与えたりすることはできない

   • 「Operator」権利プロファイル – バックアップと復元、プリンタ管理など、単純な管理タスクを実行できる役割用

   これらの権利プロファイルを利用すると、システム管理者は 1 つの権利プロファイルを使って推奨される役割を構成することができます。

   これらの権利プロファイルを詳細に検証するには、権限ツールを使用して内容を表示します。標準的な権利プロファイルの概要については、権利プロファイルの内容も参照してください。コンソールツールを使用すると、これらの役割と権利プロファイルをカスタマイズして、組織の要件を満たすことができます。

5. 追加する任意の役割または権利プロファイルが組織に適切であるかどうかを判断します。

   使用するサイトで、アクセスを制限する必要があるアプリケーションを調べます。セキュリティに影響するアプリケーション、サービス拒否が発生する可能性のあるアプリケーション、特別な管理者教育を必要とするアプリケーションには、RBAC を適用することをお勧めします。

   1. 新しい操作に必要なコマンドを決定します。

   2. この操作に適切な権利プロファイルを決定します。

      既存の権利プロファイルがこの操作に割り当てられていないか、または別の権利プロファイルを作成する必要がないかどうかを確認します。

   3. この権利プロファイルに適した役割を決定します。

      この操作の権利プロファイルを既存の役割に割り当てるかどうか、または新しい役割を作成するかどうかを決定します。既存の役割を使用する場合は、この役割を割り当てるユーザーにほかの権利プロファイルが適していないかどうかを確認します。

6. 役割に割り当てるユーザーを決定します。

   必要な権限だけを割り当てるために、ユーザーの信頼レベルに応じて役割を割り当てます。ユーザーが使用しない操作の権限は割り当てないようにすると、問題が発生する可能性が減少します。

ユーザーツールコレクションを初めて使用する

初期ユーザーをインストールして役割を割り当てるには、最初に通常のユーザーとしてログインします。Solaris 管理コンソールにユーザー自身を認証させるときは、root ユーザーを指定します。

ユーザーツールコレクションを実行する方法

1. 通常のユーザーとしてログインし、Solaris 管理コンソールを起動します。

   % whoami johnDoe % /usr/sadm/bin/smc&

2. 「ユーザーツールコレクション (User Tool Collection)」に移動して、アイコンをクリックします。

   1. ナビゲーション区画の 「管理ツール (Management Tool)」で、「このコンピュータ (This Computer)」というラベルのアイコンを見つけます。

   2. その左にある切り替えアイコンをクリックします。

      切り替えアイコンは、レバーに似ています。レバーが水平の場合、フォルダの内容は表示されていません。レバーが垂直の場合、内容が表示されています。切り替えアイコンをクリックすると、フォルダの表示と非表示が切り替わります。

   3. 「System Configuration」フォルダの横にある切り替えアイコンをクリックして、その内容を表示します。

   4. 「ユーザー (User)」アイコンをクリックして、「ユーザーツールコレクション (User Tool Collection)」を開きます。

      ユーザーログインダイアログボックスが表示されます。

3. 「ログイン: ユーザー名 (Login:User Name)」ダイアログボックスに、root と root パスワードを入力します。 「了解 (OK)」をクリックします。

   通常は、ここでユーザー名を入力して役割を引き受けます。しかし、最初は役割が存在しないため、root ユーザーを入力する必要があります。「ユーザーツールコレクション (User Tool Collection)」が開きます (次の図を参照)。

   図 6–1 「ユーザーツールコレクション (User Tool Collection)」

   
   

初期ユーザーの設定

すべてのユーザーが役割に割り当てられ、すでにシステムにインストールされている場合は、この手順を省略して 初期役割の設定に進みます。

ユーザーアカウントツールを使用して初期ユーザーを作成する方法

1. ナビゲーション区画または「ユーザーツールコレクション (User Tool Collection)」の表示区画で、ユーザーアカウントツールのアイコンをクリックします。

   ユーザーアカウントツールが起動します。「アクション (Action)」メニューにこのツールのオプションが表示されます。

2. 「アクション (Action)」メニューから「ユーザーを追加 (Add User)」->「ウィザードを使用 (With Wizard)」を選択します。

   「ユーザーを追加 (Add User)」ウィザードが起動します。このウィザードは、ユーザーの構成に必要な情報を要求するダイアログボックスの集合です。「次へ (Next)」および「戻る (Back)」ボタンを使用して、ダイアログボックスを移動します。「次へ (Next)」ボタンは、すべての必須フィールドに入力するまで有効になりません。最後に、入力したデータを確認するダイアログボックスが表示されます。前のダイアログボックスに戻って入力を変更するか、「完了 (Finish)」をクリックして新しい役割を保存します。

   次の図は、最初に表示される「手順 1: ユーザー名を入力します。(Step 1:Enter a user name)」ダイアログボックスです。

   図 6–2 「ユーザーを追加 (Add User)」ウィザード

   
   

3. 最初のユーザー名とその他の識別情報を入力します。

4. 「手順 2: ユーザー識別番号を入力します。(Step 2: Enter a User Identification Number)」ダイアログボックスで UID を入力します。

   このエントリは、ユーザーの既存の UID と一致している必要があります。

5. 「手順 3: ユーザーのパスワードを入力します。(Step 3: Enter the User's Password)」ダイアログボックスで、パスワードを設定するかどうかを指定します。

   ユーザー自身のパスワードをこのアカウントに設定する場合は、2 番目のオプションをクリックします。この場合、ユーザー自身のパスワードを入力し、確認を行います。

6. 「手順 4: ユーザーの一次グループを選択します。(Step 4: Select the User's Primary Group)」ダイアログボックスで、適切なグループを選択します。

7. 「手順 5: ユーザーのホームディレクトリを作成します。(Step 5: Create the User's Home Directory)」ダイアログボックスで、ホームディレクトリのパスを指定します。

8. 「手順 6: メールサーバーを指定します。(Step 6: Specify the Mail Server)」ダイアログボックスで、デフォルトのメールサーバーとメールボックスを確認します。

   これらの設定は、「ユーザープロパティ (User Properties)」ダイアログボックスであとで変更することができます。

9. 「確認します。(Review)」ダイアログボックスで情報を確認します。保存する場合は、「完了 (Finish)」をクリックします。情報を再入力する場合は、「戻る (Back)」をクリックします。

   情報が不足していたり、間違っていた場合は、「戻る (Back)」ボタンを繰り返しクリックして、不正な情報を入力したダイアログボックスを表示します。次に、「次へ (Next)」を繰り返しクリックして、「確認します。(Review)」ダイアログボックスに戻ります。

初期役割の設定

最初に、ユーザーと役割を管理する役割を作成します。通常は、Primary Administrator です。まず、ローカルホストにそのユーザーと役割をインストールします。ネームサービススコープのツールボックスを設定した場合は、そのネームサービスに同じユーザーと役割を作成する必要があります。『Solaris のシステム管理 (基本編)』の「ネームサービス環境で Solaris 管理ツールを使用する (作業マップ)」を参照してください。最初の役割を設定して、ユーザー自身に割り当てたあと、root になる代わりに、役割を引き受けてコンソールツールを実行することができます。

管理役割ツールを使用して最初の役割 (Primary Administrator) を作成する方法

最初の役割をインストールするには、通常のユーザーとしてログインする必要があります。Solaris 管理コンソールにユーザー自身を認証させるには、root ユーザーを指定します。まず、ローカルホストに役割をインストールします。最初の役割を設定して、ユーザー自身に割り当てたら、root としてではなく、設定した役割でコンソールツールを実行することができます。

1. 「ログイン: ユーザー名 (Login:User Name)」ダイアログボックスに、root と root パスワードを入力します。 「了解 (OK)」をクリックします。

2. ナビゲーション区画または「ユーザーツールコレクション (User Tool Collection)」の表示区画で、「管理役割 (Administrative Roles)」アイコンをクリックします。

   管理役割ツールが起動します。「アクション (Action)」メニューにこのツールのオプションが表示されます。

3. 「アクション (Action)」メニューから「管理役割を追加 (Add Administrative)」を選択します。

   「管理役割を追加 (Add Administrative)」ウィザードが起動します。このウィザードは、役割の構成に必要な情報を要求するダイアログボックスの集合です。「次へ (Next)」および「戻る (Back)」ボタンを使用して、ダイアログボックスを移動します。「次へ (Next)」ボタンは、すべての必須フィールドに入力するまで有効になりません。最後に、入力したデータを確認するダイアログボックスが表示されます。前のダイアログボックスに戻って入力を変更するか、「完了 (Finish)」をクリックして新しい役割を保存します。

   次の図は、最初に表示される「手順 1: 役割名を入力します。(Step 1:Enter a Role Name)」ダイアログボックスです。

   図 6–3 「管理役割を追加 (Add Administrative)」ウィザード

   
   

4. primaryadmin または使用している役割名と、その他の識別情報を入力します。

   役割メーリングリストオプションを選択すると、この役割を持つユーザーの別名を作成できます。

5. 「手順 2: 役割パスワードを入力します。(Step 2: Enter a Role Password)」ダイアログボックスの「役割パスワード (Role Password)」フィールドに新しい役割のパスワードを入力し、「パスワードを確認 (Confirm Password)」フィールドに再度入力します。

   入力を確認することにより、スペルミスのパスワードが保存されるのを防ぐことができます。

6. 「手順 3: 役割権利を選択します。(Step 3: Enter Role Rights)」ダイアログボックスで、「Primary Administrator」の権利プロファイルを選択します。

   「有効な権利 (Available Rights)」列 (左側) の Primary Administrator 権利プロファイルをダブルクリックします。「許可された権利 (Granted Rights)」列 (右側) の権利プロファイルが、この役割に割り当てられた権利プロファイルです。この例では、Primary Administrator 権利プロファイルだけが必要です。

7. 「手順 4: ホームディレクトリを選択します。(Step 4: Select a Home Directory)」ダイアログボックスで、ホームディレクトリのサーバーとパスを指定します。

8. 「手順 5: この役割にユーザーを割り当てます。(Step 5: Assign Users to This Role)」ダイアログボックスで、Primary Administrator の役割に割り当てるユーザーのログイン名を入力します。

   追加するユーザーは、動作中のネームサービススコープに定義されている必要があります。「手順 1: 役割名を入力します。(Step 1: Enter a Role Name)」ダイアログボックスで役割のメーリングリストオプションを選択した場合、これらのユーザーは Primary Administrator 役割に送信された電子メールを受信します。

9. 「確認します。(Review)」ダイアログボックスで情報を確認します。保存する場合は、「完了 (Finish)」をクリックします。情報を再入力する場合は、「戻る (Back)」をクリックします。

   情報が不足していたり、間違っていた場合は、「戻る (Back)」ボタンを繰り返しクリックして、不正な情報を入力したダイアログボックスを表示します。次に、「次へ (Next)」を繰り返しクリックして、「確認します。(Review)」ダイアログボックスに戻ります。

10. 端末ウィンドウを開いてスーパーユーザーになり、ネームサービスキャッシュデーモンを起動して停止します。

    新しい役割は、ネームサービスキャッシュデーモンを再起動するまで有効になりません。スーパーユーザーで、次のように入力します。

    # /etc/init.d/nscd stop # /etc/init.d/nscd start

root を役割にする

この手順では、ローカルな有効範囲内の root ユーザーを役割にします。root を役割にすると、そのサーバーに root ユーザーとして直接ログインすることを防ぐことができます。ユーザーはまず、通常のユーザーとしてログインする必要があり、その UID は監査できるようになります。

root を役割にするときに、root を有効なユーザー、または root に相当する現在の既存の役割に割り当てなかった場合は、すべてのユーザーが root になることができなくなります。

root を役割にする方法

1. 対象のサーバーにログインします。

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

3. /etc/user_attr ファイルを編集します。

   次に、標準的な user_attr ファイルの一部を示します。

   root::::type=normal;auths=solaris.*,solaris.grant;profiles=All johnDoe::::type=normal

4. このファイルにユーザー名があることを確認します。

5. ユーザー自身のレコードに割り当てられている役割に対して、root を追加します。

   root の役割を、任意の適用可能なユーザーに割り当てます。primaryadmin を最も強力な役割として使用する場合は、root を任意のユーザーに割り当てる必要はありません。

   johnDoe::::type=normal;roles=root

6. このファイルの root レコードに移動し、type=normal を type=root に変更します。

   root::::type=role;auths=solaris.*,solaris.grant;profiles=All

7. ファイルを保存します。

RBAC 情報の管理 (作業マップ)

次の作業マップでは、特定の RBAC 操作に必要な情報の入手先を示します。

これらの手順を行なって、役割によるアクセス制御 (RBAC) で使用される要素を管理します。ユーザー管理手順については、『Solaris のシステム管理 (基本編)』の「ユーザーアカウントとグループの管理 (手順)」を参照してください。

特権付きアプリケーションの使用

特権付きアプリケーションを実行するには、まずスーパーユーザーになるか、または同等の役割を引き受ける必要があります。特権付きアプリケーションは通常のユーザーとして実行することもできますが、不注意に実行するとエラーが発生します。できるだけ、通常のユーザーとして実行しないでください。

コマンド行で役割を引き受ける方法

1. su コマンドを次のように使用します。

   % su my-role Password: my-role-password #

   su だけを入力すると、スーパーユーザーになります。役割名を指定して su と入力すると、その役割を引き受けます (役割が割り当てられている場合)。適切なパスワードを入力してください。役割になると、コマンド行がその役割のプロファイルシェルに切り替わります。その役割の権利プロファイルに割り当てられたセキュリティ属性でコマンドが実行されるように、プロファイルシェルが変更されます。

2. シェルにコマンドを入力します。

   コマンドは、割り当てられたセキュリティ属性と setuid または setgid アクセス権で実行されます。

コンソールツールで役割を引き受ける方法

1. Solaris 管理コンソールを起動します。

   次のいずれかの方式を使用します。

   • コマンド行で smc と入力する

   • 「ツール (Tools)」サブパネルの 「Solaris 管理コンソール (Solaris Management Console)」アイコンをクリックする

   • 「アプリケーションマネージャ (Application Manager)」の「Solaris 管理コンソール (Solaris Management Console)」アイコンをダブルクリックする

   すべての Solaris 管理コンソールツールでは、拡張コンテキストヘルプを使用して、各フィールドの説明を表示できます。また、「ヘルプ (Help)」メニューからさまざまなヘルプトピックにアクセスできます。コンソールを起動するときは、root としてログインしても、通常のユーザーとしてログインしてもかまいません。

2. 操作に必要なツールボックスを選択します。

   適切な適用範囲のツールまたはコレクションを含むツールボックスに移動し、アイコンをクリックします。スコープには、ファイル (ローカル)、NIS、NIS+、および LDAP があります。適切なツールボックスがナビゲーション区画に表示されていない場合は、「コンソール (Console)」メニューから「ツールボックスを開く (Open Toolbox)」を選択して、関連するツールボックスを読み込みます。

3. ツールを選択します。

   使用するツールまたはコレクションに移動して、アイコンをクリックします。RBAC 要素を管理するツールは、すべて「ユーザーツールコレクション (User Tool Collection)」にあります。

4. 「ログイン: ユーザー名 (Login: User Name)」ダイアログボックスでユーザー自身を認証させます。

   次のいずれかを選択します。

   • ユーザー名とパスワードを入力して、通常のユーザーとして役割を引き受ける、または操作する

   • root および root パスワードを入力して、スーパーユーザーとして操作する

   役割を設定していないか、設定されている役割が必要な操作を実行できない場合は、 root としてログインする必要があります。ユーザーが、root または役割が割り当てられていないユーザーとして認証された場合は、ツールがコンソールに読み込まれます。この場合は、手順 6 に進んでください。

5. 「ログイン: 役割名 (Login: Role)」ダイアログボックスでユーザーを認証させます。

   ダイアログボックスの「役割 (Role)」オプションメニューに、割り当てられる役割が表示されます。役割を選択して、役割のパスワードを入力します。通常のユーザーとして操作している場合は、ユーザー自身のユーザー名とパスワードを入力します。

6. 実行するツールに移動して、アイコンをクリックします。

役割の作成

役割を作成するには、Primary Administrator 権利プロファイルが割り当てられている役割になるか、root ユーザーとして実行する必要があります。役割の詳細は、RBAC の役割と 推奨される役割の構成を参照してください。

管理役割ツールを使用して役割を作成する方法

1. 管理役割ツールを起動します。

   管理役割ツールを実行して、Solaris 管理コンソールを起動します (コンソールツールで役割を引き受ける方法を参照)。次に、「ユーザーツールコレクション (User Tool Collection)」を開いて、「管理役割 (Administrative Roles)」アイコンをクリックします。

2. 「管理役割を追加 (Add Administrative)」ウィザードが起動します。

   「アクション (Action)」メニューから「管理役割を追加 (Add Administrative Role)」を選択して、「管理役割を追加 (Add Administrative)」ウィザードを起動します。

3. 表示されるダイアログボックスのフィールドに入力します。入力が完了したら、「完了 (Finish)」をクリックします。

   「次へ (Next)」および「戻る (Back)」ボタンを使用して、ダイアログボックスを移動します。「次へ (Next)」ボタンは、すべての必須フィールドに入力するまで有効になりません。最後に、入力したデータを確認するダイアログボックスが表示されます。前のダイアログボックスに戻って入力を変更するか、「完了 (Finish)」をクリックして新しい役割を保存します。表 6–1 に、ダイアログボックスの要約を示します。

4. 端末ウィンドウを開いてスーパーユーザーになり、ネームサービスキャッシュデーモンを起動して停止します。

   新しい役割は、ネームサービスキャッシュデーモンを再起動するまで有効になりません。スーパーユーザーで、次のように入力します。

   # /etc/init.d/nscd stop # /etc/init.d/nscd start

コマンド行から役割を作成する方法

1. スーパーユーザーになるか、ほかの役割を作成できる役割を引き受けます。

2. 次のいずれかの役割の作成方法を選択します。

   • ローカルスコープの役割を作成する場合、roleadd コマンドを使用して、新しいローカル役割とその属性を指定する

   • また同じくローカルスコープの役割を作成する場合、user_attr ファイルを編集して、ユーザーに type=role を追加することもできる

     この方法は、入力ミスが発生しやすいため、緊急時以外はできるだけ使用しない

   • ネームサービスの役割を作成する場合は、smrole コマンドを使用して、新しい役割とその属性を指定する

     このコマンドは、スーパーユーザー、またはその他の役割を作成できる役割による認証を必要とする。smrole コマンドは、すべてのネームサービスに適用でき、Solaris 管理コンソールサーバーのクライアントとして動作する

3. ネームサービスキャッシュデーモンを起動して停止します。

   新しい役割は、ネームサービスキャッシュデーモンを再起動するまで有効になりません。スーパーユーザーで次のように入力します。

   # /etc/init.d/nscd stop # /etc/init.d/nscd start

例 6–1 smrole コマンドを使用してカスタムの Operator 役割を作成する

次のコマンドシーケンスは、smrole コマンドを使用して役割を作成します。この例では、新しい Operator 役割が作成され、標準の Operator 権利プロファイルと Media Restore 権利プロファイルが割り当てられます。

% su primaryadmin 
# /usr/sadm/bin/smrole add -H myHost -- -c "Custom Operator" -n oper2 -a johnDoe \
-d /export/home/oper2 -F "Backup/Restore Operator" -p "Operator" -p "Media Restore"
Authenticating as user: primaryadmin

Type /? for help, pressing <enter> accepts the default denoted by [ ]
Please enter a string value for: password :: <primaryadmin パスワードを入力する>

Loading Tool: com.sun.admin.usermgr.cli.role.UserMgrRoleCli from myHost
Login to myHost as user primaryadmin was successful.
Download of com.sun.admin.usermgr.cli.role.UserMgrRoleCli from myHost was successful.

Type /? for help, pressing <enter> accepts the default denoted by [ ]
Please enter a string value for: password ::<oper2 パスワードを入力する>

# /etc/init.d/nscd stop
# /etc/init.d/nscd start

新しく作成した役割およびその他の役割を表示するには、次のように smrole コマンドに list サブコマンドを指定します。

# /usr/sadm/bin/smrole list --
Authenticating as user: primaryadmin

Type /? for help, pressing <enter> accepts the default denoted by [ ]
Please enter a string value for: password :: <primaryadmin パスワードを入力する>

Loading Tool: com.sun.admin.usermgr.cli.role.UserMgrRoleCli from myHost
Login to myHost as user primaryadmin was successful.
Download of com.sun.admin.usermgr.cli.role.UserMgrRoleCli from myHost was successful.
root                    0               Super-User
primaryadmin            100             Most powerful role
sysadmin                101             Performs non-security admin tasks
oper2                   102             Backup/Restore Operator

役割プロパティの変更

役割を変更するには、Primary Administrator 権利プロファイルが割り当てられている役割を引き受ける必要があります。役割が設定されていない場合は、スーパーユーザーとして「ユーザーツールコレクション (User Tool Collection)」を実行する必要があります。

管理役割ツールを使用して役割を変更する方法

1. 管理役割ツールを起動します。

   管理役割ツールを実行するには、Solaris 管理コンソールを実行する必要があります (コンソールツールで役割を引き受ける方法を参照)。次に、「ユーザーツールコレクション (User Tool Collection)」を開いて、「管理役割 (Administrative Roles)」アイコンをクリックします。

   管理役割ツールが起動したら、既存の役割のアイコンが表示区画に表示されます。

2. 変更する役割をクリックして、 「アクション (Action)」メニューから適切な項目を次のように選択します。

   • 役割に割り当てられるユーザーを変更するには、「管理役割を割り当てる (Assign Administrative Role)」を選択する

     「管理役割を割り当てる (Assign Administrative Role)」ダイアログボックスが表示されます。「管理役割を割り当てる (Assign Administrative Role)」ダイアログボックスは、「役割プロパティ (Role Properties)」ダイアログボックスに似ていますが、「ユーザー (Users)」タブだけで構成されます。現在のスコープのユーザーをこの役割に割り当てるときは、「追加 (Add)」フィールドを使用します。ユーザーに割り当てられた役割を削除するときは、「削除 (Delete)」フィールドを使用します。「了解 (OK)」をクリックして、保存します。

   • 役割に割り当てられた権利を変更するときは、「ユーザーへ権利を割り当てる (Assign Rights to Role)」を選択する

     「ユーザーへ権利を割り当てる (Assign Rights to Role)」ダイアログボックスが表示されます。「ユーザーへ権利を割り当てる (Assign Rights to Role)」ダイアログボックスは、「役割プロパティ (Role Properties)」ダイアログボックスに似ていますが、「権利 (Rights)」タブだけで構成されます。「有効な権利 (Available Right)」列と「許可された権利 (Granted Rights)」列を使用して、選択した役割に対して権利プロファイルの追加または削除を行います。「了解 (OK)」をクリックして、保存します。

   • 役割の任意のプロパティを変更するときは、「プロパティ (Properties)」 を選択するか、役割アイコンをダブルクリックする

     「役割プロパティ (Role Properties)」ダイアログボックスが表示され、すべての役割プロパティにアクセスすることができます (次の図と表を参照)。タブを使用して変更する情報に移動し、必要な変更を行なってから、「了解 (OK)」をクリックして保存します。

     図 6–4 「役割プロパティ (Role Properties)」ダイアログボックス

     
     
     表 6–2 「役割プロパティ (Role Properties)」の要約

     タブ	タブの説明
     基本 (General)	役割 ID 情報とデフォルトのログインシェルを指定する
     パスワード (Password)	役割パスワードを指定する
     ユーザー (Users)	役割に割り当てるユーザーを指定する
     グループ (Group)	役割の一次グループと二次グループを設定する。ファイルとディレクトリのアクセスおよび作成に使用する
     ホームディレクトリ (Home Directory)	役割のホームディレクトリ、ホームディレクトリサーバー、自動マウント、およびディレクトリアクセスを指定する
     権利 (Rights)	権利プロファイルを特定の役割に割り当てることができるようにする。割り当てられた権利プロファイルの優先度は、ここで変更できる

コマンド行から役割を変更する方法

1. スーパーユーザーになるか、ほかの役割を作成できる役割を引き受けます。

2. 操作に適切な次のコマンドを使用します。

   • ローカルに定義された役割の属性を変更するときは、rolemod コマンドを使用する

   • ローカルに定義された役割を削除するときは、roledel コマンドを使用する

   • ローカル役割に割り当てられた承認または権利プロファイルを変更するときは、user_attr ファイルを編集する

     この方法は、入力ミスが発生しやすいため、緊急時以外はできるだけ使用しない

   • ネームサービスの役割の属性を変更するときは、smrole コマンドを使用する

     このコマンドは、スーパーユーザーか、ほかの役割を作成できる役割としての認証を必要とする。smrole コマンドは、Solaris 管理コンソールサーバーのクライアントとして動作する

権利プロファイルの作成または変更

権利プロファイルを作成または変更するには、Primary Administrator 権利プロファイルが割り当てられている役割を引き受ける必要があります。役割が設定されていない場合は、スーパーユーザーとしてユーザーツールコレクションを実行する必要があります。権利プロファイルの詳細は、RBAC の役割と 推奨される役割の構成を参照してください。

権利ツールを使用して権利プロファイルを作成または変更する方法

1. 権利ツールを起動します。

   権利ツールを実行するには、Solaris 管理コンソールを起動する必要があります (コンソールツールで役割を引き受ける方法を参照)。次に、「ユーザーツールコレクション (User Tool Collection)」を開いて、「権利 (Rights)」アイコンをクリックします。

   権利ツールが起動すると、既存の権利プロファイルのアイコンが表示区画に表示されます。

2. 権利プロファイルの作成または変更に適した次の動作を選択します。

   • 新しい権利プロファイルを作成するときは、「アクション (Action)」メニューから「権利を追加 (Add Rights)」を選択する

   • 既存の権利プロファイルを変更するときは、その権利プロファイルのアイコンをクリックして、「アクション (Action)」メニューから「プロパティ (Properties)」を選択するか、権利プロファイルのアイコンをダブルクリックする

   どちらの場合も 「権利プロパティ (Rights Properties)」に似たダイアログボックスが表示されます。次の図に示す「権利を追加 (Add Right)」ダイアログボックスには、書き込み可能な 「名前 (Name)」フィールドがあります。標準の「権利プロパティ (Rights Properties)」ダイアログボックスの「名前 (Name)」フィールドは、読み取り専用になっています。いったん定義した権利プロファイルは、変更できないためです。

   図 6–5 「権利を追加 (Add Right)」ダイアログボックス

   
   

3. 新しい情報を入力します。「了解 (OK)」をクリックして、権利プロファイルを保存します。

   次の表は、「権利プロパティ (Right Properties)」ダイアログボックスのタブとフィールドの一覧です。

   タブ	フィールド	フィールドの説明
   基本 (General)	名前 (Name)	新しい権利プロファイル名
   	備考欄 (Description)	新しい権利プロファイルの説明
   	ヘルプファイル名 (Help File Name)	新しい権利プロファイルの HTML ヘルプファイル名
   コマンド (Commands)	ディレクトリを追加 (Add Directory)	「拒否されたコマンド (Commands Denied)」または「許可されたコマンド (Commands Permitted)」列に存在しないディレクトリを追加するためのダイアログボックスを開く
   	拒否されたコマンド (Commands Denied) / 許可されたコマンド (Commands Permitted)	権利プロファイルのコマンドの割り当てまたは削除を行う
   	セキュリティ属性を設定 (Set Security Attributes)	コマンドのセキュリティ属性 (実 UID または GID、あるいは実効 UID または GID) の割り当てまたは削除を行うダイアログボックスを開く (図 6–6 を参照) 注 – 実 ID ではなく、実効 ID を割り当てることが望ましい。実 ID は、pkgadd などのコマンドで必要な場合にだけ使用する
   	検索 (Find (command))	2 つのコマンドリストから指定した文字列を検索する
   承認 (Authorizations)	含まれない承認 (Authorizations Excluded) / 含まれる承認 (Authorizations Included)	権利プロファイルの承認の割り当てまたは削除を行う
   補助権利 (Supplementary Rights)	含まれない権利 (Rights Excluded) / 含まれる権利 (Rights Included)	権利プロファイルの補助権利プロファイルの割り当てまたは削除を行う

   図 6–6 セキュリティ属性をコマンドに追加する

   
   

例 6–2 権利ツールを使用して新しい権利プロファイルを作成する

次の表は、「Restart」と呼ばれる仮想権利プロファイルを作成するときのサンプルデータです。この例の権利プロファイル「Restart」には、サブディレクトリ /etc/init.d のコマンドが割り当てられています。これらのコマンドの実効 UID は 0 です。この権利プロファイルは、/etc/init.d 内のデーモンを停止および起動できるシステム管理者が使用します。

コマンド行から権利プロファイルを変更する方法

1. スーパーユーザーになるか、Primary Administrator 権利プロファイルを持つ役割を引き受けます。

2. 操作に適した smprofile のサブコマンドを使用します。

   このコマンドは認証を必要とします。このコマンドは、すべてのネームサービスに適用できます。smprofile コマンドは、Solaris 管理コンソールサーバーのクライアントとして動作します。

   • 新しいプロファイルを追加するときは、 smprofile の add サブコマンドを使用する

   • 既存のプロファイルを変更するときは、smprofile の modify サブコマンドを使用する

ユーザーの RBAC プロパティの変更

ユーザーのプロパティを変更するには、ユーザーツールコレクションをスーパーユーザーとして実行するか、Primary Administrator 権利プロファイルが割り当てられている役割を持つ必要があります。

ユーザーアカウントツールを使用してユーザーの RBAC プロパティを変更する方法

1. ユーザーアカウントツールを起動します。

   ユーザーアカウントツールを実行するには、Solaris 管理コンソールを起動する必要があります (コンソールツールで役割を引き受ける方法を参照)。次に、「ユーザーツールコレクション (User Tool Collection)」を開いて、「ユーザーアカウント (User Accounts)」アイコンをクリックします。

   ユーザーアカウントツールが起動すると、既存のユーザーアカウントのアイコンが表示区画に表示されます。

2. 変更するユーザーアカウントのアイコンをクリックして、「アクション (Action)」メニューから「プロパティ (Properties)」を選択するか、ユーザーアカウントのアイコンをダブルクリックします。

3. 変更するプロパティのダイアログボックスで、適切なタブを次のように選択します。

   • ユーザーに割り当てられた役割を変更するときは、「役割 (Role)」タブをクリックして、変更する役割を「有効な役割 (Available Roles)」または「割り当てられた役割 (Assigned Roles)」列に移動します。

   • ユーザーに割り当てられた権利プロファイルを変更するときは、「権利 (Rights)」タブをクリックして、変更する権利プロファイルを「有効な権利 (Available Rights)」または「許可された権利 (Assigned Rights)」列に移動します。

     ---

     注 –

     権利プロファイルは、できるだけユーザーに直接割り当てないでください。特権付きアプリケーションを実行するときは、ユーザーが役割を引き受けるようにしてください。通常のユーザーが、特権を不正に使用できないようにするためです。

     ---

コマンド行からユーザーの RBAC プロパティを変更する方法

1. スーパーユーザーになるか、ユーザーファイルを変更できる役割を引き受けます。

2. 次のように適切なコマンドを使用します。

   • ローカルスコープに定義されたユーザーに割り当てられている承認、役割、または権利プロファイルを変更する場合は、 usermod コマンドを使用する

   • また同じくローカルスコープに定義されたユーザーに割り当てられている承認、役割、または権利プロファイルを変更する場合は、user_attr ファイルを編集することもできる

     この方法は、入力ミスが発生しやすいため、緊急時以外はできるだけ使用しない

   • ネームサービスに定義されたユーザーに割り当てられている承認、役割、または権利プロファイルを変更するときは、 smuser コマンドを使用する

     このコマンドは、スーパーユーザー、またはユーザーファイルを変更できる役割による認証を必要とする。smuser コマンドは、すべてのネームサービスに適用でき、Solaris 管理コンソールサーバーのクライアントとして動作する

レガシーアプリケーションのセキュリティ保護

この節では、レガシーアプリケーションのセキュリティを強化する方法について説明します。レガシーアプリケーションを Solaris 管理コンソールに追加するときは、『Solaris のシステム管理 (基本編)』の「Solaris 管理コンソールにツールを追加する」を参照してください。

レガシーアプリケーションにセキュリティ属性を追加する方法

レガシーアプリケーションにセキュリティ属性を追加するときは、コマンドに追加する場合と同じ方法で追加します。「権利プロパティ (Rights property)」ダイアログボックスの「コマンド (Commands)」タブにある「拒否されたコマンド (Commands Denied)」列に、コマンドまたはそのディレクトリを追加する必要があります。次に、そのコマンドを「許可されたコマンド (Commands Permitted)」列に移動します。

スクリプト内のコマンドにセキュリティ属性を追加する方法

スクリプト内のコマンドに setUID ビットを設定して実行する場合は、セキュリティ属性を同じ権利プロファイル内のそのコマンドに追加します。権利ツールを使用して権利プロファイルを作成または変更する方法を参照してください。

スクリプトまたはプログラム内の承認を確認する方法

承認を必要とするスクリプトを作成するには、auths コマンドに基づいたテストを追加する必要があります (auths(1) のマニュアルページを参照)。たとえば、次の行では、 $1 引数に指定した承認がユーザーに与えられているかどうかをテストします。

if [ `/usr/bin/auths|/usr/xpg4/bin/grep $1` ]; then
        echo Auth granted
else
        echo Auth denied
fi

さらに詳細にテストするには、ワイルドカードを使用してその他の承認を確認する論理を追加する必要があります。たとえば、solaris.admin.usermgr.write 承認がユーザーに与えられているかどうかをテストするには、solaris.admin.usermgr.write、solaris.admin.usermgr.* 、solaris.admin.*、および solaris.* という文字列を確認する必要があります。

プログラムを作成している場合は、getauthattr() 関数を使用して、承認をテストします。

第 7 章 役割によるアクセス制御 (参照)

この章では、第 5 章「役割によるアクセス制御 (概要)」 の追加情報を提供します。

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

• 推奨される役割の構成

• 権利プロファイルの内容

• 承認

• RBAC データベースの関係

• user_attr データベース

• auth_attr データベース

• prof_attr データベース

• exec_attr データベース

• RBAC を管理するコマンド行アプリケーション

• 承認を必要とするコマンド

RBAC タスクについては、第 6 章「役割によるアクセス制御 (手順)」を参照してください。

RBAC 要素: 参照情報

この節では、役割によるアクセス制御 (RBAC) の要素について詳細に説明します。

推奨される役割の構成

Solaris 9 には、事前定義済みの役割は組み込まれていません。顧客サイトの管理者は、設定する役割の種類を決定する必要があります。ただし、適切な事前定義済みの権利プロファイルを対応する役割に割り当てると、次の 3 つの推奨される役割を簡単に構成できます。

• 「Primary Administrator」権利プロファイル – すべての管理タスクを実行できる役割用。ほかのユーザーに権限を与えたり、管理役割に関連付けられた権限を編集したりする。この役割のユーザーは、Primary Administrator 役割を割り当てたり、他のユーザーに権利を与えたりすることができる

• 「System Administrator」権利プロファイル – セキュリティに関係しない管理タスクを実行できる役割用。たとえば、System Administrator は、新しいユーザーアカウントは追加できるが、パスワードを設定したりほかのユーザーに権利を与えたりすることはできない

• 「Operator」権利プロファイル – バックアップと復元、プリンタ管理など、単純な管理タスクを実行できる役割用

これらの権利プロファイルを利用すると、システム管理者は権利プロファイルを組み合わせたり調整したりしなくても、1 つの権利プロファイルを使って推奨される役割を構成することができます。

役割をカスタマイズするときは、役割に割り当てられた権利プロファイルの順序を詳細に確認する必要があります。同一のコマンドを複数回入力しても、エラーにはなりません。権利プロファイルでは、最初に発生したコマンドに割り当てられる属性が優先され、後続の同一コマンドはすべて無視されます。

root は、役割として設定することもできます。root を役割に設定すると、ユーザーは root として直接ログインできなくなり、通常のユーザーとしてログインする必要があります。root を役割にするを参照してください。

権利プロファイルの内容

この節では、いくつかの標準的な権利プロファイルについて説明します。

• 「All」権利プロファイルでは、セキュリティ属性のないコマンドへアクセスする権利が割り当てられる

• 「Primary Administrator」権利プロファイルは、Primary Administrator 役割用に設計されている。Primary Administrator 権利プロファイルでは、ワイルドカードを使用できる

• 「System Administrator」権利プロファイルは、System Administrator 役割用に設計されている。System Administrator 権利プロファイルでは、複数の補助プロファイルを組み合わせて強力な役割を作成する

• 「Operator」権利プロファイルは、Operator 役割用に設計されている。Operator 権利プロファイルでは、複数の補助プロファイルを組み合わせて単純な役割を作成する

• 「Basic Solaris User」権利プロファイルには、 policy.conf ファイルを使用して、セキュリティに関係しないタスクをユーザーに割り当てる

• 「Printer Management」権利プロファイルは、特定の管理領域専用のプロファイルの 1 つ

次の節の表では、コマンド、承認、補助権限、権利プロファイル、関連するヘルプファイルなど、これらの権利プロファイルの目的と内容を示します。

ヘルプファイルは HTML 形式なので、必要に応じて簡単にカスタマイズできます。ヘルプファイルは、/usr/lib/help/auths/locale/C ディレクトリにあります。

Solaris 管理コンソールの権利ツールを使用して、権利プロファイルの内容を検査することもできます。

All 権利プロファイル

All 権利プロファイルは、セキュリティ属性のないコマンドを除いたすべてのコマンドを使用できるようにワイルドカードを使用したプロファイルです。この権利プロファイルは、ほかの権利プロファイルに明示的に割り当てられていないすべてのコマンドにアクセスできる役割です。All 権利プロファイルまたはワイルドカードを使用するその他の権利プロファイルを使用しないと、役割は明示的に割り当てられているコマンド以外にはアクセスできません。これは、あまり実用的ではありません。

権利プロファイルのコマンドは、発生順に解釈されます。このため、ワイルドカードを使用する場合は、最後に指定します。明示的に割り当てた属性が、誤って優先指定されないようにするためです。All 権利プロファイルを使用する場合は、最後に割り当ててください。

Primary Administrator 権利プロファイル

Primary Administrator 権利プロファイルには、システム上で最も強力な役割が割り当てられます。実質的に、スーパーユーザーの機能を持つ役割が提供されます。

• solaris.* 承認は、実質的に Solaris ソフトウェアから提供されるすべての承認を割り当てる

• solaris.grant 承認は、任意の権利プロファイル、役割、またはユーザーに任意の承認を割り当てる

• *:uid=0;gid=0 のコマンド割り当ては、UID=0 および GID=0 ですべてのコマンドを実行する

ヘルプファイル RtPriAdmin.html はサイト内では同一であるため、必要に応じて変更できます。ヘルプファイルは、 /usr/lib/help/auths/locale/C ディレクトリに格納されています。

Primary Administrator 権利プロファイルがサイトのセキュリティポリシーと矛盾する場合は、 このプロファイルを変更したり、割り当てないようにしたりすることもできます。ただし、Primary Administrator 権利プロファイルのセキュリティ機能は、ほかの権利プロファイル処理するのに必要となります。

System Administrator 権利プロファイル

System Administrator 権利プロファイルは、System Administrator 役割用に設計されています。System Administrator では、Primary Administrator の強力な権限を持たないため、ワイルドカードは使用できません。代わりに、セキュリティに関係しない個別の管理権利プロファイルが割り当てられます。次の表では、補助権利プロファイルに割り当てられているコマンドは説明していません。

All 権利プロファイルは、補助権利プロファイルのリストの最後にあります。

Operator 権利プロファイル

Operator 権利プロファイルは、権限の弱い管理権利プロファイルで、バックアップとプリンタ管理を行います。ファイルの復元は、セキュリティに影響するため、デフォルトではこの権利プロファイルに割り当てられていません。

ユーザー用の Basic Solaris User 権利プロファイル

デフォルトでは、Basic Solaris User 権利プロファイルは、policy.conf ファイルによってすべてのユーザーに自動的に割り当てられます。この権利プロファイルでは、通常の操作に使用する基本的な承認を与えます。Basic Solaris User 権利プロファイルを使用するときは、サイトのセキュリティ要件を考慮する必要があります。高いセキュリティを必要とするサイトでは、この権利プロファイルを policy.conf ファイルから削除することをお勧めします。

Printer Management 権利プロファイル

Printer Management は、特定のタスクを実行する標準権限ファイルです。Printer Management 権利プロファイルには、承認とコマンドが割り当てられます。次の表では、使用できるコマンドの一部を示します。

承認

「承認」とは、役割またはユーザーに許可できる個別の権限のことです。RBAC に準拠したアプリケーションによって承認が確認されてから、ユーザーはアプリケーションまたはアプリケーションの特定の操作へのアクセス権を取得します。従来の UNIX アプリケーションでは、UID=0 で承認が確認されていました。

承認の命名規則

承認名には、RBAC の内部およびファイル内で使用される名前 (solaris.admin.usermgr.pswd など) と、グラフィカルユーザーインタフェースに表示される短い名前 (Change Passwords など) があります。

承認名の書式は、インターネット名と逆の順序になり、サプライヤ、被認証者領域、任意の下位領域、および承認の機能で構成されます。各要素の区切り文字はドット (.) です。たとえば、com.xyzcorp.device.access のように指定します。ただし、Sun から許可される承認では、インターネット名の代わりに接頭辞 solaris が使用されます。システム管理者は、ドットの右側に任意の文字列を表すワイルドカード (*) を使用して、承認を階層方式で適用することができます。

承認レベルの違いの例

ここでは、承認の使用方法の例を示します。Operator 役割のユーザーは、多くの場合、solaris.admin.usermgr.read 承認に制限されます。この承認では、ユーザーの構成ファイルに対する読み取り権は許可されますが、書き込み権は許可されません。System Administrator 役割では、solaris.admin.usermgr.read 承認だけでなく、ユーザーのファイルを変更できる solaris.admin.usermgr.write 承認も許可されます。ただし、System Administrator には、solaris.admin.usermgr.pswd 承認が許可されないため、パスワードは変更できません。Primary Administrator では、これらの 3 つの承認がすべて許可されます。

Solaris 管理コンソールのユーザーツールのパスワードを変更するには、solaris.admin.usermgr.pswd 承認が必要です。この承認は、smuser、smmultiuser、および smrole コマンドのパスワード変更オプションを使用するときにも必要になります。

承認の委託

接尾辞が grant の承認が許可されたユーザーまたは役割は、割り当てられている承認のうち同じ接頭辞を持つ任意の承認を、ほかのユーザーに委託することができます。

たとえば、solaris.admin.usermgr.grant 承認と solaris.admin.usermgr.read 承認を持つ役割は、solaris.admin.usermgr.read 承認をほかのユーザーに委託できます。solaris.admin.usermgr.grant と solaris.admin.usermgr.* を持つ役割は、solaris.admin.usermgr 接頭辞を持つ任意の承認をほかのユーザーに委託できます。

RBAC をサポートするデータベース

次の 4 つのデータベースには、RBAC 要素のデータが格納されます。

• user_attr (拡張ユーザー属性のデータベース) – ユーザーと役割を承認と権利に関連付ける

• auth_attr (承認属性のデータベース) – 承認とその属性を定義し、関連するヘルプファイルを指定する

• prof_attr (権利プロファイル属性のデータベース) – 権利プロファイルを定義し、その権利プロファイルに割り当てられた承認を指定し、関連するヘルプファイルを指定する

• exec_attr (実行属性のデータベース) – 特定の権利プロファイルに割り当てられたセキュリティ属性を持つコマンドを指定する

コマンドには、セキュリティポリシーを指定することもできます。Solaris オペレーティング環境で現在利用できるセキュリティポリシーは、suser (スーパーユーザーの短縮形) だけです。suser ポリシーはデフォルトで使用され、ID 属性と承認が格納されます。Solaris 環境と相互運用できる Trusted Solaris 環境では、tsol というポリシーが使用されます。今後のリリースでは、ポリシーが追加される予定です。

RBAC の実装では、policy.conf データベースも重要です。このデータベースには、すべてのユーザーにデフォルトで適用される承認と権利プロファイルが含まれます。

RBAC データベースの関係

次の図は、RBAC データベースの相互関係を示しています。

図 7–1 RBAC データベースの関係

user_attr データベースには、ユーザーと役割の基本定義が格納されます。ユーザーと役割は、タイプフィールドで識別します。 user_attr データベースには、図に示す属性が格納されます。権利プロファイル名を、コンマで区切って指定します。権利プロファイルは、2 つのデータベースに分けて定義します。prof_attr データベースには、権利プロファイルの ID 情報、そのプロファイルに割り当てる承認、および補助プロファイルが格納されます。exec_attr データベースには、セキュリティポリシーを識別し、コマンド、およびコマンドに関連付けられたセキュリティ属性が格納されます。auth_attr データベースには、Sun 管理コンソールツールに渡す承認情報が格納されます。policy.conf データベースには、すべてのユーザーに適用されるデフォルトの承認と権利プロファイルが格納されます。

各データベースには、key=value という構文を使用して、値を格納します。この方式は、データベースの拡張に対応するだけでなく、ポリシーが認識できない鍵が検出された場合にも対応できます。

RBAC データベースの適用範囲は、NIS、NIS+、LDAP などのネームサービスを使用している各ホストまたはすべてのホストに適用できます。ローカル構成ファイルと 配布された user_attr データベースの優先順位は、/etc/nsswitch.conf ファイルの passwd エントリに設定します。prof_attr データベースと auth_attr データベースの優先順位は、/etc/nsswitch.conf に個別に設定します。exec_attr データベースには、prof_attr と同じ優先順位が適用されます。たとえば、セキュリティ属性を指定したコマンドを特定のプロファイルに割り当てた場合に、そのプロファイルが 2 つの適用範囲に存在するときは、最初の適用範囲のエントリだけが使用されます。

これらのデータベースは、ローカルシステムに配置するか、NIS、NIS+、LDAP ネームサービスによって管理します。

これらのデータベースは手動編集でき、RBAC を管理するコマンド行アプリケーションで説明するコマンドを使用して操作できます。

user_attr データベース

user_attr データベースには、ユーザーと役割の情報が格納されます。これらの情報は、passwd および shadow データベースによって利用されます。user_attr データベースには、承認、権利プロファイル、割り当てられた役割など、さまざまなユーザー属性が格納されます。user_attr データベースの各フィールドは次のようにコロンで区切ります。

user:qualifier:res1:res2:attr

次の表で、これらのフィールドについて説明します。

次の例では、Operator 役割を標準的な user_attr データベースに定義して、それをユーザー johnDoe に割り当てる方法を示しています。役割とユーザーは、type キーワードによって識別されます。

% grep operator /etc/user_attr 
johnDoe::::type=normal;roles=sysadmin,operator
operator::::profiles=Operator;type=role

auth_attr データベース

承認はすべて auth_attr データベースに格納されます。承認は、 user_attr データベースのユーザー (または役割) に直接割り当てることができます。承認は、ユーザーに割り当てられている権利プロファイルに割り当てることもできます。

auth_attr データベースのフィールドは次のようにコロンで区切ります。

authname:res1:res2:short_desc:long_desc:attr

次の表で、これらのフィールドについて説明します。

次の例は、標準的な値がいくつか設定された auth_attr データベースを示します。

% grep printer /etc/security/auth_attr 
solaris.admin.printer.:::Printer Information::help=AuthPrinterHeader.html
solaris.admin.printer.delete:::Delete Printer Information::help=AuthPrinterDelete.html
solaris.admin.printer.modify:::Update Printer Information::help=AuthPrinterModify.html
solaris.admin.printer.read:::View Printer Information::help=AuthPrinterRead.html

solaris.admin.printer. はドット(.) で終わっているため、ヘッダーとして定義されます。ヘッダーは、承認の集合を作成するために、GUI によって使用されます。

prof_attr データベース

prof_attr データベースには、権利プロファイルに割り当てる名前、説明、ヘルプファイルの場所、および承認が格納されます。権利プロファイルに割り当てたコマンドとセキュリティ属性は、exec_attr データベースに格納されます (exec_attr データベース を参照)。prof_attr データベースのフィールドは次のようにコロンで区切ります。

profname:res1:res2:desc:attr

次の表で、これらのフィールドについて説明します。

次の例では、標準的な prof_attr データベースを示します。Printer Management 権利プロファイルは、Operator 権利プロファイルに割り当てられる補助権利プロファイルです。

% grep 'Printer Management' /etc/security/prof_attr 
Printer Management:::Manage printers, daemons, spooling:help=RtPrntAdmin.html; \ 
auths=solaris.admin.printer.read,solaris.admin.printer.modify,solaris.admin.printer.delete \
Operator:::Can perform simple administrative tasks:profiles=Printer Management,\
Media Backup,All;help=RtOperator.html
...

exec_attr データベース

実行属性は、特定の UID または GID に関連付けられるコマンドで、権利プロファイルに割り当てられます。セキュリティ属性を指定したコマンドは、権利プロファイルが割り当てられているユーザーまたは役割が実行できます。

exec_attr データベースには、実行属性の定義が格納されます。

exec_attr データベースのフィールドは次のようにコロンで区切って指定します。

name:policy:type:res1:res2:id:attr

次の表で、これらのフィールドについて説明します。

次の例に、exec_attr データベースの標準的な値をいくつか示します。

% grep 'Printer Management' /etc/security/exec_attr
Printer Management:suser:cmd:::/usr/sbin/accept:euid=lp
Printer Management:suser:cmd:::/usr/ucb/lpq:euid=0
Printer Management:suser:cmd:::/etc/init.d/lp:euid=0
.
.
.

policy.conf ファイル

policy.conf ファイルには、特定の権利プロファイルと承認をすべてのユーザーに与える方法を定義します。このファイルは、次の 2 つの鍵と値のペアで構成されます。

• AUTHS_GRANTED=authorizations – 1 つまたは複数の承認

• PROFS_GRANTED=right profiles – 1 つまたは複数の権利プロファイル

次の例では、policy.conf データベースの標準的な値をいくつか示します。

# grep AUTHS /etc/security/policy
AUTHS_GRANTED=solaris.device.cdrw

# grep PROFS /etc/security/policy
PROFS_GRANTED=Basic Solaris User

RBAC コマンド

この節では、RBAC の管理に使用するコマンドを一覧します。承認を使用してアクセス権を制御できるコマンドについても説明します。

RBAC を管理するコマンド行アプリケーション

RBAC データベースを直接編集するほかに、次のコマンドを使用して RBAC のタスクへのアクセスを管理できます。

承認を必要とするコマンド

次の表では、承認を使用して Solaris 環境のコマンドオプションを制限する方法を示します。承認も参照してください。

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

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

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

• 自動セキュリティ拡張ツール (ASET)

• ASET の実行

• ASET の問題の障害追跡

自動セキュリティ拡張ツール (ASET)

Solaris 9 には、ASET が組み込まれています。ASET を使用すると、ほかの場合には手作業で実行する作業が自動的に実行され、システムのセキュリティを監視して制御できます。

ASET セキュリティパッケージには、システムのセキュリティを制御して監視できるように、自動管理ツールが組み込まれています。ASET を実行するセキュリティレベルには、低レベル、中レベル、または高レベルを指定できます。上のレベルほど、ASET のファイル制御機能が増え、ファイルアクセスは減少し、システムセキュリティが厳しくなります。

ASET には 7 つのタスクがあり、各タスクがシステムファイルに対して特定の検査と調整を行います。ASET のタスクはファイルのアクセス権を厳しくし、重要なシステムファイルの内容にセキュリティ上の弱点がないかどうかを確認して、重要な領域を監視します。ASET では、ゲートウェイシステムとして機能するシステムにファイアウォールシステムの基本要件を適用し、ネットワークも保護できます (ファイアウォールの設定を参照)。

ASET は、構成用のマスターファイルを使用します。マスターファイルやレポートなどの ASET ファイルは、/usr/aset ディレクトリにあります。これらのファイルは、サイトの特定の要件に合わせて変更できます。

各タスクは、検出されたセキュリティ上の弱点と、タスクがシステムファイルに対して行なった変更を示すレポートを生成します。最上位のセキュリティレベルで実行すると、ASET はシステムセキュリティ上のすべての弱点を変更しようとします。潜在的なセキュリティ問題を解決できない場合、ASET は問題の存在を報告します。

ASET セッションを起動するには、/usr/aset コマンドを対話的に使用します。ASET を定期的に実行する場合は、crontab ファイルにエントリを指定します。

ASET のタスクはディスクをかなり使用するため、通常の動作の妨げになることがあります。システム性能への影響を最小限度に抑えるために、24 時間ごとまたは 48 時間ごとに深夜など、システムの稼働レベルが最も低いときに ASET を実行するようにスケジュールしてください。

ASET のセキュリティレベル

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

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

セキュリティレベルを下げるか、システムを ASET 実行前の設定に意図的に戻さない限り、ASET によってファイルのアクセス権のセキュリティが低くなることはありません。

ASET のタスク

この節では、ASET のタスクについて説明します。レポートを解釈して活用するには、各 ASET のタスク (その目的、実行される操作、および影響を受けるシステム構成要素) を理解しておく必要があります。

ASET のレポートファイルには、各 ASET タスクで検出された問題をできるだけ詳細に記述するメッセージが含まれています。これらのメッセージによって、問題を診断して解決できます。ただし、ASET を活用するには、システム管理とシステム構成要素を全般的に理解していることが前提となります。システム管理者になったばかりのユーザーは、ほかの Solaris システム管理マニュアルと関連するマニュアルページを参照して、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/utmpx

• /.rhosts

• /etc/vfstab

• /etc/dfs/dfstab

• /etc/ftpd/ftpusers

ASET は、これらのファイルに関して各種の検査と変更を実行し、すべての問題を sysconf.rpt ファイル内にレポートします。

環境変数の確認

このタスクでは、スーパーユーザー用とその他のユーザー用の PATH 環境変数と UMASK 環境変数が /.profile、/.login、/.cshrc ファイル内でどのように設定されているかを検査します。

環境のセキュリティ状況を検査した結果は、env.rpt ファイル内にレポートされます。

eeprom の確認

このタスクでは、eeprom セキュリティパラメータの値が検査され、適切なセキュリティレベルに設定されていることを確認します。eeprom セキュリティパラメータは、none、command、または full に設定できます。

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

ファイアウォールの設定

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

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

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

ASET 実行ログ

ASET を対話形式またはバックグラウンドで実行すると、実行ログが生成されます。デフォルトでは、ASET はログファイルを標準出力に生成します。実行ログは、ASET が指定された時刻に実行されたことを確認するもので、実行エラーメッセージも含まれています。aset -n コマンドを使用すると、ログを指定したユーザーに電子メールで配信できます。ASET オプションの一覧については、aset(1M) のマニュアルページを参照してください。

ASET 実行ログファイルの例

ASET running at security level low

Machine=example; Current time = 0325_08:00


aset: Using /usr/aset as working directory

Executing task list...
        firewall
        env
        sysconfig
        usrgrp
        tune
        cklist
        eeprom
All tasks executed. Some background tasks may still be running.

Run /usr/aset/util/taskstat to check their status:
     $/usr/aset/util/taskstat     aset_dir
Where aset_dir is ASET's operating directory, currently=/usr/aset

When the tasks complete, the reports can be found in:
     /usr/aset/reports/latest/*.rpt
You can view them by:
more /usr/aset/reports/latest/*.rpt 

実行ログはまず、ASET が実行されたシステムと時刻を示します。次に、開始したタスクの一覧を表示します。

ASET のタスクで説明しているように、ASET はこれらのタスクごとにバックグラウンド処理を呼び出します。タスクは開始されると実行ログに一覧表示されます。この一覧は、タスクの完了を示しているわけではありません。バックグラウンドタスクの状態を確認するには、taskstat コマンドを使用します。

ASET レポート

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

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

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

図 8–1 ASET reports ディレクトリの構造

この例では、2 つのレポートサブディレクトリを示しています。

• 0124_01:00

• 0125_01:00

サブディレクトリ名は、レポートの生成日時を示します。各レポートサブディレクトリ名の形式は次のとおりです。

monthdate_hour:minute

この場合、month、date、hour、minute は、いずれも 2 桁の数値です。たとえば、0125_01:00 は 1 月 25 日の午前 1 時を表します。

2 つのレポートサブディレクトリには、それぞれ ASET を 1 度実行して、生成されたレポートの集合が含まれています。

latest ディレクトリは、常に最新レポートが入っているサブディレクトリを指すシンボリックリンクです。したがって、ディレクトリ /usr/aset/reports/latest に移動すると、ASET で生成された最新レポートを見ることができます。このディレクトリには、最後に ASET を実行した各タスクのレポートファイルが入っています。

ASET レポートファイルの形式

各レポートファイルは、それを生成したタスクから取った名前が付けられます。 次の表にタスクとそのレポートのリストを示します。

各レポートファイル内で、メッセージの前後はバナー行で囲まれています。ASET の構成要素を誤って削除したり損傷したりした場合など、タスクが途中で終了することがあります。 このような場合、通常はレポートファイルの末尾の方に、途中で終了した理由を示すメッセージが記録されています。

次にレポートファイル usrgrp.rpt の例を示します。

*** Begin User and Group Checking ***

Checking /etc/passwd ...
Warning! Password file, line 10, no passwd
:sync::1:1::/:/bin/sync
..end user check; starting group check ...
Checking /etc/group...
*** End User And group Checking ***

ASET レポートファイルの検査

ASET を最初に実行したときまたは再構成したときは、レポートファイルを詳細に検査する必要があります。再構成には、asetenv ファイル、masters サブディレクトリのマスターファイルを変更したり、ASET が動作するセキュリティレベルを変更したりすることが含まれます。

このレポートには、ASET の再構成によって発生したエラーがすべて記録されます。レポートを詳しく確認すると、問題が発生した時点で対処して解決できます。

ASET レポートファイルの比較

構成上の変更やシステム更新がない期間中にレポートファイルを監視すると、レポートの内容が安定状態になり、予期しない情報は、あってもわずかであることがわかります。diff ユーティリティを使用して、レポートを比較できます。

ASET マスターファイル

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

調整ファイル

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

uid_aliases ファイル

uid_aliases ファイルには、同じユーザー ID (UID) を共有する複数のユーザーアカウントの一覧が入っています。このような複数のユーザーアカウントがあると責任の所在があいまいになるため、通常は ASET が警告を出します。uid_aliases ファイル内で例外を一覧すると、この規則に例外を設けることができます。重複する UID を持つ passwd ファイル内のエントリを uid_aliases ファイル内で指定しておくと、これらのエントリは ASET でレポートされません。

複数のユーザーアカウント (パスワードエントリ) に同じ UID を共有しないでください。他の方法で目的を達成することを検討する必要があります。たとえば、複数のユーザーにアクセス権一式を共有させたい場合は、グループアカウントを作成できます。UID の共有は最後の手段であり、どうしても必要で、他の方法では目的を達成できない場合にだけに使用します。

環境変数 UID_ALIASES を使用すると、別の別名ファイルを指定できます。 デフォルトファイルは /usr/aset/masters/uid_aliases です。

確認リストファイル

システムファイルの確認に使用されるマスターファイルは、初めて ASET を実行するときか、セキュリティレベルの変更後に ASET を実行するときに生成されます。

次の環境変数には、このタスクで確認するファイルを定義します

• CKLISTPATH_LOW

• CKLISTPATH_MED

• CKLISTPATH_HIGH

ASET 環境ファイル (asetenv)

環境ファイル asetenv には、ASET タスクに影響する環境変数の一覧が入っています。一部の環境変数を変更すると、ASET の動作を修正することができます。

ASET の構成

この節では、ASET を構成する方法とその操作の基礎となる環境について説明します。

ASET の管理と構成は最小限ですみ、ほとんどの場合はデフォルト値で実行できます。ただし、ASET の処理や動作に影響する一部のパラメータを調整して、その特長を最大限に発揮させることができます。デフォルト値を変更する前に、ASET の機能と、システムの構成要素に及ぼす影響を理解しておく必要があります。

ASET は、次の 4 つの構成ファイルに依存してタスクの動作を制御します。

• /usr/aset/asetenv

• /usr/aset/masters/tune.low

• /usr/aset/masters/tune.med

• /usr/aset/masters/tune.high

環境ファイルの変更 (asetenv)

/usr/aset/asetenv ファイルは、次の 2 つの主要セクションに分かれています

• ユーザーが構成可能な環境変数セクション

• 内部環境変数セクション

ユーザーが構成可能なパラメータセクションは変更できます。ただし、内部環境変数セクションの設定は内部使用だけに限られ、変更できません。

ユーザーが構成可能なセクションのエントリを編集して、次の操作を行うことができます。

• 実行するタスクを選択する

• システムファイルの確認タスク用のディレクトリを指定する

• ASET の実行スケジュールを指定する

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

• 確認対象を NIS+ テーブルまで拡張する

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

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

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

asetenv ファイル内で環境変数の TASKS の一覧を編集すると、ファイアウォール機能を使用しないで高セキュリティレベルで実行するように ASET を設定できます。デフォルトでは、TASKS の一覧にはすべての ASET タスクが含まれています。特定のタスクを削除するには、このファイルからそのタスクに関連する変数を削除します。この場合は、一覧から firewall 環境変数を削除することになります。次の一覧に ASET を実行すると、除外したタスクは実行されません。

次の例では、すべての ASET タスクが含まれる TASKS の一覧が表示されます。

TASKS=”env sysconfig usrgrp tune cklist eeprom firewall”

システムファイル確認タスクのディレクトリの指定: CKLISTPATH

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

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

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

これらのディレクトリに対して実行される確認は再帰的ではありません。ASET では、環境変数に明示的に指定されているディレクトリだけが確認されます。ASETでは、そのサブディレクトリは確認されません。

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

ASET の実行スケジュールの指定: PERIODIC_SCHEDULE

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

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

別名ファイルの指定: UID_ALIASES

UID_ALIASES 変数は、共有 UID が一覧される別名ファイルを指定します。 デフォルトファイルは /usr/aset/masters/uid_aliases です。

確認範囲を NIS+ テーブルまで拡張する: YPCHECK

YPCHECK 環境変数は、ASET でシステム構成ファイルテーブルも確認するかどうかを指定します。YPCHECK はブール型変数なので、true または false しか指定できません。デフォルト値は false で、NIS+ テーブルの確認は無効になっています。

この環境変数の機能を理解するために、passwd ファイルに与える影響を考えてみてください。false に設定すると、ASET はローカルの passwd ファイルを確認します。true に設定すると、NIS+ の passwd ファイル内でシステムのドメインも確認されます。

ASET ではローカルテーブルが自動的に修復されますが、NIS+ テーブル内の潜在的な問題はレポートされるだけです。ASET ではそれらの問題は変更しません。

調整ファイルの変更

ASET は、3 つのマスター調整ファイル、tune.low、tune.med、tune.high を使用して、重要なシステムファイルへのアクセス制限を緩めたり厳しくしたりします。この 3 つのマスターファイルは /usr/aset/masters ディレクトリにあり、環境に合わせて調整できます。詳細は、調整ファイルを参照してください。

tune.low ファイルは、アクセス権をデフォルトのシステム設定に適した値に設定します。tune.med ファイルは、これらのアクセス権をさらに制限し、tune.low に含まれていないエントリを追加します。tune.high ファイルは、アクセス権をさらに厳しく制限します。

調整ファイル内の設定を変更するには、ファイルのエントリを追加または削除します。アクセス権を現在の設定よりも制限が緩やかになるような値に設定しても意味がありません。システムセキュリティを下位レベルに下げない限り、ASET がアクセス権の制限を緩和したことになりません。

ASET で変更されたシステムファイルの復元

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

システムファイルに適用した変更は、aset.restore コマンドを実行すると失われます。

aset.restore コマンドは、次のような場合に使用します。

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

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

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

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

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

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

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

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

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

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

ASET レポートの収集

スーパーユーザー特権を持っているかどうかにかかわらず、クライアントにアクセスされるサーバー上に ASET 構成要素を集中できるほか、サーバー上に集中ディレクトリを設定して、各種クライアント上で実行中のタスクによって生成されるすべてのレポートを収集できます。収集メカニズムを設定する方法については、サーバー上で ASET レポートを収集する方法を参照してください。

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

ASET 環境変数

次の表に 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 つのすべての調整ファイルのエントリの書式を示します。

調整ファイルを編集するときは、次の規則が適用されます。

• パス名には、アスタリスク (*) や疑問符 (?) など、通常のシェルのワイルドカード文字を使用して、複数のエントリを指定できます。詳細は、sh(1) のマニュアルページを参照してください。

• mode は、最も制限が緩やかな値を表します。現在の設定が指定した値よりもすでに厳しく制限されている場合、ASET はアクセス権の設定を緩和しません。たとえば、指定した値が 00777 の場合、00777 は常に現在の設定よりも緩やかな制限を表すため、アクセス権は変更されません。

  セキュリティレベルを下げるか、ASET を削除しない限り、ASET ではこの方法でモード設定を行います。セキュリティレベルを前回の実行時よりも下げるときや、システムファイルを ASET を最初に実行する前の状態に復元したいときには、ASET は操作の内容を認識して保護レベルを下げます。

• owner と group には、数値 ID ではなく名前を使用する必要があります。

• owner、group、type の代わりに疑問符 (?) を使用すると、ASET がこれらのパラメータの既存の値を変更しないようにします。

• type には、symlink (シンボリックリンク)、ディレクトリ、またはファイルなどすべての種類を指定できます。

• セキュリティレベルが高くなるほど、調整ファイルは下位レベルよりも緩やかなファイルアクセス権にリセットされます。また、上位セキュリティレベルになるほど、一覧に多数のファイルが追加されます。

• 1 つのファイルで複数の調整ファイルエントリを照合できます。たとえば、etc/passwd は etc/pass* エントリと /etc/* エントリに一致します。

• 2 つのエントリのアクセス権が異なる場合は、ファイルアクセス権は最も厳しいアクセス権を表す値に設定されます。次の例では、/etc/passwd のアクセス権は 00755 に設定されますが、これは 00755 は 00770 よりも厳密な制限であることを表します。

  /etc/pass* 00755 ? ? file /etc/* 00770 ? ? file

• 2 つのエントリの owner 指定または group 指定が異なる場合は、最後のエントリが優先されます。次の例では、/usr/sbin/chroot の所有者が root に設定されます。

  /usr/sbin/chroot 00555 bin bin file /usr/sbin/chroot 00555 root bin file