Hallo, dies ist ein Test.
PWD: /www/data-lst1/unixsoft/unixsoft/kaempfer/.public_html
Running in File Mode
Relative path: ./../../../../../../usr/man/man7/rbac.7
Real path: /usr/share/man/man7/rbac.7
Zurück
'\" te .\" Copyright (c) 2002, 2021, Oracle and/or its affiliates. .TH rbac 7 "21 Jun 2021" "Oracle Solaris 11.4" "Standards, Environments, Macros, Character Sets, and miscellany" .SH NAME rbac, RBAC \- role-based access control .SH DESCRIPTION .sp .LP Role-based access control allows system administrators to delegate the administrative control of parts of the system to users. Users can be given the ability to run commands with additional privileges in two ways: .RS +4 .TP .ie t \(bu .el o by assigning a profile directly to the user, in which case no additional authentication is required .RE .RS +4 .TP .ie t \(bu .el o by creating a role and assigning the profiles to the role. It can also be used to build restrictive environments for users by removing their ability to run commands they would normally be allowed to run. .RE .SS "Profiles" .sp .LP Profiles are named collections of commands and authorizations that are run with additional privilege and/or a specific real and effective UID and GID. For example, most of the printer system can be managed by having the \fBlp\fR commands run with the UID of \fBlp\fR. Some commands need privileges as defined in \fBprivileges\fR(7) to run. For example, the "Process Management" profile allows a user to run the \fBkill\fR command with the \fBproc_owner\fR privilege so that it can send signals to processes it does not own. .sp .LP See \fBexec_attr\fR(5) and \fBprof_attr\fR(5) for information about how the administrator can extend the system-provided profiles and create their own. Profile configuration can be stored in any of the currently supported name services (files, NIS, LDAP). .sp .LP Profiles can also be used with the Service Management Facility (SMF) to control the privileges and UID/GID with which a service runs. See \fBsmf_security\fR(7) for more information. .sp .LP Profiles are searched in the order specified in the user's entries in the \fBuser_attr\fR(5) database and \fBpolicy.conf\fR(5). For each user, there are two sets of profiles, an authenticated set, and an unauthenticated set. The user is required to reauthenticate prior to using \fBpfexec\fR(1) to execute commands which match an entry in the \fBexec_attr\fR(5) database corresponding to the authenticated profiles set. If the command is executed from a terminal, the authentication state is cached for the current user and tty, subject to the timeout option set for \fBpam_tty_tickets\fR(7) in the PAM stack \fB/etc/pam.d/pfexec\fR. If there is no current tty, but there is an active X11 session, the user is prompted to authenticate through a \fBzenity\fR(1) dialog. This authentication state is cached for the current user and \fBDISPLAY\fR environment setting. .sp .LP 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, \fBPRIV_PFEXEC_AUTH\fR, which exempts child processes from subsequent reauthentication. Both the \fBPRIV_PFEXEC\fR and \fBPRIV_PFEXEC_AUTH\fR flags are inherited by child processes unless the real uid is changed. .sp .LP Commands that match the set of unauthenticated profiles do not require reauthentication, but have lower precedence than commands in the set of authenticated profiles. If the same command appears in more than one profile, the profile shell uses the first matching entry. .SS "Roles" .sp .LP A role is a special shared account that cannot directly login to the system that can only be accessed by authorized users with the \fBsu\fR(8) command or over the network with \fBssh\fR(1) when using host-based authentication or GSS-API authentication. It can not login with \fBrlogin\fR(1), \fBtelnet\fR(1), or \fBgdm\fR(8). .sp .LP A role has a UID, a password, and a home directory just like a normal user. Authentication to the role can be either with the user's own password or with the per-role password (the \fBroleauth\fR keyword in \fBuser_attr\fR(5) controls that behavior on a per-role basis). Usually a role's login shell is one of the profile shells (see \fBpfsh\fR(1) for a list) that are granted one or more Profiles, allowing the role to always execute commands with privilege. .sp .LP A role is normally needed only if a shared account environment is required. Usually assigning profiles directly to the user is sufficient. .sp .LP The root user can be configured to be a role using the \fBusermod\fR(8) command. This ensures that only authorized users can become root even when the root password is more widely known. .sp .in +2 .nf # usermod -K type=role root .fi .in -2 .sp .sp .LP Making root a role does not restrict access to single user mode. The system console should be protected using other means, such as setting a security password with \fBeeprom\fR(8). .SS "Authorizations" .sp .LP An authorization is a unique string that represents a user's right to perform some operation or class of operations. Authorizations are normally only checked by programs that always run with some privilege, for example \fBsetuid\fR(2) programs such as \fBcdrw\fR(1) or the system \fBcron\fR(8) daemon. .sp .LP Authorization definitions are stored in the \fBauth_attr\fR(5) database. For programming authorization checks, only the authorization name is significant. .sp .LP Some typical values in an \fBauth_attr\fR database are as follows: .sp .in +2 .nf solaris.jobs.:::Cron and At Jobs::help=JobHeader.html solaris.jobs.grant:::Delegate Cron & At \e Administration::help=JobsGrant.html solaris.jobs.admin:::Manage All Jobs::help=AuthJobsAdmin.html solaris.jobs.user:::Cron & At User::help=JobsUser.html .fi .in -2 .sp .sp .LP Authorization name strings ending with the \fBgrant\fR suffix are special authorizations that give a user the ability to delegate authorizations with the same prefix and functional area to other users. .sp .LP All authorization names starting with \fBsolaris\fR are reserved for allocation by the operating system vendor. Developers and administrators may create their own top level namespace; use of a unique identifier such as the company name, DNS domain name, or application name is suggested. .SS "Authorization Checks" .sp .LP To check authorizations from C code, developers should use the \fBchkauthattr\fR(3C) library function, which verifies whether or not a user has a given authorization. .sp .LP Authorizations can be explicitly checked in shell scripts by checking the output of the \fBauths\fR(1) utility. For example, .sp .in +2 .nf 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 .fi .in -2 .sp .sp .LP Authorizations are also used by the Service Management Facility (SMF) to control which users can change the state of a service or reconfigure a service. See \fBsmf_security\fR(7) for more information. .SS "Comparison with sudo(8)" .sp .LP RBAC in Solaris provides a similar set of functionality to \fBsudo\fR(8) that is often provided with UNIX or UNIX-like systems, including Oracle Solaris. .sp .LP One of the most obvious differences between Solaris RBAC and \fBsudo\fR is the authentication model. In \fBsudo\fR, users reauthenticate as themselves. 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. .sp .LP Using the \fBNOPASSWD\fR functionality in \fBsudo\fR is similar to assigning the profile to the user and having the user execute the command using \fBpfexec\fR(1). For example, if \fBsudoers\fR(5) allows the user to run \fBkill\fR(1) as UID 0 but without authentication (\fBNOPASSWD\fR), the user would run: .sp .in +2 .nf $ \fBsudo kill -HUP 1235\fR .fi .in -2 .sp .sp .LP 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 \fBpfexec\fR as follows: .sp .in +2 .nf $ \fBpfexec kill -HUP 1235\fR .fi .in -2 .sp .sp .LP If the user has a profile shell (such as \fBpfsh\fR) as the login shell, then \fBkill\fR will always run with the additional privilege without the need of a "prefix". For example, .sp .in +2 .nf $ \fBkill -HUP 1235\fR .fi .in -2 .sp .sp .LP An RBAC role is similar in concept to the \fBUser_Alias\fR in \fBsudoers\fR(5), except that the role password rather than the user password is required. .sp .LP Execution profiles (\fBexec_attr\fR(5) entries) in RBAC are similar to the \fBCmnd_Alias\fR in \fBsudoers\fR. .sp .LP There is currently no equivalent of the \fBHost_Alias\fR \fBsudo\fR(8) functionality in Solaris RBAC. .SH SEE ALSO .sp .LP \fBauths\fR(1), \fBld.so.1\fR(1), \fBpfexec\fR(1), \fBpfsh\fR(1), \fBprofiles\fR(1), \fBroles\fR(1), \fBauth_attr\fR(5), \fBexec_attr\fR(5), \fBprof_attr\fR(5), \fBsudoers\fR(5), \fBuser_attr\fR(5), \fBpam_tty_tickets\fR(7), \fBsmf_security\fR(7), \fBsudo\fR(8) .SH HISTORY .sp .LP Support for authenticated profiles was added in Oracle Solaris 11.2.0. .sp .LP RBAC was added to Solaris in Solaris 8.