rbac, RBAC - 役割に基づくアクセス制御
役割に基づくアクセス制御を使用すると、システム管理者は、システムの各部分の管理制御をユーザーに委任できます。ユーザーが追加の特権を使用してコマンドを実行できるようにするための方法には、次の 2 つがあります:
ユーザーにプロファイルを直接割り当てます。この場合、追加の認証は必要ありません
役割を作成し、その役割にプロファイルを割り当てます。また、このアクセス制御を使用すると、通常であれば実行を許可されるコマンドを実行できなくすることにより、ユーザーにとって制限的な環境を構築することもできます。
プロファイルは、追加の特権または特定の実 UID/GID や実効 UID/GID、あるいはその両方で実行されるコマンドおよび承認の名前付き集合です。For example, most of the printer system can be managed by having the lp commands run with the UID of lp.一部のコマンドの実行には、privileges(7) で定義された特権が必要です。For example, the “Process Management” profile allows a user to run the kill command with the proc_owner privilege so that it can send signals to processes it does not own.
管理者がシステムで提供されたプロファイルを拡張したり、独自のプロファイルを作成したりする方法については、exec_attr(5) および prof_attr(5) を参照してください。プロファイルの構成は、現在サポートされているネームサービス (ファイル、NIS、LDAP) のいずれかに格納できます。
プロファイルはまた、サービスの実行に使用される特権や UID/GID を制御するためにサービス管理機能 (SMF) でも使用できます。詳細は、smf_security(7) を参照してください。
プロファイルは、user_attr(5) データベース内のユーザーのエントリと policy.conf(5) に指定された順序で検索されます。ユーザーごとに、認証されたセットと認証されていないセットという、プロファイルの 2 つのセットがあります。The user is required to reauthenticate prior to using pfexec(1) to execute commands which match an entry in the exec_attr(5) database corresponding to the authenticated profiles set.このコマンドが端末から実行された場合、PAM スタック /etc/pam.d/pfexec 内の pam_tty_tickets(7) に対して設定されたタイムアウトオプションに従って、現在のユーザーと tty の認証状態がキャッシュされます。現在の tty は存在しないが、アクティブな X11 セッションが存在する場合、ユーザーは、zenity(1) ダイアログを通して認証するよう求められます。This authentication state is cached for the current user and DISPLAY environment setting.
Processes that have been successfully reauthenticated, including those that were implicitly authenticated within the timeout value of the cache, are marked with an additional process flag, PRIV_PFEXEC_AUTH, which exempts child processes from subsequent reauthentication.Both the PRIV_PFEXEC and PRIV_PFEXEC_AUTH flags are inherited by child processes unless the real uid is changed.
認証されていないプロファイルのセットに一致するコマンドは、再認証する必要はありませんが、認証されたプロファイルのセット内のコマンドに比べて優先順位が低くなります。同じコマンドが複数のプロファイルに存在する場合、プロファイルシェルは最初に一致したエントリを使用します。
役割は、承認されたユーザーが su(8) コマンドを使用して、またはホストベース認証や GSS-API 認証を使用している場合は ssh(1) を使用してネットワーク経由でしかアクセスできないシステムに直接ログインできない特殊な共有アカウントです。It can not login with rlogin(1), telnet(1), or gdm(8).
役割には、通常ユーザーと同様に UID、パスワード、およびホームディレクトリがあります。役割に対する認証は、ユーザー独自のパスワードまたは役割ごとのパスワードのどちらかで行うことができます (user_attr(5) の roleauth キーワードによって、役割ごとの動作が制御されます)。Usually a role's login shell is one of the profile shells (see pfsh(1) for a list) that are granted one or more Profiles, allowing the role to always execute commands with privilege.
役割は通常、共有アカウント環境が必要な場合にのみ必要になります。通常は、ユーザーにプロファイルを直接割り当てれば十分です。
root ユーザーは、usermod(8) コマンドを使用して、役割になるように構成できます。これにより、root パスワードがより広範囲に知られている場合でも、承認ユーザーのみが root になれることが保証されます。
# usermod -K type=role root
root を役割にしても、シングルユーザーモードへのアクセスは制限されません。システムコンソールは、eeprom(8) によるセキュリティーパスワードの設定などの、ほかの手段を使用して保護するようにしてください。
承認は、一部の操作または操作のクラスを実行するためのユーザーの権利を表す一意の文字列です。Authorizations are normally only checked by programs that always run with some privilege, for example setuid(2) programs such as cdrw(1) or the system cron(8) daemon.
承認の定義は、auth_attr(5) データベースに格納されます。プログラミングでの承認チェックの場合は、承認名のみが重要です。
auth_attr データベース内のいくつかの代表的な値を次に示します:
solaris.jobs.:::Cron and At Jobs::help=JobHeader.html
solaris.jobs.grant:::Delegate Cron & At \
Administration::help=JobsGrant.html
solaris.jobs.admin:::Manage All Jobs::help=AuthJobsAdmin.html
solaris.jobs.user:::Cron & At User::help=JobsUser.html
grant 接尾辞で終わる承認名文字列は、ユーザーが、同じ接頭辞と機能領域を持つ承認をほかのユーザーに委任できるようにする特殊な承認です。
solaris で始まる承認名はすべて、オペレーティングシステムのベンダーによる割り当てのために予約されています。開発者と管理者は、独自の最上位の名前空間を作成できます (会社名、DNS ドメイン名、アプリケーション名などの一意の識別子を使用することをお勧めします)。
C コードから承認をチェックするには、開発者は、ユーザーに特定の承認が割り当てられているかどうかを検証する chkauthattr(3C) ライブラリ関数を使用してください。
承認は、auths(1) ユーティリティーの出力をチェックすることによって、シェルスクリプトで明示的にチェックできます。For example,
for auth in `auths | tr , " "` NOTFOUND ; do
["$auth" = "solaris.date" ] && break # authorization found
done
if [ "$auth" != "solaris.date" ] ; then
echo >&2 "$PROG: ERROR: you are not authorized to set the date"
exit 1
fi
承認はまた、どのユーザーがサービスの状態を変更したり、サービスを再構成したりできるかを制御するためにサービス管理機能 (SMF) でも使用されます。詳細は、smf_security(7) を参照してください。
RBAC in Solaris provides a similar set of functionality to sudo(8) that is often provided with UNIX or UNIX-like systems, including Oracle Solaris.
One of the most obvious differences between Solaris RBAC and sudo is the authentication model.sudo では、ユーザーは自分自身として再認証します。In Solaris RBAC, no additional authentication is needed when unauthenticated profiles are assigned directly to the user.Authentication may be needed in Solaris RBAC when executing commands from an authenticated profile, or when the user authenticates to a shared account called a role.
Using the NOPASSWD functionality in sudo is similar to assigning the profile to the user and having the user execute the command using pfexec(1).For example, if sudoers(5) allows the user to run kill(1) as UID 0 but without authentication (NOPASSWD), the user would run:
$ sudo kill -HUP 1235
In Solaris RBAC, if the user has a normal (that is, no profile) login shell, the user would execute the equivalent operation by being assigned the “Process Management” profile and would use pfexec as follows:
$ pfexec kill -HUP 1235
ユーザーにログインシェルとして (pfsh などの) プロファイルシェルが割り当てられている場合は、「接頭辞」がなくても kill は常に追加の特権で実行されます。For example,
$ kill -HUP 1235
An RBAC role is similar in concept to the User_Alias in sudoers(5), except that the role password rather than the user password is required.
RBAC の実行プロファイル ((exec_attr(5) エントリ) は、sudoers の Cmnd_Alias に似ています。
There is currently no equivalent of the Host_Alias sudo(8) functionality in Solaris RBAC.
auths(1), ld.so.1(1), pfexec(1), pfsh(1), profiles(1), roles(1), auth_attr(5), exec_attr(5), prof_attr(5), sudoers(5), user_attr(5), pam_tty_tickets(7), smf_security(7), sudo(8)
Support for authenticated profiles was added in Oracle Solaris 11.2.0.
RBAC was added to Solaris in Solaris 8.