デフォルトの Trusted Solaris プログラムやアクションには、あらかじめ、その機能を果たすために必要な特権、実効 UID、実効 GID などが割り当てられています。この節では、次の種類のソフトウェアを追加する際の問題や作業について説明します。
Trusted Solaris のセキュリティポリシーを認識したり施行したりしないサンの別パッケージの製品やサン以外のアプリケーション
Trusted Solaris プログラミングインタフェースを使用して作成したラベルと MAC (必須アクセス制御) を認識し、Trusted Solaris セキュリティポリシーの範囲内で動作する新しいプログラム
新しいアクション (セキュリティ管理者役割によって作成または、認可されたもの)
シェルスクリプト (セキュリティ管理者役割によって作成または、認可されたもの)
プログラムの中には、単一レベルで実行され、特権が必要ないため、セキュリティ管理者役割が ADMIN_LOW
で公開ディレクトリにインストールするだけで、ユーザーや役割の実行プロファイルに必要なコマンドを割り当てることのできるものがあります。このとき、プログラムを機能させるために特権を割り当てたり、その他の属性を修正する必要はありません。一方、セキュリティポリシーを回避する必要のあるプログラムの場合は、あらかじめ分析やテストを行なった上で、特権を割り当てる必要があります。
既存のプログラムを Trusted Solaris システムに追加する場合は、そのプログラムが社外で作成されたアプリケーション、Solaris の別パッケージのソフトウェアプログラム、社内で作成されたプログラムのいずれの場合でも、次の指示に従って作業を行なってください。
そのアプリケーションが Trusted Solaris システム内で変更なしに正しく実行できることを 確認します。
特権を付与したり修正を加えたりしないで実行できる場合、ここで作業は終了です。
プログラムが失敗した場合は、その原因を見つけます。
Trusted Solaris オペレーティング環境には、セキュリティポリシーを施行するために特別な修正が加えられています。そのため、Solaris 用に作成された別パッケージのソフトウェアやサン以外のアプリケーションの中には、Trusted Solaris 環境で実行できないものもあります。たとえば、カーネルとリンクするソフトウエアは、Trusted Solaris 用に修正されたカーネルデータ構造とは互換性がない場合があります。同様の理由で、読み込み可能なデバイスドライバやその他のソフトウエアも、コードを変更しない限り、この環境で実行できない可能性があります。
アプリケーションがカーネルにリンクしているか、オペレーティングシステムの修正された部分に依存している場合、そのプログラムに特権を付与しても、コードを変更しない限り、Trusted Solaris で実行できない可能性があります。
Solaris オペレーティングシステムの Trusted Solaris 用に修正された部分には依存していないプログラムで、特権を使用しないとエラーが発生する場合、必要な特権やその他の属性を判断します。
特権の使用が必要な場合、プログラムが信頼できる方法で特権を使用するかどうかを調査します。
「特権を使用しないとエラーが発生するプログラム」を参照してください。
プログラムが、特権またはその他の必要な属性を使用して、Trusted Solaris のセキュリティポリシーや独自に導入しているセキュリティポリシーに違反することなく安全に実行できる場合は、必要な特権を割り当てます。この方法については、「特権がコマンドとアクションに割り当てられる方法」参照してください。
プログラムのソースコードへのアクセス権がある場合、コードを修正した後、セキュリティを熟知したセキュリティコンサルタントやプログラマが特権を追加できる場合もあります。
このような修正では、特権ブラケットを使用したり、プログラムに Trusted Solaris のセキュリティポリシーを認識させるためのコードを追加したりします。
プログラムで特権を使用できるようにする場合、そのプログラムが使用するライブラリがトラステッドとして認識されるかどうかを確認する必要があります。「特権プログラムがトラステッド共用ライブラリを使用する理由」を参照してください。
プログラムが信頼できる方法で特権を使用できない場合や、修正が不可能な場合は、特権を使用可能にしてはなりません。
Trusted Solaris 環境において特権がないためにエラーを発生するもっとも典型的なプログラムは、標準 Solaris 環境でスーパーユーザーとして実行する必要があるプログラムです (たとえば、setuid をスーパーユーザーにして動作するようなプログラム)。この種類のプログラムには、プロファイルでスーパーユーザーの実効 UID を割り当てることができます。あるいは、実 UID を必要とする場合は、(セキュリティ管理者役割の判断により)、そのプログラムをスーパーユーザー役割に割り当てることもできます。
ほとんどのアプリケーションは、MAC などの Trusted Slaris のセキュリティ機構を持たない環境で作成されます。このため、セキュリティと、新しいプログラムで実現しようとしている内容について完全に理解しなければ、プログラムを評価することができません。
ユーザーに代わってあらかじめ厳密なチェックを行なったとしても、DAC に違反するような標準 UNIX アプリケーション管理者が、MAC と同様のチェックを行うことはありません。つまり、このようなプログラムに MAC の無効化特権を付与した場合、ユーザーが任意で MAC を無効にできる方法を提供してしまうことになります。
セキュリティ上の考慮が必要な点について、UNIX プログラムで一般的に使用される rcp(1) の動作を例に挙げて説明します。rcp コマンドは、ネットワーク内でファイルをコピーするコマンドで、setuid を root として実行されます。root として実行すると、プログラムは、標準の UNIX システムのすべての特権を使用して実行されます。このプログラムは DAC 制限の回避を許可されていますが、ファイルの DAC アクセス権をチェックして、rcp コマンドを実行したユーザーが、ファイルへのアクセス権を持っていることを確認します。ただし、rcp では MAC 制限は行われません。また、 file_mac_read
特権や file_mac_write
特権を付与したとしても、ファイルへのアクセス時に MAC 関連のチェックを行う組み込み機能もありません。したがって、rcp は、システムのセキュリティポリシーを実現するために割り当てられた特権を使用することができません。
これと類似したプログラムに、実行に必要な特権を単純に割り当て、Trusted Solaris のセキュリティポリシーに従って動作するように修正しなかった場合、そのプログラムはシステムセキュリティに違反することになります。システムセキュリティに違反せずに実行できるようにするには、プログラムのソースコードにコードを追加する必要があります。たとえば、ファイルの読み取りや書き込みを行うときに MAC 制限を回避しなければならない場合、必要な MAC チェックを行うコードを追加して、ソースコードを変更する必要があります。
ソフトウェアの中には、特権が必要な理由が明確でないものもあります。さらに、プログラムの実行に特権が必要ないものもあります。けれども、システムのセキュリティポリシーに違反するような機能を持たないプログラムであっても、共用ログファイル中の処理の履歴を追跡したり、/dev/kmem (mem(7D) を参照) から読み取りを行うなど、セキュリティに違反する内部作業を行なっている可能性があります。内部で発生するポリシー違反は、ユーザーに便利な機能を提供するだけで、アプリケーションを正しく操作するためには特に重要でない場合があります。サイトでソースコードを調べられる場合は、アプリケーションのパフォーマンスに影響を与えることなく、ポリシーの無効化を必要とする操作を削除できないか検討します。
MAC 検査を行わずにファイルの読み取りや書き込みを行うなど、いくつかの面で Trusted Solaris のセキュリティポリシーに違反するプログラムについては、可能であれば、ソースコードに必要な MAC 検査を追加します。そうでなければ、そのプログラムの移植は控えてください。
通常、特殊なアプリケーションやパッケージをインストールするソフトウェアの場合、正常に処理を行うためには、スーパーユーザーの実効 UID が必要です。プロファイル機構では、アプリケーションに実効 UID を割り当てられるのはセキュリティ管理者役割だけなので、インストールプログラムのプロファイルにスーパーユーザーの UID を割り当てるのは、セキュリティ要件に適合しません。コマンドがスーパーユーザーの実 UID で実行できるようにする唯一の方法は、スーパーユーザー役割がそのコマンドを実行することです。セキュリティ管理者役割は、アカウントにスーパーユーザー役割を割り当て、Custom Root Profile などのプロファイルにコマンドを追加できます。詳細は、「アプリケーションの設定: スーパーユーザーの実 UID を使用して実行する」を参照してください。
スーパーユーザーが実行するアプリケーションについては、次の 3 つのオプションを使用して、サイトのセキュリティポリシーと矛盾がないか評価する必要があります。これはセキュリティ管理者役割の業務です。
アプリケーションの実行にスーパーユーザーの実効 UID が必要ない場合、スーパーユーザーの実効 UID を使用するように設定する
「アプリケーションの設定: スーパーユーザーの実効 UID を使用して実行する」を参照してください。
アプリケーションに必要な特権を特定し、アプリケーションがその特権を信頼できる方法で使用することを確認してから、必要な特権だけを割り当てる
「アプリケーションに必要な特権を調べるには」を参照してください。
必要なアカウントにスーパーユーザーの役割を一時的または常に割り当て、そのアカウントのプロファイルの 1 つにコマンドを割り当てる
「アプリケーションの設定: スーパーユーザーの実 UID を使用して実行する」を参照してください。
runpd(1M) コマンドは任意のコマンドを実行して、そのコマンドが使った特権を記録します。
runpd コマンドにはトラステッドパス属性が必要です。コマンドがトラステッドパス属性を取得できるのは、そのコマンドがプロファイル中に指定されており、管理役割によって実行されるときだけです。したがって、通常のユーザーは runpd を実行して、通常のユーザーに必要な特権を見つけることはできません。runpd を実行するためにスーパーユーザー役割を使ってはなりません。これは、UID 0 が他の UID よりも多くのアクセス権をコマンドに与えてしまうためです。runpd コマンドを使うと、コマンドが使用されるラベルにおいて、そのコマンドがどの特権を使うのかテストできます。管理役割 (スーパーユーザー役割を除く) として runpd を実行すると、コマンドがユーザーの認可範囲内の機密ラベルで実行された場合、通常のユーザーに必要な特権が記録されます。
デフォルトでは、セキュリティ管理者役割は、そのプロファイル内に runpd コマンドが割り当てられている唯一の役割です。「アプリケーションに必要な特権を調べるには」で説明している手順に従うと、特権デバッグを有効にできます。その手順では、特権デバッグ専用の管理役割を作成する方法についても説明しています。
コマンドが必要とする特権は、自動的に割り当ててはなりません。特権を割り当てる前に、他の方法を検討してください。
プログラムがファイルにアクセスするときに DAC または MAC の制限を回避する必要がある場合、セキュリティ管理者役割は実効 UID または GID を割り当てることによって、特権を不要にすることも可能です。詳細は、「特権の割り当て以外の方法」を参照してください。
ソフトウェアに特権、あるいは代替の UID または GID が割り当てられているとき、そのソフトウェアは、Trusted Solaris セキュリティポリシーを無効にできるという意味で「トラステッド (信頼できる)」になります。したがって、「信頼できない」ソフトウェアでも「トラステッド (信頼できる)」になってしまうことに注意してください。セキュリティ管理者役割は、ソフトウェアが信用に値する方法で特権を使うことが確信できるまで、そのソフトウェアに特権を与えてはなりません。ソフトウェアを十分に調べ、システムのセキュリティポリシーの範囲内で特権を使っていることが判明した場合にのみ、そのソフトウェアは「信頼のおける」プログラムであると言えます。
プログラムの開発者がソースコードに組み込む特権をセットを操作できてもセキュリティ管理者役割がプログラムに必要な特権を割り当てなければ、プログラムで特権を使用することはできません。セキュリティポリシーを無効にできなければ、そのプログラムは期待通りの処理を完全に行えなかったり、Trusted Solaris システムで実行することができなかったりします。
Trusted Solaris システムに追加されるプログラムを作成する開発者には、次の条件が必要です。
プログラムが機能するために特権が必要かどうか判断できる
特権ブラケットなどの技術を習得しており、プログラムで安全に特権を行使するために使用できる
プログラムに特権を割り当てるときは、セキュリティの実現に注意し、プログラムがセキュリティポリシーに違反しないことを確認する
セキュリティ管理者役割との共同作業により、「特権プログラムがトラステッド共用ライブラリを使用する理由」の説明に従って、プログラムにリンクされた共用ライブラリをトラステッドディレクトリ内に格納する。また、プログラムをコンパイルするときは、「」 に従って、トラステッドディレクトリの場所を使用する
プログラム内で特権を使用する方法については、『Trusted Solaris 開発ガイド』を参照してください。
セキュリティ管理者役割は、Trusted Solaris のシステムコールやルーチンを使用してセキュリティポリシーの範囲内で処理を行うプログラムが、絶対に Trusted Solaris システムのセキュリティに違反しないようにする必要があります。
プログラマやプログラム配布プロセスが信頼できることを確認する
次の情報源から、プログラムに必要な特権を決定する
プログラマに確認する
ソースコードを調べて、プログラムが使用する予定の特権を検索する
runpd を使用する。これについては、「アプリケーションに必要な特権を調べるには」で説明しています。
ソースコードを綿密に調査し、処理に必要な特権を使用する際に信頼できる方法で動作することを確認する
Trusted Solaris システムでアクションを作成し、使用する方法は、標準 Solaris の場合とほとんど変わりません。アクションの追加方法については、『Solaris 共通デスクトップ環境 上級ユーザ及びシステム管理者ガイド』で説明しています。
Trusted Solaris では、アクションの使用は実行プロファイル機構によって制御されます。アクションには、任意の実行プロファイルに特権、実効 ULD、実効 GID などのセキュリティ属性を割り当てることができ、継承可能セットからアクションに特権を引き渡すことのできるウィンドウシステムのトラステッドプロセスの中で呼び出された場合は、特権を使用して実行することができます。Trusted Solaris システムでは、多数のアクションの実行プロファイルに特権が割り当てられていて、そのプロファイルはデフォルトで特定の役割に割り当てられています。表 16-3 に、Trusted Solaris システムでアクションを作成したり使用するときの重要な相違点についてまとめます。
表 16-3 Trusted Solaris の制限下でアクションを作成したり使用する際の相違点標準 CDE | Trusted Solaris |
---|---|
新しいアクションは、だれでも自分のホームディレクトリ内に作成できる。また、作成者は自動的に新しいアクションを使用できるようになる。 | アクションは、ユーザーや役割の実行プロファイルに含まれている場合だけ使用可能。 |
プロファイルに、「アクション作成 (Create Action)」 アクションまたはコマンド、ファイルの編集を許可するアクションがある場合、ユーザーや役割は、自分のホームディレクトリ内に新しいアクションを作成することができる。ただし、それを使用することはできない。 | |
ユーザーが新しいアクションを使用するためには、セキュリティ管理者役割が新しいアクションの名前をアカウントの実行プロファイルの 1 つに追加するか、All プロファイルが割り当てられていることが必要。All プロファイルは、アクションに対するすべてのチェックを無効にするため、ユーザーは、常駐するアクションでも、一時的アクションでも、すべてのアクションを使用することができる。 | |
実行プロファイルによってアクションの使用を許可されているアカウントであれば、ファイルマネージャを使用してホームディレクトリからアクションを起動することができる。デフォルトのシステム管理者役割とセキュリティ管理者役割は、公開ディレクトリにアクションを配置することが許可されている。 | |
アクションをフロントパネルにドラッグ&ドロップすることが可能。 | フロントパネルは、トラステッドパスの一部。ウィンドウマネージャは、システム全体のアクションファイルが保存されている /usr/dt および /etc/dt サブディレクトリにある、管理者が追加したアクションだけを認識する。したがって、一般ユーザーまたは管理役割以外のアカウントが自分のホームディレクトリに新しいアクションを作成し、All Accounts プロファイルを持っていたとしても、ユーザーのホームディレクトリからフロントパネルにドラッグされた新しいアクションは、ウィンドウマネージャに認識されない。ウィンドウマネージャは公開ディレクトリ内だけを検索する。 |
アクションが特権を付与された処理を行うためには、スーパーユーザー (root) によって実行されなくてはならない。 | 呼び出し元のアカウントの実行プロファイルで、特権を持つことが指定されているアクションの場合、トラステッドプロセスから起動されたときは、特権を継承することができる。つまり、アクションが特権を付与された処理を行うためには、アカウントのプロファイルに特権を割り当てておかなくてはならない。 |