このセクションでは、ユーザーレベルでの権利の実装と使用についてさらに詳しく説明します。
承認とは、役割、プログラム、ゾーン、またはユーザーに付与できる権利です。承認は、ユーザーアプリケーションレベルでポリシーを適用します。特権と同様に、承認の割り当てを誤ると、本来予定していたよりも多くの権利が付与される結果となる可能性があります。詳細は、特権エスカレーションとユーザー権利を参照してください。
承認と特権の違いは、セキュリティーポリシーが適用されるレベルにあります。プロセスに適切な特権がないと、特権化された処理の実行がカーネルによって防止される可能性があります。適切な承認が与えられていないユーザーは、特権付きアプリケーションを使用できなかったり、特権付きアプリケーションに含まれるセキュリティーの厳しい処理を実行できなかったりする可能性があります。特権の詳しい説明については、プロセス権管理を参照してください。
権利に準拠したアプリケーションは、ユーザーの承認を確認してから、アプリケーションまたはアプリケーション内の特定の操作に対するアクセス権を許可します。この確認は、従来の UNIX アプリケーションが行なっていた UID=0 の確認に代わるものです。
承認についての詳細は、次のセクションを参照してください。
権利プロファイルは、管理権利が必要なタスクを実行するために役割またはユーザーに割り当てることができる権利の集合です。権利プロファイルには、承認、特権、セキュリティー属性が割り当てられたコマンド、およびほかの権利プロファイルを含めることができます。権利プロファイルにはまた、特権の初期継承可能セットを削減または拡張したり、制限セットを削減したりするためのエントリも含まれています。
認証権利プロファイルは、ユーザーに対しパスワードの入力、つまり再認証を求める権利プロファイルです。管理者は、どのプロファイルをユーザーの再認証なしで使用できるかを決定します。再認証が不要なプロファイルの例として、Basic Solaris User 権利プロファイルがあります。サイトのセキュリティー要件に基づき、セキュリティーの厳しいタスクのための権利プロファイルでは、再認証が必要になることがあります。
権利プロファイルの参照情報については、次のセクションを参照してください。
「役割」は、特権付きアプリケーションを実行できる特別な種類のユーザーアカウントです。役割は、ユーザーアカウントと同じ方法で作成され、ホームディレクトリ、グループ割り当て、パスワードなどを持ちます。権利プロファイルと承認により、役割に管理権利が提供されます。役割は、ほかの役割やその役割を引き受けるユーザーから権利を継承することはできません。役割によりスーパーユーザー特権が割り振られるため、セキュリティーが強化された管理を実施できます。
各役割は、複数のユーザーに割り当てることができます。同じ役割になるすべてのユーザーは、同じ役割のホームディレクトリを持ち、同じ環境で動作し、同じファイルへのアクセス権を持ちます。ユーザーは、役割を引き受けるにはコマンド行で su コマンドを実行し、役割名と役割のパスワードを入力します。管理者は、ユーザーが、そのユーザーのパスワードを指定することによって認証できるようにシステムを構成できます。使用例 18を参照してください。
役割は直接ログインすることはできません。ユーザーがまずログインし、続いて役割を引き受けます。役割を引き受けたあとで別の役割を引き受けるには、まず現在の役割を終了する必要があります。
また、権利プロファイルはユーザーの環境に権利を追加しますが、役割はユーザーに対し、その役割を引き受けることができるほかのユーザーと共有するクリーンな実行環境を提供します。ユーザーが役割に切り替わっても、ユーザーの承認または権利プロファイルはすべて役割には適用されません。
passwd、shadow、および user_attr データベースに、静的な役割情報が格納されます。ユーザーは役割のアクションを監査できるので、この監査を実行すべきです。
役割の設定についての詳細は、次のセクションを参照してください。
Oracle Solaris では root は役割であるため、匿名の root ログインが回避されます。プロファイルシェルコマンド pfexec が監査されると、監査トレールにはログインユーザーの実 UID、ユーザーが引き受けている役割、および実行された特権付き操作が含まれています。特権付き操作についてシステムを監査するには、管理アクションの監査を参照してください。
修飾ユーザー属性は、ユーザーや役割、およびホストやネットグループと呼ばれるホストのグループに割り当てることができる属性です。ネットグループにより、ラボネットワークなどの一連のシステムの管理が簡素化されます。これらの修飾子は LDAP アカウントにのみ適用され、files ネームサービスには適用されません。
修飾および非修飾ユーザー属性は独立して保持され、組み合わせることはできません。この独立性により、管理者は 1 人のユーザーまたは役割に修飾と非修飾の両方の拡張ポリシー属性を割り当てることができます。実行時に、システムはまず、実行が発生しているホスト名を判定し、次に適切なポリシー属性のセットを適用します。
usermod および rolemod コマンドは、セキュリティー属性が適用されるホストまたはネットグループを示す修飾子オプション -q を受け入れます。修飾または非修飾属性の各セットを管理するには、個別の usermod および rolemod コマンドが必要です。userdel および roledel コマンドは、ほかの修飾または非修飾属性に影響を与えることなく、完全な修飾属性のセットを削除できます。
適切なユーザー属性のセットを適用するためのポリシーは、name-service/switch サービスによって指定された検索順序に従い、name-service/cache サービスによってキャッシュされます。その順序は次のとおりです。
指定されたユーザーまたは役割に一致するローカルエントリ
指定されたユーザーまたは役割の修飾属性の 1 つ以上の LDAP エントリ
ホスト名が現在のホストに一致する LDAP エントリ
現在のホストをメンバーとして持つ (LDAP 内の) ネットグループ
指定された LDAP ユーザーまたは役割の非修飾エントリ
割り当てられた Stop 権利プロファイルがない場合は、/etc/policy.conf ファイルで指定されているデフォルト属性
一致が見つかった場合は、以降のクエリーを最適化するためにその内容がキャッシュされます。例については、使用例 29を参照してください。