- Email: [email protected]
The development of a specification language for a computer security system
143
The Development of a Specification for a Computer Security Svstem
Language
J
Jan
H.P.
1. Introduction
Eloff
Rand A/rikaans Unruers~ty, Aucklandprrrk, Johannesburg, 2000 South Africa
P.O.
Box
524,
The primary goal of this paper is to define an initial step towards the definition of ‘systems grammar’ based on the notion of formal languages which can be used as a ‘tool’ in the formal representation of computer security systems. Currently all modelling done on computer security systems is written up as mathematical models. These mathematical models are usually based on the mathematics of relations amongst objects, as opposed to the model described in this paper which is based on the theory of formal languages. This paper is aimed at people who are doing research on the logical aspects of computer security. It is the first of a series of two papers. This paper will give interim results and make more specific the definition of a ‘formal language’ which suits the computer security environment. The second paper will illustrate the actual use of the defined ‘formal language’ and show how to represent the characteristics of a computer security environment by using this ‘formal language’. Keywords; Logical security, Mathematical models, security, Specification languages. Formal languages
Jan H.P. Eloff received a B.Sc. (Computer Science) degree at the Rand Afrikaans University, Johannesburg, South Africa in 1978. In 1979 he received an honours degree and in 1980 an M.Sc. in Computer Science at the same university. His dissertation involved in-depth study of all the logical aspects of computer security and he delivered a paper on this work at the South African Computer symposium held in October 1981. Part of this research was published in “Computers & Security” (Vol. 2, Nr. 3) under the title “Selection Process for Security Packages”. Mr. Eloff is currently a senior systems analyst with SASOL, South Africa, and is completing his work for a Ph.D.
North-Holland Computers & Security
0167-4048/85/$3.30
4 (1985) 143-147
0 1985, Elsevier Science Publishers
Computer security can be seen as the protection of the organization’s computer assets and the effectiveness of the installation to provide reliable and accurate service of a high standard. Functionally, computer security can be divided into physical and logical security. Physical security can be defined as the action that prevents physical harm to the resources of the computer system. Logical security is the protection of data and programs stored in the system. As stated in the majority of the literature available, the three most basic requirements for a logical security system are: 0 Each reference made by a program must be verified. 0 The security system must be an isolated system - this feature will protect it from the interactions of any other systems. l The software security system must be proven correct. A logical security system can be proven correct by one of the following alternatives: The code of the programs in the system can be proved correct. A prototype of the system, i.e. a mathematical model can be proved correct. The system can be proved correct through excessive testing. In the current literature available all the prototypes of systems are represented as mathematical models. These mathematical models are mainly based on the mathematics of the relations among objects.
2. Objectives
for this Research
The objective of this paper is to define an initial step towards the definition of a ‘systems grammar’ based on the notion of formal languages which can be used as a ‘tool’ when representing computer security systems formally. These objectives are shown in Figure 1.
B.V. (North-Holland)
144
J. H. P. Eloff / Specification
Language for a Security System
3. Required Features for the ‘To Be Developed’ Grammar
Fig. 1. Diagram of Research Objectives
Thus, the three areas that play a major role in this research are: i Computer Security ii Mathematical Modelling iii Formal Languages The objectives are to try to find an appropriate formal grammar/language which can be used to represent the elements as well as the relationships among those elements which form part of a computer security environment. The relation ‘COMPUTER SECURITY SYSTEM - MATHEMATICAL MODEL’ is very well defined in different mathematical models available today, e.g. the model developed by Bell. The relation ‘FORMAL LANGUAGES MATHEMATICAL MODEL’ is well defined by the fact that the theory of formal languages is very strongly based on the theory of mathematics. The relation ‘FORMAL LANGUAGES COMPUTER SECURITY SYSTEM’ is the stated objective of the paper. The strategy followed to define the relation ‘FORMAL LANGUAGES’COMPUTER SECURITY SYSTEM was to define initially the ‘logical’ environment for a computer security system, i.e. all the elements that play a role as well as their interaction with each other. In addition we evaluate a mathematical model for this environment and define a formal grammar which will best represent this environment.
The ‘ideal’ formal grammar to fulfil the requirements as set by the computer security environment can be summarized as having the following features: 1. Context sensitivity - this feature will implement the idea of a ‘need-to-know’ facility, i.e. a user should have a certain level of knowledge before he can gain access to a specifically protected object in the system. 2. Mapping - this is a common feature in all formal languages. This facility supports the idea of cryptography, i.e. the transformation of a readable message to a message in encoded form. Mapping will also contribute to the assignment of security classes and categories to the users in the system. The mapping and context sensitivity features of a grammar support the idea of program pathing in our model. Program pathing allows for the dynamic allocation of a higher access authority under certain conditions. 3. Numeric - the ‘to be developed’ grammar must be able to interpret numeric constants, i.e. 3 must not only be seen as a symbol but also as a symbol with an attached numeric value. The implementation of this facility will help us to compare symbols. Specifically in the security environment we want to compare security classifications of objects. We also need a ‘numeric’ facility to implement time indices (i.e. elements of a time set) which are needed to define a secure state of a system. 4. The ‘to be developed’ grammar must be able to control ‘n’ grammars, these grammars to be on a subordinate level. This will be the realisation of the concept of multiple users operating concurrently in a real system. 5. The ‘to be developed’ grammar must be able to test for the equivalence between strings, but also, if possible, test for the equivalence between a string and the contents of a cell (i.e. a variable). This feature will help us to do a test on the access rights of a user. 6. The ‘to be developed’ grammar must also be able to handle global and local symbols with not only rewriting capabilities but also doing assignments. This feature contributes to the implementation of concurrency in a multi-access database environment.
145
J. H. P. Eloff / Specificatmn Language for a Security System
7. Deadlock - the grammar must be able to handle the deadlock situation as we want to provide in the model for multiple users operating concurrently in a common data base environment.
4. M-Systems
Grammar
Let us call the grammar that will fit the previously mentioned features (section 3) an M-Systems Grammar. Existing formal languages were reviewed functionally. It turned out that no existing grammar is suitable to fit the requirements set in section 3. However, the programmed, scattered context and permitting context grammars showed potential for further investigation. As part of the research done we showed that the pure programmed grammar provides a natural framework for representing concurrent usage of code. As stated, the idea is to keep the defined grammar as close as possible to the existing theory of formal languages. The strength of this concept indicated to us a path to be followed while we were defining the ideal grammar. The development of the M-Systems Grammar was as follows: 4.1. Existing
theory: Grammar
the base for
the M-Systems
The programmed, scattered context and permitting context grammars will form the basis of the new M-Systems Grammar. As the theory of formal languages is well proven, we want to keep the M-Systems Grammar as pure as possible, i.e. defined in the concepts of formal languages in the usual context. Thus, our initial definition of the M-Systems Grammar will be without any deviation from the existing theory of formal languages. Let us refer to this version of the M-Systems Grammar as a Minimum M-Systems Grammar. 4.2. Defining the Minimum
M-Systems
Grammar
The Minimum M-Systems Grammar is based purely on the three grammars mentioned previously. This grammar controls a number of grammars which will generate strings of symbols in parallel, the interdependency among the ‘m’ grammars on subordinate level will be controlled by a special set of symbols called the ‘global’ symbols.
The productions of the Minimum M-Systems Grammar can be divided into two groups: First, there is a set of productions specifically designed to manipulate the set of global symbols. Second, there is a set of productions to manipulate the variables and terminals in the usual formal language sense. The Minimum M-Systems Grammar can be seen as a ‘high level grammar’ as opposed to the programmed, scattered and permitting context grammars. We will now give the formal definition of the Minimum M-Systems Grammar. Definition: A minimum 6-tuple
M-Systems
G,=
q, h, S
;
{G,},
V,,u,
i i=l
is a
> 1
where each Gj is a 4-tuple G, = (I&
Grammar
defined
by
I%,,, P,, B,),<,<,v.
We will now discuss the meaning of each symbol: V,={g,, g2,_..,g,},EN isafinitesetofsymbols called the global symbols. Each G, is a grammar defined as follows: Each production in P, has a unique label, q, and h, are mappings of production labels in P, into the set of subsets of production labels in P,. q, and h, can be different for each G,. Let f be a label for a production in G,. We will then refer to q,(f) and h,(f) respectively as the success and failure fields of f. Let q,(f) be represented by and h,(f) be represented by S(f,,?. . .3 f,,> F(f,,, . . . >6,). (i) V,, is the set of non-terminal VN = v,u
symbols:
v, u v,,,
where for every i: V,, is a finite set of symbols, local symbols for G,, and V,, is a finite set of symbols, variables for G,,
called
the set of
called
the set of
VI n Vz = 0 and V, n VK = 0 and V, n V, = 0. V,, may be different from F, for i #j, but need not be. The same applies for V,, and V2,, i #j.
Let v, = {VI,, V,,, V,, ,..., v,=
{I$,,
I&, l&...J&}.
V,,}
and
J. H. P. Eloff / Specification Language
146
(ii) V, is the set of terminal mar G, and V,, n VT, = a.
symbols
for gram-
for a Security System
only used as a shorthand (iv) B, is the initial
(iii) P, = P’ u p where (a) P’ is a set of productions specifically designed to manipulate the sets of local and global symbols. Every production in P’ is of the form: (f,)A
+B
S(f,)F(fR)
notation.
symbol
of G,, and
B, = CrC,S,, where C, E V, (i.e. a global symbol), C, E V,, (i.e. a local symbol), S, E V,, (i.e. a variable).
The application of the above production is the same as for a production of class p, as discussed further on. (b) p is a set of productions to manipulate the variables and terminals in the usual formal language sense. p consists of two classes of productions namely P, and P2, i.e., P=P,UP,. Productions productions
in P, are pure programmed of the form:
(L)X’B
S(f,)F(fR)>
grammar
We have now defined the elements of the grammar G,. Initially we defined the Minimum M-systems Grammar G, as: M G,=
i
u {G,}, I=1
V,,
p,
4, h, S 1’
The first= two elements have already been plained. P is a single production of the form: S-(B,,,
ex-
BIZY..,B,Jk& _
where where XE
v2,,
B E (v2,u
I/T,,)*.
An application of a production of class P, to a string U has the following meaning: if X is present in U it can be substituted by R and the follow-up production will be selected from S(i). If X is not present in U, no substitution will take place and the follow-up production will be selected from F(f,). Productions in P2 are of the form: (f,)T-,
B[U:O]
S(f,)F(f,&
S is the start symbol, B,, is the start symbol of G,, and of (1, 2,. . . , k). (ii, i *, . . . , ik) is a permutation This completes the definition of a Minimum MSystems Grammar. The concepts implemented in the Minimum M-Systems Grammar which were originally set out in our set of required features are: - context sensitivity, - mapping, _ global and local symbols, - parallelism. 4.3. Define the M-Systems Grammar
where TE
Vz,,
R E (V,, U VT,)* and UC VN,.
A production of class Pz is used as follows: if T appears in a string W and all symbols of U appear somewhere in W, then T is replaced by R and the follow-up production is selected out of S(i), otherwise the follow-up production is selected out of F(i). Note that the production above is actually a permitting context production as defined by [6]. Note further that this production can be simulated by a series of pure programmed grammar productions. This form of the production is therefore
The M-Systems Grammar is based on the Minimum M-Systems Grammar with a few additional features. Most important is the implementation of the concept of a ‘variable’ in a grammar, as stated in our set of required features. This concept will help us test for security classes of objects in a computer security environment. Seven classes of productions are defined where the majority of these classes provide for the handling of ‘variables’, i.e. a symbol which is the name of a cell which again contains a symbol. The M-Systems Grammar can be seen as a ‘high level grammar’ as opposed to the Minimum
J. H. P. Eloff / Specificatron Language for a Securily System
M-Systems a deviation languages Minimum herits all Grammar aspects of permitting
Grammar. This M-System Grammar is from the existing theory of formal and cannot be defined as purely as the M-Systems Grammar. However, it inaspects of the Minimum M-Systems and for that reason it also inherits all the programmed, scattered context and context grammars.
4.4. An Enhanced
M-Systems
Grammar
The previously defined M-Systems Grammar contains most of the required features of the ‘to-be developed’ grammar. However, we are still unable to make comparisons between numeric values. The highlight of this enhancement to the MSystems Grammar is to implement a ‘numeric’ concept in a grammar. This is implemented through a special set of symbols called the ‘counting’ symbols. This enhanced M-Systems Grammar contains all of the required features as set out in (section 3) as well as some features to qualify as a pseudo programming language. Examples of programming constructs that can be provided, are: - IF---THEN construct - DO---WHILE construct - basic assignments, e.g. A = A + B. Note - the formal definitions of the “M-Systems Grammar” and the “Enhanced M-Systems Grammar” are not given in this paper. These two grammars are based on the Minimum M-Systems Grammar as defined in this paper. This concludes our definition of the M-Systems Grammar. In the follow-up paper we will illustrate how this M-Systems Grammar can be utilized as a tool in the formal presentation of computer security systems. This formal presentation of computer systems will increase the degree to which a computer security system can be proven correct.
5. Conclusions The Enhanced M-Systems Grammar is an enhancement as well as a deviation of the existing
147
theory of formal languages. This grammar serves as a ‘formal tool’ which can be utilized for the modeling of a computer security system. The unique benefit is that this ‘formal tool’ is based on the theory of formal languages which can be accepted as mathematically correct. This ‘formal tool’ has more benefits as opposed to a mathematical model as it contains pure computer related features, e.g. it inherits strong programmability features. It can also be seen as a control structure through which many of the concepts used in operating system theory can be represented, concepts like: - concurrent processes, - deadlock, - locking and unlocking of records. This ‘formal tool’ also contains certain ‘dynamic’ features that will contribute to the definition of expert systems. These systems are becoming an important part of the ‘logical’ aspects of computer security. In the follow-up paper it will be shown how this M-Systems Grammar can be used to formally describe a computer security system.
References [l] Elliot D, Bell, et al., “Secure Computer Systems. A Mathematical Model Volume II” Mitre Corporation (Nov. 1973). [2] J.H.P. Eloff, “Computer Security with special reference to the software aspect” MSc. Dissertation, Rand Afrikaans University, South Africa (1980). Process for Security Packages” [3] J.H.P. Eloff, “Selection Computers & Security, Vol. 2, Nr. 3. p. 256-260, 1983. [4] R.J. Lipton & T.A. Budd, “On Classes of Protection Systems” Foundations of Secure Computation, p. 281-296 Academic Press (1978). [S] J. Nicolas, “Logic for Improving Integrity Checking in Relational Data Bases” Acta Information, Vol. 18, p. 227-253, 1982. [6] A. Salomaa, “Formal Languages” Academic Press (1973). [7] S.H. van Solms. “Random Context Array Grammars” Proceedings of IFIP Congress 80, p. 59-64 North Holland.
The Development of a Specification for a Computer Security Svstem
Language
J
Jan
H.P.
1. Introduction
Eloff
Rand A/rikaans Unruers~ty, Aucklandprrrk, Johannesburg, 2000 South Africa
P.O.
Box
524,
The primary goal of this paper is to define an initial step towards the definition of ‘systems grammar’ based on the notion of formal languages which can be used as a ‘tool’ in the formal representation of computer security systems. Currently all modelling done on computer security systems is written up as mathematical models. These mathematical models are usually based on the mathematics of relations amongst objects, as opposed to the model described in this paper which is based on the theory of formal languages. This paper is aimed at people who are doing research on the logical aspects of computer security. It is the first of a series of two papers. This paper will give interim results and make more specific the definition of a ‘formal language’ which suits the computer security environment. The second paper will illustrate the actual use of the defined ‘formal language’ and show how to represent the characteristics of a computer security environment by using this ‘formal language’. Keywords; Logical security, Mathematical models, security, Specification languages. Formal languages
Jan H.P. Eloff received a B.Sc. (Computer Science) degree at the Rand Afrikaans University, Johannesburg, South Africa in 1978. In 1979 he received an honours degree and in 1980 an M.Sc. in Computer Science at the same university. His dissertation involved in-depth study of all the logical aspects of computer security and he delivered a paper on this work at the South African Computer symposium held in October 1981. Part of this research was published in “Computers & Security” (Vol. 2, Nr. 3) under the title “Selection Process for Security Packages”. Mr. Eloff is currently a senior systems analyst with SASOL, South Africa, and is completing his work for a Ph.D.
North-Holland Computers & Security
0167-4048/85/$3.30
4 (1985) 143-147
0 1985, Elsevier Science Publishers
Computer security can be seen as the protection of the organization’s computer assets and the effectiveness of the installation to provide reliable and accurate service of a high standard. Functionally, computer security can be divided into physical and logical security. Physical security can be defined as the action that prevents physical harm to the resources of the computer system. Logical security is the protection of data and programs stored in the system. As stated in the majority of the literature available, the three most basic requirements for a logical security system are: 0 Each reference made by a program must be verified. 0 The security system must be an isolated system - this feature will protect it from the interactions of any other systems. l The software security system must be proven correct. A logical security system can be proven correct by one of the following alternatives: The code of the programs in the system can be proved correct. A prototype of the system, i.e. a mathematical model can be proved correct. The system can be proved correct through excessive testing. In the current literature available all the prototypes of systems are represented as mathematical models. These mathematical models are mainly based on the mathematics of the relations among objects.
2. Objectives
for this Research
The objective of this paper is to define an initial step towards the definition of a ‘systems grammar’ based on the notion of formal languages which can be used as a ‘tool’ when representing computer security systems formally. These objectives are shown in Figure 1.
B.V. (North-Holland)
144
J. H. P. Eloff / Specification
Language for a Security System
3. Required Features for the ‘To Be Developed’ Grammar
Fig. 1. Diagram of Research Objectives
Thus, the three areas that play a major role in this research are: i Computer Security ii Mathematical Modelling iii Formal Languages The objectives are to try to find an appropriate formal grammar/language which can be used to represent the elements as well as the relationships among those elements which form part of a computer security environment. The relation ‘COMPUTER SECURITY SYSTEM - MATHEMATICAL MODEL’ is very well defined in different mathematical models available today, e.g. the model developed by Bell. The relation ‘FORMAL LANGUAGES MATHEMATICAL MODEL’ is well defined by the fact that the theory of formal languages is very strongly based on the theory of mathematics. The relation ‘FORMAL LANGUAGES COMPUTER SECURITY SYSTEM’ is the stated objective of the paper. The strategy followed to define the relation ‘FORMAL LANGUAGES’COMPUTER SECURITY SYSTEM was to define initially the ‘logical’ environment for a computer security system, i.e. all the elements that play a role as well as their interaction with each other. In addition we evaluate a mathematical model for this environment and define a formal grammar which will best represent this environment.
The ‘ideal’ formal grammar to fulfil the requirements as set by the computer security environment can be summarized as having the following features: 1. Context sensitivity - this feature will implement the idea of a ‘need-to-know’ facility, i.e. a user should have a certain level of knowledge before he can gain access to a specifically protected object in the system. 2. Mapping - this is a common feature in all formal languages. This facility supports the idea of cryptography, i.e. the transformation of a readable message to a message in encoded form. Mapping will also contribute to the assignment of security classes and categories to the users in the system. The mapping and context sensitivity features of a grammar support the idea of program pathing in our model. Program pathing allows for the dynamic allocation of a higher access authority under certain conditions. 3. Numeric - the ‘to be developed’ grammar must be able to interpret numeric constants, i.e. 3 must not only be seen as a symbol but also as a symbol with an attached numeric value. The implementation of this facility will help us to compare symbols. Specifically in the security environment we want to compare security classifications of objects. We also need a ‘numeric’ facility to implement time indices (i.e. elements of a time set) which are needed to define a secure state of a system. 4. The ‘to be developed’ grammar must be able to control ‘n’ grammars, these grammars to be on a subordinate level. This will be the realisation of the concept of multiple users operating concurrently in a real system. 5. The ‘to be developed’ grammar must be able to test for the equivalence between strings, but also, if possible, test for the equivalence between a string and the contents of a cell (i.e. a variable). This feature will help us to do a test on the access rights of a user. 6. The ‘to be developed’ grammar must also be able to handle global and local symbols with not only rewriting capabilities but also doing assignments. This feature contributes to the implementation of concurrency in a multi-access database environment.
145
J. H. P. Eloff / Specificatmn Language for a Security System
7. Deadlock - the grammar must be able to handle the deadlock situation as we want to provide in the model for multiple users operating concurrently in a common data base environment.
4. M-Systems
Grammar
Let us call the grammar that will fit the previously mentioned features (section 3) an M-Systems Grammar. Existing formal languages were reviewed functionally. It turned out that no existing grammar is suitable to fit the requirements set in section 3. However, the programmed, scattered context and permitting context grammars showed potential for further investigation. As part of the research done we showed that the pure programmed grammar provides a natural framework for representing concurrent usage of code. As stated, the idea is to keep the defined grammar as close as possible to the existing theory of formal languages. The strength of this concept indicated to us a path to be followed while we were defining the ideal grammar. The development of the M-Systems Grammar was as follows: 4.1. Existing
theory: Grammar
the base for
the M-Systems
The programmed, scattered context and permitting context grammars will form the basis of the new M-Systems Grammar. As the theory of formal languages is well proven, we want to keep the M-Systems Grammar as pure as possible, i.e. defined in the concepts of formal languages in the usual context. Thus, our initial definition of the M-Systems Grammar will be without any deviation from the existing theory of formal languages. Let us refer to this version of the M-Systems Grammar as a Minimum M-Systems Grammar. 4.2. Defining the Minimum
M-Systems
Grammar
The Minimum M-Systems Grammar is based purely on the three grammars mentioned previously. This grammar controls a number of grammars which will generate strings of symbols in parallel, the interdependency among the ‘m’ grammars on subordinate level will be controlled by a special set of symbols called the ‘global’ symbols.
The productions of the Minimum M-Systems Grammar can be divided into two groups: First, there is a set of productions specifically designed to manipulate the set of global symbols. Second, there is a set of productions to manipulate the variables and terminals in the usual formal language sense. The Minimum M-Systems Grammar can be seen as a ‘high level grammar’ as opposed to the programmed, scattered and permitting context grammars. We will now give the formal definition of the Minimum M-Systems Grammar. Definition: A minimum 6-tuple
M-Systems
G,=
q, h, S
;
{G,},
V,,u,
i i=l
is a
> 1
where each Gj is a 4-tuple G, = (I&
Grammar
defined
by
I%,,, P,, B,),<,<,v.
We will now discuss the meaning of each symbol: V,={g,, g2,_..,g,},EN isafinitesetofsymbols called the global symbols. Each G, is a grammar defined as follows: Each production in P, has a unique label, q, and h, are mappings of production labels in P, into the set of subsets of production labels in P,. q, and h, can be different for each G,. Let f be a label for a production in G,. We will then refer to q,(f) and h,(f) respectively as the success and failure fields of f. Let q,(f) be represented by and h,(f) be represented by S(f,,?. . .3 f,,> F(f,,, . . . >6,). (i) V,, is the set of non-terminal VN = v,u
symbols:
v, u v,,,
where for every i: V,, is a finite set of symbols, local symbols for G,, and V,, is a finite set of symbols, variables for G,,
called
the set of
called
the set of
VI n Vz = 0 and V, n VK = 0 and V, n V, = 0. V,, may be different from F, for i #j, but need not be. The same applies for V,, and V2,, i #j.
Let v, = {VI,, V,,, V,, ,..., v,=
{I$,,
I&, l&...J&}.
V,,}
and
J. H. P. Eloff / Specification Language
146
(ii) V, is the set of terminal mar G, and V,, n VT, = a.
symbols
for gram-
for a Security System
only used as a shorthand (iv) B, is the initial
(iii) P, = P’ u p where (a) P’ is a set of productions specifically designed to manipulate the sets of local and global symbols. Every production in P’ is of the form: (f,)A
+B
S(f,)F(fR)
notation.
symbol
of G,, and
B, = CrC,S,, where C, E V, (i.e. a global symbol), C, E V,, (i.e. a local symbol), S, E V,, (i.e. a variable).
The application of the above production is the same as for a production of class p, as discussed further on. (b) p is a set of productions to manipulate the variables and terminals in the usual formal language sense. p consists of two classes of productions namely P, and P2, i.e., P=P,UP,. Productions productions
in P, are pure programmed of the form:
(L)X’B
S(f,)F(fR)>
grammar
We have now defined the elements of the grammar G,. Initially we defined the Minimum M-systems Grammar G, as: M G,=
i
u {G,}, I=1
V,,
p,
4, h, S 1’
The first= two elements have already been plained. P is a single production of the form: S-(B,,,
ex-
BIZY..,B,Jk& _
where where XE
v2,,
B E (v2,u
I/T,,)*.
An application of a production of class P, to a string U has the following meaning: if X is present in U it can be substituted by R and the follow-up production will be selected from S(i). If X is not present in U, no substitution will take place and the follow-up production will be selected from F(f,). Productions in P2 are of the form: (f,)T-,
B[U:O]
S(f,)F(f,&
S is the start symbol, B,, is the start symbol of G,, and of (1, 2,. . . , k). (ii, i *, . . . , ik) is a permutation This completes the definition of a Minimum MSystems Grammar. The concepts implemented in the Minimum M-Systems Grammar which were originally set out in our set of required features are: - context sensitivity, - mapping, _ global and local symbols, - parallelism. 4.3. Define the M-Systems Grammar
where TE
Vz,,
R E (V,, U VT,)* and UC VN,.
A production of class Pz is used as follows: if T appears in a string W and all symbols of U appear somewhere in W, then T is replaced by R and the follow-up production is selected out of S(i), otherwise the follow-up production is selected out of F(i). Note that the production above is actually a permitting context production as defined by [6]. Note further that this production can be simulated by a series of pure programmed grammar productions. This form of the production is therefore
The M-Systems Grammar is based on the Minimum M-Systems Grammar with a few additional features. Most important is the implementation of the concept of a ‘variable’ in a grammar, as stated in our set of required features. This concept will help us test for security classes of objects in a computer security environment. Seven classes of productions are defined where the majority of these classes provide for the handling of ‘variables’, i.e. a symbol which is the name of a cell which again contains a symbol. The M-Systems Grammar can be seen as a ‘high level grammar’ as opposed to the Minimum
J. H. P. Eloff / Specificatron Language for a Securily System
M-Systems a deviation languages Minimum herits all Grammar aspects of permitting
Grammar. This M-System Grammar is from the existing theory of formal and cannot be defined as purely as the M-Systems Grammar. However, it inaspects of the Minimum M-Systems and for that reason it also inherits all the programmed, scattered context and context grammars.
4.4. An Enhanced
M-Systems
Grammar
The previously defined M-Systems Grammar contains most of the required features of the ‘to-be developed’ grammar. However, we are still unable to make comparisons between numeric values. The highlight of this enhancement to the MSystems Grammar is to implement a ‘numeric’ concept in a grammar. This is implemented through a special set of symbols called the ‘counting’ symbols. This enhanced M-Systems Grammar contains all of the required features as set out in (section 3) as well as some features to qualify as a pseudo programming language. Examples of programming constructs that can be provided, are: - IF---THEN construct - DO---WHILE construct - basic assignments, e.g. A = A + B. Note - the formal definitions of the “M-Systems Grammar” and the “Enhanced M-Systems Grammar” are not given in this paper. These two grammars are based on the Minimum M-Systems Grammar as defined in this paper. This concludes our definition of the M-Systems Grammar. In the follow-up paper we will illustrate how this M-Systems Grammar can be utilized as a tool in the formal presentation of computer security systems. This formal presentation of computer systems will increase the degree to which a computer security system can be proven correct.
5. Conclusions The Enhanced M-Systems Grammar is an enhancement as well as a deviation of the existing
147
theory of formal languages. This grammar serves as a ‘formal tool’ which can be utilized for the modeling of a computer security system. The unique benefit is that this ‘formal tool’ is based on the theory of formal languages which can be accepted as mathematically correct. This ‘formal tool’ has more benefits as opposed to a mathematical model as it contains pure computer related features, e.g. it inherits strong programmability features. It can also be seen as a control structure through which many of the concepts used in operating system theory can be represented, concepts like: - concurrent processes, - deadlock, - locking and unlocking of records. This ‘formal tool’ also contains certain ‘dynamic’ features that will contribute to the definition of expert systems. These systems are becoming an important part of the ‘logical’ aspects of computer security. In the follow-up paper it will be shown how this M-Systems Grammar can be used to formally describe a computer security system.
References [l] Elliot D, Bell, et al., “Secure Computer Systems. A Mathematical Model Volume II” Mitre Corporation (Nov. 1973). [2] J.H.P. Eloff, “Computer Security with special reference to the software aspect” MSc. Dissertation, Rand Afrikaans University, South Africa (1980). Process for Security Packages” [3] J.H.P. Eloff, “Selection Computers & Security, Vol. 2, Nr. 3. p. 256-260, 1983. [4] R.J. Lipton & T.A. Budd, “On Classes of Protection Systems” Foundations of Secure Computation, p. 281-296 Academic Press (1978). [S] J. Nicolas, “Logic for Improving Integrity Checking in Relational Data Bases” Acta Information, Vol. 18, p. 227-253, 1982. [6] A. Salomaa, “Formal Languages” Academic Press (1973). [7] S.H. van Solms. “Random Context Array Grammars” Proceedings of IFIP Congress 80, p. 59-64 North Holland.