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.