R. Sandhu, E. Coyne, H. Feinstein, C. Youman. 1995. "Role-Based Access Control Models"

Some motivations for constructing a role

1. A role can represent competency to do specific tasks, such as a physician or a pharmacist.
2. A role can embody authority and responsibility, e.g., project supervisor.
   • Authority and responsibility are distinct from competency. Jane Doe may be competent to head several departments, but is assigned to head one of them.
3. Roles can reflect specific duty assignments that are rotated through multiple users, e.g., a duty physician or shift manager.
   

Shift in application of RBAC: access control in mainframes, network OSs (Novell's NetWare, Windows NT) -> RBAC in application level (is application specific; challenge is to find application-independent facilities that are sufficiently flexible, yet simple to implement and use, to support a wide range of applications with minimal customization)

RBAC directly supports three well-known security principles: least privilege, separation of duties, and data abstraction. (least privilege and separation of duty have already been discussed) Data abstraction is supported by means of abstract permissions such as credit and debit for an account object, rather than the read, write, execute permissions typically provided by the operating system. However, these principles must be directly implemented by security officer; they are not automatically enforced by RBAC.

RBAC is not a panacea for all access control issues. More sophisticated forms of access control are required to deal with situations where sequences of operations need to be controlled. For example, a purchase requisition requires various steps before it can lead to issuance of a purchase order. RBAC does not attempt to directly control the permissions for such a sequence of events. Other forms of access control can be layered on top of RBAC for this purpose. (task based access control?)

Roles vs compartments
Compartments are a part of the security label structure as used in the classified defense and government sectors. (compartment = sensitivity? top secret, restricted, confidential, etc.)
Similar because they both restrict access (to the information) to those who proper permission(?).
However, the use of compartments is for the specific policy of one-directional information flow in a lattice of labels. Roles do not presume a particular policy of this kind.

Family of reference models

RBAC0 - minimum requirement for any system that professes to support RBAC
RBAC1 - adds the concept of role hierarchies (situations where roles can inherit permissions from other roles)
RBAC2 - adds constraints (which impose restrictions on acceptable configurations of the different components of RBAC)
RBAC3 - includes RBAC1 and RBAC2

RBAC0

• user
• role
• permission - authorization, access right, privilege
  
  • permissions only apply to data and resource objects and not to the components of RBAC itself (administrative permissions)
• session - a user establishes a session during which the user activates some subset of roles that he or she is a member of
  
  • a user may have multiple subjects (or sessions) with different permissions active at the same time
• duty - obligation on a user's part to perform one or more tasks, which are generally essential for the smooth functioning of an organization
  
  • One approach is to treat them as similar to permissions. Other approaches could be based on new access control paradigms such as task-based authorization.
  
  

RBAC1
Mathematically, these hierarchies are partial orders. A partial order is a reflexive, transitive and anti-symmetric relation. Inheritance is reflexive because a role inherits its own permissions, transitivity is a natural requirement in this context, and anti-symmetry rules out roles that inherit from one another and would therefore be redundant.

Note that a user is allowed to establish a session with any combination of roles junior to those the user is a member of.


role hierarchy:

user is a primary-care physician
user can still establish a session as physician and(?)/or health-care provider


Private role
role hierarchy:

*test engineers wish to keep some permissions private to their role and prevent their inheritance in the hierarchy to project supervisors
**use private roles



***in some systems the effect of private roles is achieved by blocking upward inheritance of certain permissions
(private roles seem clumsy, or maybe it's just the naming - test engineer and test engineer')



RBAC2
Constraints allow the management of RBAC to be decentralized. They allow senior security officers to restrict the ability of users who can exercise administrative privileges, enabling the chief security officer to lay out the broad scope of what is acceptable and impose this as a mandatory requirement on other security officers and users who participate in RBAC management.

Constraints are defined on user assignment to roles (UA) and/or(?) permission assignment to roles (PA).

Mutually exclusive roles
Consider two mutually exclusive roles, accounts-manager and purchasing-manager. Mutual exclusion in terms of UA specifies that one individual cannot be a member of both roles. Mutual exclusion in terms of PA specifies that the same permission cannot be assigned to both roles.

Cardinality constraints
There is only one person in the role of chairman of a department.
Similarly, the number of roles to which an individual user can belong could also be limited.
Correspondingly, the number of roles to which a permission can be assigned can have cardinality constraints to control the distribution of powerful permissions.

(It should be noted that minimum cardinality constraints may be difficult to implement. For example if there is a minimum number of occupants of a role, what can the system do if one of them disappears? How will the system know this has happened?)

Prerequisite roles
UA - A user can be assigned to role A only if the user is already a member of role B.
PA - Permission p can be assigned to a role only if that role already possesses permission q. For instance, in many systems permission to read a file requires permission to read the directory in which the file is located.

Constraints on sessions
It may be acceptable for a user to be a member of two roles but the user cannot be active in both roles at the same time.
Other constraints on sessions can limit the number of sessions that a user can have active at the same time.
Correspondingly, the number of sessions to which a permission is assigned can be limited.



RBAC3
Constraints can apply to the role hierarchy.
- limit the number of senior (or junior) roles that a given role may have
- two or more roles can also be constrained to have no common senior (or junior) role

Suppose that test engineer and programmer roles are declared to be mutually exclusive in previous figure. The project supervisor role violates this mutual exclusion. It would depend on a case by case basis if this would be allowed.

For cardinality constraints, do they apply only to direct membership, or do they also carry on to inherited membership?

Private roles
The shared counterpart of the private roles can be declared to have a maximum cardinality constraint of zero members. In this way test engineers must be assigned to the test engineer' role. The test engineer role serves as a means for sharing permissions with the project supervisor role.




Management model

It is intended that administrative roles AR and administrative permissions AP be respectively disjoint from the regular roles R and permissions P. The model shows that permissions can only be assigned to roles and administrative permissions can only be assigned to administrative roles. This is a built-in constraint.

How about management of the administrative hierarchy?
- create second level to manage first level, etc etc.
- left to a single chief security officer

One of the main issues in the management model is how to scope the administrative authority vested in administrative roles (which administrative role can manage which part of the model/role hierarchy).




Research directions
- design and analysis of role hierarchies
- categorization and taxonomy of constraints
- formal notation for stating and enforcing constraints, along with some measure of difficulty of enforcement
- ability to reason about constraints and analyze the net effect of an RBAC configuration in terms of higher-level policy objectives
- development of a systematic methodology that deals with the design and analysis of role hierarchies, constraints, and RBAC management in a unified framework

D. Ferraiolo, D. Kuhn. 1992. "Role-Based Access Controls"

(some notes on the paper since most of the information overlaps with other notes)

Like DoD agencies, civilian government and commercial firms are very much concerned with protecting the confidentiality of information... But many of these organizations have even greater concern for integrity.

An organizational meaning of security cannot be presupposed. Each organization has unique security requirements.

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.

The determination of membership and the allocation of transactions (permissions) 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.

RBAC	MAC
more concerned with access to functions and information	more concerned with access to information
"who can perform what acts on what information"	"who can read what information"

Transaction (permission) clarification: "read" is not a transaction, because it is not bound to a particular data item. "read savings file" is.

RBAC applications

• database system - using roles to control access


• cryptographic authentication devices commonly used in the banking industry


• proposed standard by NIST, "Security Requirements for Cryptographic Modules," that will require support for access control and administration through roles

Role based access controls described in this paper address security primarily for application-level systems, as opposed to general purpose operating systems. (RBAC can be applied in OSs)


Formal description of RBAC

1. Role assignment: A subject can execute a transaction only if the subject has selected or been assigned a role


2. Role authorization: A subject's active role must be authorized for the subject


3. Transaction authorization: A subject can execute a transaction only if the transaction is authorized for the subject's active role
   
   • 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 the set of transactions potentially executable by the subject's active role.

It is 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.

4. for every s: subject, t: tran, o: object, (exec(s,t) is true if access(AR(s),t,o, x))

access(r, i, o, x) 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.

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. (unclear why it can't be achieved using original 3 rules)

Enforcing integrity through RBAC
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.

Static vs dynamic separation of duty

Static	Dynamic
no individual who can serve as payment initiator could also serve as payment authorizer.	an individual can take on both initiator and authorizer roles, with the exception that no one could authorize payments that he or she had initiated.
may be too rigid for commercial use, making the cost of security greater than the loss that might be expected without the security.	more flexible
could be implemented by checking only roles of users	could be implemented by checking both role and user ID

http://en.wikipedia.org/wiki/Role-based_access_control

RBAC differs from access control lists (ACLs) used in traditional discretionary access control systems in that it assigns permissions to specific operations with meaning in the organization, rather than to low level data objects. (ACL authorizes read/write access to a file, RBAC authorizes what fields in the file can be read/write, for example)


RBAC model

• S = Subject = A person or automated agent
• R = Role = Job function or title which defines an authority level
• P = Permissions = An approval of a mode of access to a resource
• SE = Session = A mapping involving S, R and/or P
• SA = Subject Assignment
• PA = Permission Assignment
• RH = Partially ordered role Hierarchy. RH can also be written: ≥ (The notation: x ≥ y means that x inherits the permissions of y.)
• Many to many relation for subject-role and role-permission.

A constraint places a restrictive rule on the potential inheritance of permissions from opposing roles, thus it can be used to achieve appropriate separation of duties. For example, the same person should not be allowed to both create a login account and to authorize the account creation.

• PA is a subset of P X R
• SA is a subset of S X R
• RH is a subset of R X R

(What is the organization for?)

With the increasing complexity of organizations, using RBAC becomes extremely complex without hierarchical creation of roles and privilege assignments. Alternatives to RBAC are being researched. There are also newer systems that extend the RBAC model to address its limitations.

http://en.wikipedia.org/wiki/Access_control

In any access control model, the entities that can perform actions in the system are called subjects, and the entities representing resources to which access may need to be controlled are called objects (see also Access Control Matrix). Subjects and objects should both be considered as software entities, rather than as human users: any human user can only have an effect on the system via the software entities that they control. Although some systems equate subjects with user IDs, so that all processes started by a user by default have the same authority, this level of control is not fine-grained enough to satisfy the Principle of least privilege, and arguably is responsible for the prevalence of malware in such systems (see computer insecurity).


Attribute-based Access Control

In attribute-based access control, access is granted not based on the rights of the subject associated with a user after authentication, but based on attributes of the user. The user has to prove so called claims about his attributes to the access control engine. An attribute-based access control policy specifies which claims need to satisfied in order to grant access to an object. For instance the claim could be "older than 18" . Any user that can prove this claim is granted access. Users can be anonymous as authentication and identification are not strictly required. One does however require means for proving claims anonymously. This can for instance be achieved using Anonymous credentials.

CS 253 Access Control Notes

Access control - generic term for the process(es) by which a computer system controls the interaction between users and system resources

Why use access control?

• to limit access of users (authorized and unauthorized) to system resources; unlimited access is undesirable

Principle of Least Privilege

• assignment of permissions to users such that the user is given no more permission than is necessary to perform his or her job function

Difficulties:

• job functions and all their required permissions must be identified
• an individual can have different permissions at different times; difficult to maintain
  

Reference monitor

• an entity(?) that makes decisions on whether to grant or deny access
• completeness: it must always be invoked and impossible to bypass (component of kernel in OS?)
• isolation: it must be tamper proof (securely coded?)
• verifiability: it must be shown to be properly implemented (fully tested?)
  

There are two entities in an access control model: subject and object.
A subject can observe (read) an object: flow of information is object -> subject.
A subject can alter (write to) an object: flow of information is subject -> object.

*Execute - neither read nor write
Has different meanings in different contexts in different systems.

• execute access to a binary executable file grants permission to runs the program
• execute access to a Unix directory grants permission to search the contents of the directory
  

Building a Secure System
1. Identify security requirements

• Low priority users cannot read high priority documents.

2. Develop logical model of system

• How do we represent "low" and "high" in abstract terms?
• How do we represent "users" and "documents" conceptually?
  

3. Implement system

• What data structures do we use to store security information about users and documents?
• How do we identify users and documents within systems?
  

Why are models useful?

• formal results can be deduced from the model that make statements about the security of the system
• a model may also generate rules that can provide a blueprint for an implementation
  

Access Control Matrix

• introduced by Lampson (1972) and extended by Harrison, Ruzzo and Ullman (1976-8)
• columns indexed by objects
• rows indexed by subjects
  

Disadvantages

• not suitable for direct implementation
• the matrix is likely to be extremely sparse and therefore implementation is inefficient
• management of the matrix is likely to be extremely difficult if there are 0000s of files and 00s of users (resulting in 000000s of matrix entries)
  

Access Control List

• an ACL corresponds to a column in the access control matrix
• typically implemented at OS level
  
• disadvantage: hard to check the access rights of a particular subject efficiently

Capability List

• a capability list corresponds to a row in the access control matrix
• typically implemented at application level
  
• disadvantage: hard to check which subjects can access a given object efficiently

Discretionary Access Control (DAC)

• creators or owners of files assign access rights, and a subject with discretionary access to information can pass that information to another subject
• inapplicable to a military setting, where access rights to objects/documents are mandated by classification levels (Top Secret, Secret, Confidential, Restricted, Unclassified)
  

Mandatory Access Control (MAC)

• a mandated set of accesses on all objects of the system
• since rules are defined externally, users cannot assign access rights, as compared to DAC
  

DAC and MAC are unsuitable for commercial requirements. (why?)



Role Based Access Control (RBAC)

• access to computer system objects is based on a user’s role in an organization

Role

• acts as a bridge between users and objects; all access to objects must go through roles
  
• essentially a collection of permissions
  

3 Basic Rules:

• Role assignment - a subject can execute a transaction only if the subject selected, or has been assigned to, a role (logging in is not a transaction)
  
• Role authorization - a subject’s active role must be authorized for the subject
• Transaction authorization - a subject can execute a transaction only if the transaction
  is authorized for the subject’s active role

Why use roles?

• Roles within an organization are relatively stable, while users and permissions are numerous and may change rapidly. Therefore, it makes sense to control access through roles.

Roles vs Groups

• a role will always exhibit the properties defined by the RBAC model; a group may or may not exhibit these properties

Similarities	Differences
a role can represent a collection of users a user can be a member of multiple roles a single privilege can be associated with one or more groups or roles a single group or role can be associated with one or more privileges	within some UNIX environments, only one group can be associated with a particular file other operating system environments allow multiple groups to coexist among the access control entries of a file other access control systems prevent a user from being a member of more than one group at a time

Permissions - the binding between computer operations and resource objects






Granularity of method

• a teller role needs to be able to perform a savings deposit operation – which requires read and write access to specific fields in the savings file
• an account supervisor that is allowed to perform correction operations – which also requires read and write operations to the same fields, but the supervisor should not be able to initiate withdrawals or deposits

Granularity of access

• a pharmacist might need to access a patient’s record to check for interactions between medications and add notes on the medication
• however, they should not be able to read or alter other parts of the patient record

Subjects

• a subject is an entity that has access to roles, operations, and objects
• subjects act in behalf of users (users don't necessarily have direct access to roles)
  
• subjects have a unique identifier which is used to check their authorization
• many to many correspondence between users and subjects

Role hierarchies

• individual roles within an organization have overlapping functions
  
  • example, there are general functions performed by all or most users within an organization
  • without role hierarchy, these functions would need to be defined for all roles
  • using role hierarchy, these functions could be defined for only a single role which other roles would inherit
    
• role inheritance
  
  • if a role A inherits role B, it means that all of B’s permissions are available via role A
  • in other words, B’s permissions are a proper subset of the permissions of A

RBAC vs DAC

• end users do not own the information to which they are allowed access, as assumed by DAC; organization or government are the owners
  
• may not be appropriate to allow users to give access rights to information
• with RBAC, access decisions are based on the roles individual users have as part of an
  organization

RBAC vs MAC

• traditional MAC supports military policies for unauthorized access to classified information, particularly to the protection of the confidentiality of sensitive information
• RBAC is usually put in place to enforce confidentiality, or integrity, or both

Efficiency of RBAC - since there is usually a direct relationship between the cost of administration and the number of associations that must be managed, RBAC can help organizational efficiency by reducing the amount of associations that must be managed


Well-formed transactions - constrain the user to change data only in authorised ways thus ensuring that all data that starts in a valid state will remain so after the execution of the transaction

• a bank teller cannot modify an arbitrary part of a customer record, only those data fields that are incorporated into the particular transaction being run, such as a savings deposit or withdrawal

Separation of duty - prevents any one individual possessing all the privileges required to carry out a sensitive transaction

• a division manager, for example, can request an expenditure, but another person must approve it, and a third audits the completed transaction to ensure that fraud has not occurred

Clark-Wilson model

• user
• transformation procedure (TP)
  
• constrained data item (CDI) - an object for which integrity must be preserved
• unconstrained data item (UDI) - not protected by integrity model
• integrity verification procedure (IVP) - ensures that a data item is in a valid state
• Certification rules
  
  1. IVPs must ensure that all CDIs are in a valid state.
  2. Each TP must be certified to be valid (that is, valid CDIs must be transformed into valid CDIs by the TP) and must be certified to access a specific set of CDIs.
  3. The access rules must satisfy any separation of duty requirements.
  4. All TPs must write to an append-only log.
  5. Any TP that takes a UDI as input must either convert it into a CDI or fail.
• Enforcement rules
  
  1. The system must maintain and protect the list of CDIs that a TP is certified to access.
  2. The system must maintain and protect the list of TPs that a user can execute.
  3. The system must authenticate each user requesting the use of a TP.
  4. Only a certifier of a TP can change the certification. The certifier must not be allowed to execute the TP.