Access Control: Principles

and PracticeReference: Access Control: Principles and

Practice, Ravi S. Sandhu and Pierangela

Samarati, IEEE Communications Magazine,

1994

Prepared by: Nabeel Mohamed

Access Control

The purpose is to limit that the operations or actions that a legitimate user of a computer system can perform

Constrains◦ What a user can do directly, and

◦ What programs executing on behalf of users are allowed to do

Thus, tries to prevent activities that could lead to a breach of security

Is required to achieve confidentiality, integrity and availability objectives

The Big Picture

The Big Picture

Shows a logical picture of security services and their interactions

Authentication service should correctly establish the identity of the user

Authentication, and then Access Control

Access control is not a complete solution for securing a system. What is the missing service?◦ Auditing

The Big Picture

Auditing

◦ Performs a posteriori analysis of all the

requests and activities of users in the system

◦ Requires logging all requests and activities

◦ How can auditing help?

Acting as a deterrent

Identifying attempted or actual violations

Identifying flaws in the security system

Preventing authorized users from misusing their

privileges (accountability)

Policies vs. Mechanisms

Policies◦ High-level guidelines that determine how

accesses are controlled and access decisions determined

Mechanisms◦ Low-level software and hardware functions

that can be configured to implement a policy

It is desirable to develop access control mechanisms that are largely independent of the policy for which they could be used

The Access Matrix

All resources controlled by a computer system can be represented by data stored in objects

Subjects, which initiate activities in the system, are typically users or programs executing on behalf of users

Subjects can themselves be objects

Subjects initiate actions on objects◦ Actions are allowed or denied in accordance

with the authorization established

The Access Matrix

Example access rights/modes:

◦ For files, the typical access rights are

read, write, execute and own

OS implements them

◦ For bank accounts, the typical access

rights are inquiry, credit and debit

Application programs implement them

The Access Matrix

A conceptual model that specifies the

rights that each subject possesses for

each object

Subjects in rows, objects in columns

The Access Matrix

The access matrix model clearly separates the problem of authentication from that of authorization

A reference monitor should ensure that only those operations authorized by the access matrix actually get executed

Example: Alice is the owner of the file 2, and she can read and write that file

Implementation Approaches

Access matrix is usually sparse and

hence not implemented as a matrix

Some common approaches to

implementing the access matrix in

practice:

◦ Access Control Lists (ACLs)

◦ Capabilities

◦ Authorization Relations

Access Control Lists

Each object is associated with a an

ACL

ACL has an entry of each subject if it

has some kind of access to that object

This approach corresponds to storing

the access matrix by column

Access Control Lists

Access Control Lists

Advantages

◦ By looking at an object’s ACL it is easy to

determine which modes of access

subjects are currently authorized for that

object

◦ Easy to revoke all access to an object

Disadvantages

◦ It is difficult to find all accesses a subject

has

Access Control Lists

In order to reduce the list length, the

usual practice is to use groups instead

of (or in addition to) individual subject

identifiers

Example: UNIX getfacl and setfacl

allows to create ACLs on files and

folders

Capabilities

A dual approach to ACLs

Each subject is associated with a list

(call the capability list)

A capability list of a subject has a list

of objects for which subject has some

kind of access

Capabilities

Capabilities

Advantage

◦ Easy to find all accesses that a subject is

authorized to perform

◦ Easy to revoke all accesses to a subject

Disadvantages

◦ Difficult to find all subjects who have

some kind of access to a given object

Modern operating systems typically

take the ACL-based approach

Authorization Relations

Each row or tuple of the authorization relation specifies one access right of a subject to an object

For example, John’s accesses to File 1 require 3 rows

If the table is sorted by subjects, it reflects capabilities

If the table is sorted by objects, it reflects ACLs

The relation is not normalized

Authorization Relations

Access Control Policies

Discretionary policies

Mandatory policies

Role-based policies

Multiple Access Control Policies

AC policies are not exclusive; can be

combined to provide a more suitable

protection system

When policies are combined, only the

intersections of their accesses allowed

Discretionary Policies

Access control is under the discretion

of the user

Flexibility of discretionary policies has

made them successful in industry

Discretionary Policies

However, they do not provide real assurance on the flow of information in the system◦ It’s easy to bypass the access restrictions

stated through the authorizations

◦ Example: a user, able to read an object, can pass it to other users with the knowledge of the owner

◦ The reason is discretionary policies do not impose any restriction on the usage of information by a user once the user received it (dissemination of information is not controlled)

Mandatory Policies

Access control enforcement is under the control of the system

MLS (Multilevel Security) model is the most popular mandatory approach◦ Access is based on the security levels

assigned to objects and subjects

Each user and each object in the system is assigned a security level

MLS provides one-directional information flow in a lattice of security labels

Mandatory Policies

The security level associated with an

object reflects

◦ The sensitivity of the information

contained in the object

The security level associated with a

subject (also called clearance) reflects

◦ The user’s trustworthiness not to disclose

sensitive information to users not cleared

to see it

Example Security Levels

In a military setting we usually find the following security levels:◦ Top Secret (TS)

◦ Secret (S)

◦ Confidential (C)

◦ Unclassified (U)

They form the ordered set TS > S > C > U

Each security level is said to dominate itself and all others below it in this hierarchy

Confidentiality Policies

Read down◦ A subject’s clearance must dominate the

security level of the object being read

Write up◦ A subject’s clearance must be dominated by

the security level of the object being written

Prevent information in high-level objects (more sensitive) to flow to objects in lower levels

Information can only flow upwards or within the same security domain

Confidentiality Policies

Confidentiality Policies

In order to write at a lower security level, subject should be allowed to take any clearance level dominated by its original clearance level

The intuition behind write-up rule is to prevent malicious software from leaking secret information downwards

Write-up rule may destroy data in higher security levels – Hence, it is usually controlled to work only at the same security level as the subject

Integrity Policies

Read up◦ A subject’s integrity level must be dominated

by the integrity level of the object being read

Write down◦ A subject’s integrity level must dominate the

integrity level of the object being written

Prevent information stored in low objects (hence less reliable) to flow to high objects

Protect only one aspect of integrity Information can only flow downwards or

within the same security level

Integrity Policies

Role-based Policies

Neither discretionary nor mandatory approaches satisfies the needs of most commercial enterprises◦ Mandatory policies rise from rigid

environments, like those of military

◦ Discretionary policies rise from cooperative yet autonomous requirements, like those of academic researchers

One alternative is role-base policies

Role-based Policies

The flexibility required:

◦ Allow the specification of authorization to

be granted to users (or groups) on objects

like in the discretionary approach,

together with the possibility of specifying

restrictions (like in the mandatory

approach) on the assignment or on the

use of such authorizations

Role-based Policies

A role is a set of actions and responsibilities associated with a particular working activity

Instead of specifying all the accesses each user is allowed to execute, access authorizations are specified for roles

Users are given authorization to adopt roles

A user playing a role is allowed to execute all accesses for which the role is authorized.

Role-based Policies

User may or may not be allowed to

play multiple roles at the same time

A user may take on different roles on

different occasions

Advantages of Role-based

Policies Simplification of authorization

management

Hierarchical roles further simplify by allowing generalization and specialization

Adapting different roles to operate at the least privilege

Promotes separation of duty to prevent misuse of the system

Instead of individual objects, access can be specified for object classes

Administration of Authorization

Administrative policies determine who

is authorized to modify the allowed

access

In mandatory AC, security

administrator determines the access

to objects by subjects

In discretionary and role-based AC,

there are possibly many types of

administrative policies

Administration of Authorization

Example DAC administrative policies◦ Centralized – a single authorized user like

in MAC

◦ Hierarchical – authorizers are ordered in a hierarchy with decreasing power

◦ Cooperative – multiple authorizers to specify each access

◦ Ownership – owner of the object controls accesses

◦ Decentralized – delegate authorization to others to control accesses