Skip Navigation Links | |
Exit Print View | |
Oracle Solaris Administration: Security Services Oracle Solaris 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. Virus Scanning Service (Tasks)
5. Controlling Access to Devices (Tasks)
6. Using the Basic Audit Reporting Tool (Tasks)
7. Controlling Access to Files (Tasks)
Part III Roles, Rights Profiles, and Privileges
8. Using Roles and Privileges (Overview)
9. Using Role-Based Access Control (Tasks)
Viewing and Using RBAC Defaults (Tasks)
Viewing and Using RBAC Defaults (Task Map)
How to View All Defined Security Attributes
How to View Your Assigned Rights
How to Obtain Administrative Rights
Customizing RBAC for Your Site (Tasks)
Initially Configuring RBAC (Task Map)
How to Plan Your RBAC Implementation
How to Create or Change a Rights Profile
How to Add RBAC Properties to Legacy Applications
How to Troubleshoot RBAC and Privilege Assignment
How to Change the Password of a Role
How to Change the Security Attributes of a Role
How to Change the RBAC Properties of a User
How to Restrict a User to Desktop Applications
How to Restrict an Administrator to Explicitly Assigned Rights
Determining Your Privileges (Task Map)
How to List the Privileges on the System
How to Determine the Privileges That You Have Been Directly Assigned
How to Determine the Privileged Commands That You Can Run
Managing Privileges (Task Map)
How to Determine the Privileges on a Process
How to Determine Which Privileges a Program Requires
How to Run a Shell Script With Privileged Commands
10. Security Attributes in Oracle Solaris (Reference)
Part IV Cryptographic Services
11. Cryptographic Framework (Overview)
12. Cryptographic Framework (Tasks)
Part V Authentication Services and Secure Communication
14. Network Services Authentication (Tasks)
17. Using Secure Shell (Tasks)
19. Introduction to the Kerberos Service
20. Planning for the Kerberos Service
21. Configuring the Kerberos Service (Tasks)
22. Kerberos Error Messages and Troubleshooting
23. Administering Kerberos Principals and Policies (Tasks)
24. Using Kerberos Applications (Tasks)
25. The Kerberos Service (Reference)
After you have configured and are using RBAC, use the following procedures to maintain and modify RBAC on your systems.
The following task map points to procedures for maintaining role-based access control (RBAC) after RBAC has been initially implemented.
|
These procedures manage security attributes on users, roles, and rights profiles. For basic user management procedures, refer to Chapter 2, Managing User Accounts and Groups (Overview), in Oracle Solaris Administration: Common Tasks.
Before You Begin
You must be in the root role.
# passwd [-r naming-service] target-rolename
Applies the password change to the files or ldap repository. The default repository is files. If you do not specify a repository, the password is changed in all repositories.
Is the name of an existing role that you want to modify.
For more command options, see the passwd(1) man page.
Example 9-17 Changing a Role's Password
In this example, the root role changes the password of the local devmgt role.
# passwd -r files devmgt New password: Type new password Confirm password: Retype new password
In this example, the root role changes the password of the devmgt role in the LDAP directory service.
# passwd -r ldap devmgt New password: Type new password Confirm password: Retype new password
In this example, the root role changes the password of the devmgt role in file and LDAP.
# passwd devmgt New password: Type new password Confirm password: Retype new password
Before You Begin
You must be assigned the User Security rights profile to change the security attributes of a role, except for the role's password and audit flags. Role properties include rights profiles and authorizations. To assign audit flags or change a role's password, you must be in the root role.
For more information, see How to Obtain Administrative Rights.
This command modifies the attributes of a role that is defined in the local naming service or in LDAP. The values of the -A, -P, and -R options can be modified by - or ++. - indicates to subtract the value from the currently assigned values. ++ indicates to add the value to the currently assigned values.
For more information about the rolemod command, see the following:
For a short description, see the description of the roleadd command in How to Create a Role.
For all arguments to this command, see the rolemod(1M) man page.
For the list of key values for the -K option, see the user_attr(4) man page.
The following command replaces the devmgt role's assigned rights profiles in the LDAP repository:
$ rolemod -P "Device Management,File Management" -S ldap devadmin
Example 9-18 Changing a Local Role's Security Attributes
In this example, the security administrator modifies the prtmgt role to include the VSCAN Management rights profile.
$ rolemod -c "Handles printers and virus scanning" \ -P "Printer Management,VSCAN Management,All" prtmgt
These rights profiles are added to the profiles that are granted through the policy.conf file.
Example 9-19 Assigning Privileges Directly to a Role
In this example, the security administrator entrusts the systime role with a very specific privilege that affects system time.
$ rolemod -K priv=proc_clock_highres systime
The values for the priv keyword are in the list of privileges in the role's processes at all times.
User properties include login shell, rights profiles, and roles. 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.
Before You Begin
You must be assigned the User Security rights profile to change the security attributes of a user, except for the user's password and audit flags. To assign audit flags or change a role's password, you must be in the root role. To change other user attributes, you must be assigned the User Management rights profile.
For more information, see How to Obtain Administrative Rights.
This command modifies the attributes of a user that is defined in the local naming service or the LDAP naming service. The RBAC arguments to this command are similar to the arguments to the useradd command, as described on the user_attr(4) man page, and shown in Example 9-23.
In the following example, an LDAP user is assigned the devmgt role. This role replaces any prior role assignments. The devmgt role must exist in the LDAP naming service.
$ usermod -R devmgt -S ldap jdoe-ldap
In the following example, this role is added to any prior role assignments.
$ usermod -R +devmgt -S ldap jdoe-ldap
Example 9-20 Assigning a Role to a Local User
In this example, the user jdoe can now assume the role of System Administrator, sysadmin.
$ userattr roles jdoe secdevice $ usermod -R secdevice,sysadmin jdoe $ userattr roles jdoe secdevice,sysadmin
Example 9-21 Removing Privileges From a User's Limit Set
In the following example, all sessions that originate from jdoe's initial login are prevented from using the sys_linkdir privilege. That is, the user cannot make hard links to directories, nor can the user unlink directories, even after the user runs the su command.
$ usermod -K limitpriv=all,!sys_linkdir jdoe $ userattr limitpriv jdoe all,!sys_linkdir
Example 9-22 Creating a User Who Can Manage DHCP
In this example, the security administrator creates a user in LDAP. At login, the jdoe-dhcp user is able to manage DHCP.
# useradd -P "DHCP Management" -s /usr/bin/pfbash -S ldap jdoe-dhcp
Because the user is assigned pfbash as the login shell, the security attributes in the DHCP Management rights profile are available to the user in the user's default shell.
Example 9-23 Assigning Authorizations Directly to a User
In this example, the security administrator creates a local user who can control screen brightness.
# useradd -c "Screened JDoe, local" -s /usr/bin/pfbash \ -A solaris.system.power.brightness jdoe-scr
This authorization is added to the user's existing authorization assignments.
Example 9-24 Assigning Privileges Directly to a User
In this example, the security administrator trusts the user jdoe with a very specific privilege that affects system time.
$ usermod -K defaultpriv=basic,proc_clock_highres jdoe
The values for the defaultpriv keyword replace the existing values. Therefore, for the user to retain the basic privileges, the value basic is specified. In the default configuration, all users have basic privileges.
You can restrict an Oracle Solaris user to desktop access only.
Before You Begin
You must be in the root role.
For example, you could assign the pfbash shell to the user.
# usermod -s /usr/bin/pfbash username
All user processes are now under the control of RBAC.
The following command creates the rights profile. The end command indicates that the added command does not require security attributes. To create the rights profile in your LDAP repository, use the -S ldap option.
# profiles -p "Desktop Applets" profiles:Desktop Applets> set desc="Can use basic desktop applications" profiles:Desktop Applets> add cmd=/usr/bin/nautilus;end profiles:Desktop Applets> add cmd=/usr/bin/dbus-launch;end profiles:Desktop Applets> add cmd=/usr/lib/dbus-daemon;end profiles:Desktop Applets> add cmd=/usr/lib/clock-applet;end profiles:Desktop Applets> add cmd=/usr/lib/gconfd-2;end profiles:Desktop Applets> add cmd=/usr/lib/gvfsd;end profiles:Desktop Applets> add cmd=/usr/lib/gvfsd-metadata;end profiles:Desktop Applets> add cmd=/usr/lib/gvfsd-trash;end profiles:Desktop Applets> add cmd=/usr/lib/gvfs-hal-volume-monitor;end profiles:Desktop Applets> add cmd=/usr/lib/gnome-pty-helper;end profiles:Desktop Applets> add cmd=/usr/lib/utmp_update;end profiles:Desktop Applets> add cmd=/usr/bin/sh;end profiles:Desktop Applets> add cmd=/usr/bin/bash;end profiles:Desktop Applets> add cmd=/usr/bin/csh;end profiles:Desktop Applets> add cmd=/usr/bin/ksh;end profiles:Desktop Applets> commit profiles:Desktop Applets> exit
Review the entries for errors, such as typos, omissions, or repetition.
# profiles -p "Desktop Applets" info Found profile in files repository. name=Desktop Applets desc=Can use basic desktop applications cmd=/usr/bin/nautilus cmd=/usr/bin/dbus-launch cmd=/usr/lib/dbus-daemon cmd=/usr/lib/clock-applet cmd=/usr/lib/gconfd-2 cmd=/usr/lib/gvfsd cmd=/usr/lib/gvfsd-metadata cmd=/usr/lib/gvfsd-trash cmd=/usr/lib/gvfs-hal-volume-monitor cmd=/usr/lib/gnome-pty-helper cmd=/usr/lib/utmp_update cmd=/usr/bin/sh cmd=/usr/bin/bash cmd=/usr/bin/csh cmd=/usr/bin/ksh
Tip - You can create a rights profile for an application or a class of applications that have desktop icons. Then, add Desktop Applets as a supplementary rights profile to this new rights profile. Together, these rights profiles enable the user to use the appropriate desktop applications.
# usermod -P "Desktop Applets,Stop" username
This user does not have the Basic Solaris User rights profile or the Console User rights profile. Therefore, no commands other than the commands in the Desktop Applets rights profile can be run by this user. For example, the user does not have access to a terminal window.
For more information, see Rights Profiles, Order of Search for Assigned Security Attributes, and How to Limit a User to Desktop Applications in Trusted Extensions Configuration and Administration.
The usermod command modifies the user attributes that are defined in the local naming service or in LDAP. For arguments to this command, see the usermod(1M) man page.
You can restrict a role or user to a limited number of administrative actions in two ways.
You can use the Stop rights profile.
The Stop rights profile is the simplest way to create a restricted shell. The authorizations and rights profiles that are assigned in the policy.conf file are not consulted. In the default configuration, the role or user is not assigned the Basic Solaris User rights profile, the Console User rights profile, or the solaris.device.cdrw authorization.
You can modify the policy.conf file on a system, and require the role or user to use that system for administrative tasks.
Before You Begin
You must be in the root role.
For example, you could limit the auditrev role to performing only audit reviews.
# rolemod -P "Audit Review,Stop" auditrev
Because the auditrev role does not have the Console User rights profile, the auditor cannot shut down the system. Because this role does not have the solaris.device.cdrw authorization, the auditor cannot read from or write to the CD-ROM drive. Because this role does not have the Basic Solaris User rights profile, no commands other than the commands in the Audit Review rights profile can be run in this role. For example, the ls command will not run. The role uses the File Browser to view the audit files.
For more information, see Rights Profiles and Order of Search for Assigned Security Attributes.
The rolemod command modifies the attributes of a role that is defined in the local naming service or in LDAP. For arguments to this command, see the rolemod(1M) man page. The list of RBAC arguments is similar to the list for the roleadd command, as described in How to Create a Role
Example 9-25 Modifying a System to Limit the Rights Available to Its Users
In this example, the administrator creates a system that is useful only to administer the network. The administrator removes the Basic Solaris User rights profile and the solaris.device.cdrw authorization from the policy.conf file. The Console User rights profile is not removed. The affected lines in the resulting policy.conf file are the following:
... #AUTHS_GRANTED=solaris.device.cdrw #PROFS_GRANTED=Basic Solaris User CONSOLE_USER=Console User ...
Only a user who has been explicitly assigned authorizations, commands, or rights profiles is able to use this system. After login, the authorized user can perform administrative duties. If the authorized user is sitting at the system, the user has the rights of the Console User.
By default, users must type the role's password to assume a role. Perform this procedure to make assuming a role in Oracle Solaris similar to assuming a role in a Linux environment.
Before You Begin
You must have assumed a role that includes the User Security rights profile. This role cannot be the role whose roleauth value you want to change.
$ rolemod -K roleauth=user rolename
To assume this role, the assigned users can now use their own password, not the password that was created specifically for the role.
Example 9-26 Enabling a Role to Use the Assigned User's Password When Using a Rights Profile
In this example, the root role changes the value of roleauth for the role secadmin on the local system.
# profiles -K roleauth=user "System Administrator"
When a user who is assigned the Security Administrator rights profile wants to assume the role, the user is prompted for a password. In the following sequence, the role name is secadmin:
% su - secadmin Password: Type user password $ /** You are now in a profile shell with administrative rights**/
If the user has been assigned other roles, they use their own password to authenticate to those roles, too.
Example 9-27 Changing the Value of roleauth for a Role in the LDAP Repository
In this example, the root role enables all users who can assume the role secadmin to use their own password when assuming a role. This capability is granted to these users for all systems that are managed by the LDAP server.
# rolemod -S ldap -K roleauth=user secadmin # profiles -S ldap -K roleauth=user "Security Administrator"
Troubleshooting
If roleauth=user is set for the role, the user password enables the authenticated role to access all rights that are assigned to that role. This keyword is search-dependent. For more information, see Order of Search for Assigned Security Attributes.
An administrator might change root to a user when decommissioning a system that has been removed from the network. In this instance, logging in to the system as root simplifies the cleanup.
Before You Begin
You must become an administrator who is assigned the User Management and User Security rights profiles.
For example, remove the role assignment from two users.
% su - root Password: a!2@3#4$5%6^7 # roles jdoe root # roles kdoe root # roles ldoe secadmin # usermod -R "" jdoe # usermod -R "" kdoe #
# rolemod -K type=normal root
Users who are currently in the root role remain so, Other users who have root access can su to root or log in to the system as the root user.
You can use one of the following commands.
# getent user_attr root root::::auths=solaris.*;profiles=All;audit_flags=lo\:no;lock_after_retries=no; min_label=admin_low;clearance=admin_high
If the type keyword is missing in the output or is equal to normal, the account is not a role.
# userattr type root
If the output is empty or lists normal, the account is not a role.
Example 9-28 Preventing the root Role From Being Used to Configure a System
In this example, site security policy requires that the root account be prevented from maintaining the system. The administrator has created and tested the roles which maintain the system. These roles include every security profile and the System Administrator rights profile. A trusted user has been assigned a role that can restore a backup. No role can change the audit flags for the system, a user, or a rights profile.
To prevent the root account from being used to maintain the system, the security administrator removes the root role assignment. Because the root account must be able to log in to the system in single-user mode, the account retains a password.
# rolemod -K roles= jdoe # userattr roles jdoe
Example 9-29 Changing the root User Into the root Role
In this example, the root user turns the root user back into a role.
First, root changes the root account into a role and verifies the change.
# rolemod -K type=role root # getent user_attr root root::::type=role;auths=solaris.*;profiles=All;audit_flags=lo\:no; lock_after_retries=no;min_label=admin_low;clearance=admin_high
Then, root assigns the root role to a local user.
# usermod -R root jdoe
Troubleshooting
In a desktop environment, you cannot directly log in as root when root is a role. A diagnostic message indicates that root is a role on your system.
If you do not have a local account that can assume the root role, create one. As root, log in to the system in single-user mode, create a local user account and password, and assign the root role to the new account. Then, log in as the new user and assume the root role.