|
|
Creating profiles and assigning roles are not excessively difficult using the Solaris Management Console (see Figure 9-1). In this section, we'll talk about the tasks involved with configuring RBAC. However, before we begin, let's examine some important planning functions that should take place before implementing RBAC:
Check company policy. Your company's security policy should outline threats, risks, and remediation. Be sure to plan profiles and roles that adhere to your policy.
Determine RBAC roles. Decide what levels of RBAC and which rights profiles and roles your company needs.
Determine which users should be assigned to roles. Follow the principle of least privilege and assign roles to users with the level of permissions required to do their jobs.
Although you can manage rights and roles directly from the command line, we'll focus on using the console. Creating custom rights and editing current rights is easy with the Solaris Management Console. To start the console, simply type the following command at a terminal prompt
/usr/sbin/smc &
or right-click the desktop and choose Tools/Solaris Management Console from the drop-down Workspace menu. Then click the current system from the Navigation menu, and click System Configuration. Next, click Users and then log in with an appropriate administrative or root account.
From the console, click Rights to enter the Solaris Management Console Users Rights interface, shown in Figure 9-2. This tool is used for managing rights. A right is a named collection consisting of commands, authorizations to use specific applications (or to perform specific functions within an application), and other previously created rights, whose use can be granted or denied to an administrator.
In the Uses Rights interface, you should see a collection of default rights created during the installation or upgrade of Solaris. You can click to select a particular right for modification. Otherwise, to create a right, select Add Right from the Action menu. This will invoke the Add Right interface shown in Figure 9-3.
A few configurable tabs appear in the Add Right interface:
General tab Add or view the right's name and description.
Commands tab Add commands to this right (by placing them in the Commands Permitted column), or remove them. When a user or role enters a command in an administrator's shell, the command can be executed only if it is included in a right assigned to the user or role. (The user must have been given an administrator's shell—through the User Properties dialog box—or must type pfsh, pfcsh, or pfksh on the command line of one of the normal user shells.) To add or remove individual commands or directories of commands, select the command or directory and click Add or Remove. Click Add All or Remove All to move all commands from one column to the other.
Authorizations tab Used to view or modify authorizations. An authorization permits the use of a specific application or specific functions within an application. The authorizations added to this right (by being placed in the Authorizations Included column) will be granted when this right is granted to users or to roles. Click an authorization to display information about it. To add or remove individual authorizations, select the authorization and click Add or Remove. Click Add All or Remove All to move all authorizations from one column to the other.
Supplementary Rights tab Used to include or exclude supplementary rights, which are existing, previously created rights that you can add to this right—they make it easier to create a new right by allowing you to add commands and authorizations without adding the individual items.
When you're through creating or modifying a right, click OK on the bottom of the Solaris Management Console Add Right interface.
| Exam Watch |
For the exam, be sure to understand what a right is. Sun's definition states that a right is a named collection that consists of commands, authorizations, and other previously created rights whose use can be granted or denied to an administrator. |
Creating roles using the console GUI is just as easy as creating rights. By default, no roles should be on the system. Assuming you've already created users that will assume any roles you create, and you have administrator access, you can start the console and click the Administrative Roles icon. Select Add Administrative Role from the Action menu option shown in Figure 9-4. (Incidentally, the roleadd command can be used to create roles and associates a role with an authorization or a profile as well.)
Sun's official definition of a role is a special user account used to grant rights. Users can assume only those roles they have been granted permission to assume. Once a user takes on a role, the user relinquishes his or her own user identity and takes on the properties, including the rights, of that role.
You'll see a few dialog boxes with which to create a new role in the new role wizard. Follow these steps from Sun to create a new role:
Step 1. Enter a role name. The role name is the name an administrator uses to log in to a specific role. Each role name must
Be unique within a domain
Contain 2 to 32 letters, numerals, underscores (_), hyphens (-), and periods (.)
Begin with a letter
Have at least one lowercase letter
Not contain spaces
If you later change a role name in a Role Properties dialog box, the name of the mailing list associated with this role is automatically changed as well.
Step 2. Enter the role password. Enter the password for this role. A password must consist of a combination of 6 to 15 case-sensitive letters, numbers, and special characters (only the first 8 characters are used, but 15 are available for users who want longer passwords). Within the first 6 characters, at least 2 must be alphabetic and at least 1 must be a number or special character. Inform each user entitled to assume this role of this password and of the need to use it when assuming the role. Click Next to continue.
Step 3. Assign role rights. Assign rights to this role by choosing from the list of Available Rights and adding them to the list of Granted Rights. Click each right for additional information about that right. Click Next to continue.
Step 4. Enter the home directory. Enter the home directory server where this role's private files will be stored. Click Next to continue.
Step 5. Assign users. Add the user names of users who will be permitted to assume this role. After you have finished adding this role, you can always assign additional users. The most direct method is to choose Action | Assign Administrative Role (in the Administrative Roles tool), and use the dialog box that opens. Or use a Role Properties dialog box or a User Properties dialog box. Incidentally, the usermod command associates a user's login with a role, profile, and authorization in the /etc/user_attr database, which can also be used to grant a user access to a role. Click Next to continue.
| Exam Watch |
For the exam, you should know how to issue the usermod command. From the command line, the command associates a user's login with a role, profile, and authorization in the /etc/user_attr database, which can also be used to grant a user access to a role. |
Step 6. Click Finish and verify role assignment. When you're through with the five steps in the new role wizard, click Finish. To verify a role assignment, go to the User Accounts interface within the console and click to open any user name to which you assigned a role. From the User Properties window, click the Roles tab to verify assigned roles (see Figure 9-5).
Following are three examples that Sun provides as templates for creating roles for administrator, operator, and security-related rights profiles:
Creating a Role for the System Administrator Rights Profile In this example, the new role can perform system administration tasks that are not connected to security. The role is created by performing the preceding procedure with the following parameters:
Role name: sysadmin
Role full name: System Administrator
Role description: Performs nonsecurity administration tasks
Rights profile: System Administrator
This rights profile is at the top of the list of profiles that are included in the role.
Creating a Role for the Operator Rights Profile The Operator rights profile can manage printers and back up the system to offline media. You might want to assign the role to one user on each shift. To do so, you would select the role mailing list option in Step 1. The Operator role would have the following definition:
Role name: operad
Role full name: Operator
Role description: Backup operator
Rights profile: Operator
This rights profile must be at the top of the list of profiles that are included in the role.
Creating a Role for a Security-Related Rights Profile By default, the only rights profile that contains security-related commands and rights is the Primary Administrator profile. If you want to create a role that is not as powerful as Primary Administrator but can handle some security-related tasks, you must create the role. In the following example, you create a role that protects devices. The role is created by performing the preceding procedure with the following parameters:
Role name: devicesec\
Role full name: Device Security
Role description: Configures devices
Rights profile: Device Security
In the following example, you create a role that secures systems and hosts on the network. The role is created by performing the preceding procedure with the following parameters:
Role name: netsec
Role full name: Network Security
Role description: Handles IPSEC, IKE, and SSH
Rights profile: Network Security
 |
Following are steps for creating a role for the System Administrator rights profile:
Log in as superuser.
Start the management console and click the Administrative Roles icon.
Enter the role name: sysadmin.
Enter the role full name: System Administrator.
Enter the role description: Performs nonsecurity administrative tasks.
Enter the role password.
Assign the role rights: System Administrator.
Enter the home directory or accept the default.
Add the user names of users who will be permitted to assume this role.
|
Once a role is assigned to a user, that role can be assumed at any time from a terminal window. To do so
Log in as a user and open a terminal session.
Type roles to verify which roles are available to you.
Issue the su command followed by the role name to assume that role:
su backup_operator
Enter the associated password.
To verify that the role has been assumed, issue the /usr/ucb/whoami command.
You should recall that recurring security-relevant event assessments are part of problem identification and auditing for network defense testing against techniques used by intruders and for post-intrusion analysis. In other words, regularly scheduled auditing should be practiced. This applies not only to components with regard to outside intrusions but is applicable to internal intrusions as well.
As you should recall from Chapter 5, the /etc/security/audit_control file can be modified to preselect audit classes. In the audit_control file, the flags and naflags arguments define which attributable and nonattributable events (the na preceding the second flags argument specifies nonattributable events) should be audited for the entire system—that is, all users on the system. To audit a role, you should add the ua or the as event to the flags line, as shown in the following extract:
# ident "@(#)audit_control.txt 1.4 00/07/17 SMI" # flags:as
Be sure to configure the remaining auditing components as specified in Chapter 5, and then start the auditing service using these steps:
Log in with an account that has root privileges, or use the su command to become superuser.
Bring down the system to single-user mode using the init command: init 1
In the /etc/security directory, run the bsmconv script to enable the auditing service: ./bsmconv
Bring the system into multi-user mode using the init command: init 6
Here are some of the key points from the certification objectives in Chapter 9.
With RBAC, system administrators can delegate privileged commands to non-root users without giving them full superuser access.
The principle of least privilege states that a user should not be given any more privilege or permissions necessary for performing a job.
A rights profile grants specific authorizations and/or privilege commands to a user's role. Privilege commands execute with administrative capabilities usually reserved for administrators.
Sun's best practices dictate that you do not assign rights profiles, privileges, and authorizations directly to users, or privileges and authorizations directly to roles. It's best to assign authorizations to rights profiles, rights profiles to roles, and roles to users.
Applications that check authorizations include audit administration commands, batch job commands, device commands, printer administration commands, and the Solaris Management Console tool suite.
Privileges that have been removed from a program or process cannot be exploited. If a program or process was compromised, the attacker will have only those privileges that the program or process had. Other unrelated programs and processes would not be compromised.
Roles get access to privileged commands through rights profiles that contain the commands.
Commands that check for privileges include commands that control processes, file and file system commands, Kerberos commands, and network commands.
The four sets of process privileges are the effective privilege set (E), which are privileges currently in use; the inheritable privilege set (I), which are privileges a process can inherit; the permitted privilege set (P), which are privileges available for use now; and the limit privilege set (L), which is outside privilege limits of which processes can shrink but never extend.
With RBAC, a user role whose rights profile contains permission to execute specific commands can do so without having to become superuser.
A rights profile can be assigned to a role or user and can contain authorizations, privilege commands, or other rights profiles.
The rights profile name and authorizations can be found in the prof_attr database, the profile name and commands with specific security attributes are stored in the exec_attr database, and the user_attr database contains user and role information that supplements the passwd and shadow databases.
A role is a type of user account that can run privileged applications and commands included in its rights profiles.
Before implementing RBAC, you should properly plan by creating profiles and roles that adhere to company policy and abide by the principle of least privilege when assigning permissions.
A right is a named collection consisting of commands, authorizations to use specific applications (or to perform specific functions within an application), and other previously created rights whose use can be granted or denied to an administrator.
The roleadd command can be used to create roles and associates a role with an authorization or a profile from the command line.
From the command line, the usermod command associates a user's login with a role, profile, and authorization in the /etc/user_attr database, which can also be used to grant a user access to a role.
A role is a special user account used to grant rights.
Users can assume only those roles they have been granted permission to assume. Once a user takes on a role, the user relinquishes his or her own user identity and takes on the properties, including the rights, of that role.
To audit a role, you should add the ua or the as event to the flags line in the audit_control file, and then start the auditing service.
The following questions will help you measure your understanding of the material presented in this chapter. Read all the choices carefully, because there might be more than one correct answer. Choose all correct answers for each question. Some questions are short-answer questions to ensure you have a good understanding of the material.
|
Which of the following are benefits of Role-Based Access Control (RBAC)?
|
|
|
|
Which of the following can be assigned to a role or user as a collection of administrative functions and can contain authorizations and privilege commands or rights profiles?
|
|
|
|
What is the principle of least privilege? |
|
|
|
It is advisable not to assign rights profiles, privileges, and authorizations directly to users.
|
|
|
|
Which of the following is an example of the principle of least privilege?
|
|
|
|
Which of these are privileges in common with every process?
|
|
|
|
Which of the following can check for user IDs (UIDs), group IDs (GIDs), privileges, or authorizations via application or command?
|
|
|
|
Which of the following are applications or commands that check for privileges?
|
|
|
|
Which of the following can be granted to a command, user, role, or system and gives a process the ability to perform an operation and therefore enforces security policy in the kernel?
|
|
|
|
It is advisable to assign privileges and authorizations directly to roles.
|
|
|
|
Which rights profile database contains user and role information that supplements the passwd and shadow databases?
|
|
|
|
Which of the following types of applications comply with RBAC and therefore can check a user's authorizations before giving the user access?
|
|
|
|
Which rights profile database contains the profile name and commands with specific security attributes?
|
|
|
|
Which of these databases contains role information?
|
|
|
|
Explain the meaning of a role as it pertains to Role-Based Access Control (RBAC). |
|
Answers
|
þ B and D. Role-Based Access Control (RBAC) allows system administrators to delegate privileged commands to non-root users without giving them full superuser access to the system. Similarly, users can be assigned only the exact privileges and permissions necessary for performing a job. ý A is wrong, because although it's true that privilege commands execute with administrative capabilities usually reserved for administrators, that statement does not describe a benefit to RBAC. C is wrong because Sun's best practices dictate that you do not assign rights profiles, privileges, and authorizations directly to users or privileges and authorizations directly to roles. It's best to assign authorizations to rights profiles, rights profiles to roles, and roles to users. |
|
|
þ D. A rights profile can be assigned to a role or user as a collection of administrative functions. Rights profiles can contain authorizations, privilege commands, or other rights profiles. ý A is wrong because authorization can be assigned to a role or user. B is wrong because a privilege can be granted to a command, user, role, or system. Privilege gives a process the ability to perform an operation and therefore enforces security policy in the kernel. C is wrong because a privileged application can check for user IDs (UIDs), group IDs (GIDs), privileges, or authorizations via an application or command. E is wrong because a role is a predefined identity that can run privileged applications. |
|
|
þ The principle of least privilege states that a user should not be granted any more privileges or permissions than those necessary for performing a specific job. |
|
|
þ A. True. Sun's best practices dictate that you do not assign rights profiles, privileges, and authorizations directly to users, or privileges and authorizations directly to roles. It's best to assign authorizations to rights profiles, rights profiles to roles, and roles to users. |
|
|
þ A, B, and C. Examples of the principle of least privilege include programs—using privileges— that do not require making calls to setuid, when system administrators delegate privileged commands to non-root users without giving them full superuser access, and users that are only given privilege or permission necessary for performing their jobs. ý D is wrong because it's simply a true statement concerning privileged commands. |
|
|
þ A, B, and D. Every process has four sets of privileges: the effective privilege set (E), which are privileges currently in use (note that processes can be used to add permitted privileges to the set); inheritable privilege set (I), which are privileges a process can inherit; permitted privilege set (P), which are privileges available for use now; and limited privilege set (L), which are outside privilege limits of which processes can shrink but never extend. ý C and E are wrong because they don't exist. |
|
|
þ C. A privileged application can check for user IDs (UIDs), group IDs (GIDs), privileges, or authorizations via an application or command. ý A is wrong because authorization can be assigned to a role or user. B is wrong because a privilege can be granted to a command, user, role, or system. Privilege gives a process the ability to perform an operation and therefore enforces security policy in the kernel. D is wrong because a rights profile can be assigned to a role or user as a collection of administrative functions. E is wrong because a role is a predefined identity that can run privileged applications. |
|
|
þ B, C, and D. Applications and commands that check for privileges include commands that control processes (such as kill, pcred, and rcapadm), file and file system commands (such as chmod, chgrp, and mount), Kerberos commands (such as kadmin, kprop, and kdb5_util), and network commands (such as ifconfig, route, and snoop). ý A and E are wrong because they are databases. |
|
|
þ B. A privilege can be granted to a command, user, role, or system. Privilege gives a process the ability to perform an operation and therefore enforces security policy in the kernel. ý A is wrong because authorization can be assigned to a role or user. C is wrong because a privileged application can check for user IDs (UIDs), group IDs (GIDs), privileges, or authorizations via an application or command. D is wrong because a rights profile can be assigned to a role or user as a collection of administrative functions. E is wrong because a role is a predefined identity that can run privileged applications. |
|
|
þ B. False. Sun's best practices dictate that you do not assign rights profiles, privileges, and authorizations directly to users, or privileges and authorizations directly to roles. It's best to assign authorizations to rights profiles, rights profiles to roles, and roles to users. |
|
|
þ C. The user_attr database contains user and role information that supplements the passwd and shadow databases. This database also contains extended user attributes such as authorizations, rights profiles, and assigned roles. ý A is incorrect because the rights profile name and authorizations are found in the prof_attr database. B is wrong because the rights profile name and commands with specific security attributes are stored in the exec_attr database. D and E are wrong because the passwd and shadow databases do not contain user and role information that supplements themselves. |
|
|
þ F. All answers are correct. Applications that comply with RBAC can check a user's authorizations before giving the user access. These applications include the following audit administration commands (auditconfig and auditreduce), batch job commands (at, atq, batch, and crontab), device commands (allocate, deallocate, list_devices, and cdrw), printer administration commands (lpadmin and lpfilter), and the Solaris Management Console (includes all tools). |
|
|
þ B. The rights profile name and commands with specific security attributes are stored in the exec_attr database. ý A is wrong because the rights profile name and authorizations are in the prof_attr database. C is wrong because the user_attr database contains user and role information that supplements the passwd and shadow databases. D and E are wrong because those databases don't apply here. |
|
|
þ C, D, and E. Role information can be found in the user_attr, passwd, and shadow databases. The user_attr database contains user and role information that supplements the passwd and shadow databases. ý A is wrong because the rights profile name and authorizations can be found in the prof_attr database. B is wrong because the rights profile name and commands with specific security attributes are stored in the exec_attr database. |
|
|
þ A role is a special user account used to grant rights. Users can assume only those roles they have been granted permission to assume. Once a user takes on a role, the user relinquishes his or her own user identity and takes on the properties, including the rights, of that role. |
|
Which command associates a user's login with a role, profile, and authorization in the /etc/ user_attr database, which can also be used to grant a user access to a role?
|
|
|
|
To audit a role, which event(s) should be added to the flags line in the audit_control file? |
|
|
|
Which command can be used to check the privileges available to your current shell's process?
|
|
|
|
Which command can be used to create roles and associates a role with an authorization or a profile from the command line?
|
|
|
|
Explain the meaning of a right as it pertains to Role-Based Access Control (RBAC). |
|
Answers
|
þ C. The usermod command associates a user's login with a role, profile, and authorization in the /etc/user_attr database, which can also be used to grant a user access to a role. ý A is wrong because to check the privileges available to your current shell's process, you would use the ppriv -v pid $$ command. B is wrong because in order to start the management console, you would issue the /usr/sbin/smc & command. D is wrong because the roleadd command is used to create roles and associates a role with an authorization or a profile from the command line. |
|
|
þ To audit a role, you should add the ua or the as event to the flags line in the audit_control file, and then start the auditing service. |
|
|
þ A. To check the privileges available to your current shell's process, you would use the ppriv -v pid $$ command. ý B is wrong because in order to start the management console you would issue the /usr/sbin/smc & command. C is wrong because the usermod command associates a user's login with a role, profile, and authorization in the /etc/user_attr database, which can also be used to grant a user access to a role. D is wrong because the roleadd command is used to create roles and associates a role with an authorization or a profile from the command line. |
|
|
þ D. The roleadd command can be used to create roles and associates a role with an authorization or a profile from the command line. ý A is wrong because to check the privileges available to your current shell's process, you would use the ppriv -v pid $$ command. B is wrong because in order to start the management console you would issue the /usr/sbin/smc & command. C is wrong because the usermod command associates a user's login with a role, profile, and authorization in the /etc/user_attr database, which can also be used to grant a user access to a role. |
|
|
þ A right is a named collection, consisting of commands, authorizations to use specific applications (or to perform specific functions within an application), and other previously created rights, whose use can be granted or denied to an administrator. |
|
Your customer, ABCD Inc., called you in to create a role for backup using the Operator rights profile in its Role-Based Access Control (RBAC) system. What steps would you perform to provide the requested service? |
|
Answers
|
The Operator rights profile can manage printers and back up the system to offline media. ABCD Inc. hired you to create a role for backup using the Operator rights profile in their Role-Based Access Control (RBAC) system. To do so, you should follow these steps:
|
|
|
