ACTEN: A conceptual model for security systems design

196

ACTEN: A Conceptual Model for Securitv Systems Design J

1. Introduction

M. Fugini and G. Martella Dipartimento di Elettronica, Politecnico dt Milano, Piazza L.da Vinci 32, 20133- Milano, ITALY

This paper describes ACTEN, a conceptual model for the design of security systems. Security information is represented by action-entity pairs and organized into a framework composed of graphs and tables. The rules permitting the building and management of this framework are introduced. The model describes both static and dynamic aspects of the security system; in fact, it shows the access modalities between objects in the system and the evolution of such modalities due to grant and revocation of rights within the security system. ACTEN also allows the identification of the authority and protection level of each component of the system. The tools for this analysis are introduced and an example is given. Keywords; Privacy, database access control, security tion, security models, access rights management.

database

design

and

informa-

Mariagrazia Fugini received the Dr. Ing. degree in Electronics Engineering from the Politecnico di Milan0 in 1981. Since then she has been with the computer Science Laboratory at the Dipartimento di Elettronica of the Politecnico of Milan where she is currently a research assistant. Her research interests include privacy and security in database and office information systems, and database design. She contributes to the National Council Project on automated methodologies for is a member of the Italian National

Giancarlo Martella received the Dr. Ing. degree in Electronics Engineering from the Politecnico di Milano, Italy, in 1968. Since then he has been with the Computer Science Laboratory at the Dipartimento di Elettronica, Politecnico di Milano, where he is currently Associate Professor of Computer Science. His main research interests are in the field of database security and privacy control, database management, information systems analysis and design. On these topics he has been invited as a guest lecturer in many workshops and conferences, has published books and articles, conducted research and projects in the university environment, organized and conducted post-doctoral courses for technical and management personnel, and has been a consultant to many

North-Holland Computers & Security

0167-4048/84/$3.00

3 (1984) 196-214

0 1984, Elsevier Science Publishers

It is well recognized that the choice of a multiphase methodology for database systems design is one of the most influential factors for the success of the whole design activity [l]. In the field of data protection against unauthorized access in a database environment, a multiphase methodology in the design of security systems allows for defining security information at different levels of detail, starting from the understanding, the description and the analysis of security requirements and policies down to implementation details [2-51. Remarkable relevance is assumed by the conceptual security design phase, which is aimed at representing security relationships [6,7] among the resources in the system, independently of the available Data Base Management System (DBMS) and of security tools and mechanisms. In this phase the designer can concentrate exclusively on the enterprise security requirements and on the semantics of security information [8,9]. The product of this phase is a conceptual security model outlining the structure of the security system in terms of resources, access rights, and constraints. In order to support the conceptual security design phase, a conceptual model is needed, emphasizing the semantic content of security information and being able to reflect security requirements and policies in a clear and natural way. A conceptual model for security must show the system resources involved in security relationships, the access rights distribution among these resources, and how this distribution can change over time by way of grant and revocation of access rights. Many formal models and systems have been large companies and governmental organizations. Professor Martella has received the Cilea-Univac “Informatica ‘80” international award for a research project on data security in information systems, and the “1981 HUSPI Projects International award” for research on automated databases in clinical applications. He is past chairman of the working group on Information System Engineering of the Italian National Computing Society (A.I.C.A.) and a member of IFIP Technical Committee on Security (TCll).

B.V. (North-Holland)

M. Fugini, G. Martella / ACTEN

proposed and applied in the field of data security in database systems [lo-241. In particular, takegrant models [17-201 tackle some of the above discussed aspects. The protection state of a system is expressed by a directed graph where nodes represent subjects and objects, and arcs represent the read, write, take and grant rights. These models underline the access control mechanism and the rights propagation mechanism inside the system, due to the “take” and “grant” access rights. However, there is a weak separation between access rights and propagation rights, and neither selective grant of access rights nor general security constraints can be specified through the models. In [8] the application of the binary model [23] to the problem of monitoring access rights is discussed. The resulting security model, breaking down information into elementary units, is suitable to solve design problems deriving from conflicting security requirements, but appears implementation-dependent and more oriented to the logical design level than to the conceptual one. In this paper, ACTEN, a conceptual security model based on the ACTion-ENtity pair is proposed. An action represents an access right, such as read, insert, append, or the right to grant and revoke access rights. An entity is a system resource (a physical device, a class of users, a data file) which needs to be protected or whose authorization within the system must be restricted. In the model, access and propagation rights are separately represented, so that the safety question [25], i.e. whether a given entity, given an initial state of the security system, can obtain a given access to another, can be easily managed. Rules for abstracting some security properties of the system represented through the model are also included. 0 In Section 2, the goals of the model and its basic elements are introduced. a In Section 3, the model framework and the rules for its manipulation and management are illustrated. 0 In Section 4, an example of the use of the model is given. 2. Conceptual Modeling One of the main goals in the design of a security system is the specification of the entities to be protected and those whose authorization is to be

191

restricted. Furthermore, it is necessary to specify the rules regulating access of entities to other entities, conditions on this access and constraints regarding entities and their behaviour. When examining security requirements and policies, the security designer has to describe all these elements through a security model allowing him to specify entities, access rights and constraints. An additional problem is to examine whether his model matches the real enterprise. This requires to: A. analyze access rights, verify the correctness of the representation of these rights which has been obtained, test the closeness of such representation to the security requirements. This implies: l the examination of direct access rights existing between any two entities in the model, i.e. the operations that one entity is expressly authorized to execute in its interaction with another entity; l the examination of indirect access rights existing between any two entities in the model. These are privileges that some resources hold through chains of direct rights. Let us suppose, for example, the right chain composed of an operator 0, who can run an application program P (direct right), that can update a data file F (direct right). The indirect right is the privilege held by 0 upon F through P, i.e. the operation that 0 can indirectly execute on F through P. In most cases, such operations are neither stated by the security requirements nor easily discerned in the system. Their presence must be checked and it must be verified whether indirect rights create ambiguities or conflicts, or violate security constraints. This problem, known as the control of the access rights flow, can be solved by assigning a level of clearance to each entity according to its role inside the enterprise and according to security constraints. B. monitor the access rights propagation and the security system evolution. This aspect is bound to the presence of grant and revoke rights answering the enterprise’s need to decentralize administrative authority and responsibility among several entities. A solution to the problem of controlling the system dynamics is given by the analysis of the authorization and protection degree of entities and of the changes in this degree due to the acquisition or loss of privileges. The access rights propagation control problem implies consistency rules and mechanisms for the selective grant and revocation of rights (rights selective management).

198

2.1.

M. Fugim, G. Martella / ACTEN

Elements

of the Model

The ACTEN basic element is the action-entity pair which represents security information. An entity Ei is a component of the security system able to execute or undergo an action. Users, application programs, I/O devices and data are examples of entities. An action A is a binary relationship betwen entities of the security system provided with: l direction l one or more attributes called predicates. The direction specifies which of the two entities Ei and Ej involved in A executes the action and which one undergoes it; this is from Ei to Ej if Ei executes and Ej undergoes A. The presence of direction is denoted by A,,, where the indexes i and j refer to entities Ei and Ej and their order to A’s direction. Predicates are conditions on the execution of actions. A can therefore be specified as: A,,=a-

{P*,11

where a is an operation such as READ, UPDATE, etc. and { pi, } is the set of conditions which must be respected while executing a. For instance, the security requirement: “User El can read file E2 from 8h to 12h a.m.” is expressed through the following action A between entities El and E2: A,, = READ - ‘from 8h to 12h a.m.’ where the predicatep,, = ‘from 8h to 12h a.m.’ is a temporal condition on the READ operation. (**).

Entities which are not involved in any action cannot exist in the model. Referring to an entity Ei, two sets of pairs can be identified where: Sa(Ei):{Afj-Ej}

j=l...N j#i

(1)

h, > 1 Sp(Ei):{ApJ-Ej}

j=l...N j#i

(2)

m, >1 l

N is the number of all entities of the model. Sa(Ei) is the authorization state of entity Ei. It is the set of the pairs A:] - Ej, where Afj are the h actions which Ei can execute on Ej. l Sp( Ei) is the protection state of entity Ei. It is the set of the pairs A,:/ - Ej, where A,:) are the m actions which Ei can undergo by Ej. l The number of different values of j in Sa( Ei) is the number ni of all entities that can undergo actions by Ei; these values are grouped into a set denoted by { J ) . l The number of different values ofj in Sp( Ei) is the number pi of all entities that can execute actions on Ei; these values are grouped into a set denoted by {L}. l hj and m, are the number of actions between Ei and Ej in Sa( Ei) and Sp( Ei), respectively. l The cardinality of Sa( Ei) and of Sp( Ei) are respectively: l

ISa( Ei)(

= xh,,

vjg

VI

(**) Some access rights depend on the name or content of the entity that is accessed. These conditions are predicates on entities; in fact they cause a resource to be defined as two or more different entities. For each of these entities the access condition is true or false and the access to each of them is selectively allowed on the basis of this condition. For example, in the following security requirement: “Mr. Jones can update the relation MANAGER if MANAGER. SALARY < $5.0 * 104” the content-dependent condition MANAGER. SALARY < $5.0 * lo4 makes the resource MANAGER be defined as two entities: for each of them one of the following predicates on the SALARY field is true: SALARY

c $5.0 * lo4

SALARY

> $5.0 * lo4

In the context of this paper predicates on entities are supposed to have been examined in a former design phase, the security requirements analysis phase, where the security system’s resources are defined and partitioned on the basis of such predicates.

lSp(Ei)l=im,,

VjE

{L},

.i

where the sums are computed on the different values of j in (1) and (2) respectively. 2.2. Entity Classification On the basis of the sets Sa( Ei) and Sp( Ei), each entity Ei may be classified as: ACTIVE ENTITY if: Sa( Ei) + (0) PASSIVE ENTITY if: Sp( Ei) # (0) In particular, an entity Ei may be an: ONLY ACTIVE ENTITY if: Sa( Ei) f (0) A Sp( Ei) = (0) ONLY PASSIVE ENTITY if: Sa( Ei) = (0) A Sp(Ei)

f (01

199

M. Fugini, G. Martella / ACTEN

c. ACTIVE AND PASSIVE ENTITY if: Sa(Ei) # (0) A Sp(Ei) # (0). Examples of only active entities are the database administrator and a general manager. In fact they can execute actions, such as reading, creating, updating data, etc. or grant access rights to users and applications, but do not undergo any action. A data file, a data record, a record field are examples of only passive entities; these can be created, updated, etc. but cannot execute any action. An application program is an example of active and passive entity; it can write into a data file (active), or can be used by a programmer (passive). 2.3. Action Classification Actions are organized in a hierarchical framework, where: l a level is assigned to each action; l if an entity Ei can execute the actions on level L, Ei can automatically execute all the actions on levels L’ < L. This organization is the mechanism allowing the selective rights management; when an action on level L is granted, all the actions on the levels L’ < L are granted. This simplifies the procedures of grant and revocation of access rights because only one level is to be specified in order to grant a set of access rights. Furthermore, the level of clearance for each entity can be assigned by specifying the highest level L of operation that it is allowed to perform in the security system. The introduction of hierarchical levels also represents the mechanism for the control of indirect rights. Along a rights chain each entity cannot gain an access right on a level L that is higher than its clearance. A hierarchical distribution of rights is a reality for several enterprise environments where, for instance, an entity holding the right of updating a specific piece of information is automatically allowed to read it. In the model, the hierarchical framework has a consequence on the numbers h, and mj of different actions that may connect two entities. These may be reduced by specifying the action of the highest level only. Actions are classified in the model as belonging to two different classes: static actions and dynamic actions. 0 An action is defined as a static action (SA) if its

Table 1 Static actions

I

L--_

1

I

USE

I

execution does not modify Sa( Ei) or Sp( Ei). 0 An action is defined as a dynamic action (DA) if its execution modifies Sa( Ei) or Sp( Ei). Let us now introduce a set of static actions and a set of dynamic actions as an example. These sets of actions would generally require that they be expanded in order to model real security systems; however, it is beyond our purpose to model an enterprise environment. These two sets of real actions will be used in all the examples of the present work and are shown in Tables 1 and 2. The meaning of each action in our context is illustrated in the following. 2.3. I. Static Actions 0 USE: it is the access modality that commonly exists between users, groups of users, operators, programmers, etc. and I/O devices or application programs. In the first case, ‘USE’ means that the user can use a specific device to run his jobs; in the second case the user is allowed to execute a program. 0 READ: this action’s meaning is copy, that is transfer the entity into the applicant’s memory area. l UPDATE: the meaning is ‘modify’ or ‘manipulate’. l CREATE/DELETE: it is the ability to insert and erase entities in the security system. These actions are on the same level, as usually an entity having the right to create entities has also the right to delete them.

Table 2 Dynamic

actions

200

M. Fugini, G. Martella / ACTEN

2.3.2. Dynamic Actions GRANT/REVOKE: an entity Ei can grant to or revoke from another entity Ej the right to execute a static action on entity Ek. Ei must be authorized to execute on Ek the action it grants (revokes). ‘GRANT’ and ‘REVOKE’ have the same hierarchical level; if Ei can grant the rights (or a subset of them) it holds on Ek, it can also revoke them. 0 DELEGATE/ABROGATE: an entity Ei can grant to (revoke from) another entity Ej the right to grant (revoke) a static action SA on entity Ek. We say that ‘Ei delegates (abrogates) SA on Ek to Ej ‘. Only some entities are allowed to execute this action and the level of SA can be anyone. If Ej is not yet authorized to execute the SA it is delegated, it is automatically enabled. DELEGATE and ABROGATE have the same hierarchical level, since an entity having the right to delegate actions also has the right to abrogate them. Entity Ek ‘on which’ SAs are granted (revoked) or delegated (abrogated) is called parameter entity of the dynamic action. In the model, a dynamic action is denoted by A,J,k, meaning that Ei can execute A on Ej with parameter entity Ek. Also specified in the ‘DELEGATE/ABROGATE’ action is the set {M} of the indexes of all entities Em to which Ej can grant (revoke) the SA it has been delegated by Ei. If an entity Ei can execute and grant the execution of the ‘CREATE/DELETE’ action on Ek and can execute the ‘DELEGATE/ABROGATE’ action on Ek, then Ei is owner of Ek. Each entity has only one owner. The ‘DELEGATE/ABROGATE’ action on the parameter entity Ek can be executed only by Ek’s owner.

We distinguish three cases: [l] If DA E { A,,},j E { L} is executed, then: ]Sa( Ei) 1changes ]Sp( Ei)l does not change ]Sa( Ej)/ and ]Sp( Ej)( do not change. In particular, if only and all the DAs revoking Ei’s rights are executed, ]Sa( Ei)l achieves its minimum value ]Sa( Ei)l,i,. Analogously, if only and all the DAs enlarging Ei’s rights are executed, ISa( Ei) I achieves its maximum value ISa( Ei) Imax. [2] If DA E { Ai,}, j E {J} is executed, then: ]Sa( Ei) 1and ]SP( Ei)l do not change ISa( Ej) I changes ]Sp( Ej)l does not change. [3] If DAE{A,~}, z=l...N, jE{L}, z#ifj and with parameter entity Ei is executed, then: ]Sa( Ei)l does not change (Sp( Ei) ( changes ]Sa( Ej) 1changes ISp( Ej) I does not change ]Sa( Ez) I and ]Sp( Ez)l do not change. In particular, if only and all the actions revoking the rights of each entity Ej on Ei are executed, ]Sp( Ei) I achieves its minimum value ]Sp( Ei) Imin. Analogously, if only and all the actions enlarging the rights of each entity Ej and Ei are executed, ISp( Ei) 1achieves its maximum value ]Sp( Ei) Imax.

2.4. Authorization tion

3. I. Graphs

l

and Protection

Sttite Classifica-

Referring to one entity Ei, let us consider the dynamic actions which entity Ei is involved in, that is the dynamic actions which Ei can execute (A,,,jE{J})andundergodirectly(A,,,jE{L}) or indirectly (A,, , z = 1. . . N, j E { L } with parameter entity Ei). The execution of one or more dynamic actions related to Ei may in general modify Sa( Ei) and Sp( Ei); more precisely, Sa( Ei) and Sp( Ei) change their cardinality.

3. Model Frameworks and Rules We are now concerned with the organization of the elements and concepts previously illustrated in the conceptual security model. In this section the conceptual frameworks for security information are introduced; these are graphs and tables. The rules for their manipulation and use are also presented.

We introduce two graphs: [l] a static graph SG where static actions are represented, [2] a dynamic graph DG where dynamic actions are represented. Let us examine the structure of the static and the dynamic graphs SG and DG. 3.1.1. The Static Graph SG is composed of nodes and arrows. To each

201

M. Fugmi, G. Martella / ACTEN

entity Ei we associate a node which is indicated by a circle. To each action A we associate an arrow labeled with the name of the operation a. This means that the entity at the tail of the arrow can execute the named operation on the entity at the head of the arrow. An arrow is crossed if a is conditioned by a set of predicates ( p }. In Figure 1 an example of SG is shown, where user El can read the application programs E2 and E5 without conditions, can use the peripheral E3 only from 8h to 12h a.m. The application programs E2 and E5 can respectively update and create or delete the data record E4 without conditions. 3.1.2. The Dynamic Graph DG is composed of nodes and arrows. To each entity Ei we associate a node which is indicated by a circle. To each action A we associate an arrow labeled with the name of the operation a. This means that the entity at the tail of the arrow can execute the named operation on the entity at the head of the arrow. Arrows are labeled with the following notation: DA SAC{ M}), where SA is the static action granted (revoked) or delegated (abrogated) and where the set {M} has to be specified only if the DA is the ‘DELEGATE/ABROGATE’ action. A labeled bar on the arrow specifies the parameter entity Ek of the dynamic action. An arrow is crossed if a is conditioned by a set of predicates { p } For simplicity, on DG only the GRANT and DELEGATE labels are indicated, implying the presence of the REVOKE and ABROGATE labels respectively. In Figure 2 an example of DG is shown. User

PELETE u Legend. El E2 E3 E4 E5 AIJ {p]

= user I application program = peripheral : data record I application program : USE - {p) z’from 8h to 12h a.m

Fig. 1. Static Graph (SC).

El can grant user E2 the right to read the data file E3 under some conditions and E2 can grant the application program E4 the right to use the card reader E5 without conditions. E2 can delegate the applications program E7 the ‘UPDATE’ action on E6. As a consequence, E7 can grant this delegated SA to the application program El0 and to user E9. E7 can also grant the ‘READ’ action on the data field E6 to the application program E8. The introduction of two distinct graphs is aimed at the separation between access rights and propagation rights. In particular, only the static graph is examined in order to check direct and indirect access rights (see section 2). Furthermore, only the dynamic graph is examined in order to predict the evolution of the rights distribution. In fact, dynamic actions represent transactions on security information because their execution, modifying the authorization and protection state of entities, changes the security system structure. This analysis of the possible transactions on security information, together with the evaluation of their consequences on the whole structure, provides the security system evolution as follows: l the capability for a transaction to take place is monitored on DG; l the consequences of the transaction are evaluated on SG (if the transaction is a ‘GRANT/REVOKE’ action), on DG (if the transaction is a ‘DELEGATE/ABROGATE’ action). Both graphs must be analyzed only when global information about the state of the system and

Legend: El E2 E3 E4 ES E6 E7 E8 E9 El0

= u.ser :user = data File = application = card reader = data field = application : application = user = application

Fig. 2. Dynamic

program

program program program

Graph

(DC).

202

M. Fug&i, G. Martella / ACTEN

about the authorization entities is required.

and

protection

state

of

3.2. Tables These model frameworks express the security constraints on entities and on their rights. They are: 0 the table of security classes, l the table of entity states, l the table of action hierarchy. In the table of security classes all the system entities are listed. For each entity Ei, two constraints are indicated: l Ei’s active potentiality, that is the static action Ai+ on the highest level that Ei can execute; l Ei’s passive potentiality, that is the static action Ai- on the lowest level that Ei can undergo. Only active entities do not have a passive potentiality, while only passive entities do not have an active potentiality. The presence of this table answers the need to assign each entity a certain level of authority and protection within the system, according to its physical nature, its functional position inside the system and the role it plays within a project or organization. An example is illustrated in Table 3 where the ‘ + ’ and ‘ - ’ symbols denote Ai+ and Ai- respectively; the example relates to the security system entities shown in the static graph of Figure 1. User El cannot undergo any static actions, owing to its physical nature; therefore its passive potentiality is not defined. The largest privilege (A2+) defined for the application program E2 is UPDATE, while it can be created and deleted (A2-). The peripheral E3’s active potentiality (A3+) is CREATE/ DELETE; this means that it is possible for a user or operator to run and kill jobs and processes from that terminal. E3’s passive potentiality A3+ is Table 3 Table of Security

Classes

TABLE OF SECURITY

CLASSES Legend: El = E2: E3 = E4 I ES =

user applicationprogram peripheral data record applicationprogram

Table 4 Table of Entity States TABLE

OF ENTITY

OWler

Owned

STATES EntItles

I

El

EB,

E4

E6

E5,

E7

Legend : Fl = project manager Ei = application program E3 = video terminal E4 = cobol programmer E5 = pay-enrollment file cobol library system programmers group data file

USE. The data file E4 is an only passive entity and therefore only its passive potentiality A4+ is defined. The application program ES can create and delete entities in the security system and can be itself created and deleted by other entities. The table of entity states shows which entities are owners and, for each of them, the owned entities. It is examined in order to verify the legitimacy of grants and revocations of dynamic actions. Table 4 is an example of a table of entity states: note that E2 is owned by E7 and indirectly by El. In the table of action hierarchy the set of static actions and the set of dynamic actions for a given security system are recorded. An example of this table for the set of actions introduced in Section 2 is given by Tables 1 and 2 of section 2.3. 3.3. Consistency

and Transformation

Rules

The SG and DG management is obtained through the following rules. [a] Rules which assure that each graph framework is consistent with the security system reality. These rules, called Rules of Internal Consistency, regulate SG’s and DG’s evolution from one state (or configuration) to another. [b] Rules assuring that, at any moment, SG and DG are not clashing in their description of the same reality. They are called Rules of Mutual Consistency. [c] Transformation (or rewriting) Rules. These are concerned with the analysis of indirect rights and of access rights flow and propagation. In fact, their application makes possible the determination of the authorization and protection state of entities and of whether an entity can execute specific actions. These three groups of rules will be explained separately for SG and DG.

M. Fugini, G. Martella / ACTEN

3.3.1. Static Graph Rules SG Internal Consistency Rules. In the security system any entity must be authorized to execute and undergo exclusively those actions which are compatible with its nature and its role within the security system. For instance, ‘READ’ is nonsense if executed by one application program on another. Analogously, ‘CREATE/DELETE’ cannot be executed on peripherals, ‘USE’ on files. Internal consistency rules assure this consistency. If the starting graph’s configuration is consistent with the system reality and with the physical nature of components (i.e. with the table of security classes), SG evolution from one configuration to another is regulated so as to avoid the occurrence of inconsistent states. To this purpose, a “filter routine” is executed after the achievement of each new state to verify its consistency and to manage anomalous cases. Such a routine examines the table of security classes and the table of entity states. SG Transformation Rules. The aim of these rules is to show the privileges that an entity Ei can indirectly exercise on other entities. Through its connections with some entities Ej, Ei can in fact execute (undergo) actions also on (by) entities Ez which it is not directly connected to by an arrow on SG. The transformation rule we provide is defined for groups of three entities Ei, Ej, Ez and two actions A,,, Aj, (see Figure 3). It determines the static action Aj, on the basis of the chain Aij - A,,. A transformation (or rewriting) rule is a function F of four arguments A,,, A,,, Ei, Ez; its value is the action Ai,, that is: Ai, = F( A,j, A,,, Ei, Ez) F is a function of Aij and of Aj, because A,, depends on the kind and hierarchical level of the actions connecting the three entities. F is function of Ei and Et because A,, must be consistent with Ei ‘s and Et ‘s nature and role inside the system. In particular the table of security classes must be consulted in order to get Ei’s active potentiality and Ez’s passive potentiality; on this way it is

Fig. 3. Definition of the transformation

rule for SC.

203

assured that A,i neither increases Ei’s authority (i.e., does not violate Ai+), nor violates EL’S protection limits (Ai-). F is fixed by the security requirements and policies chosen by security administrators. The algorithm for determining A,, is the following:

Algorithm A 1. L( A,,) is compared with L( A,,) 2. if L(A,,)>L(A,,) then L(A;,)=L(A,,) 3. if L( A,,) < L( A,,) then Ei’s active potentiality Ai+ in the table of security classes is examined. 4. if L( Aj,) > L( Ai+) then L( A,Z) = L(Ai+) 5. if L( A,Z) < L( Ai’) then L( A,,) = L( Aj,) This algorithm does not consider EL’S passive potentiality AZ- because of the choice of Aj,‘s value in STEP 2, STEP 4, and STEP 5 which implies that Ez’s protection limits are never violated. If Aij and A, are conditioned by predicates p,, and pjz respectively, the predicate pi2 on action Ai, is given by: (31

Pi2 = Pij A Pjz

REATE/

DELETE

. .+___

--A,,=READ

---

-4

Legend: El E2

= user = application

PrograIn

E3 = data File Al2 = CREATE/DELETE

- [P,L\ VTlOO'

~~~z~Z’~~oZl’~~f-ininai

{p,,]= TABLE

'dtsKRLO mu-dd'

OF SECURITY

CLASSES

Fig. 4. Application of the transformation rule for SG.

204

M. Fugint, G. Martella / ACTEN

Figure 4 shows a sample static graph and table of security classes for three entities El, E2, E3. A,, and A,, are conditioned by predicates, as detailed in the legend of the figure. A,3 is graphically represented through a dotted line arrow and is determined by applying algorithm A. In this case we have:

and, according to STEP 2, A,, = A,, = READ. In fact, even if user El’s active potentiality is Al + = CREATE/DELETE, this is limited by the presence of action READ between E2 and E3. A,, is conditioned by a predicate pi, given by the following expression: P,~ = ‘from peripheral

Q

USE . .

@UPDATE

_--___---

TABLE

example

~FZ@CREATEIDELETE_B _--

(b)

is shown in Figure 5a and 5b,

-______---A,,=UPDATE

of the transformation

rule for

where a user group El, a peripheral E2 and a data file E3 are represented. Figure 5a is the case of STEP 3 of algorithm A and, since Al+ in the table of security classes is UPDATE, STEP 4 is executed; therefore A,, (dotted line arrow) is the UPDATE action. Figure 5b is also the case of STEP 3 of algorithm A, but since Al+ in the table of security classes is now CREATE/DELETE, STEP 5 is executed; therefore, A,, = CREATE/ DELETE. When more than one entity is interposed between Ei and Ez, Ai, is determined by applying the transformation rule to groups of two actions and by substituting in each step the action determined in the last step. In figure 6a and 6b the two steps for A,, ‘s determination are shown, where dotted line arrows denote the actions resulting from the application of the transformation rule and the double line arrow of Figure 6b the action obtained in the last step. First A,, is determined (Figure 6a) by checking Al+; then action A,, is matched with A,,, in order to obtain A,, (Figure 6b).

__--

(a) USE --____-_--A,,=CREATE/DELETE (b)

Legend: El E2

__--

--___---CREATE/U~LETE

CREATE/DELETE

USE

.N._

CLASSES

UPDATE

Fig. 6. Steps in the application SC.

‘.N_

OF SECURITY

(a)

if disk RLO is mounted’ Another

@

urUUlE

‘I..._

VT 100 and

@CREATE/DELETE _-*

q user group = peripheral

E2 = date file TABLE

OF SECURITY

TABLE

OF SECURITY

CLASSES

CLASSES

3.3.2. Dynamic

Fig. 5. Determination potentialities (A: ).

of indirect

actions

with different

active

Graph Rules

DG Internal Consistency entity E, be owner of (k # i #j) can execute GRANT SA. In fact, if

Rules. Rule Il. Let an Ek. No other entity Ei an action A,j,k of kind Ej is E,‘s owner, it can

M. Fugini, G. Martella

/ ACTEN

205

execute the static action on the highest hierarchical level (see the definition of ‘owner’ in section 2.3). Rule 12. An entity Ei can execute the ‘DELEGATE/ABROGATE’ action with parameter entity Ek only if Ei is Ek’s owner (also indirect owner). Rule I3. Let an entity Ej be authorized to an entity Em (m # i) a static action on with parameter entity Ek. The entity Ei owner of Ek can execute on Ej actions kind DELEGATE SA only if L(SA) z L’.

grant level which Ai,,k

to L’ is of

Rule 14. An entity Ej, to which an SA on level L has been delegated, can grant this SA only to those entities Em with Am+ on level L’ > L. This is a condition on the set { M } of the ‘DELEGATE/ ABROGATE’ action. SG and DG Mutual

Consistency

Rules

Rule Ml. An entity Ei can grant another entity Ej the right to execute an SA on level L with parameter entity Ek, only if, in SG, Ei can execute an SA on level L’ > L on Ek. This rule conforms to the definition of the dynamic action ‘GRANT/REVOKE’ given in Section 2.3. Rule M2. If an entity Ei can execute a static action Aj, on level L, in DG an entity Ei can grant Ej the right to execute only static actions on levels L’ > L on the entity Ek.

Legend

:

El =user E2 quser E3 qdata File E4 q application

program

Fig. 7. Right flow on DC.

a right to E4 through the grant chain composed of entities El, E2 and E4 and of the direct rights among them. This indirect right has to be checked and tested in order to verify its consistency with security requirements and constraints. The transformation rules determine the dynamic action connecting El and E4 on the basis of the chain A 12/3 -A 24/3. The transformation rule we provide is defined for groups of three entities Ei, Ej, Ez and two dynamic actions A,,,, and A,:,,. These actions have to be defined on the same parameter entity Ek; the rationale for this condition is that the proposed rule is aimed at the solution of one of the most common problems in the analysis of security systems, i.e. the control of the right flow on one specific entity Ek in order to monitor Ek’s protection state. The indirect action A,,,x does not always exist. This can be explained through the example in UPDATE

Rule M3.To each action A,J,k of kind DELEGATE SA in DG, the ‘CREATE/DELETE’ action A,, must correspond in SG. In fact, the ‘DEL LEGATE/ABROGATE’ action on an entity Ek can be executed only by Ek ‘s owner Ei. Therefore, Ei must be authorized to execute the ‘CREATE/DELETE’ action on Ek. DG Transformation Rules The purpose of these rules is to show how the rights to execute static actions and the rights of kind grant/revoke flow within the security system due to the execution of dynamic actions. If, for instance, a user El can grant another user E2 the right to update a data file E3 and E2 can grant the right to read the same file E3 to an application program E4 (see figure 7), El has indirectly granted

E2

E2

A,.,,,DOES Legend

NOT

EXIST

:

El =user E2 = data File E3 q application E4 = application

program program

Fig. 8. DC where the transformation

rule cannot

be applied.

M. Fugm;, G. Martella / ACTEN

206

Figure 8, where the static and dynamic graphs for a given security system are shown. (Dotted line arrows from node E4 in SG denote actions that are irrelevant for our purposes.) The application program E3 can read the data file E2 and grant the ‘READ’ action on E2 to the application program E4. The dynamic action between user El and E3 on DG, i.e. the granting of the UPDATE right, does not affect the relationship between E3 and E4 on DG, because the two ‘GRANT’ actions of one another; in A 13/2 and A34/2 are independent this case the indirect action A,4,2 does not exist. In general, Al_/k exists when A,_.,x “depends” of on the action A,,,k, i.e. when the capability executing A.,_.,k is subordinate to the execution of A tJ,k. Thus we introduce the concept of SUBORDINATE ACTION. An action A,Z,l, of kind GRANT SA’ is subordinate to action A,,,A if: 1. Ej and Ek are not connected by any actions Alk on SG 2. If action A,, exists in SG, then: L( A,,)

< L(W)

3. The static action SA” granted or delegated through A,,,k is on level L” 2 L(SA’). Subordinate actions are denoted on DG by boldface arrows. In Figure 9 a security system is represented, where A,,,, is subordinate to A,3,2. The transformation rule for DG can now be applied, since Al4,* represents a right flow from El with the to E4. Note that A34,2 is inconsistent actions shown on SG (E3 can only ‘USE’ E2 and can not therefore grant the ‘READ’ action); A34,2 becomes consistent with these actions only when E3 has received from El the right to execute the ‘UPDATE’ action on E2. Subordinate actions A,r,k are therefore particular GRANT actions since they do not respect the Section 2.3 on the condition given in

oc

0;’

GRANT

Fig. 9. Subordinate

UPDATE

action.

GRANT

READ@

GRANT/REVOKE actions (an entity Ej must be authorized to execute on Ek the SA it grants). The subordinate action A,z,x becomes a ‘GRANT’ action according to that description only after the execution of the A,,,, action. Therefore the subordinate action introduces a time-dependent condition in DG. We now introduce the following transformation rule. Rule Tl. Let us start with an action A,,,k of kind DELEGATE SA” or GRANT SA” and an action A J_/k of kind GRANT SA’ and subordinate to A t,,k. The action A,z,k is of kind GRANT SA where SA is determined through the transformation rule F as follows: SA = F(SA”,

SA’, Ei, Ez)

F is a function of these four arguments for reason analogous to those explained in Section 3.3 about the transformation rule on SG. The SA is determined as follows: from what said in point 3 of the subordinate action’s definition and referring to algorithm A (see Section 3.3.1) the step of this algorithm to be applied is always STEP 2. Therefore we have: SA = SA’ The application of the described transformation rule to the dynamic graph of Figure 9 provides: A 14,2 = GRANT

READ

When

Aij,k and A,r,k are conditioned by predithe predicate cates Pij/k and P/r/k respectively, pir,k on Air,k is given by: P!r/k=

Pij/k

Apjz/k

This transformation rule may be applied to more than three entities and two actions only if these entities and actions belong to a grant (revoke) chain. A grant (revoke) chain on Ek is a DG’s path composed of one action of kind DELEGATE SA or GRANT SA and of some subordinate actions A ,r,k of kind GRANT SA. Many chains on the same parameter entity Ek may appear in the same dynamic graph. A grant (revoke) chain has the following properties: a. only the first arrow of the chain can be labeled with DELEGATE SA. In fact, all the other arrows of the chain represent subordinate actions

M. Fugini, G. Marrella / ACTEN

TABLE

OF ENTITY

OWNER

OWNED

El

I

207

STATES ENTITIES

E 2 ,

I

(a)

-_

---____---. GRANT

READ (bl)

/A -\

--___---

GRANT

USE

e-

/H

_.------

(b2) Fig. 10. Application

of the transformation

rule for DG to a grant

and the ‘DELEGATE/ABROGATE’ action can not be subordinated to any other action. b. the hierarchical level of the SAs delegated or granted along a grant (revoke) chain can not increase. This follows from point 3 of the definition of subordinate actions. The transformation rule is applied along the chain to groups of three entities and by substituting in each step the action determined in the last step. In Figure 10 an example of how the transformation rule is applied to a grant (revoke) chain is illustrated. Given the static graph and the table of entity states of Figure lOa, the two steps of the rule are shown in Figure lob1 and lOb2.

4. Use of the Model In this section some examples of how the actionentity model can be used are shown. At first, the method for determining the authorization and protection state of an entity through the graphs trans-

chain.

formation rules is illustrated; furthermore, the analysis of how the authorization state may evolve owing to grant and revocation of privileges (rights propagation) is given. 4.1. Analysis State

of the Authorization

and Protection

The authorization state Sa( Ei) of an entity Ei and its protection state Sp(Ei) in a given security system are derivable from the analysis of the ACTEN static and dynamic graphs and of the ACTEN table of security classes. As far as SA(Ei) is concerned, first the graphs have to be examined in order to check Ei’s direct rights (arrow departing from the graph node denoting Ei in the model); then, the graphs transformation rules are applied in order to check Ei’s indirect rights. SA( Ei) is composed of both direct and indirect rights. Sp( Ei) is derivable from the examination of all the access rights upon Ei, direct (arrows reaching the

M. Fugini, G. Martella / ACTEN

208

graph node denoting Ei in the model) and indirect (transformation rules). The analysis of SG and of DG is performed through the following algorithm. This algorithm leaves effectiveness aspects out of consideration; it is beyond this work’s purpose to select the optimal strategy for determining Sa(Ei) and Sp(Ei). In this algorithm, which is also illustrated through a program in the appendix, Ei’s direct subgraph is the subgraph of SG or DG composed of node Ei, of the arrows departing from Ei, and of nodes Ej at the head of such arrows. (In the analysis of Ei’s protection state arrows reaching Ei and nodes at the tail of such arrows are considered.) A leaf node in one entity’s subgraph is a node from which no arrows depart. (In the case of the protection state analysis, a leaf node is a node which is not reached by any arrow.) The symbols S’(Ei) and S”( Ei) represent partial expressions of Sa( Ei), respectively obtained while examining SG and DG. (In the case of the protection state analysis, these represent partial expressions of Sp( Ei).) A temporary variable x for the entity indexes is used; the notation x < ---y means that x takes the value of the index y. Algorithm B STEP

I: Ei’s direct subgraph on SG is examined and a first expression of S’ (Ei) is obtained.

STEP 5: The analysis subgraph is considered S”( Ei) is obtained. STEP

6: Those nodes Ex of Ei’s direct subgraph on DG which: 0 are not leaves in DG 0 belong to a grant (revoke) chain together with Ei are considered and, for each of them, STEP 7 and STEP 8 are executed. STEP 7: The actions belonging to Ex’s direct subgraph on DG are matched with the action A,, through the transformation rule for DG. A,, is the last determined DA between Ei and Ex. Its value must be updated to the last determined value. The action-entity pairs obtained from this match are inserted into S”(Ei). If, in this expression, two or more actions executed on the same entity and with the same parameter entity appear, then the DA containing the SA on the highest level is selected. STEP 8:For each node Ey belonging to Ex ‘s direct subgraph on DG which 0 is not a leaf l belongs to a grant (revoke) chain together with Ei STEP 7 and STEP 8 are executed with x < - - -y. STEP

STEP

2: From

Ei’s

9: Ei’s authorization

direct subgraph on SG the nodes Ex which are not leaves are selected. For each of these Ex, the direct subgraph is considered and STEP 3 and STEP 4 are executed.

given by:

STEP 3: The actions belonging to Ex’s direct subgraph on SG are matched with the action Ai, through the transformation rule for SG and algorithm A is applied. The action A,, is the last determined action and must be always updated to the last value. The action-entity pairs obtained from this match are inserted into the expression of S’( Ei). If two or more SAs executed on the same entity appear in this expression, then the SA on the highest hierarchical level is selected.

Example

STEP 4: For each node Ey of Ex’s direct subgraph on SG which is not a leaf, Ey ‘s direct subgraph is considered and STEP 3 and STEP 4 are executed, with x < - - -y.

shifts to DG. Ei’s direct and a first expression of

(protection)

state

is

S’( Ei) u S”( Ei)

Let us now apply ALGORITHM B to an example. Figure 11 shows a security system represented through the ACTEN model. More precisely, the system is composed of 13 entities (whose meaning is explained in the legend of the figure) and has a hierarchical organization for the static and dynamic actions as illustrated in Tables 1 and 2 (see Section 2). The figure also shows the ownership relations among entities (table of entity states) and the portion of the table of security classes that is significant for our purpose. STEP

I: El’s direct subgraph

on SG is examined.

209

M. Fugini, G. Martella / ACTEN

E2

GRANT

GRANT

READ

READ Legend:

TABLE OWNER

Fig.

OF ENTITY OWNED

11. A security

El’s authorization this subgraph is:

TABLE

STATES

OF SECURITY

El = user E2 = application program E3 = data file E4 =data record E5 =data file E6 q user E7 = application program E8 = peripheral E9 q data record ElO= application program El1 = record field E12= record field E13= user

CLASSCS

ENTITIES

system

described

through

the ACTEN

state on SG corresponding

S’( El) = {READ-E2,

READ-E7,

to

UPDATE-E9) (I)

model.

Examining the table of security classes of Figure 11, the match’s results is: S’( El) = { READ-E2,

UPDATE-E3,

UPDATE-E4,

USE-E 7,

node E7 are selected. Let us consider node E2. Its analysis provides the following expression for E 2’s authorization state:

READ-E7, UPDATE-E9) (3) Matching READ-E7 with USE-E7 and reorganizing the pairs in expression (3) we obtain the following expression:

S’( E2) = { CREATE/DELETE-E3,

S’( El) = {READ-E2,

STEP 2: From El’s direct subgraph nodes E2 and

UPDATE-E3,

(2)

UPDATE-E4,

transformation rule for SG is applied in order to match A,, (‘READ’) with each action belonging to S’( E2). For instance:

UPDATE-E9)

UPDATE-E4, STEP j:The

A,, = F(&,

A,,, El, E3)

USE-E7)

READ-E7, (4)

STEP 4: In E2’s direct subgraph, node E7 is not a leaf; it is therefore selected and its direct subgraph is considered.

M. Fugini, G. Martella

/ ACTEN

STEP 3: The result of the match between A,, and A,, does not modify expression (6). Therefore, S’( El) is still graphically represented in Figure 12. Let us consider the other node belonging to El’s direct subgraph, node E7 which is not a leaf in SG. The examination of direct subgraph of node E 7 on SG and the match between A,, and A,, with A,, does not add any pairs to expression (6). Therefore, (6) is the final expression of S’( El) which is graphically shown in Figure 12, where all the entities that are directly or indirectly accessible by El are shown.

Fig. 12. Access rights of entity El.

STEP 2, STEP 3, STEP 4 are executed for entity E7. STEP 2: The analysis of E7’s direct subgraph provides:

Analysis

S’( E7) = {UPDATE-ES,

S”( El) = {GRANT

USE-E8)

(5)

STEP 3: The result of the match of A,, = READ with A,, and A,* is: S’( El) = { READ-E2,

UPDATE-E3,

UPDATE-E4, READ-E7,

UPDATE-ES, USE-E8,

UPDATE-E9)

(6)

and is graphically shown in Figure 12. STEP 4: In E7’s direct subgraph node E8 is not a leaf; it is therefore selected and its direct subgraph is considered. STEP 2 and STEP 3 are executed for entity E8. STEP 2: The analysis of E8’s direct subgraph provides: S’( E8) = {UPDATE-ES}

(7)

of DG

STEP 5: The direct subgraph analyzed. The result is:

GRANT

of El

on DG

is

USE - E2/E7, READ - E6/E2}

(8)

STEP 6: The direct subgraph of node E6 is analyzed. STEP 7: Action A16,2 is matched with action A,,,, through the transformation rule for DG. A ,7,2 is of kind GRANT SA where: SA = F(READ,

USE, El, E7) = USE

Therefore: S”( El) = {GRANT

USE - E2/E7,

GRANT

READ - E6/E2,

GRANT

USE - E 7/E 2)

(9)

STEP 8: In E6’s direct subgraph there is only a leaf node E 7. Therefore such subgraph requires no further analysis. Expression (9), is the final expression of S”( El).

GRANT

Fig. 13. El’s authorization

state.

M. Fugini, G. MatWla

211

/ ACTEN

E0

El1 GRANT

UPDATE

Fig. 14. DAs of Entity El.

STEP 9: El’s pressed by:

authorization

state

Sa(E1)

is ex-

Sa( El) = S’( El) U S”( El) Sa( El) is shown graphically 4.2. Analysis

in figure 13.

of the Authorization

USE-E7/E2,

GRANT

READ-ElO/E3}

(10)

Sa( El) is shown graphically in Figure 15. In particular, Sa(E1) of expression (10) and Figure 15 is the authorization state with the. maximum value of cardinality lSa( El)J,,,. In fact, the DAs above considered (&,s, A,, 1,,, and AZ1,3) are all the actions A,l,, of kind GRANT that can be executed on El. If after the execution of such actions all the corresponding actions of kind REVOKE are executed, then the model configuration is once again the one shown in Figure 11. For instance, if E6 revokes from El the ‘READ’ action on E8, the direct arrow from El to ES and labeled with ‘READ’ is removed; however El still holds the privilege of using E8 through E7.

State Evolution

Referring to the example illustrated in Section 4.1, let us show how the authorization state of entity El, Sa( El), may evolve due to the execution of the dynamic actions in which El is involved. To this purpose, and referring to the discussion in Section 2.4, the set of dynamic actions {A,, }, j E {L} and the protection state Sp(E1) on DG have to be considered. Sp( El) on DG is represented in Figure 14. The execution of Abl,sr A,, ,,,, and AZ1,3 modifies SG and DG of Figure 11. More precisely: [l] The execution of Ab,,8 modifies SG, where an arrow between El and E8 labeled with ‘READ must be inserted. [2] The execution of A,, ,,,, modifies SG, where an arrow between El and El1 labeled with ‘UPDATE’ must be inserted. [3] The execution of AZ,,3 modifies DC, where an arrow between El and El0 labeled with ‘GRANT READ’ and with parameter entity E3 must be inserted. Sa( El) is now determined through the application of Algorithm B. This provides the following expression for the authorization state: Sa( El) = { READ-E2,

GRANT

5. Concluding Remarks This paper the design

has illustrated a conceptual model for of security systems. The model ele-

-0 E3

-SG

UPDATE-E3,

UPDATE-E4, READ-E7,

UPDATE-ES, READ-E8,

UPDATE-E9,

UPDATE-Eli,

GRANT

USE-E2/E7,

GRANT

READ-E6/E2,

oc Fig. 15. El’s DAs.

authorization

state

after

the execution

of some

212

M. Fuginr, G. Vartella

ments, entities, actions, rights, conditions, and framework (graphs and tables) have been described. Methods for the analysis of the authorization and protection state of entities have also been discussed. Transformation rules for indirect rights and rights propagation checking have been considered. Static and dynamic aspects of the security system are embedded in the model through two separated frameworks: a static graph, where the distribution of access rights is represented, and a dynamic graph, where the evolution of these rights, resulting from grants and revocations is controlled. The emphasis of ACTEN is on the semantic content of security information. The model is also aimed at a non-redundant and univocal representation of security requirements and policies, independent of aspects bound to the actual implementation of security mechanisms and to the available DBMS technology. ACTEN is a tool for analyzing the security system, i.e. resources, access and propagation rights and security constraints during the conceptual design phase. Starting from the enterprise security requirements and policies, the security designer can represent security relationships at the conceptual level through ACTEN, so as to analyze them and verify the correctness of the design. Future developments of this research will include the mapping of the ACTEN model into a logical model (relational, network, hierarchical) supported by existing DBMSs.

References [l] Teorey T.J., Fry J.P., Design of Database Structures, Prentice-Hall Inc., 1982. [2] Bussolati U., Martella G., Towards a new approach to secure database design, Computers & Security, vol. 2, n.1, January 1983. [3] Bussolati U., Martella G., Data Security Management in Distributed Databases, Information Systems, vol. 7, n.3, 1982. [4] Bussolati U., Martella G., Access Control and Management in Multilevel Database Models, Proc. of 3rd Conf. of the European Co-operation in Informatics, ECI, Monaco, 1981. [5] Fernandez E.B., Summers R.C., Wood C., Data Base Security: requirements, policies and models, IBM System Journal, vol. 19, n.2, 1980.

/ ACTEN

[6] Gaines R.S., Shapiro N.Z., Some security principles and their application to computer security, in Foundations of Secure Computation, Academic Press, New York, 1978. (71 Larson J.A., Granting and Revoking Discretionary Authority, Information Systems, vol. 8, n.4, 1983. [S] Bussolati U., Martella G., A database approach to modelling and managing of security information, Proc. of 7th Int. Conf. on Very Large Data Bases, Cannes, Sept. 1981. [9] Summers R.C., Fernandez E.B.. A system structure for data security, IBM Los Angeles SC. Center Report G 320-2687, April 1977. [lo] Jones A.K., Protection mechanism models: their usefulness, in Foundations of Secure Computation, Academic Press, New York, 1977. [ll] Landwher C.E., Formal models for computer security, ACM Computing Surveys, vol. 13, n. 3, Sept. 1981. [12] Hartson H.R., Database Security-System Architectures, Information Systems, vol. 6, 1981. [I31 Harrison M.A., Ruzzo W.L., Ulmann J.D.. On protection in operating systems, Comm. ACM 19.8, Aug. 1976. I141 Fernandez E.B., Wood C., The relationship between Operating Systems and database system security: A survey, Proc. IEEE Computer and Software Application Conf., Chicago, Nov. 1977. [151 Lampson B.W., Protection, Proc. 5th Annual Princeton Conf. on Info. Sciences and Systems, 1971. Reprinted in ACM Operating Systems Review 8, 1, January 1974. principles and [I61 Graham G.S., Denning P.J., Protection: practice, AFIPS Conf. Proc. 40, Montvale, N.J., 1972. (171 Lipton R.J., Snyder L., A linear time algorithm for deciding subject security, Journal ACM 24, 3, July 1977. and I181 Bishop M., Snyder L., The transfer of information authority in a protection system, Proc. 7th Symp. Operating Systems Principles, ACM SIGOPS Operating Syst. Rev. 13, 4, Dec. 1979. 1191 Snyder L., Formal models of capability based protection systems. Tech. Rep. 151, Dept. Computer Science, Yale Univ., New Haven, Con”., April 1979. Transport of WI Lockman A., Minsky N., Unidirectional Rights and Take-Grant Control, IEEE Trans. on Software Engineering, vol. 8, n. 6, November 1982. Pll Hartson H.R., Hsiao D.K., A semantic model for database protection languages, Proc. 2nd Int. Conf. on Very Large Data Bases, Brussels, Sept. 1976. E.B., Summers R.C., Coleman C.D., An WI Fernandez authorization model for a shared database, Proc. ACMSIGMOD Int. Conf. on Management of Data, San Jose, May 1975. ~231 Baldissera C., Ceri S., Pelagatti G., Bracchi G., Interactive specification and formal verification of user’s view in database design, Proc. 5th. Int. Conf. on Very Large Data Bases, Rio de Janeiro, Oct. 1979. [24] Bussolati U., Martella G., Treating data privacy in distributed systems, Information & Management, vol. 4, n. 6, 1981. 1251 Fernandez E.B., Summers R.C., Wood C., Database security and integrity, Addison-Wesley Publ. Co., 1981.

hf. Fugini, G. Martella / ACTEN

213

Appendix PROGRAM B begin (Select Ei’s direct subgraph on SC = S’(Ei)}; (Select the nodes which are not leaves in S’(Ei) = Xl, X2,. ., Xn; n = number of these nodes); t:=1; call subl; (Select Ei’s direct subgraph on DC = S”(B)); (Select the nodes that are not leaves in S”(Ei) and belong to a grant (revoke) chain together with Ei = Xl, X2.. , Xn; n := number of these nodes]; t:=1. call sub2; I’S authorization (protection) state := S’(Ei)U S”(B)); end. lE’ Procedure sub1 begin for y = 1 to n do begin {Select X,‘s direct subgraph on SC); {For every action in Xv’s direct subgraph apply algorithm A (see sect. 3.3.1, where A, is the action between Ei and X,, A,, is the action between X, and the considered entity of the X,‘s direct subgraph)}; (Obtain a new Ei’s subgraph on SC}; if (the subgraph contains more actions on the same entity) then {select the action on the highest level and obtain a new Ei’s subgraph on SC = S’(Ei)); if (X,‘s direct subgraph has nodes that are not leaves] then begin {select the nodes that are not leaves in X,‘s direct subgraph on SC = Xl, X2,. , Xn’; n’= number of these nodes); t:=t+1 call sub1 (where n: = n’); end else begin ify=n then if t = 1 then stop else t:=t-I end end (do) end. (procedure subl) Procedure sub2 begin for y = 1 to n do begin {Select X,‘s direct subgraph on DC); (For every action in X,‘s direct subgraph apply algorithm A (see sect. 3.3.1, where Ai, is the static action granted by Ei to X,, Aj, is the static action granted by X, to the considered entity in the X,‘s direct subgraph)); {Obtain a new Ei’s subgraph on DC}; if {the subgraph contains more actions on the same entity] then (select the action of the highest level and obtain a new Ei’s subgraph on DC = S”(Ei)); if (X,3 direct subgraph has nodes that are are not leaves and belong to a grant (revoke) chain together with Ei)

M. Fugini, G. Martella / ACTEN

214 then begin

{Select the nodes which are not leaves and belong to a grant (revoke) chain together direct subgraph on DG; Xl, X2.. _,Xn’, n’ = number of these nodes]; t:=t+1 call sub2 (where n: = n’); end else

begin if y = n then if

t=1

then stop else

end end {do) end. {procedure sub2)

t:=t-1

with Ei in X,‘s