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)
How to Plan Your RBAC Implementation
How to Create and Assign a Role by Using the GUI
How to Create a Role From the Command Line
How to Assign a Role to a Local User
How to Make root User Into a Role
How to Assume a Role in a Terminal Window
How to Assume a Role in the Solaris Management Console
How to Change the Password of a Role
How to Change the Properties of a Role
How to Create or Change a Rights Profile
10. Role-Based Access Control (Reference)
Part IV Oracle Solaris 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 Solaris Secure Shell (Tasks)
20. 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 Solaris Auditing (Tasks)
The Solaris Management Console GUI is the preferred method for managing RBAC.
Note - Do not attempt to administer RBAC with the command line and the graphical user interface at the same time. Conflicting changes could be made to the configuration, and the behavior would be unpredictable. Both tools can administer RBAC, but you cannot use both tools concurrently.
You must have assumed a role that includes the User Security profile or have switched to superuser. You cannot be in the role whose password you want to change. A role cannot change its own password.
$ passwd -r naming-service target-rolename
Applies the password change to one of the following repositories files, nis, nisplus, or ldap. If a repository is not specified, the password is changed in files.
Is the name of an existing role that you want to modify.
For more command options, see the passwd(1) man page.
To start the console, see How to Assume a Role in the Solaris Management Console.
The login role cannot be the target role.
The Files scope modifies the role password on the local system. The LDAP scope modifies the role password in the LDAP naming service.
For more extensive information, see the online help.
This command runs as a client of the Solaris Management Console server.
$ /usr/sadm/bin/smrole -D domain-name -r admin-role -l <Type admin-role password> \ modify -- -n target-rolename -P password
Is the name of the domain that you want to manage.
Is the name of the administrative role that can modify the target role. The administrative role must have the solaris.admin.usermgr.pswd authorization. The administrative role and the target role cannot be the same role.
Is the prompt for the password of admin-role.
Is the required separator between authentication options and subcommand options.
Is the name of the target role.
Is the new password for target-rolename.
For the full list of command options, see the smrole(1M) man page.
Example 9-13 Changing a Local Role's Password With the passwd Command
In this example, superuser changes the password of the local operadm role.
# passwd -r files operadm New password: Type new password Re-enter new password: Retype new password
Example 9-14 Changing a Role's Password in an LDAP Repository
In this example, the Primary Administrator role changes the password of the operadm role in the LDAP directory service.
$ passwd -r ldap operadm New password: Type new password Re-enter new password: Retype new password
Example 9-15 Changing a Role's Password With the smrole modify Command
In this example, the administrator contacts the Solaris Management Console server to change the operadm password in the NIS domain. When the administrator does not provide the password before pressing the Return key, the New Password: prompt appears.
$ /usr/sadm/bin/smrole -D nis:/examplehost/example.domain \ -r primaryadm -l <Type primaryadm password> \ modify -- -n operadm -P Press the Return key New Password: a!2@3#4$5%6*7 $
You must either assume a role that includes the Primary Administrator rights profile, or switch to the user root to change the properties of a role. Role properties include password, rights profiles, and authorizations.
To start the console, see How to Assume a Role in the Solaris Management Console. Follow the instructions in the left-hand pane to modify a role in Administrative Roles. For more extensive information, see the online help.
This command modifies the attributes of a role that is defined in the local name service.
$ rolemod -c comment -P profile-list rolename
Is the new comment that describes the capabilities of the role.
Is the list of the profiles that are included in the role. This list replaces the current list of profiles.
Is the name of an existing, local role that you want to modify.
For more command options, see the rolemod(1M) man page.
This command modifies the attributes of a role in a distributed name service, such as NIS, NIS+, or LDAP. This command runs as a client of the Solaris Management Console server.
$ /usr/sadm/bin/smrole -D domain-name \ -r admin-role -l <Type admin-role password> \ modify -- -n rolename -r username -u username
Is the name of the domain that you want to manage.
Is the name of the administrative role that can modify the role. The administrative role must have the solaris.role.assign authorization. If you are modifying a role that you have assumed, the role must have the solaris.role.delegate authorization.
Is the prompt for the password of admin-role.
Is the required separator between authentication options and subcommand options.
Is the name of the new role.
Is the name of the user who can no longer assume rolename.
Is the name of the user who can now assume rolename.
For more command options, see the smrole(1M) man page.
Example 9-16 Changing a Local Role's Properties With the rolemod Command
In this example, the operadm role is modified to include the Media Restore rights profile.
$ rolemod -c "Handles printers, backup, AND restore" \ -P "Printer Management,Media Backup,Media Restore,All" operadm
These rights profiles are added to the profiles that are granted through the policy.conf file.
Example 9-17 Changing a Local Role's Properties With the smrole modify Command
In the following example, the operadm role is modified to add the Media Restore rights profile.
$ /usr/sadm/bin/smrole -r primaryadm -l <Type primaryadm password> \ modify -- -n operadm -c "Handles printers, backup, AND restore" \ -p "Media Restore"
Example 9-18 Changing a Role in a Domain With the smrole modify Command
In the following example, the clockmgr role is changed. The NIS user whose ID is 108 can no longer assume the role. The NIS user whose ID is 110 can assume the role clockmgr.
$ /usr/sadm/bin/smrole -D nis:/examplehost/example.domain \ -r primaryadm -l <Type primaryadm password> \ modify -- -n clockmgr -r 108 -u 110
A rights profile is a property of a role. You should create or change a rights profile when the prof_attr database does not contain a rights profile that fulfills your needs. To learn more about rights profiles, see RBAC Rights Profiles.
To create or change a rights profile, you must have assumed the role of Primary Administrator or have switched to superuser.
To start the console, see How to Assume a Role in the Solaris Management Console. Follow the instructions in the left-hand pane to create or change a rights profile in Rights. For more extensive information, see the online help.
This command enables you to add, modify, list, or delete a rights profile. The command works on files, and in a distributed name service, such as NIS, NIS+, or LDAP. The smprofile command runs as a client of the Solaris Management Console server.
$ /usr/sadm/bin/smprofile -D domain-name \ -r admin-role -l <Type admin-role password> \ add | modify -- -n profile-name \ -d description -m help-file -p supplementary-profile
Is the name of the domain that you want to manage.
Is the name of the administrative role that can modify the role. The administrative role must have the solaris.role.assign authorization. If you are modifying a role that you have assumed, the role must have the solaris.role.delegate authorization.
Is the prompt for the password of admin-role.
Is the required separator between authentication options and subcommand options.
Is the name of the new profile.
Is a short description of the profile.
Is the name of the HTML help file that you have created and placed in the /usr/lib/help/profiles/locale/C directory.
Is the name of an existing rights profile that is included in this rights profile. You can specify multiple -p supplementary-profile options.
For more command options, see the smprofile(1M) man page.
Example 9-19 Modifying a Rights Profile From the Command Line
In the following example, the Network Management rights profile is made a supplementary profile of the Network Security rights profile. The role that contains the Network Security profile can now configure the network and hosts, as well has run security-relevant commands.
$ /usr/sadm/bin/smprofile -D nisplus:/example.host/example.domain \ -r primaryadm -l <Type primaryadm password> \ modify -- -n "Network Security" \ -d "Manage network and host configuration and security" \ -m RtNetConfSec.html -p "Network Management"
The administrator created a new help file, RtNetConfSec.html, and placed it in the /usr/lib/help/profiles/locale/C directory, before running this command.
Example 9-20 Creating a New Rights Profile With the Rights Tool
The following table shows sample data for a hypothetical rights profile that is called “Build Administrator”. This rights profile includes the commands in the subdirectory /usr/local/swctrl/bin. These commands have an effective UID of 0. The Build Administrator rights profile would be useful for administrators who manage the builds and versioning for software development.
|
Check the following if the rights profile does not provide the role with the capabilities that you expect:
Are the rights profiles for the role listed in the GUI from most to least powerful?
For example, if the All rights profile is at the top of the list, then no commands are run with security attributes. A profile that contains commands with security attributes must precede the All rights profile in the list.
Is a command listed more than once in the role's rights profiles? If so, does the first instance of the command have all the security attributes that are required?
For example, a command can require privileges for particular options to the command. For the options that require privileges to succeed, the first instance of the command in the highest rights profile in the list must have the assigned privileges.
Do the commands in the role's rights profiles have the appropriate security attributes?
For example, when the policy is suser, some commands require uid=0 rather than euid=0 to succeed.
Has the name service cache, svc:/system/name-service-cache, been restarted?
The nscd daemon can have a lengthy time-to-live interval. By restarting the daemon, you update the name service with current data.
User properties include password, rights profiles, roles, and authorizations. The most secure method of giving a user administrative capabilities is to assign a role to the user. For a discussion, see Security Considerations When Directly Assigning Security Attributes.
You must either assume a role that includes the Primary Administrator rights profile, or switch to the user root.
To start the console, see How to Assume a Role in the Solaris Management Console. Follow the instructions in the left-hand pane to modify a user in User Accounts. For more extensive information, see the online help.
Tip - It is not good practice to assign authorizations, privileges, or rights profiles directly to users. The preferred approach is to assign a role to users. Users then assume a role to perform privileged operations.
This command modifies the attributes of a user that is defined in the local name service.
$ usermod -R rolename username
Is the name of an existing local role.
Is the name of an existing, local user that you want to modify.
For more command options, see the usermod(1M) man page.
This command modifies the attributes of a user in a distributed name service, such as NIS, NIS+, or LDAP. This command runs as a client of the Solaris Management Console server.
$ /usr/sadm/bin/smuser -D domain-name \ -r admin-role -l <Type admin-role password> \ modify -- -n username -a rolename
Is the name of the domain that you want to manage.
Is the name of the administrative role that can modify the role. The administrative role must have the solaris.role.assign authorization. If you are modifying a role that you have assumed, the role must have the solaris.role.delegate authorization.
Is the prompt for the password of admin-role.
Is the required separator between authentication options and subcommand options.
Is the name of the user who is being assigned rolename.
Is the name of the role that you are assigning to username. You can specify multiple -a rolenameoptions.
For more command options, see the smuser(1M) man page.
Example 9-21 Modifying a Local User's RBAC Properties From the Command Line
In this example, the user jdoe can now assume the role of System Administrator.
$ usermod -R sysadmin jdoe
This role is added the roles that the user can assume.
Example 9-22 Modifying a User's RBAC Properties With the smuser Command
In this example, the user jdoe is assigned two roles, System Administrator and Operator. Because the user and the roles are defined locally, the -D option is not necessary.
$ /usr/sadm/bin/smuser -r primaryadm -l <Type primaryadm password> \ modify -- -n jdoe -a sysadmin -a operadm
In the following example, the user is defined in the NIS name service. Therefore, the -D option is required. Two roles are defined in the name service. One role, root, is defined locally.
$ /usr/sadm/bin/smuser -D nis:/examplehost/example.domain \ -r primaryadm -l <Type primaryadm password> \ modify -- -n jdoe -a sysadmin -a operadm -a root
A legacy application is a command or set of commands. The security attributes are set for each command in a rights profile. The rights profile is then included in a role. A user who assumes the role can run the legacy application with the security attributes.
To add legacy applications to the Solaris Management Console, see Adding Tools to the Solaris Management Console in System Administration Guide: Basic Administration.
You must have assumed the role of Primary Administrator or have switched to superuser to change the security attributes of a command in a rights profile.
To start the console, see How to Assume a Role in the Solaris Management Console. Follow the instructions in the left-hand pane to modify a rights profile in Rights. For more extensive information, see the online help.
You add security attributes to a legacy application in the same way that you would for any command. You must add the command with security attributes to a rights profile. For a legacy command, give the command euid=0 or uid=0 security attributes. For details of the procedure, see How to Create or Change a Rights Profile.
To add a rights profile to a role, see How to Change the Properties of a Role.
Example 9-23 Adding Security Attributes to Commands in a Script
If a command in a script needs to have the setuid bit or setgid bit set to succeed, the script executable and the command must have the security attributes added in a rights profile. Then, the rights profile is included in a role, and the role is assigned to a user. When the user assumes the role and executes the script, the command runs with the security attributes.
To add security attributes to a command or shell script, see How to Create or Change a Rights Profile.
Example 9-24 Checking for Authorizations in a Script or Program
To have a script for authorizations, you need to add a test that is based on the auths command. For detailed information about this command, see the auths(1) man page.
For example, the following line tests if the user has the authorization that is supplied as the $1 argument:
if [ `/usr/bin/auths|/usr/xpg4/bin/grep $1` ]; then echo Auth granted else echo Auth denied fi
To be more complete, the test should include logic that checks for other authorizations that use wildcards. For example, to test if the user has the solaris.admin.usermgr.write authorization, you would need to check for the following strings:
solaris.admin.usermgr.write
solaris.admin.usermgr.*
solaris.admin.*
solaris.*
If you are writing a program, use the function getauthattr() to test for the authorization.