Skip Navigation Links | |
Exit Print View | |
![]() |
System Administration Guide: Security Services Oracle Solaris 10 8/11 Information Library |
1. Security Services (Overview)
Part II System, File, and Device Security
2. Managing Machine Security (Overview)
3. Controlling Access to Systems (Tasks)
4. Controlling Access to Devices (Tasks)
5. Using the Basic Audit Reporting Tool (Tasks)
6. Controlling Access to Files (Tasks)
7. Using the Automated Security Enhancement Tool (Tasks)
Part III Roles, Rights Profiles, and Privileges
8. Using Roles and Privileges (Overview)
9. Using Role-Based Access Control (Tasks)
10. Role-Based Access Control (Reference)
Primary Administrator Rights Profile
System Administrator Rights Profile
Printer Management Rights Profile
Basic Solaris User Rights Profile
Viewing the Contents of Rights Profiles
Authorization Naming and Delegation
Authorization Naming Conventions
Example of Authorization Granularity
Delegation Authority in Authorizations
Commands That Require Authorizations
Part IV Cryptographic Services
13. Oracle Solaris Cryptographic Framework (Overview)
14. Oracle Solaris Cryptographic Framework (Tasks)
15. Oracle Solaris Key Management Framework
Part V Authentication Services and Secure Communication
16. Using Authentication Services (Tasks)
19. Using Oracle Solaris Secure Shell (Tasks)
20. Oracle Solaris Secure Shell (Reference)
21. Introduction to the Kerberos Service
22. Planning for the Kerberos Service
23. Configuring the Kerberos Service (Tasks)
24. Kerberos Error Messages and Troubleshooting
25. Administering Kerberos Principals and Policies (Tasks)
26. Using Kerberos Applications (Tasks)
27. The Kerberos Service (Reference)
Part VII Oracle Solaris Auditing
28. Oracle Solaris Auditing (Overview)
29. Planning for Oracle Solaris Auditing
30. Managing Oracle Solaris Auditing (Tasks)
The following four databases store the data for the RBAC elements:
Extended user attributes database (user_attr) – Associates users and roles with authorizations, privileges, and rights profiles
Rights profile attributes database (prof_attr) – Defines rights profiles, lists the profiles' assigned authorizations, keywords, and identifies the associated help file
Authorization attributes database (auth_attr) – Defines authorizations and their attributes, and identifies the associated help file
Execution attributes database (exec_attr) – Identifies the commands with security attributes that are assigned to specific rights profiles
The policy.conf database contains authorizations,privileges, and rights profiles that are applied to all users. For more information, see policy.conf File.
Each RBAC database uses a key=value syntax for storing attributes. This method accommodates future expansion of the databases. The method also enables a system to continue to operate if the system encounters a keyword that is unknown to its policy. The key=value contents link the files. The following linked entries from the four databases illustrate how the RBAC databases work together.
Example 10-1 Showing RBAC Database Connections
In the following example, the user jdoe gets the capabilities of the File System Management rights profile through being assigned the role filemgr.
The user jdoe is assigned the role filemgr in the jdoe user entry in the user_attr database.
# user_attr - user definition jdoe::::type=normal;roles=filemgr
The role filemgr is assigned the rights profile File System Management in the role's entry in the user_attr database.
# user_attr - role definition filemgr::::profiles=File System Management;type=role
The user and the role are uniquely defined in the passwd and shadow files on the local system, or in equivalent databases in a distributed naming service.
The File System Management rights profile is defined in the prof_attr database. This database also assigns three sets of authorizations to the File System Management entry.
# prof_attr - rights profile definitions and assigned authorizations File System Management:::Manage, mount, share file systems: help=RtFileSysMngmnt.html; auths=solaris.admin.fsmgr.*,solaris.admin.diskmgr.*,solaris.admin.volmgr.*
The authorizations are defined in the auth_attr database.
# auth_attr - authorization definitions solaris.admin.fsmgr.:::Mounts and Shares::help=AuthFsmgrHeader.html solaris.admin.fsmgr.read:::View Mounts and Shares::help=AuthFsmgrRead.html solaris.admin.fsmgr.write:::Mount and Share Files::help=AuthFsmgrWrite.html
The File System Management rights profile is assigned commands with security attributes in the exec_attr database.
# exec_attr - rights profile names with secured commands File System Management:suser:cmd:::/usr/sbin/mount:uid=0 File System Management:suser:cmd:::/usr/sbin/dfshares:euid=0 … File System Management:solaris:cmd:::/usr/sbin/mount:privs=sys_mount …
The name service scope of the RBAC databases can apply to the local host only. The scope can also include all hosts that are served by a naming service such as NIS, NIS+, or LDAP. Which naming service has precedence is set for each of the databases in the /etc/nsswitch.conf file.
auth_attr entry – Sets the naming service precedence for the auth_attr database.
passwd entry – Sets the naming service precedence for the user_attr database.
prof_attr entry – Sets the naming service precedence for the prof_attr database. Also sets the naming service precedence for the exec_attr database.
For example, if a command with security attributes is assigned to a rights profile that exists in two naming services, only the entry in the first service is used.
The user_attr database contains user and role information that supplements the passwd and shadow databases. The user_attr database contains extended user attributes such as authorizations, rights profiles, privileges, and assigned roles. The fields in the user_attr database are separated by colons, as follows:
user:qualifier:res1:res2:attr
The fields have the following meanings:
The name of the user or role as specified in the passwd database.
These fields are reserved for future use.
An optional list of semicolon-separated (;) key-value pairs that describes the security attributes to be applied when the user runs commands. The four valid keys are type, auths, profiles, and roles.
The type keyword can be set to normal, if this account is for a normal user. The type is role if this account is for a role.
The auths keyword specifies a comma-separated list of authorization names that are chosen from names that are defined in the auth_attr database. Authorization names can include the asterisk (*) character as a wildcard. For example, solaris.device.* means all of the Oracle Solaris device authorizations.
The profiles keyword specifies an ordered, comma-separated list of rights profile names from the prof_attr database. The order of rights profiles works similarly to UNIX search paths. The first profile in the list that contains the command to be executed defines which (if any) security attributes are to be applied to the command.
The roles keyword specifies a comma-separated list of role names. Note that roles are defined in the same user_attr database. Roles are indicated by setting the type value to role. Roles cannot be assigned to other roles.
The following example demonstrates how the Operator role is defined in a typical user_attr database. The example shows how the role is assigned to user jdoe. Roles and users are differentiated by the type keyword.
% grep operator /etc/user_attr jdoe::::type=normal;roles=operator operator::::profiles=Operator;type=role
All authorizations are stored in the auth_attr database. Authorizations can be assigned to users, to roles, or to rights profiles. The preferred method is to place authorizations in a rights profile, to include the profile in a role's list of profiles, and then to assign the role to a user.
The fields in the auth_attr database are separated by colons, as follows:
authname:res1:res2:short_desc:long_desc:attr
The fields have the following meanings:
A unique character string that is used to identify the authorization in the format prefix.[suffix]. Authorizations for Oracle Solaris use solaris as a prefix. All other authorizations should use a prefix that begins with the reverse-order Internet domain name of the organization that creates the authorization (for example, com.xyzcompany). The suffix indicates what is being authorized, which is typically the functional area and operation.
When the authname consists of a prefix and functional area and ends with a period, the authname serves as a heading to be used by applications in their GUIs. A two-part authname is not an actual authorization. The authname of solaris.printmgr. is an example of a heading.
When authname ends with the word “grant,” the authname serves as a grant authorization. A grant authorization enables the user to delegate to other users authorizations with the same prefix and functional area. The authname of solaris.printmgr.grant is an example of a grant authorization. solaris.printmgr.grant gives the user the right to delegate to other users such authorizations as solaris.printmgr.admin and solaris.printmgr.nobanner.
Reserved for future use.
A short name for the authorization. This short name is suitable for display in user interfaces, such as in a scrolling list in a GUI.
A long description. This field identifies the purpose of the authorization, the applications in which the authorization is used, and the type of user who might use the authorization. The long description can be displayed in the help text of an application.
An optional list of semicolon-separated (;) key-value pairs that describe the attributes of an authorization. Zero or more keys can be specified.
The keyword help identifies a help file in HTML. Help files can be accessed from the index.html file in the /usr/lib/help/auths/locale/C directory.
The following example shows an auth_attr database with some typical values:
% 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
Note that solaris.admin.printer. is defined as a heading, because the authorization name ends in a dot (.). Headings are used by the GUIs to organize families of authorizations.
The prof_attr database stores the name, description, help file location, privileges, and authorizations that are assigned to rights profiles. The commands and security attributes that are assigned to rights profiles are stored in the exec_attr database. For more information, see exec_attr Database. The fields in the prof_attr database are separated by colons, as follows:
profname:res1:res2:desc:attr
The fields have the following meanings:
The name of the rights profile. Rights profile names are case-sensitive. This name is also used by the user_attr database to indicate the profiles that are assigned to roles and users.
Reserved for future use.
A long description. This field should explain the purpose of the rights profile, including what type of user would be interested in using the profile. The long description should be suitable for display in the help text of an application.
An optional list of key-value pairs that are separated by semicolons (;) that describes the security attributes to apply to the object on execution. Zero or more keys can be specified. The valid keys are help. profiles, and auths.
The keyword help identifies a help file in HTML. Help files can be accessed from the index.html file in the /usr/lib/help/profiles/locale/C directory.
The keyword profiles specifies a comma-separated list of rights profiles. These profiles are called supplementary rights profiles.
The keyword auths specifies a comma-separated list of authorization names that are chosen from those names that are defined in the auth_attr database. Authorization names can be specified with the asterisk (*) character as a wildcard.
The keyword privs specifies a comma-separated list of privileges. These privileges are in effect for all commands in a profile shell.
The following example shows two typical prof_attr database entries. Note that the Printer Management rights profile is a supplementary rights profile of the Operator rights profile. The example is wrapped for display purposes.
% grep 'Printer Management' /etc/security/prof_attr Printer Management::: Name of rights profile Manage printers, daemons, spooling: Description help=RtPrntAdmin.html; Help file auths=solaris.admin.printer.read, Authorizations solaris.admin.printer.modify,solaris.admin.printer.delete ... Operator::: Name of rights profile Can perform simple administrative tasks: Description profiles=Printer Management, Supplementary rights profiles Media Backup,All; help=RtOperator.html Help file
The exec_attr database defines commands that require security attributes to succeed. The commands are part of a rights profile. A command with its security attributes can be run by roles or users to whom the profile is assigned.
The fields in the exec_attr database are separated by colons, as follows:
name:policy:type:res1:res2:id:attr
The fields have the following meanings.
The name of the rights profile. Rights profile names are case-sensitive. The name refers to a profile in the prof_attr database.
The security policy that is associated with this entry. Currently, suser and solaris are the valid entries. The solaris policy recognizes privileges. The suser policy does not.
The type of entity that is specified. Currently, the only valid entity type is cmd (command).
Reserved for future use.
A string that identifies the entity. Commands should have the full path or a path with a wildcard (*). To specify arguments, write a script with the arguments and point the id to the script.
An optional list of semicolon (;) separated key-value pairs that describes the security attributes to apply to the entity on execution. Zero or more keys can be specified. The list of valid keywords depends on the policy that is enforced.
For the suser policy, the four valid keys are euid, uid, egid, and gid.
The euid and uid keywords contain a single user name or a numeric user ID (UID). Commands that are designated with euid run with the supplied UID, which is similar to setting the setuid bit on an executable file. Commands that are designated with uid run with both the real UID and the effective UID.
The egid and gid keywords contain a single group name or numeric group ID (GID). Commands that are designated with egid run with the supplied GID, which is similar to setting the setgid bit on an executable file. Commands that are designated with gid run with both the real GID and the effective GID.
For the solaris policy, the valid keyword is privs. The value consists of a list of privileges that are separated by commas.
The following example shows some typical values from an exec_attr database:
% grep 'File System Management' /etc/security/exec_attr File System Management:suser:cmd:::/usr/sbin/ff:euid=0 File System Management:solaris:cmd:::/usr/sbin/mount:privs=sys_mount …
The policy.conf file provides a way of granting specific rights profiles, specific authorizations, and specific privileges to all users. The relevant entries in the file consist of key=value pairs:
AUTHS_GRANTED=authorizations – Refers to one or more authorizations.
PROFS_GRANTED=rights profiles – Refers to one or more rights profiles.
The following example shows some typical values from a policy.conf database:
# grep AUTHS /etc/security/policy AUTHS_GRANTED=solaris.device.cdrw # grep PROFS /etc/security/policy PROFS_GRANTED=Basic Solaris User # grep PRIV /etc/security/policy #PRIV_DEFAULT=basic #PRIV_LIMIT=all
For more information about privileges, see Privileges (Overview).