Problems of Modelling Access Control
for Object-Oriented Databases

Daniel Cvrček*

cvrcek@dcse.fee.vutbr.cz


 


Abstract

Although file services of operation systems are used for archiving and management of majority of information up today, it becomes clear that database management systems take this task over in a few years. There is a certain heterogeneity in the present. It appears that information is saved in a classical file but more exhaustive view discovers that the file is a small database (e.g. files created in MS Office 97).

With respect to growing usage of database systems it is necessary to solve problems related to security (physical and logical). Important segment of logical security are access control models. Problems with their development are charge of this paper. Because of difficulty of design of non-secure database systems, modelling and simulation of access control models is very actual for errorless design of secure database systems. This contribution tries to describe one possible view on the problem solution. It tries to propose process for creation of automatic system for analysis of access control models. It is preliminary study of the problem.

1. Introduction

In analysis of problem of access control models simulation we find out that our advantage is formalisation of majority of access control models. This fact can be potentially exploited for conversion of models into a form convenient for automatic model evaluation and/or verification of its security properties.

The first step that has to be done before we try to design an automatic evaluation system is decomposition of the problem into logically consistent tasks. This phase can be considered as preliminary analysis. At the end of the step following problems can be obtained.

  1. definition of data model
  2. definition of subjects and their dependencies
  3. definition of subject-object dependencies
  4. definition of roles for access control
  5. requirements on data visibility for subjects
  6. automated instrument for creation of representative database instances
  7. devices for automatic consistency evaluation of items 4 and 5
  8. visualisation of evaluation results
In the previous list there are used terms subject and object. Subject is an entity that mediates contact between system and environment (it is typically user). Object is term that comprehends all entities that appear in the data model of database system (data items and methods). Moreover, we can see data items as methods that return values. By this way becomes data model more compact. Objects are thus basic entities of data model.

2. The Data Model

2.1. Selection of Data Model

On the first sight there is nothing to solve. We use object-oriented data model and that is all. But it is not so simple at all. At least for non-existence of unified formal definition of OO data model. One of the possibilities is e.g. definition used for C++ language. Another one is model described in ODMG93 but whole range of possibilities is wide and we can even define our own data model for science purposes.

Surely it is necessary to choose appropriate mathematical model for its definition. The one that could be used in the following steps would be ideal. In that case we would obtain consistent formal model for the whole simulation process. In the following paragraphs we are going to describe relations between sets, set operations, constructions for description of new relations and appropriate predicates.

2.2. Objects and Their Relations

We are interested in object classification and description of object types relations at the place. Object classification means declaration of different object types that can be supported with text description that is meaningless for further processing.

Example:

type: composite_object=object
type: objects=(object)*
;set of objects with 0 up to infinitely many elements

The basic assumption for description of new object types is existence of construction to express new object types by relations with existing ones. To create elegant definition it is necessary to allow definitions of variety relations and predicates.

We define number of objects that are needed for the relation and we use logical implication for dependence on predicate. Notation is simpler by the fact we are interested only in the object structures.

Example:

Proposal of possible relation definition:

relation: name_of_relation (o is type_of_o, o1 is type_of_o1,
o2 is type_of_o2, ..., on is type_of_on)=>p

If object o is in relation name_of_relation with objects o1, ..., on then predicate p is true.

and simple example

relation: inheritance(son is object,
father is object)=>son ? father

Relation inheritance, objects son and father are of basic type object. If son is in relation inheritance with father then structure of the son is subset of father’s structure.

As you can see, definition and expression of object relations is much more interesting. I suppose that we should avoid predefined relations that could bound us while describing data model. So relations described with user defined relations should cover the majority of data model definitions. I thing that such relations can be defined independently on existing operators or relations.

As I have said, for each relation can be defined conditions (predicates) that have to be fulfilled for relation validity. Otherwise, predicates are implied from relation existence.

The result of this step is creation of three important sets. They are: set of objects (O), set of defined predicates (P) and the most important - set of relations that uses the first two sets for description of its elements.

I have thought about other possibilities to narrow relations in the first reasoning. But in the end I have decided that predicates are the simplest way. For example relation of inheritance or object versioning contain conditions (related to the object structures) that have to be true. On the other side, the fact that only structure is important for us simplifies description. So only basic operators for comparison (<, >, =), set operators, appendage to a set, and logical operators are sufficient. So instruments for predicate logic.

Talking about assumptions, the basic object from which all other objects are derived has to be defined by the system.

Example: object - the basic type provided by the simulation system.

type: objects=(object)*
relation: contains(whole is object, part is objects) => son < parent
relation: is_derived_from (son is object, parent is object) => son < parent

2.3. Subjects

This step is much simpler in contrast to the previous one. We have to define subject types and relations between them. The mathematical instrument described above should be rich enough to define lattice or other structure of subjects’ relations. The task is simpler by fact that predicates are not to be used here.

Example:

fig. 1 Example of subject hierarchy

subject: accountant > subject
subject: chef_accountant > accountant
subject: auditor > subject


The result of this step is a set of objects (S) and a set of subjects’ relations. Comparison operators should be sufficient for this purpose.

The fundamental difference from the previous step is object of our interest. We focus on relations of subjects that are not based on subject structure but on their privileges to execute defined tasks in the frame of modelled database system.

Note: If there is not defined a relation between subjects (they are incomparable) then it is supposed that their predecessor (or common subject) is subject that is defined by the system and that is basis for all derived subjects.

2.4. Subject-Object Relations

The last item we concentrate on, during data model definition, is definition of subject-object relations. The only relation that strikes me is ownership of an object by a subject. This relation is defined with creation of the object. I do not want to bound you from defining other relations indeed. They may have various names and meaning.

3. The Access Control Model

In the moment all relations and concepts needed for access control definitions are defined. We have to define rules and axioms of the specified access control model. Then particular relations have to be defined to enable testing of the model properties.

3.1. Rules for Access Control

Access control models consist from axioms that must be fulfilled during the lifetime of the system and from rules that constrain method execution (manipulation with objects) and possible changes of object properties. Properties that are relevant to security of information contained in the object.

Definition of rules for access control is composed from two parts:

a) object access to objects
b) subject access to objects The first item contains rules that constrain allowed behaviour of objects’ methods to other objects in the database system. They define which method can be applied on which objects and also conditions that must be satisfied.

The second set of rules concerns conditions that must be fulfilled to grant a subject access right to perform an operation over an object. Relations between subjects that have been defined above play important role here.

Note: Concepts read, write, execute, append and so on have been used in relation database systems. I am using just execution of a method in this methodology. Such a method can perform whatever action. That is one of the basic principle in object oriented technology.

All properties we need for access control model simulations are defined. At the moment we can, with suitable engine, check consistency of the defined access model.

3.2. Visibility of Data for Subjects

This task is concurrent with the previous one on the first sight. But basic difference is in the purpose. While general rules for access control have been defined above, particular relations are defined here as we assume they look like. We determine what the subject/object should be able to execute. Or more precisely: “We define the way the access control model constrains operations over the database.”

Here is an example for better understanding of this step’s aim. Let’s have a firm that has got concrete idea concerning security properties and access rights of their new information system. Because they have no theoretical knowledge they formulate their requirements with such sentences: “Accountants have full access to information contained in the firm accountancy and they can read information about all payments from other departments.” or “Common employees of personal department can access personal data up to the position of head of department.” and so on.

Access control rules for the database system from the previous step can be synthesised according to those specifications. After we specify those customer requirements for the automated system we can perform consistency check.

Another application of this step can be definition of particular properties that should be true in the designed model. The system can automatically compare actual model properties with these defined.

3.3. Database Instance Creation

We can create representative instance of database on the basis of steps 1) and 3). That instance can be used for testing and simulation of properties of the proposed model. We can create that instance manually, of course. If we are interested in some specific property so we can create an instance with specific properties.

Automatic creation of the database instance is more suitable for the most of the applications. The instance should be so complex to contain all possible (ideal) relations so that the analysis of examined model could be complex and as complete as possible.

This step is on the edge of artificial intelligence. I suppose that instruments that are available are sufficient for implementation of this step.

3.4. Visibility Requirements Check

This step should control the requirements on the access control (chapter 3.1.) with respect to the visibility of data (chapter 3.2.). This control is going to be performed on the database instance created in the previous chapter.

Result of the control should be in the form of text output which would describe occasional inconsistencies between expected and real behaviour of the access control. This description should be formal or semiformal.

3.5. Visualisation of Simulation Results

This step exploits result of the previous ones (chapter 3.3. and 3.4.) for visualisation of simulation results. It should be suitable for demonstration of specific properties of the model.

User could specify request for the database access and on the graphical model should be displayed process of access control for the given request or place on which has been access rejected.

4. Conclusion

Objective of this study is to analyse problems joint with design of an automated instrument for analysis and simulation of access control models. I suppose that the task of design of such a software is possible but there are hidden many theoretical problems. The main problem that waits for solution is going to be ”engine” for processing the model description that will be able to apply that on the database instances.

I suppose this problem is sufficient from the theoretic point of view for thesis that would join more areas (mathematics, simulation, graphics, security).

5. References

[1] Sandhu R.S.: Access Control: The Neglected Frontier. Proc. 1st Australasian Conference on Information Security and Privacy, 1996
[2] Castalo S., Fugini M. G., Martella G., Samarati P.: Database security. Addison-Wesley & ACM Press, 1995
[3] Olivier M.S., Von Solms S.H.: A Taxonomy for Secure Object-Oriented Databases. ACM Transactions on Database Systems, March 1994, pages. 3-46