|
|
With RBAC, when a user logs in and assumes a role, the associated rights profile grants specific authorizations and/or privileged commands to the user. In other words, system administrators can delegate privileged commands to non-root users without giving them full superuser access. It's important to note that privileged commands execute with administrative capabilities usually reserved for administrators.
For the exam, you should know the following components included in the RBAC model:
Authorization An authorization is a permission to perform an action or class of actions. Can be assigned to a role or user but typically included in a rights profile.
Privilege Privilege gives a process the ability to perform an operation and therefore enforces security policy in the kernel. Can be granted to a command, user, role, or system.
| Exam Watch |
RBAC or role-based security reduces the complexity and cost of security administration. For example, by using RBAC, system administrators can delegate privileged commands to non- root users without having to give them full superuser or root access to the system. This can save a lot of time by facilitating the administration process. Be sure to understand RBAC with regard to Solaris rights profiles for the exam. With a rights profile, administrators can assign specific authorizations to a user's role. A role is a type of user account that can run privileged applications and commands included in its rights profiles. Also know that 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. You should assign authorizations to rights profiles, assign rights profiles to user roles, and assign roles to user accounts. |
Privileged application Privileged application gives an application or program the ability to check for user IDs (UIDs), group IDs (GIDs), privileges, or authorizations.
Rights profile Rights profiles can contain authorizations, privilege commands, or other rights profiles. Can be assigned to a role or user as a collection of administrative functions.
Role A role is a predefined identity that can run privileged applications. Can be granted to users.
For all practical purposes, an authorization is included in a rights profile, the rights profile in turn is included in a role, and the role is assigned to a user. If you're not yet clear on these terms, we'll cover them in more detail later in this chapter.
To avoid having users override security policy, Sun recommends that you do not assign rights profiles, privileges, and authorizations directly to users. In addition, Sun advises against assigning privileges and authorizations directly to roles. Instead, you should assign authorizations to rights profiles. Rights profiles should then be included in roles. Finally, roles—conforming to the principle of least privilege— should be assigned to users.
An authorization is a right that can be assigned to a role or a user; however, as stated previously, Sun advises against assigning authorizations directly to a user. 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)
Solaris Management Console (includes all tools)
| Exam Watch |
Be sure to know which type of applications check for user authorizations. For the exam, remember that audit administration commands, batch job commands, device commands, printer administration commands, and the Solaris Management Console comply with RBAC and can check a user's authorizations before giving the user access. |
A privilege is the right a process needs to perform an operation; therefore, it inherently protects kernel processes. Furthermore, with privileges, programs will not be required to make calls to setuid. In other words, programs do not need to run as root because privileges can mandate that programs run only with the privileges required for the program to operate. This is another example of the principle of least privilege.
So what's the bottom line here with regard to security? If you haven't already deduced the answer, privileges that have been removed from a program or process cannot be exploited. As a result, you can speculate that the privilege model is much more secure than the old superuser model. Under the privilege model, if a program or process was compromised, the attacker will have only the same privileges that the program or process had. Other unrelated programs and processes would theoretically not be compromised. Roles, on the other hand, get access to privileged commands through rights profiles that contain the commands. This is a secure way to allow users privileged access to specific commands—by assigning them certain roles.
Applications and commands that check for privileges include the following:
Commands that control processes (kill, pcred, and rcapadm)
File and file system commands (chmod, chgrp, and mount)
Kerberos commands (kadmin, kprop, and kdb5_util)
Network commands (ifconfig, route, and snoop)
Privileges fall into several areas, including the following:
FILE These privileges begin with the string file and pertain to system objects.
IPC These privileges begin with the string ipc and pertain to IPC object access controls.
NET These privileges begin with the string net and pertain to network functionality.
PROC These privileges begin with the string proc and pertain to giving processes the ability to modify restrictions.
SYS These privileges begin with the string sys and pertain to giving processes root access to a variety of system properties.
Processes obtain privileges either from inheritance (that is, via user login) or assignment (via rights profile). Every process has four sets of privileges:
Effective privilege set (E) Privileges currently in use (note that processes can add permitted privileges to the set)
Inheritable privilege set (I) Privileges a process can inherit
Permitted privilege set (P) Privileges available for use now
Limit privilege set (L) Outside privilege limits of which processes can shrink but never extend
To check the privileges available to your current shell's process, use the ppriv -v pid $$ command; where pid is the process number, $$ passes the process number of the parent shell to the command, and -v provides more detail/ verbose listing.
| Exam Watch |
For the exam, remember the four sets privileges that every process has. Also know that a privilege is the right a process needs to perform an operation. |
As you know, privileged applications can check for user IDs (UIDs), group IDs (GIDs), privileges, or authorizations via application or command. However, with RBAC, you can specify the UID or GID, say, for example, for commands. In other words, with RBAC, a user role whose rights profile contains permission to execute specific commands can do so without having to become superuser and can thus have full privileged access to all system commands and applications. Again, this falls right in line with the principle of least privilege.
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, whereas the rights profile name and commands with specific security attributes are stored in the exec_attr database. 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 role is a predefined identity—created by an administrator and assigned to users— that can run privileged applications. Just like a typical user account, roles have an assigned home directory, a password, a group, and other similar attributes. Any authorizations included in a rights profile that is included in a role and assigned to a user give that user limited administrative capabilities. Furthermore, a specific role can be assigned to more than one user.
It's important to note that a user must first log in and can then assume a role. In other words, roles cannot log in. What's more, users must first exit a role before assuming another role type. Role information can be found in the passwd, shadow, and user_attr databases.
|
|