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 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
How to Enable a User to Use Own Password to Assume a Role
How to Change the root Role Into a User
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)
Initial configuration of RBAC includes creating users who can assume specific roles, creating the roles, and assigning them to the appropriate users.
Use the following task map to plan and initially implement RBAC at your site. Some tasks are ordered.
|
RBAC can be an integral part of how an organization manages its information resources. Planning requires a thorough knowledge of the RBAC capabilities as well as the security requirements of your organization.
Note - Default rights are assigned in the /etc/security/policy.conf file.
Read Role-Based Access Control (Overview). Using RBAC to administer a system is very different from using conventional UNIX administrative practices. To be familiar with RBAC concepts before you start your implementation, see Chapter 10, Security Attributes in Oracle Solaris (Reference).
Your organization's security policy details the potential threats to your system, measures the risk of each threat, and provides strategies to counter these threats. Isolating the security-relevant tasks through RBAC can be a part of the strategy. Although you can use the installed RBAC configurations as is, you might need to customize it to adhere to your security policy.
Depending on your security needs, you can use varying degrees of RBAC, as follows:
Root as a role – This method is provided by default. It prevents any user from logging in as root. Instead, a user must log in by using their assigned login prior to assuming the root role.
Discrete roles – This method creates roles that are based on provided rights profiles. The roles can be assigned according to level of responsibility, scope of task, and type of task. For example, the System Administrator role can perform many tasks that superuser can perform, while the Network IPsec Management role can manage IPsec.
You can also separate security responsibilities from other responsibilities, The User Management role can create users, while the User Security role can assign security attributes, such as roles and rights profiles. However, the User Security role cannot create a user, and the User Management role cannot assign a rights profile to a user.
No root role – This method requires you to change the default configuration of the system. In this configuration, any user who knows the password for root can log in and modify the system. You cannot tell which user was acting as superuser.
Review the capabilities of the recommended roles and their default rights profiles. Default rights profiles enable administrators to configure a recommended role by using a single profile.
To further examine rights profiles, do one of the following:
For the available rights profiles on your system, use the getent prof_attr command.
In this guide, refer to Rights Profiles for summaries of some typical rights profiles.
Look for other applications or families of applications at your site that might benefit from restricted access. Applications that affect security, that can cause denial-of-service problems, or that require special administrator training are good candidates for RBAC. You can customize roles and rights profiles to handle the security requirements of your organization.
Check if an existing rights profile can handle this task or if a separate rights profile needs to be created.
Note - The Media Backup and Media Restore rights profiles provide access to the entire root file system. Therefore, these rights profiles are appropriately assigned to trusted users only. Alternatively, you can choose to not assign these rights profiles. By default, only the root role is trusted to back up and restore.
Decide if the rights profile for this task should be assigned to an existing role or if a new role should be created. If you use an existing role, check that the role's original rights profiles are appropriate for users who are assigned to this role. Order the new rights profile so that commands execute with their required privileges. For information about ordering, see Order of Search for Assigned Security Attributes.
According to the principle of least privilege, you assign users to roles that are appropriate to the user's level of trust. When you prevent users from performing tasks that the users do not need to perform, you reduce potential problems.
Roles can be created locally and in an LDAP repository.
Before You Begin
To create a role and assign its initial password, you must be assigned the User Management rights profile. To assign security attributes to the role, you must be assigned the User Security rights profile.
For more information, see How to Obtain Administrative Rights.
The RBAC arguments to the command are the following:
# roleadd [-e expire] [-f inactive] [-s shell] [-m] [-S repository] \ [-A authorization-list] -K key=value] rolename
Is the date that a role expires. Use this option to create temporary roles.
Is the maximum number of days that is allowed between uses of a role. When the inactive value is exceeded, the role cannot be used. The default value is 0, no expiration date.
Creates a home directory for rolename at the default location.
Is the login shell for rolename. This shell must be a profile shell. For a list of profile shells, see the pfexec(1) man page.
Tip - You can also list the profile shells from the /usr/bin directory on your system, as in ls /usr/bin/pf*sh.
Is one of files or ldap. The default is local files.
Is one or more authorizations separated by commas. For the list of authorizations, see the /etc/security/auth_attr file.
Is a key=value pair. This option can be repeated. The following keys are available: audit_flags, auths, profiles, project, defaultpriv, limitpriv, lock_after_retries, and roleauth. For information about the keys, their values, and the authorizations that are required to set the values, see the user_attr(4) man page.
Is the name of the new role. For restrictions on acceptable strings, see the roleadd(1M) man page.
Tip - When the name of the role reflects the name of a rights profile, you can easily understand the purpose of the role. For example, assign the Audit Review rights profile to the auditreview role to enable the role to read, filter, and archive audit records.
For example, the following command creates a local User Administrator role and a home directory:
# roleadd -c "User Administrator role, local" -s /usr/bin/pfbash \ -m -K profiles="User Security,User Management" useradm 80 blocks # ls /export/home/useradm local.cshrc local.login local.profile
# passwd -r files useradmPassword: <Type useradm password> Confirm Password: <Retype useradm password> #
Note - Typically, a role account is assigned to more than one user. Therefore, an administrator typically creates a role password and provides the users with the role password out of band.
For the procedure, see How to Assign a Role and Example 9-10.
Example 9-7 Creating a User Administrator Role in the LDAP Repository
In this example, the administrator's site uses an LDAP repository. By running the following command, the administrator creates a User Administrator role in LDAP.
# roleadd -c "User Administrator role, LDAP" -s /usr/bin/pfbash \ -m -S ldap -K profiles="User Security,User Management" useradm
Example 9-8 Creating Roles for Separation of Duty
In this example, the administrator's site uses an LDAP repository. By running the following commands, the administrator creates two roles. The usermgt role can create users, give them home directories, assign an initial password, and perform other non-security tasks. The usersec role cannot create users, but can change user passwords and change other RBAC properties.
# roleadd -c "User Management role, LDAP" -s /usr/bin/pfbash \ -m -S ldap -K profiles="User Management" usermgt # roleadd -c "User Security role, LDAP" -s /usr/bin/pfbash \ -m -S ldap -K profiles="User Security" usersec
Example 9-9 Creating a Device and File Security Role
In this example, the administrator creates a Device and File Security role for this system:
# roleadd -c "Device and File System Security admin, local" -s /usr/bin/pfbash \ -m -K profiles="Device Security,File System Security" devflsec
This procedure assigns a role to a user, restarts the name cache daemon, and then shows how the user can assume the role.
Before You Begin
You have added a role and assigned the role a password, as described in How to Create a Role.
To modify most security attributes of a user, you must be assigned the User Security rights profile. To modify a user's audit flags, you must be superuer. To modify other attributes, you must be assigned the User Management rights profile.
For more information, see How to Obtain Administrative Rights.
usermod [-S repository] [RBAC-arguments] login
For example, assign the role to a local user:
# usermod -R +useradm jdoe-local
For the options to the usermod command, see the usermod(1M) man page or the description in Step 2 in How to Create a Role.
# svcadm restart system/name-service-cache
Example 9-10 Creating and Assigning a Role to Administer Crypto
In this example, the administrator on an LDAP network creates a role to administer the Cryptographic Framework, and assigns the role to UID 1111. The administrator restarts the nscd daemon to put the assignment into effect.
# roleadd -c "Cryptographic Services manager" \ -g 14 -m -u 104 -s /usr/bin/pfksh \ -S ldap -K profiles="Crypto Management" cryptmgt # passwd cryptmgt New Password: <Type cryptmgt password> Confirm password: <Retype cryptmgt password> # usermod -u 1111 -R +cryptmgt # svcadm restart system/name-service-cache
The user with UID 1111 logs in, then assumes the role and displays the assigned security attributes.
% su - cryptmgt Password: <Type cryptmgt password> Confirm Password: <Retype cryptmgt password> $ profiles -l Crypto Management /usr/bin/kmfcfg euid=0 /usr/sbin/cryptoadm euid=0 /usr/sfw/bin/CA.pl euid=0 /usr/sfw/bin/openssl euid=0 $
For information about the Cryptographic Framework, see Chapter 11, Cryptographic Framework (Overview). To administer the framework, see Administering the Cryptographic Framework (Task Map).
The actions that a role performs can be audited. Included in the audit record is the login name of the user who assumed the role, the rolename, and the action that the role performed. The 116:AUE_PFEXEC:execve(2) with pfexec enabled:ps,ex,ua,as audit event captures role actions,. By preselecting one of the as, ex, ps, or ua classes, role actions are audited.
Before You Begin
To configure auditing, you must be assigned the Audit Configuration rights profile. To enable or refresh the audit service, you must be assigned the Audit Control rights profile.
For planning information, see Chapter 27, Planning for Auditing.
For more information, see How to Obtain Administrative Rights.
# auditconfig -getflags
If one of the as, ex, ps, or ua classes is preselected, role actions are being audited. If not, add one of these classes to the existing classes.
# auditconfig -setflags existing preselections,as
# auditconfig -setflags as
In this example, the administrator chooses the as class. This class includes other audit events. To view the audit events that are included in a class, use the auditrecord command, as shown in Example 28-25.
# audit -s
You can create or change a rights profile when the provided rights profiles do not contain the collection security attributes that you need. To learn more about rights profiles, see RBAC Rights Profiles.
The easiest way to create a new rights profile is to copy and modify an existing rights profile.
Before You Begin
To create or change a rights profile, you must be assigned the File Security rights profile.
For more information, see How to Obtain Administrative Rights.
# profiles [-S repository] existing-profile-name
You are prompted for a new name. The content of the existing rights profile is duplicated in the new profile.
Add or remove supplementary rights profiles, authorizations, and other security attributes, as shown in the following examples.
Example 9-11 Creating a New Rights Profile From an Existing Profile
In this example, the administrator customizes the Console User rights profile in the LDAP repository.
# profiles -S ldap Console User New name: ExampleCo Console User ExampleCo Console User > Description > Manage MyCompany Systems as the Console User Help > ExCoConsUser.html
The administrator sets the roleauth attribute for this rights profile.
roleauth=yes
Example 9-12 Removing a Basic Privilege From a Rights Profile
In the following example, after thorough testing, the security administrator removes a basic privilege from all users who are assigned the SunRayUser rights profile. They are prevented from using the proc_session privilege. That is, these users cannot examine any processes outside the user's current session.
$ profiles -K defaultpriv=basic,!proc_session SunRayUser
Example 9-13 Removing Privileges From the Limit Set of a Rights Profile
In the following example, after thorough testing, the security administrator removes a limit privilege from all users who are assigned the SunRayUser rights profile. This removal prevents these users from viewing other users' processes.
$ profiles -K limitpriv=all,!proc_session SunRayUser
Example 9-14 Adding Privileges to a Command
In this example, the security administrator adds privileges to an application in a rights profile. The application is privilege-aware.
# profiles -p SiteApp profiles:SiteApp> set desc="Site application" profiles:SiteApp> add cmd=/opt/site-app/bin/site-cmd profiles:SiteApp:site-cmd> add privs=proc_fork,proc_taskid profiles:SiteApp:site-cmd> end profiles:SiteApp> exit
To verify, the administrator selects the site-cmd.
# profiles -p SiteApp "select cmd=/opt/site-app/bin/site-cmd; info;end" Found profile in files repository. id=/opt/site-app/bin/site-cmd privs=proc_fork,proc_taskid
See Also
To troubleshoot security attribute assignment, see How to Troubleshoot RBAC and Privilege Assignment. For background, see Order of Search for Assigned Security Attributes.
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.
Before You Begin
To create the rights profile, you must be assigned the Information Security or Rights Management rights profile. To assign the rights profile, you must be assigned the User Security rights profile.
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.
For the steps, see How to Create or Change a Rights Profile.
For an example, see Example 9-14.
To assign a rights profile to a role, see Example 9-10.
Example 9-15 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.
Example 9-16 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 must include logic that checks for other authorizations that use wildcards. For example, to test if the user has the solaris.system.date authorization, you would need to check for the following strings:
solaris.system.date
solaris.system.*
solaris.*
If you are writing a program, use the function getauthattr() to test for the authorization.
Several factors can affect why a user or role's processes do not run with assigned security attributes.
The security attribute is misspelled. Misspelled authorizations fail silently.
The user or role is not using the naming service that includes the assignments.
The assignment that you expect is not the first assignment of that attribute.
The order in which a user or role's security attributes are searched for and then assigned at authentication determines which assignments are successful. The exception is authorizations. During search, authorizations that are assigned to the user or role accumulate. In contrast, privilege assignment, and the assignment of security attributes in rights profiles is search-dependent. First assignment wins, later assignments are ignored.
The command is not being run in a profile shell.
Before You Begin
You must be in the root role.
The nscd daemon can have a lengthy time-to-live interval. By restarting the daemon, you update the naming service with current data.
Use the security attribute as the value to the userattr -v command. For example, the following commands indicate which security attributes are assigned and where the assignment was made for the user jdoe:
# userattr -v audit_flags jdoe Modifications to the system defaults user_attr: fw:no # userattr -v auths jdoe Assigned authorizations solaris.admin.wusb.read,solaris.device.cdrw,solaris.device.mount.removable, solaris.mail.mailq,solaris.profmgr.read,solaris.smf.manage.audit, solaris.smf.value.audit # userattr -v audit_flags jdoe Modifications to audit preselection mask # userattr -v auths jdoe Assigned authorizations # userattr -v defaultpriv jdoe Modifications to basic user privileges # userattr -v limitpriv jdoe Modifications to limit privileges # userattr -v lock_after_retries jdoe Automatic lockout attribute # userattr -v profiles jdoe Assigned rights profiles user_attr: Audit Review,Stop # userattr roles jdoe Assigned roles user_attr : cryptomgt,infosec
For example, some commands require uid=0 rather than euid=0 to succeed. Aspects of some commands can require authorizations.
Use the userattr command.
The value of the attribute in the earliest rights profile in the list is the value that the user can use. If this value is incorrect, either change the value in that rights profile, or reorder the list of profiles.
For privileged commands, check if a privilege is assigned in the defaultpriv keyword. This assignment is in addition to privileges on a particular command.
If the attribute is assigned to a role, the user must assume the role to obtain the security attributes. If the attribute is assigned to more than one role, the assignment in the earliest role in the list is effective. If this value is incorrect, either assign the correct value to the first role in the list, or reorder the role assignment.
Note - Aspects of some commands can require authorization. Best practice is to assign a rights profile that includes the administrative command, rather than assign a privilege directly.
Review the rights profiles that include the administrative command. If a rights profile exists that includes authorizations, assign the rights profile to the user, not simply the privileges. Order the rights profile before any other rights profile that includes the command.
Administrative commands must be executed in a profile shell. To mitigate user error, you can assign a profile shell as the user's login shell. Or, you can remind the user to run administrative commands in a profile shell.
In particular, check the values of the user's defaultpriv and limitpriv attributes.
The earliest value in the list of rights profiles is the value that the user can use. If this value is incorrect, either change the value in that rights profile, or reorder the list of profiles.
In particular, check the values of the profile's defaultpriv and limitpriv attributes.
If the command is assigned to a role, the user must assume the role to obtain the security attributes. If the attribute is assigned to more than one role, the assignment in the earliest role in the list is effective. If this value is incorrect, either assign the correct value to the first role in the list, or reorder the role assignment.
Administrative commands require privileges to succeed. Aspects of some commands can require authorization. Best practice is to assign a rights profile that includes the administrative command.
In particular, check the values of the role's defaultprivand limitpriv attributes.
The earliest value in the list of rights profiles is the value that the user can use. If this value is incorrect, either change the value in that rights profile, or reorder the list of profiles.