Access Control

                

1. Role of access control

Definition:  Access control evaluates access requests to the resources by the authenticated users and, based on some access rules, it determines whether they are granted or denied.

It consists of two parts:  

(1) authorization administration: decide authorization rules;

(2) reference monitor: given an access request, determine whether it is authorized or not (according to authorization rules).

It relies on another security service – Authentication.


2. Conceptual model and implementation
Conceptual model : access matrix

It involves three concepts: a subject is a user or a process run by a user; an object is resource or data in system; access rights are possible operations on the objects, such as read, write in operating system.  

The access matrix specifies the access rights that each subject has for each object. There is one column for each object and one row for each subject. Each cell of the matrix specifies the access rights authorized for the subject in the row to the object in the column.

There are some theorems about the decidability of system safety. Generally, to determine a system is safe or not is undecidable ([McLean]).

 

Implementation:

(Access matrices are usually sparse, and rarely implemented as matrices.)

(1) access control lists (ACL): each object is associated with an ACL, storing all subjects that can access it and its access rights. (storing the matrix by column)

(2) capabilities:  storing the matrix by row

(3) table: usually in the database system

3. Access control policies:

 

An access control policy is high level guidelines which determine how accesses are controlled and access decisions are made. Although numerous access control models and systems have been proposed, there’re mainly three access control policies.

 

(1)   DAC(Discretionary Access Control)

DAC decides the access rights of users simply based on the access matrix. It is “discretionary” in the sense that it allows user to grant other users authorization to access the objects. It has the drawback that it is easy to bypass the access restriction and pass the information to unauthorized user.

Trojan horse problem:  There are a high level user A and a low level user B in the system, and a table T which only A can read. Suppose B is malicious and give a Trojan horse program to A which on the surface does some useful work. Now A runs the program, but without the notice of A, the program reads T and writes the content to another table T’ which B can read. Thus the information in T is leaked to unauthorized user B.

 

 (2) MAC (mandatory access control) which protects data against Trojan horse
   Bell-LaPadula model

   each subject or object has a security level: Top Secret, Secret, Confidential, Unclassified (TS>S>C>U)

   Read-down: a subject S has read access to an object O if and only if  level(S) >= level (O);

   Write-up:     a subject S has write access to an object O if and only if  level(S) <= level (O);

   How it fixes Trojan horse problem:  if T’ has high security level, then B can not read it; if it has low security level, the Trojan horse program, which has the same high security level as A, cannot write it.

MAC enforces one-directional information flow (also called lattice model). [Sandhu] provides a review about lattice models.

 

 (3) RBAC (role-based access control)

   RBAC introduce the notion role: access rights are specified between objects and roles; a user is associated with one or many roles. Roles can be viewed as a set of actions and responsibilities with a particular working activity.

 

4. Example access control models/systems:

 (1) UNIX

UNIX provides primitive access control.

Policy: DAC;

Authorization rules: Each user belongs to one group. There are three categories of users: the owner of the file, the group the owner belongs to; all the others;

Administration interface: chmod;

Implementation: ACL (9 bits).

 

(2)   Seaview, a relational database with MAC (multi-level DB) [Lunt et al.]

Policy: MAC;

Authorization rules: each user or object (relation/ tuple/ attribute/ elements or attribute value) has a security level: TS, S, C or U.

Each attribute in the original table is associated with a security level, and each tuple also has a security level.

Example:

 

Flight

C1

Departs

C2

Dest

C3

T

964

U

1040

U

Chicago

U

U

75

U

1400

U

Berlin

S

S

1125

S

1730

S

S. S.

S

S

 

Read-down: a user can only read those data with lower or equal security level;

Write-up:     an object written by a user S has the same security level as S.

So a user of security level S or TS can see the whole table, while what a user of level U sees looks like this:

 

964

U

1040

U

Chicago

U

U

75

U

1400

U

Null

U

U

 

Other constraints like: security levels of primary keys must be the same, and be dominated by those of non-key attributes (to ensure integrity).

 

Implementation:

Decompose the relation into single level relations. Storage is divided into 4 segments. All data with the security level i is stored in segment i. A multi-level relation is a view over several single-level relations. (Information about a relation (primary key, length, attributes etc)  is stored in the level of the relation.)

reference monitor:  simply compare the level of the user with the level of the segment which he request to access.

 

(3)   XML access control with DAC.

 I didn’t have time to talk about this example today. If you are interested, you may look at [Damiani et al.].

 

References:

[Sandhu and Samarati] Access Control: Principles and Practice

[Lunt et al.] The Seaview security model.

[McLean] Security models.

 

 

Ying Xu (xuying@stanford.edu)