Access Control in Database Management Systems

e-mail: cvrcek@dcse.fee.vutbr.cz

1. Introduction

Design of secure DBMS assumes identification of security risks and selection of right security policies (what is the security system supposed to do) and mechanisms (the way we are going to achieve that) for their neutralization.

Secure database system should satisfy three basic requirements on data protection: security, integrity and availability. What is the content of those words?

• Ensuring security - preventing, detecting and deterring improper disclosure of information. This is especially important in strongly protected environments (e.g. army).
• Ensuring integrity - preventing, detecting and deterring improper changes of information. The proper function of any organization depends on proper operations on proper data.
• Ensuring system availability - effort for prevention of improper denial of service that DBMS provides.

1.1. Security Policies

Generally, policies should give answers on basic security questions. Policies can be divided into two basic types - of minimal (army) and maximal (university) privilege. System with such a policy is called closed or opened, respectively.

Talking about access control, the way of administration of access rules should be determined.

• hierarchical decentralized - central authorizer distributes responsibilities among dependent subauthorizers
• ownership based - owner of an object (its author) determines access to the object
• cooperative authorization - authorization of special rights for special resources is approved by all members of predefined group

1.2. Security Mechanisms

• administrative controls
• physical controls

• authentication - user identity is verified; this process is based on knowledge of something, ownership of an object or on physical characteristics of user
• authorization - system answers only those queries that user is authorized for (access control)
• audit - is composed from two phases; logging of actions in the system and reporting of logged information

1.3. Security Threat

• natural or accidental disasters- earthquake, water damage or fire. As data as hardware is damaged which leads to the integrity violence and service rejection.
• errors and bugs in hardware andsoftware - causes improper application of security policies.
• human errors - unintentional violations such as incorrect input or wrong use of applications.

• authorized users - abuse there privileges
• hostile agents - various hostile programs - viruses, Trojan horses, back-doors

1.4. Requirements on DBMS Security

1. Protection from improper access- only authorized users should be granted access to objects of DBMS. This control should be applied on smaller objects (record, attribute, value).
2. Protection from inference - inference of confidential information from available data should be avoided. This regards mainly statistical DBMSs.
3. Database integrity - partially is ensured with system controls of DBMS (atomic transactions) and various back-up and recovery procedures and partially with security procedures.
4. Operational data integrity - logical consistence of data during concurrent transactions (concurrency manager), serializability and isolation of transactions (locking techniques).
5. Semantic data integrity - ensuring that attribute values are in allowed ranges. This is ensured with integrity constraints.
6. Accountability and auditing - there should be possibility to log all data accesses.
7. User authentication - there should be unambiguous identification of each DBMS user. This is basis for all authorization mechanisms.
8. Management and protection of sensitive data - access should be granted only to narrow round of users.
9. Multilevel security - data may be classified according to their sensitivity. Access granting should then depend on that classification.
10. Confinement (subject isolation) - there is necessity to isolate subjects to avoid uncontrolled data flow between programs (memory channels, covert channels).

• flow control - we control information flows in frame of DBMS
• inference control - control of dependencies among data
• access control - access to the information in DBMS is restricted

1.4.1. Flow Control

Flow control policies need list of acceptable information flows and their constrains. Flow constraints are often based on classification of system elements and definition of acceptable flows between classification levels.

1.4.2. Inference Control

1. correlated data - typical channel when visible data X are semantically related with invisible data Y
2. missing data - result of query contains NULL values that mask sensitive data. Existence of that data may by detected that way.
3. statistical inference - typical for databases that provide statistical information about entities.

1. data perturbation - concrete data are replaced with statistical results
2. query controls - more frequently used, mostly it is based on minimal and maximal number of items that are concerned with query. Results are satisfactory but this technique is expensive and difficult for administration.

1.4.3. Access Control

For better image look at the figure of secure DBMS.

Fig.1 Schema of secure database management system

2. Security Models

Security model should provide rich semantic representation which allows description of functional and structural properties of security system. It should also provide definitions for protection requirements and system policies. The proof of model properties should be available, too.

It is clear that level on which we decide to describe access control can greatly differ as we will see in the next paragraph. Description of basic approaches for access control is introduced in chapter 2.2. Description of concrete models follows.

2.1. Abstractions of Access Models

1. trust objectives - definition of basic requirements on the system trustfulness
2. requirements on external interface - security requirements on interface system-environments
3. internal requirements - requirements that must be satisfied in system components
4. operational rules - describe assurance of internal requirements
5. functional design - functional description of behavior of system components

2.2 Types of Access Control Models

Two basic model types arised very soon - discretionary and mandatory access control. Owner of data governs access in the former one. This is the most common form of authorization administration - ownership based. That policy is very flexible but also very difficult for control from the global point of view. Models with mandatory access control enforce global policy by the flow control among security levels that are assigned to objects.

It seemed that nothing else would exist but OO technologies have encourage new approaches that reflect OO DBMSs and new requirements of commercial sphere. The first one is RBAC - access control based on roles and the second one is TBAC which is based on concept of task. TBAC brings absolutely new ideas and notion of active security.

We finish this introduction and try to describe policy types on concrete models.

2.3. HRU - Matrix Access Model

2.3.1 Authorization State

Authorization state for DBMS can be enriched by predicates of access rights. Those predicates may by data, time, context or history dependent.

Six primitive operations are defined for authorization state administration. They are granting and revoking of rights r from A[s, o], creating and deleting of subject s, creating and deleting of object o. Operations are used for composition of commands for authorization state modifications. Harrison assumes that modification commands have two parts; conditional and executive. The executive part is performed when the conditional is true.

Set of possible access rights depends on object. The model knows read, write, append, execute, own. The last one determines owner that administers access to it.

2.3.2 Administration of Authorizations

There are modifications of access rights in some systems that allow other subjects to administer access rights. This is expressed by explicit flag on access right that may have two forms.

• copy flag - m* in A[s₁, o] allows grant an access right m for object o to other subjects, rights of subject s₁ do not change and subject s₂ receives right m for object o


Fig. 2. Use of copy flag

• transfer flag - subject s₁ grants right m for object o to subject s₂, subject s₁ loses the right. Subject s₁ has got m⁺ (with transfer flag)


Fig. 3. Use of transfer flag

2.3.3 Model Extensions

The model has been extended several ways for security question decidability.

• Schematic protections model (Sandhu)
• Extended schematic protection model (Ammann and Sandhu)
• Typed access matrix (TAM) model (Sandhu) - each object and subject has a type that is assign with creation of entity and it does not change during lifecycle.

2.4. Bell-LaPadula Model

2.4.1 Classification of System Elements

The classification is fully ordered set of four elements - {TS, S, C, U} (from the biggest). The set of categories is a subset of non-hierarchical set of elements that corresponds to application area and environment. The security levels with operation ? compose lattice that is defined by the following way:

L₁=(C₁, S₁) ? L₂=(C₂, S₂) ? C₁ ? C₂ ? S_{1 ?} S₂

Each user has got clearance and may work in the system on any level that is dominated (lower or equal) by clearance. Each object receives security level during its creation.

There are four access rights: read-only, append (can not see existing content), execute and read-write.

2.4.2. System State

• b - actual access set - set of triples <subject, object, access right>
• M - access matrix which describes subjects’ access rights to objects (see. HRU model)
• f - level function that associates security level with every object and subject in the system f: O? S® L each object has got security level f_o each subject has got two security levels, one is security clearance (f_s) and the second is actual security level on which the subject actually works (f_c)
• H - actual object hierarchy - oriented rooted tree that nodes represent objects in the system; there are no unavailable objects (compatibility property - security level of son dominates security level of its father)

2.4.3. Axioms

Simple security (ss) property

Trusted subject can read or write an object just when its security clearance dominates security level of the object. System state v=(b, M, f, H) satisfies ss-property when each element of M[s, o] that keeps read or write access right satisfies f_s(s) ? f_o(o).

Star (*) property

Any subject may keep access right append on object when security level of the object dominates actual security level of subject. This subject may write the object just when level of object equals to level of security subject and subject may read the object when object’s security level is dominated by subject’s security level. The formal notation is as follows:

Let s Î S, SÍ S, where S is set of untrusted subjects; then

No read-up - I can read just objects that security level is dominated by my security level.

No write-down - I can write just objects that security level dominates my security level.

Discretionary security property (ds-property)

Each actual access must be in the access matrix. Subject may perform only those accesses that he has got access rights for. The system state guarantees the ds-property just when the following equation holds for all subjects, objects and access rights:

<s, o, m> Î b ? m Î M[s, o]

3. Conventional models for OO DBMS

Models have been accommodated by new definitions of objects, subjects and access rights and have employed some features of OO data models - inheritance, composite objects. Strong influence of relational data model however stayed. Above all, the access matrix that is ideal for relation data model but it has got nothing to do ”with objects” in my opinion. The ORION model belongs to that category. Next paragraphs introduce models that exploit other important features of OO data model - messaging and encapsulation.

3.1. Authorization model ORION

3.1.1. System Elements

Objects are databases, classes in databases, instances of classes and their components and also sets of instances of a given class or sets of attributes. Objects compose a lattice (system, databases, classes, ...).

3.1.2. Access Rights

A.up - rights are propagated from low objects upto high ones, A.up={WA, RD}
A.down - rights are propagated from high objects to low ones, A.down={W, R}
A.nill - access rights that are not propagated, A.nil={G}

Access rights are specified by users. Because there are no administration rights, the access right implies administration of itself.

The system automatically derives implicit authorizations from the explicit ones with use of relations among subjects, objects and access rights. Access rights can be positive/negative and strong/weak. The latter classification divides authorizations into two sets.

Strong authorization base (AB)
There is defined function i: S x O x A ® (True, False, Undecided), over the set. This function does not have to decide the access granting. Two properties must stay true:

• consistency property AB

if $ (s, o, a): (s, o, a) ® (s₁, o₁, a₁) ? $ ! (s₂, o₂, a₂): (s₂, o₂, a₂) ® (s₁, o₁, a₁)
• nonredundancy property AB

if $ (s, o, a): (s, o, a) ® (s₁, o₁, a₁) ? (s₁, o₁, a₁) ? AB

• completeness property WAB

for " [s, o, a] $ [s₁, o₁, a₁] Î WAB: [s₁, o₁, a₁]® [s, o, a]
• consistency property WAB

for " [s, o, a], if $ [s₁, o₁, a₁] Î WAB: [s, o, a] ® [s₁, o₁, a₁] ?
$ ! [s₂, o₂, a₂] Î WAB: [s₂, o₂, a₂]® [s₁, o₁, ? a₁]

3.2 Message Filter Model

3.2.1 Entities

1. L(o) ? L(c), o is object of the class c
2. L(c_s) ? L(c_p), c_s is subclass of the class c_p

Special object type is user session, which represents a user. This object may, in contrast to other objects, execute methods from its own initiative.

3.2.2 Information Flow

All messages can be decomposed down to three primitive messages that are sent by object to itself. They are read (g=(READ, (a_i), r)), write (g=(WRITE, (a_j, v_j), r)) and create (g=(CREATE, ((v₁, ..., v_k), S_j), r)).

3.2.3 Algorithm of Message Filtering

This criterion is used for the filtering according to the following description:

1. non-primitive message, o₁® o₂

4. Role-Based Access Control

This approach offers very suitable abstraction for expression of security policies of large companies and seems to be promising alternative to the traditional MAC and DAC models. RBAC is suitable for environments where MAC models are too strict. It has been proofed that RBAC can simulate mandatory access models and, in addition, that MAC models are specific case of RBAC.

One may say that RBAC is based on something that is very similar to groups that are used in many older models. Groups of users are used to associate subjects with the same access rights. Such a group does not represent a role but common needs for execution of certain system actions. Roles in RBAC exploit groups to abstract access rights needed for some concrete actions that are later accessible for role members.

Narrow, specific meaning of roles can not exhaustively express status of users. It seems that for effective implementation of role-base access control we need to define three aspects. They are role, individuality and locality. I demonstrate it on an example when a firm engages a new person - Smith. His position is seller (it is his role). During the trial period you do not want him to do transactions with banks (individuality) and finally you do not want him to access your system elsewhere than in New York (locality).

What are the advantages of the system? You are not bound during the policy selection, model offers strict separation of duties, ease expression of organizational policy and of course easy access rights administration.

5. Task-Based Authorization Control (TBAC)

Disadvantages of all other models from the view of TBAC are centralistic oriented (central common resources), access rights are very primitive and without relation to actual system state. Also there are no records about use of access rights.

Clearance is expressed as signature of a form in the real world. The given person undertakes responsibility for actions that are allowed with the signature. All relevant actions are automatically disabled after the signature expirates. The aim of TBAC models is to decrease demands of administration in large and complex systems and shift this administration to the described idea.

New notion - authorization step has been introduced for this purpose. It is analogy of a form. Creation of the authorization step means change of system authorization state (a given subjects is granted access rights) for the given time and for the given authorization step. Authorization state can be expressed with the following equation:

Each authorization step has got its own authorization state. The initial state contains set of access rights of maximal size. This size is decreasing during lifetime of the authorization state.

Because authorization steps are not in the system isolated there are defined relations that can be used for expression of security policy.

A₁^state1 ® A₂^state2 if A₁ goes to state1, A₂ must go to state2
A₁^state1 < A₂^state2 if A₁ goes to state1 and A₂ go to state2 then A₁ must do it first
A₁^state1 # A₂^state2 if A₁ is in state1 then A₂ must not be in state2 and vice versa
A₁^state1 ||| A₂^state2 A₁ must be in state1 if A₂ is in state2

Note: A₁, A₂ are authorization steps and state1 and state2 are states of steps A₁, A₂.

6 References