|
|
Home | Switchboard | Unix Administration | Red Hat | TCP/IP Networks | Neoliberalism | Toxic Managers |
| (slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix | |||||||
David Ferraiolo and Richard Kuhn
National Institute of Standards and Technology
Technology Administration
U.S. Department of Commerce
Gaithersburg, Md. 20899 USA
While Mandatory Access Controls (MAC) are appropriate for multilevel secure military applications, Discretionary Access Controls (DAC) are often perceived as meeting the security processing needs of industry and civilian government. This paper argues that reliance on DAC as the principal method of access control is unfounded and inappropriate for many commercial and civilian government organizations. The paper describes a type of non-discretionary access control - role-based access control (RBAC) - that is more central to the secure processing needs of non-military systems then DAC.
access control, computer security, discretionary access control, integrity, mandatory access control, role, TCSEC
The U.S. government has been involved in developing security technology for computer and communications systems for some time. Although advances have been great, it is generally perceived that the current state of security technology has, to some extent failed to address the needs of all. [1], [2] This is especially true of organizations outside the Department of Defense (DoD). [3]
The current set of security criteria, criteria interpretations, and guidelines has grown out of research and development efforts on the part of the DoD over a period of twenty plus years. Today the best known U.S. computer security standard is the Trusted Computer System Evaluation Criteria (TCSEC [4] ). It contains security features and assurances, exclusively derived, engineered and rationalized based on DoD security policy, created to meet one major security objective - preventing the unauthorized observation of classified information. The result is a collection of security products that do not fully address security issues as they pertain to unclassified sensitive processing environments. Although existing security mechanisms have been partially successful in promoting security solutions outside of the DoD [2] , in many instances these controls are less then perfect, and are used in lieu of a more appropriate set of controls.
The TCSEC specifies two types of access controls: Discretionary Access Controls (DAC) and Mandatory Access Controls (MAC). Since the TCSEC's appearance in December of 1983, DAC requirements have been perceived as being technically correct for commercial and civilian government security needs, as well as for single-level military systems. MAC is used for multi-level secure military systems, but its use in other applications is rare. The premise of this paper is that there exists a control, referred to as Role-Based Access Control (RBAC), that can be more appropriate and central to the secure processing needs within industry and civilian government than that of DAC, although the need for DAC will continue to exist.
Recently, considerable attention has been paid to researching and addressing the security needs of commercial and civilian government organizations. It is apparent that significant and broad sweeping security requirements exist outside the Department of Defense. [2] , [5] , [6] Civilian government and corporations also rely heavily on information processing systems to meet their individual operational, financial, and information technology requirements. The integrity, availability, and confidentiality of key software systems, databases, and data networks are major concerns throughout all sectors. The corruption, unauthorized disclosure, or theft of corporate resources could disrupt an organization's operations and have immediate, serious financial, legal, human safety, personal privacy and public confidence impact.
Like DoD agencies, civilian government and commercial firms are very much concerned with protecting the confidentiality of information. This includes the protection of personnel data, marketing plans, product announcements, formulas, manufacturing and development techniques. But many of these organizations have even greater concern for integrity. [1]
Within industry and civilian government, integrity deals with broader issues of security than confidentiality. Integrity is particularly relevant to such applications as funds transfer, clinical medicine, environmental research, air traffic control, and avionics. The importance of integrity concerns in defense systems has also been studied in recent years. [7] , [8]
A wide gamut of security policies and needs exist within civilian government and private organizations. An organizational meaning of security cannot be presupposed. Each organization has unique security requirements, many of which are difficult to meet using traditional MAC and DAC controls.
As defined in the TCSEC and commonly implemented, DAC is an access control mechanism that permits system users to allow or disallow other users access to objects under their control:
A means of restricting access to objects based on the identity of subjects and/or groups to which they belong. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission (perhaps indirectly) on to any other subject (unless restrained by mandatory access control). [4]
DAC, as the name implies, permits the granting and revoking of access privileges to be left to the discretion of the individual users. A DAC mechanism allows users to grant or revoke access to any of the objects under their control without the intercession of a system administrator.
In many organizations, the end users do not ``own'' the information for which they are allowed access. For these organizations, the corporation or agency is the actual ``owner'' of system objects as well as the programs that process it. Control is often based on employee functions rather than data ownership.
Access control decisions are often determined by the roles individual users take on as part of an organization. This includes the specification of duties, responsibilities, and qualifications. For example, the roles an individual associated with a hospital can assume include doctor, nurse, clinician, and pharmacist. Roles in a bank include teller, loan officer, and accountant. Roles can also apply to military systems; for example, target analyst, situation analyst, and traffic analyst are common roles in tactical systems. A role based access control (RBAC) policy bases access control decisions on the functions a user is allowed to perform within an organization. The users cannot pass access permissions on to other users at their discretion. This is a fundamental difference between RBAC and DAC.
Security objectives often support a higher level organizational policy, such as maintaining and enforcing the ethics associated with a judge's chambers, or the laws and respect for privacy associated with the diagnosis of ailments, treatment of disease, and the administering of medicine with a hospital. To support such policies, a capability to centrally control and maintain access rights is required. The security administrator is responsible for enforcing policy and represents the organization.
The determination of membership and the allocation of transactions to a role is not so much in accordance with discretionary decisions on the part of a system administrator, but rather in compliance with organization-specific protection guidelines. These policies are derived from existing laws, ethics, regulations, or generally accepted practices. These policies are non-discretionary in the sense that they are unavoidably imposed on all users. For example, a doctor can be provided with the transaction to prescribe medicine, but does not possess the authority to pass that transaction on to a nurse.
RBAC is in fact a form of mandatory access control, but it is not based on multilevel security requirements. As defined in the TCSEC, MAC is
A means of restricting access to objects based on the sensitivity (as represented by a label) of the information contained in the objects and the formal authorization (i.e. clearance) of subjects to access information of such sensitivity. [4]
Role based access control, in many applications (e.g. [9] , [10] , [11] is concerned more with access to functions and information than strictly with access to information.
The act of granting membership and specifying transactions for a role is loosely analogous to the process of clearing users (granting membership) and the labeling (associate operational sensitivities) of objects within the DoD. The military policy is with respect to one type of capability: who can read what information. For these systems the unauthorized flow of information from a high level to a low level is the principal concern. As such, constraints on both reads and writes are in support of that rule. Within a role-based system, the principal concern is protecting the integrity of information: ``who can perform what acts on what information.''
A role can be thought of as a set of transactions that a user or set of users can perform within the context of an organization. Transactions are allocated to roles by a system administrator. Such transactions include the ability for a doctor to enter a diagnosis, prescribe medication, and add a entry to (not simply modify) a record of treatments performed on a patient. The role of a pharmacist includes the transactions to dispense but not prescribe prescription drugs. Membership in a role is also granted and revoked by a system administrator.
Roles are group oriented. For each role, a set of transactions allocated the role is maintained. A transaction can be thought of as a transformation procedure [1] (a program or portion of a program) plus a set of associated data items. In addition, each role has an associated set of individual members. As a result, RBACs provide a means of naming and describing many-to-many relationships between individuals and rights. Figure 1 depicts the relationships between individual users, roles/groups, transformation procedures, and system objects.
The term transaction is used in this paper as a convenience to refer to a binding of transformation procedure and data storage access. This is not unlike conventional usage of the term in commercial systems. For example, a savings deposit transaction is a procedure that updates a savings database and transaction file. A transaction may also be quite general, e.g. ``read savings file''. Note however, that ``read'' is not a transaction in the sense used here, because the read is not bound to a particular data item, as ``read savings file'' is.
The importance of control over transactions, as opposed to simple read and write access, can be seen by considering typical banking transactions. Tellers may execute a savings deposit transaction, requiring read and write access to specific fields within a savings file and a transaction log file. An accounting supervisor may be able to execute correction transactions, requiring exactly the same read and write access to the same files as the teller. The difference is the process executed and the values written to the transaction log file.
The applicability of RBAC to commercial systems is apparent from its widespread use. Baldwin [9] describes a database system using roles to control access. Nash and Poland [10] discuss the application of role based access control to cryptographic authentication devices commonly used in the banking industry. Working with industry groups, the National Institute of Standards and Technology has developed a proposed standard, ``Security Requirements for Cryptographic Modules,'' (Federal Information Processing Standard 140-1) [11] that will require support for access control and administration through roles. To date, these role based systems have been developed by a variety of organizations, with no commonly agreed upon definition or recognition in formal standards. Role based access controls described in this paper address security primarily for application-level systems, as opposed to general purpose operating systems.
To clarify the notions presented in the previous section, we give a simple formal description, in terms of sets and relations, of role based access control. No particular implementation mechanism is implied.
For each subject, the active role is the one that the subject is currently using:
Each subject may be authorized to perform one or more roles:
Each role may be authorized to perform one or more transactions:
Subjects may execute transactions. The predicate exec(s,t) is true if subject s can execute transaction t at the current time, otherwise it is false:
Three basic rules are required:
The identification and authentication process (e.g. login) is not considered a transaction. All other user activities on the system are conducted through transactions. Thus all active users are required to have some active role.
With (1) above, this rule ensures that users can take on only roles for which they are authorized.
With (1) and (2), this rule ensures that users can execute only transactions for which they are authorized. Note that, because the conditional is ``only if'', this rule allows the possibility that additional restrictions may be placed on transaction execution. That is, the rule does not guarantee a transaction to be executable just because it is in TA(AR(s)), the set of transactions potentially executable by the subject's active role. For example, a trainee for a supervisory role may be assigned the role of ``Supervisor'', but have restrictions applied to his or her user role that limit accessible transactions to a subset of those normally allowed for the Supervisor role.
In the preceding discussion, a transaction has been defined as a transformation procedure, plus a set of data items accessed by the transformation procedure. Access control in the rules above does not require any checks on the user's right to access a data object, or on the transformation procedure's right to access a data item, since the data accesses are built into the transaction. Security issues are addressed by binding operations and data into a transaction at design time, such as when privacy issues are addressed in an insurance query transaction.
It is also possible to redefine the meaning of ``transaction'' in the above rules to refer only to the transformation procedure, without including a binding to objects. This would require a fourth rule to enforce control over the modes in which users can access objects through transaction programs. For example, a fourth rule such as
could be defined using a transaction (redefined to transformation procedure) to object access function access(r, i, o, x) which indicates if it is permissible for a subject in role r to access object o in mode x using transaction t, where x is taken from some set of modes such as read, write, append. Note that the Clark-Wilson access control triple could be implemented by letting the modes x be the access modes required by transaction t, and having a one-to-one relationship between subjects and roles. RBAC, as presented in this paper, thus includes Clark and Wilson access control as a special case.
Use of this fourth rule might be appropriate, for example, in a hospital setting. A doctor could be provided with read/write access to a prescription file, while the hospital pharmacist might have only read access. (Recall that use of the first three rules alone requires binding the transaction program t and data objects that t can access, and only controls access to the transactions.) This alternative approach using the fourth rule might be helpful in enforcing confidentiality requirements.
Another use of RBAC is to support integrity. Integrity has been defined in a variety of ways, but one aspect [8] of integrity is a requirement that data and processes be modified only in authorized ways by authorized users. This seems to be a reasonable security objective for many real systems, and RBAC should be applicable to such systems.
In general, the problem of determining whether data have been modified only in authorized ways can be as complex as the transaction that did the modification. For this reason, the practical approach is for transactions to be certified and trusted. If transactions must be trusted then access control can be incorporated directly into each transaction. Requiring the system to control access of transaction programs to objects through the access function used in rule (4) might then be a useful form of redundancy, but it could involve significant overhead for a limited benefit in enforcing integrity requirements. Therefore, inclusion of a transaction to object access control function in RBAC would be useful in some, but not all applications.
RBAC is flexible in that it can take on organizational characteristics in terms of policy and structure. One of RBAC's greatest virtues is the administrative capabilities it supports.
Once the transactions of a Role are established within a system, these transactions tend to remain relatively constant or change slowly over time. The administrative task consists of granting and revoking membership to the set of specified named roles within the system. When a new person enters the organization, the administrator simply grants membership to an existing role. When a person's function changes within the organization, the user membership to his existing roles can be easily deleted and new ones granted. Finally, when a person leaves the organization, all memberships to all Roles are deleted. For an organization that experiences a large turnover of personnel, a role-based security policy is the only logical choice.
In addition, roles can be composed of roles. For example, a Healer within a hospital can be composed of the roles Healer, Intern, and Doctor. Figure 2 depicts an example of such a relationship.
Figure 2: Multi-Role relationships
By granting membership to the Role Doctor, it implies access to all transactions defined by Intern and Healer, as well as those of a Doctor. On the other hand, by granting membership to the Intern role, this implies transactions of the Intern and Healer not the Doctor. However, by granting membership to the Healer role, this only allows access to those resources allowed under the role Healer.
The principle of least privilege has been described as important for meeting integrity objectives. [8] The principle of least privilege requires that a user be given no more privilege than necessary to perform a job. Ensuring least privilege requires identifying what the user's job is, determining the minimum set of privileges required to perform that job, and restricting the user to a domain with those privileges and nothing more. By denying to subjects transactions that are not necessary for the performance of their duties, those denied privileges cannot be used to circumvent the organizational security policy. Although the concept of least privilege currently exists within the context of the TCSEC, requirements restrict those privileges of the system administrator. Through the use of RBAC, enforced minimum privileges for general system users can be easily achieved.
RBAC mechanisms can be used by a system administrator in enforcing a policy of separation of duties. Separation of duties is considered valuable in deterring fraud since fraud can occur if an opportunity exists for collaboration between various job related capabilities. Separation of duty requires that for particular sets of transactions, no single individual be allowed to execute all transactions within the set. The most commonly used examples are the separate transactions needed to initiate a payment and to authorize a payment. No single individual should be capable of executing both transactions. Separation of duty is an important consideration in real systems. [1] , [12] , [13] , [14] The sets in question will vary depending on the application. In real situations, only certain transactions need to be restricted under separation of duty requirements. For example, we would expect a transaction for ``authorize payment'' to be restricted, but a transaction ``submit suggestion to administrator'' would not be.
Separation of duty can be either static or dynamic. Compliance with static separation requirements can be determined simply by the assignment of individuals to roles and allocation of transactions to roles. The more difficult case is dynamic separation of duty where compliance with requirements can only be determined during system operation. The objective behind dynamic separation of duty is to allow more flexibility in operations. Consider the case of initiating and authorizing payments. A static policy could require that no individual who can serve as payment initiator could also serve as payment authorizer. This could be implemented by ensuring that no one who can perform the initiator role could also perform the authorizer role. Such a policy may be too rigid for commercial use, making the cost of security greater than the loss that might be expected without the security. More flexibility could be allowed by a dynamic policy that allows the same individual to take on both initiator and authorizer roles, with the exception that no one could authorize payments that he or she had initiated. The static policy could be implemented by checking only roles of users; for the dynamic case, the system must use both role and user ID in checking access to transactions.
Separation of duty is necessarily determined by conditions external to the computer system. The Clark-Wilson [1] scheme includes the requirement that the system maintain the separation of duty requirement expressed in the access control triples. Enforcement is on a per-user basis, using the user ID from the access control triple. As discussed above, user functions can be conveniently separated by role, since many users in an organization typically perform the same function and have the same access rights on TPs and data. Allocating access rights according to role is also helpful in defining separation of duty in a way that can be enforced by the system.
In many organizations in industry and civilian government, the end users do not ``own'' the information for which they are allowed access. For these organizations, the corporation or agency is the actual ``owner'' of system objects, and discretionary access control may not be appropriate. Role-Based Access Control (RBAC) is a nondiscretionary access control mechanism which allows and promotes the central administration of an organizational specific security policy.
Access control decisions are often based on the roles individual users take on as part of an organization. A role specifies a set of transactions that a user or set of users can perform within the context of an organization. RBAC provide a means of naming and describing relationships between individuals and rights, providing a method of meeting the secure processing needs of many commercial and civilian government organizations.
Various forms of role based access control have been described and some are used in commercial systems today, but there is no commonly accepted definition or formal standards encompassing RBAC. As such, evaluation and testing programs for these systems have not been established as they have for systems conforming to the Trusted Computer Security Evaluation Criteria. This paper proposed a definition of The requirements and access control rules for RBAC proposed in this paper could be used as the basis for a common definition of access controls based on user roles.
Originally published in the Proceedings of the 15th National Computer Security Conference, Vol II, pp 554-563, 1992.
Authors' email addresses:
David Ferraiolo - [email protected], (301) 975-3046
Richard Kuhn - [email protected], (301) 975-3337
Contacts for further information on NIST Role-Based Access Control activities:
David Ferraiolo - [email protected], (301) 975-3046
John Barkley - [email protected], (301) 975-3346
|
|
Switchboard | ||||
| Latest | |||||
| Past week | |||||
| Past month | |||||
 |
 |
 |
One of the most challenging problems in managing large networked systems is the complexity of security administration. Today, security administration is costly and prone to error because administrators usually specify access control lists for each user on the system individually. Role based access control (RBAC) is a technology that is attracting increasing attention, particularly for commercial applications, because of its potential for reducing the complexity and cost of security administration in large networked applications.
With RBAC, security is managed at a level that corresponds closely to the organization's structure. Each user is assigned one or more roles, and each role is assigned one or more privileges that are permitted to users in that role. Security administration with RBAC consists of determining the operations that must be executed by persons in particular jobs, and assigning employees to the proper roles. Complexities introduced by mutually exclusive roles or role hierarchies are handled by the RBAC software, making security administration easier.
|
|
|
Print-Friendly Version
Role-Based Access Control
Content Level: Intermediate
Content Audience: Solaris Administrators and ManagersUNIX administrators have been wanting more fine-grained access control to administrative features almost since the first administrator accidentally destroyed his first system. As of Solaris 8, Sun has delivered a solution to that problem. But is the solution for you?
The Current State
The UNIX concept of a "superuser" who could do all is a good one. It allows one or more users to gain access to all system facilities, for monitoring and management. It makes debugging and correcting system problems (relatively) easy. In short, it doesn't have a lot of security to get in the way of administration. It has its failings however, including:
- "All or nothing" - Either you are the superuser or a normal user. Once a superuser, you have infinite access to all system components. This model allows bugs in
/dev/mouse(this is a true story) to allow a user to become superuser and gain total access to a machine. This model also makes it difficult to grant some rights to some users. For example, there is no ability within standard UNIX to grant operators access to backup and restore programs but to nothing else.- Lack of activity logging - The superuser activities are no more logged or monitored than any other user of the system.
- Lack of accountability - Similarly, it is difficult to determine who has performed what activities. User-ID "0" is root, and anyone with that ID or who changes to that ID can perform root operations. While you can create several accounts with ID's of 0 (not recommended) to create separate privileged accounts with different passwords, all activities take place as User-ID 0, so file and directory modifications (for example) are undifferentiable.
Given the state of UNIX access controls, how can junior administrators be given a subset of the system access of senior ones? How can operators be limited to only backup and restore operations? How can users be empowered to change only small portions of the system to suit their needs?
The need for superuser management is exacerbated as the number of users of UNIX systems grows, the number of services and features increases, and the need for security increases. Other operating systems tend to have better security models than UNIX. For instance, VMS, MVS, and even Windows 2000 have many more security options and features than older Solaris releases. (Note that having a better security model does not automatically make an operating system more secure!)
Unfortunately, standard UNIX has never had a standard way to assign different levels of systems administrator access. Each major UNIX implementation has its own facility. Sun has tried a few methods, most recently Admintool/Adminsuite. These have met with limited success, as their feature sets are small and security sometimes lacking. The largest issue has been a lack of standardization. Each operating system had its own security methodology, so heterogeneous operation was impossible. Even if an individual operating system could be made more secure, communication and interoperation with other operating systems could invalidate that extra security.
Sudo
There are other choices available to manage systems administrator access control. The most commonly used is sudo. Sudo resolves many of the issues listed above. It allows a given user to execute a set of commands as root. It also logs each action performed by each sudo user. Sudo is available as free software under a BSD-style license. But what is the downside? There are a couple of problems. Sudo is not standard with most commercial UNIX releases, so you must download it, build it, and install it on each of your systems. Also, Sudo is an application, rather than an integrated facility. It can be bypassed via the use of standard
su, for example. As a free product, it also has the usual support and management issues that can affect the ability of large companies to use it.What's New?
There is a new security offering that is starting to change this landscape. Role-Based Access Control (RBAC) is a NIST standard that is starting to appear in several operating systems. Sun's Solaris 8 is one of its first commercial appearances. Given the importance of a uniform security model for UNIX systems, I'll delve into RBAC and its functionality on Solaris 8.
Role-Based Access Control
With RBAC, it is possible for administrators to assign limited administrative capabilities to users. In essence, it allows implementation of the "least privilege" security principle, bestowing only enough privilege to accomplish a task. The RBAC functionality is flexible enough that different sites could use it in various ways to implement their distinct security policies. Furthermore, by enabling accounting along with RBAC, a full record of administrative user activities can be created.
RBAC implements several new Solaris concepts:
- Authorizations -- user rights that grant access to restricted function profiles,
- Roles -- for grouping authorizations and commands together as a common set of functions. Roles are assigned to users.
- Profiles -- (also known as "execution profiles" or "rights profiles") for performing a set of administrative tasks. The administrator creates a profile containing authorizations and privileged commands for a specific task or set of tasks. That profile can be assigned directly to a user or to a role. Profiles are assigned to roles to define the functionality of each role.
Each profile can have individual commands or authorizations assigned to it. Some commands directly use authorizations. These include Sun Management Console (SMC), batch job-related commands, and device allocation commands. For a user to enable a role, a user can either use the SMC launcher, or use special versions of the systems shells, known as "profile shells":
pfsh, pfcsh,andpfksh. There is alsopfexec, which is used to execute a single RBAC-authorized command.Furthermore, separate accounts for each role are created in the standard way, and all users of that role can share the same home directory while in that role.
Users can assume a role by
suing to that account.There generally are no predefined roles on Solaris. T
here are, however, three predefined profiles that could be enabled readily: "Primary Administrator", "System Administrator", and "Operator". To implement this functionality, there are several new system files.
/etc/user_attrstores extended security attributes related to users and roles./etc/security/auth_attrlists and describes authorizations./etc/security/prof_attrlists execution profiles and associated authorizations./etc/security/exec_attrassociates execution attributes with execution profiles./etc/security/policy.confprovides the security policy configuration for user-level attributes.In short, this is a complicated new facility, with configuration files containing complex sets of fields. These configuration files can be part of NIS, NIS+, or LDAP name services, or just kept locally on individual servers. In fact, there is a separate command,
smattrpop, which can merge entries from one attribute database into a specified naming service.These files can be edited manually, or several separate commands can be used to manage the information in them:
smexec- manageexec_attrsmmultiuser- manage bulk operations on user accountssmuser- manage user entriessmprofile- manage profiles inprof_attrandexec_attrsmrole- manage roles and users in role accountsrolemod, roledel, roleadd- perform operations on rolesPerhaps the best way to get started with RBAC is via the Sun Management Console.
That will be the topic of next month's column. Meanwhile, the following tour should help you get acquainted with the RBAC files and RBAC's features and functionality. By default, the
/etc/user_attrfile has this content:# Copyright (c) 1999 by Sun Microsystems, Inc. All rights reserved. # # /etc/user_attr # # user attributes. see user_attr(4) # #pragma ident "@(#)user_attr 1.2 99/07/14 SMI" # root::::type=normal;auths=solaris.*,solaris.grant;profiles=AllThe one entry describes user "root", and authorizes access to all Solaris services ("solaris.*,solaris.grant") in all profiles. The authorizations are contained in
/etc/security/auth_attr. On my experimental system (running Solaris 8 release 7/01), this file contains 76 lines. Here are the first few lines:solaris.admin.usermgr.:::User Accounts:: solaris.admin.usermgr.write:::Manage Users::help=AuthUsermgrWrite.html solaris.admin.usermgr.read:::View Users and Roles::help=AuthUsermgrRead.html solaris.admin.usermgr.pswd:::Change Password::help=AuthUserMgrPswd.html solaris.admin.logsvc.:::Log Viewer:: solaris.admin.logsvc.write:::Manage Log Settings::help=AuthLogsvcWrite.html solaris.admin.logsvc.purge:::Remove Log Files::help=AuthLogsvcPurge.html solaris.admin.logsvc.read:::View Log Files::help=AuthLogsvcRead.html solaris.admin.fsmgr.:::Mounts and Shares:: solaris.admin.fsmgr.write:::Mount and Share Files::help=AuthFsmgrWrite.html solaris.admin.fsmgr.read:::View Mounts and Shares::help=AuthFsmgrRead.html solaris.admin.serialmgr.:::Serial Port Manager::Thus, root has access to all of the lines that start with "solaris" (i.e., all of them). Another user could be configured to have access to "solaris.admin.usermgr", if her only activity was managing users. But what actual commands are available for that user? For that, we need to refer to two files. First, we look in
/etc/security/prof_attrto determine which profile includes those authorizations:# grep usermgr prof_attr Basic Solaris User:::Automatically assigned rights:\ auths=solaris.profmgr.read,solaris.jobs.users,\ solaris.admin.usermgr.read,solaris.admin.logsvc.read,\ solaris.admin.fsmgr.read,solaris.admin.serialmgr.read,\ solaris.admin.diskmgr.read,solaris.admin.procmgr.user,\ solaris.compsys.read,solaris.admin.printer.read,\ solaris.admin.prodreg.read,solaris.admin.dcmgr.read;\ profiles=All;help=RtDefault.html User Management:::Manage users, groups, home directory:\ auths=profmgr.read,solaris.admin.usermgr.write,\ solaris.admin.usermgr.read;help=RtUserMngmnt.html User Security:::Manage passwords, clearances:\ auths=solaris.role.*,solaris.profmgr.*,solaris.admin.usermgr.*;\ help=RtUserSecurity.html(Continuation lines added for readability.)
It is relatively clear from this output that "Basic Solaris User" members have access to a wide variety of authorizations, and that "User Management" profile users have access to some and "User Security" profile users have access to all of those authorizations. Now that we know the profile names, we can determine the commands associated with them, in
/etc/security/exec_attr:# grep "User Management" exec_attr User Management:suser:cmd:::/usr/sbin/grpck:euid=0 User Management:suser:cmd:::/usr/sbin/pwck:euid=0 User Management:suser:cmd:::/etc/init.d/utmpd:uid=0;gid=sysThere are three commands available to the "User Management" policy. The first checks
/etc/groupfor consistency; the second does the same for/etc/passwd. The third is actually a system startup script to start and stop theutmpddaemon, which monitors theutmpandutmpxfiles. These files contain information on active system users. Note that all three of these commands get run as user ID 0 (i.e., root).You would expect to see many more commands in
exec_attr. A real "user manager" should at least have access to theuser*andgroup*commands. These provide a command-line method for modifyingpasswdandgroupentries. Without these commands, a "user manager" cannot do much in the way of user management. I can find no documented reason why the list inexec_attris so short. Do these other commands provide too much functionality, or shell escapes, making them too powerful to put into small categories like user management?Of course, that is going to be the problem with the RBAC service, and truly with any service that relies on current commands to provide their secure functionality. These commands never thought that they would be run by multiple types of users, and were not designed with that fine-grain access control model. Perhaps Sun is planning on creating new command-line equivalents that provide just the functionality desired. Or perhaps they will modify the current ones. The answer at this point is unclear.
There is an even more concerning aspect to RBAC. In essence, it allows current systems administrators to grant access to previously root-only aspects of the system, in a semi-permanent fashion. Without great care in definition and assignment, systems administrators might give out more than they expected with RBAC. Determining just what a user in a role can perform is currently a challenge. Hopefully, more tools will be provided in the future to diminish these issues.
A perusal of the update manuals that come with each Solaris release reveal that RBAC is a rapidly evolving service. Presumably, these changes will continue, with the eventual result of a useful and usable new feature of Solaris 9.
Until that time, RBAC is best left for experimental rather than production use. For more information, there is an interesting RBAC white paper describing RBAC in the Solaris environment. (There are some oddities in this paper, however. For example, it says that currently no additions are allowed to
auth_attr. This is a normal text file, however, and no information is given on how changes are prevented.)For further reading, you might want to check out a SunManagers Mailing List Posting by Konstantin Rozinov, which describes the steps he used to enable the use of
snoopby non-root users.Next month, I'll explore the Sun Management Console facility, an extensive (and free) management environment that comes with Solaris, but is little used in the field.
Peter Baer Galvin (http://www.petergalvin.org) is the Chief Technologist for Corporate Technologies, a premier systems integrator and VAR. Before that, Peter was the systems manager for Brown University's Computer Science Department. He has written articles for Byte and other magazines, and previously wrote Pete's Wicked World, the security column, and Pete's Super Systems, the systems management column for Unix Insider (http://www.unixinsider.com). Peter is coauthor of the Operating Systems Concepts and Applied Operating Systems Concepts textbooks. As a consultant and trainer, Peter has taught tutorials and given talks on security and system administration worldwide.
Google matched content |
Society
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
Quotes
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Bulletin:
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
History:
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
Classic books:
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D
Copyright © 1996-2021 by Softpanorama Society. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|
|
You can use PayPal to to buy a cup of coffee for authors of this site |
Disclaimer:
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.
Last modified: March 12, 2019
