delegation and revocation was investigated in access control policy [5], but ...... eight basic sets of units in OrBAC: Org (a set of organizations),S (a set of.
Application Vulnerability Blocking: Restricted Delegation and Revocation in Language Based Security By Eng. Doaa Hassan Salem Mohammed M.Sc. in Communications and Electronics Engineering A Dissertation Submitted in Partial Fulfillment of the Requirements for the degree of Doctor of Philosophy in Computer and Control Engineering At Faculty of Engineering of Zagazig University Supervised by Prof. Dr. Ibrahim E. Ziedan Computers and Systems Department Faculty of Engineering Zagazig University Assoc. Prof. Dr. Sherif M. El Kassas Computer Science Department American University In Cairo
c 2011
Abstract Today, many security application vulnerabilities, especially those that are related to web applications can be viewed as an insecure information flow problem and the different security mechanisms such as access control and encryption are not enough to guarantee a secure information flow. Recently, a new approach has been developed: the use of programming language techniques for specifying and enforcing end to end information-flow policies, well known as security-typed programming languages or languagebased security. In these languages, data types are annotated with security labels in order to identify the confidentiality and/or integrity policies for each data element. A security label is a pair of a confidentiality policy and an integrity policy, which specifies the principals or entities allowed to read or influence the value of the data, respectively. The specification of principals in those languages allows modeling different roles in the application program with different security concerns such as users, groups and processes. In practical applications, language constructs for delegation and revocation among principals are desired in order to permit a temporary information flow from one principal (the grantor) to a certain principale (the delegatee) and to renounce a prior permission. A general form of delegation is already present in some security typed programming languages such as Jif, a well known standard for security typed programming languages. Using delegation in this language a principal p can act for another principal q (i.e., any action taken by principal q is also authorized for principal p).
However, this form of delegation does not restrict the delegation between principals by means of chain, where a certain principal (the grantor) can delegate its authority to another principal (the delegatee) and the later can delegate this authority further to another one only if the former permits this kind of delegation. In addition, there is no restriction on the actions permitted by delegation process, as all the actions taken by the grantor can be performed by the delegatee, which may not be suitable for the practical application. More than that, the revocation between principals for the form of delegation mentioned above does not exist. For example, a principal p can act for q, but a principal q can’t revoke principal p or consider any action taken by it as unauthorized during program execution if it has authorized it before. The support for revocation in the current security typed programming languages occurs at the level of methods in the application program. For example if a method can be executed with some authority granted to it by a certain principal, it can never be executed by removing (revoking) the authority granted to it by this principal. Due to lack of restricting delegation by means of delegation chain and based on the action permitted by delegation process in addition to the lack of revocation between principals, specifying temporary flows of information may prove cumbersome or security breaches may be introduced. The idea of restricted delegation and revocation was investigated in access control policy, but not extended to information flow security policy (where by one can specify the chain of delegation to which the information may flow and later revoke the allowed flows). There exist only few attempts to accommodate these concepts in language-based information flow security. This thesis goes further in this direction by addressing the limitations mentioned b
above in several ways: First the different approaches of restricting delegation and revocation in access control policy are studied. Then the existing approaches that accommodate the concept of delegation and revocation and restricting both in security typed programming languages are reviewed. Finally the limitations in these approaches are pointed out. Next, a new security typed programming language RDR (short for restricted delegation and revocation) is introduced. It allows for a more restricted form of delegation and revocation based on access rights. The syntax of RDR is described with some motivating examples as well as its operational semantics. Following, the error semantics rules for RDR are defined, by exploiting the dynamic analysis approach and enriching it with control-flow-sensitive checks introduced in static analysis approach. The error semantics of RDR provides error messages that specifies the forbidden executions of the program due to encountering insecure information flow by unsatisfying any security condition specified in the premises of semantics rules of RDR or using undeclared variables. These error messages are meant for programmers (or system administrators) to detect possible security-breaches in the developed (deployed) programs. Finally, a prototype evaluator for RDR is developed using the algebraic specification formalism ASF+SDF The implementation of this evaluator is handled in different steps. This includes the specification of RDR syntax in SDF, and implementing its operational and error semantics in ASF+SDF.To show the applicability of RDR in practice, several examples are written in its syntax and evaluated using the implemented evaluator in ASF+SDF environment. c
d
Acknowledgments First of All I must thank Allah for his numerous graces and for helping me to continue till finishing the work of my thesis. This dissertation could not have been written without a help from many people in Egypt and Netherlands. Starting from Egypt, where the basic idea of my thesis research was born, I am so grateful to my supervisor Dr. Sherif El kassas who encouraged and guided me throughout my academic research in Egypt for more than three years. I would like to thank him for his assistance in addition to his valuable advices, particulary during my research visit to Eindhoven University of Technology (TU/e) in Netherlands. I will never forget his humanity and continuous support when I was complectly down. Also I am also grateful to my supervisor Prof. Dr. Ibrahim Ziedan, the godfather of all students of Computer Engineering in Zagazig University for his kindness, valuable suggestions, patience in supervising this thesis and for professional ethics that I acquired from him during my master and PhD. I am thankful to the Examination Committee, particulary Prof. Dr. Ali A. Fahmy for his valuable remarks about my thesis. Switching to TU/e in Nederlands, where the core work of this thesis was done, I am so grateful to Dr. MohammadReza Mousavi, my advisor there, who accepted me to complete my research there and also for his effort and help. He was so patient in teaching me and I will never forget that he opened a door for completing my PhD work when I thought that all doors became closed. Also I am grateful to Prof. Dr. Mark van Den Brand and the PhD candidate, Luc Engelen in software Engineering and Technology group for helping me in dealing with the implementations tool ASF+SDF. I got benefits from discussion with them in addition to many creative ideas, valuable suggestions i
and comments. I am also grateful to Dr. ir. Jerry den Hartog in Security Group for helping me in understanding and formalizing many specific issues in information flow security and for his valuable remarks about my thesis. Special thank to Prof. Dr. ir. Jan Friso Groot who accepted to extend my research visit to Design and Analysis group in TU/e for more than one year and half. I would also like to thank him for his valuable suggestions and guidance during this time in addition to his useful remarks about my thesis, although there was no chance to work in research with him. I am thankful to the professors of TU/e who accepted me to attend lectures in their courses or assign some meetings with them which increased my knowledge and enriched my way of thinking about research. Also I would like to thank my TU/e colleagues who provided me with some useful suggestions, particulary my office roommates Muhammad Atif who gave me some tips in dealing with LATEX and Frank Stappers who helped me in solving some problems when dealing with Linux. Also I would like to thank Jan Willem Knopper, the IT developer in in TU/e who helped me in fixing some problems with Miktex. I would also like to express my thanks to the ministry of higher education in Egypt for partially funding my stay in Netherlands and also for my organization, the National Telecommunication Institute in Cairo for recommending me for this scholarship. Finally, I would like to thank my family and many friends in Egypt and Netherlands for their support and encouragement which made the completion of this work possible.
ii
Contents List of Figures
vii
1 Introduction
1
1.1
Motivation
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Security policy overview . . . . . . . . . . . . . . . . . . . . .
4
1.3
Information flow security policy . . . . . . . . . . . . . . . . .
5
1.3.1
Static analysis of information flow security policy . . .
6
1.3.2
Dynamic analysis of information flow security policy
.
7
1.4
Information flow security policy versus access control . . . . .
7
1.5
Security-typed programming languages . . . . . . . . . . . . .
8
1.6
Problem statement . . . . . . . . . . . . . . . . . . . . . . . .
9
1.7
Proposed study . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.8
Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 Delegation and revocation in language based security
12
2.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2
Restricted delegation and revocation in access control policy . 13 2.2.1
Delegation and revocation in RBDM . . . . . . . . . . 13
2.2.2
Delegation and revocation in RDM2000 . . . . . . . . . 16
2.2.3
Delegation and revocation in PBDM . . . . . . . . . . 20 iii
2.3
2.2.4
Delegation and revocation in ABDM . . . . . . . . . . 22
2.2.5
Delegation and revocation in RBAC models . . . . . . 24
2.2.6
Delegation and revocation in OrBAC . . . . . . . . . . 26
2.2.7
Delegation and revocation in DBWAC . . . . . . . . . 28
2.2.8
Delegation and revocation in DW-RBAC . . . . . . . . 30
2.2.9
Concluding remarks . . . . . . . . . . . . . . . . . . . . 31
Delegation and revocation in security typed languages . . . . . 33 2.3.1
Restricting delegation and revocation . . . . . . . . . . 35
2.4
Decided Study . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.5
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3 RDR: A Language for Restricted Delegation and Revocation 42 3.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2
Motivating examples . . . . . . . . . . . . . . . . . . . . . . . 43
3.3
RDR syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.4
Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.5
RDR semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.5.1
Information Flow Control . . . . . . . . . . . . . . . . 50
3.5.2
Program configuration (Operational State) . . . . . . . 60
3.5.3
Variable declaration
3.5.4
Assignments . . . . . . . . . . . . . . . . . . . . . . . . 66
3.5.5
If-then-else statements . . . . . . . . . . . . . . . . . . 68
3.5.6
While-do statements . . . . . . . . . . . . . . . . . . . 68
3.5.7
Delegation statements . . . . . . . . . . . . . . . . . . 69
3.5.8
Revocation statements . . . . . . . . . . . . . . . . . . 74
3.5.9
Termination . . . . . . . . . . . . . . . . . . . . . . . . 75
. . . . . . . . . . . . . . . . . . . 65
3.6
Comparison matrix . . . . . . . . . . . . . . . . . . . . . . . . 76
3.7
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 iv
4 RDR Semantics Error Handling 4.1
4.2
RDR Error Semantics
78
. . . . . . . . . . . . . . . . . . . . . . 79
4.1.1
Variable declaration error rule . . . . . . . . . . . . . . 80
4.1.2
Error rule of assignment . . . . . . . . . . . . . . . . . 80
4.1.3
Error rule of conditional . . . . . . . . . . . . . . . . . 82
4.1.4
Error rule of while-Loop . . . . . . . . . . . . . . . . . 83
4.1.5
Error rule of delegation . . . . . . . . . . . . . . . . . . 84
4.1.6
Error rule of revocation
. . . . . . . . . . . . . . . . . 89
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
5 RDR Implementation
92
5.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.2
Existing approaches for Implementation
5.3
ASF+SDF Language Specification Formalism . . . . . . . . . 97
5.4
Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.5
. . . . . . . . . . . . 93
5.4.1
Language Definition . . . . . . . . . . . . . . . . . . . 102
5.4.2
Environment Definition . . . . . . . . . . . . . . . . . . 105
5.4.3
Semantics Implementation . . . . . . . . . . . . . . . . 107
5.4.4
Evaluator Implementation . . . . . . . . . . . . . . . . 111
Motivating examples . . . . . . . . . . . . . . . . . . . . . . . 113 5.5.1
Delegation example . . . . . . . . . . . . . . . . . . . . 114
5.5.2
Assignment example . . . . . . . . . . . . . . . . . . . 115
5.5.3
If-else-then example . . . . . . . . . . . . . . . . . . . . 116
5.6
Performance evaluation . . . . . . . . . . . . . . . . . . . . . . 117
5.7
Language extension . . . . . . . . . . . . . . . . . . . . . . . . 118
5.8
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 v
6 Conclusions and future work
120
6.1
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
6.2
Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Bibliography
124
Appendices
133
Appendix A The SDF part of RDR-evaluator
133
A.1 The expressions definition in SDF . . . . . . . . . . . . . . . . 133 A.2 The definition of StaticLabel module in SDF . . . . . . . . . . 134 A.3 The definition of DynamicLabel module in SDF . . . . . . . . 135 A.4 The definition of evaluate-exp-value in SDF . . . . . . . . . . 137 A.5 The definition of evaluate-exp-label module in SDF . . . . . . 137 A.6 The definition of evaluate-exp-dl module in SDF . . . . . . . . 138 A.7 The definition of evaluate-exp-flow module in SDF . . . . . . . 138 A.8 The definition of ErrorMessage module in SDF . . . . . . . . . 139 A.9 The definition of Result module in SDF . . . . . . . . . . . . . 140 A.10 The definition of evaluator module in SDF . . . . . . . . . . . 140 A.11 The values definition in SDF . . . . . . . . . . . . . . . . . . . 141 Appendix B The equation part of language evaluator
142
B.1 The equation part of StaticLabel module . . . . . . . . . . . . 142 B.2 The equation part of DynamicLabel module . . . . . . . . . . 145 B.3 The equation part of evaluate-exp-value module . . . . . . . . 151 B.4 The equation part of evaluate-exp-label module . . . . . . . . 153 B.5 The equation part of ev-exp-dl module . . . . . . . . . . . . . 153 B.6 The equation part of evaluate-exp-flow . . . . . . . . . . . . . 155 B.7 The equation part of Result module . . . . . . . . . . . . . . . 157 vi
B.8 The equation part of Variable-declaration module . . . . . . . 157 B.9 The equation part of Assignment module . . . . . . . . . . . . 158 B.10 The equation part of if-then-else module . . . . . . . . . . . . 159 B.11 The equation part of while-do module . . . . . . . . . . . . . . 160 B.12 The equation part of Delegation module . . . . . . . . . . . . 160 B.13 The equation part of Revocation module . . . . . . . . . . . . 166
vii
List of Figures 2.1
Role-hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2
Delegation-tree . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1
Syntax of RDR. . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.2
Security Lattice L . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.1
The Syntax and equation part of Pico type-checker module . . 99
5.2
ASF+SDF meta environment global organization . . . . . . . 100
5.3
Import structure of RDR evaluator . . . . . . . . . . . . . . . 103
5.4
RDR syntax definition in SDF . . . . . . . . . . . . . . . . . . 106
5.5
Definition of variables used in [Delegate-read], [error-Delegateread-1] and and [error-Delegate-read-3] equations in SDF. . . . 112
viii
Chapter 1 Introduction 1.1
Motivation
Recently the number of security application vulnerabilities, especially the remotely exploitable web vulnerabilities has been increased sharply as a result to different kinds of bugs produced by insecure programming. Many of these vulnerabilities, especially those that are related to web applications can be viewed as an insecure information flow problem and the different security mechanisms such as access control and encryption are not enough to guarantee a secure information flow. So security remains the major challenge to achieve in application program. The current programming languages lack information flow security policy enforcement [1] in application program. Such policy protects the confidentiality and integrity of data by preventing secret information from becoming available to unauthorized party and preventing untrusted party from corrupting or destroying the data respectively. Due to this lack, many exploited security vulnerabilities are introduced [2]. Recently, a promising new approach has been developed: the use of 1
Chapter 1. Introduction security-typed programming-languages for specifying and enforcing informationflow policies. Using such languages, the programmer is able to express the information flow security policy explicitly in the application program in a form of confidentiality and integrity policies. The confidentially policy defines the principals or entities allowed to read the data, while the integrity policy specifies the principals or entities allowed to influence the data. The specification of principals in those languages allows for modeling different roles in the application program with different security concerns such as users, groups and processes. In practical applications, language constructs for delegation and revocation among principals are desired in order to permit a temporary information flow from one principal (the grantor) to a certain principal (the delegatee) and to renounce a prior permission. A general form of delegation is already present in some security typed programming languages such as Jif [3, 4], as a certain principal can act for other principal (i.e., any action taken by principal p is also authorized for principal q). However, there is no support for restricted and revocable delegation between principals, where by one can predefine the chain of principals to which the information may flow (i.e. restricted delegation) and later revoke the allowed flows (.i.e restricted revocation) . The idea of restricted delegation and revocation was investigated in access control policy [5], but not extended to information flow security policy. There exist only few attempts to accommodate these concepts in language-based information flow security [6, 7, 8]. However, delegation affects data confidentiality by allowing more principals to read the data and hence it can be considered as an escape hatch or a kind of declassification for a program designed to intentionally release some confidential information as part of its functionality. In addition, it also 2
1.1. Motivation affects data integrity by allowing more principals to write to untainted data and hence it can be considered as a kind of information endorsement [9]. Declassification [10],[11] is already present in some security typed programming languages to relax non-interference [12] property which states that no data flow form high security level in program to low security one, as such property is over restrictive for practical applications. A general form of declassification is presented by adding declassify expression, statement or method to the language syntax to declassify the security level of expression e to lower security level ` [11],[13],[14]. However, the current security typed programming language do not address the declassification of data by means of restricted delegation. There exist only few attempts that address declassification using the general form of delegation [15, 16]The work introduced in this thesis aims to validate the concept of restricted delegation and revocation (in which the grantor principal delegates its access rights (read/write) to a predefined sequence of principals, specified in a form of a delegation chain and later revoke this delegation when it is required) in security typed programming languages. It achieves this by introducing a new security typed programming language RDR (short for restricted delegation and revocation) with new constructs for this purpose. The semantics of this language and are specified in a way that permit declassification and endorsement by means of restricted delegation and later revoking this delegation when it is required. The insecure flows that can be encountered with such kind of declassification and endorsement are prevented using the error semantics of RDR which provides the error messages that describe the forbidden executions of the program which may result in (possibly implicit) information leakage to unauthorized users. These error messages themselves may reveal some sensitive information and hence, are not supposed to be displayed to unauthorized 3
Chapter 1. Introduction users. They are meant for programmers (or system administrators) to detect possible security-breaches in the developed (deployed) programs. This work also goes further in the direction of implementation of language based security, as despite the long history and a large body of research in this field, there seems to be very little practical software in existence for security typed languages that performs secure information flow analysis such as Jif [3],[4] and Flowcaml [17], fable[18] and Aura[19] . This may be due in part to the limitations and restrictive nature of many existing information flow models. It achieves this by introducing a new strategy for implementation in language based security using the algebraic specification formalism ASF+SDF [20] . An evaluator for RDR is developed using this formalism. As a result, many programs written in the syntax of this language are evaluated in practice to check information flow, in addition to the feasibility of translating this language as a domain specific language to a common programming language [21], [22].
1.2
Security policy overview
As Goguen and Meseguer mentioned in [23]: ”A security policy defines the security requirements for a given system.” Thus, a security policy is a formal statement of rules through which a certain system can protect its resources, including people, hardware, software and sensitive data. In other words a security policy describes the security properties of the system. Each rule in the policy statement describes which subjects or principals (e.g. users or processes) may access which objects (e.g. files or peripheral devices) and under which circumstances. What is desired for security may not always be clear, and will vary from 4
1.3. Information flow security policy one system to another. For example, the military model of security is to prevent improper disclosure of sensitive information; an end user might want to limit the access to his/her sensitive files; an e-commerce site may want to prevent modification of transaction records; a financial institution may want to ensure that certain procedures are always followed; and a developer of an in-house program may want to ensure that certain combinations of methods are never used for the same object. In order to meet each of these security requirements, we need to enforce its corresponding security policy. There are many styles of security policies that are commonly enforced by programmers to protect real applications, including access control[24], information flow [1, 25], type enforcement[26] (as in SELinux [27]), tainting [28, 29] (e.g., via Perl’s taint mode [30]), provenance tracking [31], stack inspection [32], and forms of security automata [33]. The work introduced in this thesis focuses on the information flow security policy. As it investigates how to accommodate the concept of restricted delegation and revocation (studied before in access control policy) in language based security, a well know approach to enforce information security policy.
1.3
Information flow security policy
Confidentiality requires that information be prevented from flowing to inappropriate destinations in order to protect the user’s privacy or assets; dually, integrity requires that information be prevented from flowing from inappropriate sources to protect data from being corrupted or destroyed by an untrusted party. To ensure that information is used only in accordance with the relevant confidentiality policies and integrity, it is necessary to analyze how information flows within the used program. Information-flow control 5
Chapter 1. Introduction mechanisms enforce information-flow policies that protect confidentiality and integrity of data to ensure that it is handled or used in a way that comply with the general security policy of the system. By this way information flow policies enforces security between end points of the system which is different from access control policies that enforces security at the end points of the system. Information-flow systems usually specify policies in terms of a lattice of security labels[34], where labels present the security levels of data. To guarantee a secure information flow, a program should satisfy noninterference property, which states that the information from a high security level within a program is prevented from flowing to a low security one. There are two types of information flow: explicit and implicit: Explicit flows are simply direct flows of information caused by directly passing confidential data to a public variable resulting from assignment operations and I/O statements. Implicit flows are indirect flows of information. They arise from the control structure of the program due to branching on conditional or while loop statements which can allow an attacker to deduce information about the data. Information flow security policy can be enforced statically, dynamically or by a combination of static and dynamic techniques[35].
1.3.1
Static analysis of information flow security policy
In this kind of analysis, the information flow policy is contained in the code, so the program must be reanalyzed, and usually rewritten for different policies. The information flow is analyzed statically before the execution of a program to prove that the program does not leak sensitive information. Such kind of analysis aims to track the static security label associated with each variable 6
1.4. Information flow security policy versus access control during its declaration. If the program respects the security policies enforced by this label, then it can be executed safely[12].
1.3.2
Dynamic analysis of information flow security policy
In this kind of analysis, the information flow security policy is not part of the code, so the program may be used in multiple security contexts as the policies are defined on the data itself [36]. As real application programs have security policies that vary dynamically and that cannot be determined before program execution. Hence, there is a need to runtime analysis of information flow that captures the change in the security level or label of data as a result of variation in its security policies during program execution.
1.4
Information flow security policy versus access control
Access control policy is a set of regulations that control how access to data maintained by the system is granted or denied [24]. However access control can’t guarantee an end to end secure information flow. Where information is prevented from flowing to inappropriate destinations or from inappropriate sources in order to protect the user’s confidentiality and integrity respectively. On the other hand, information flow security policy aims to control the propagation of data after it has been released for processing by a program or before it has been to authorized to flow to a program [1]. Recently, language based information flow control has been a common approach to enforce information flow security policy. The next section introduces a general 7
Chapter 1. Introduction background of security typed programming languages.
1.5
Security-typed programming languages
Security-typed programming languages have been proposed to enforce information flow polices that protect the confidentiality and integrity of data. The main concept of those languages is annotating the data types in the application program with static security labels that express the security levels of data. A security label is a pair of a confidentiality policy and integrity policy. Those policies specify which principals or entities can read and influence the data respectively. The specification of principals in those languages allows modeling different roles in the application program with different security concerns such as users, groups and processes. The security policies are then mostly enforced by compile-time type checking, and, thus, add little or no run-time overhead. The compiler checks the policy before the program is run, detecting potentially insecure programs before they can possibly leak confidential data, corrupt the trusted data, or perform unsafe actions[12],[37]. Currently, there are only few existing implementations of security typed programming languages such as Jif [3],[4] (a well known standard in language based security), SELinks[18], and Flowcaml[17],[38]. The work introduced in this thesis presents a new security typed programming language RDR that addresses the limitations concerning the general form of delegation and revocation in the existing one (as mentioned in the motivation in section 1.1). In addition, instead of enforcing the information flow policy statically (the popular approach in current security typed programming languages) , RDR enforces this policy dynamically. This is done by tracking the change in the security levels of variables due to delegation and revocation during program 8
1.6. Problem statement execution. Finally, a complete implementation for RDR is presented by a prototype evaluator in which the regular and error semantics of RDR are implemented. Such implementation can be added to the existing implementations of security typed programming languages.
1.6
Problem statement
The existing approaches for presenting delegation and revocation in language based security give the delegator principal a permission to delegate any data he/she has and all the actions taken by her/him to the delegatee. Hence there is no restriction on which data will be delegated and which type of actions permitted to the delegatee by means of delegation. For example if a file is annotated with a security label that specifies Alice as an owner of that file, and Alice delegate to Bob, then Bob can read or edit this file, in addition to any other file annotated with any security label specifying Alice as an owner according to this delegation. In addition, the form of delegation in most of these approaches does not restrict the scope of delegation between principals according to specific parameters . For example, if the delegator decides to delegate to another principal, then the delegatee can delegate further to other principals without any restriction which open back doors for insecure information flow according to this unrestricted delegation. However delegation in language based security was restricted based on role membership [16, 39]. In their work, delegation from one principal to another occurs if the former accepts its role to include all members of the later’s. By this way, many of roles constraints can be applied in order to restrict the delegation process. However the from of restricting the scope of delegation between entities is still not presented. Moreover, apart from the work 9
Chapter 1. Introduction presented in [15, 16, 7, 40], revoking delegation between principals in the existing approaches is in not presented in a clear way at the syntax or the semantics level of the languages that present it. For the former, there is no language constructs for revocation, while for the later there is no semantics rules for revoking delegation.
1.7
Proposed study
The work introduced in this thesis addresses the limitations of the existing approaches for restricting delegation and revocation in language based security as mentioned in the previous section. It introduces the RDR (short for restricted delegation and revocation) language; a new security typed programming language that accommodates the concept of restricted delegation and revocation between principals in the application program. The scope of delegation between principals (entities) is restricted by means of chain (a sequence of delegatees) , where a delegator delegates his/her authority to another principal (the delegatee) who can later delegates this authority further to another one only if the former permits this kind of delegation. In addition, this kind of restricted delegation and revocation is extended to include which data can be delegated (as the delegated variable is presented in the delegation or revocation statements of the introduced language), and which action is permitted to be taken by the delegatee according to this delegation (The presented actions include the authority to read and edit data).
10
1.8. Thesis outline
1.8
Thesis outline
This thesis is organized in 6 chapters as follows: Chapter 2 presents the previous work that investigates the idea of restricted delegation and revocation in access control policy. Then it presents a survey on the existing approaches for supporting delegation and revocation between principals in the existing security typed programming languages, together with examining the few attempts to accommodate the concept of restricted delegation and revocation in these languages and specifying their limitations. Chapter 3 introduces a new security typed programming language RDR that supports restricted delegation and revocation between principals based on their access rights. It describes the syntax of the language illustrated with several examples as well as its operational semantics. Chapter 4 introduces the error semantics of RDR. This semantics is defined by exploiting the dynamic approach and enriching it with control-flowsensitive checks borrowed from static approach. The main target of error semantics is to specify the forbidden execution of the program which may result in (possibly implicit) information leakage to unauthorized users. Chapter 5 focuses on the implementation of RDR. First it states briefly the current implementation in language based security. Then it introduces the ASF+SDF algebraic specification formalism [20] and its interactive development environment, the ASF+SDF Meta-Environment [41, 42] and how to use it to define the syntax of RDR and implement its operational and error semantics. An evaluator for RDR is implemented in ASF+SDF and several examples are written in RDR syntax re evaluated using this evaluator. Chapter 6 provides conclusions of this thesis with emphasis on its contributions and the directions for future work. 11
Chapter 2 Delegation and revocation in language based security 2.1
Introduction
There was an extensive research for presenting the idea of restricted delegation and revocation between different entities (i.e., principals) in access control policy. On the other hand, this idea was not extended to information flow security policy. There were few attempts to accommodate such concepts in security typed programming languages. The work introduced in this thesis aims to accommodate these concepts in language based security, where by one can specify a delegation chain to which the information may flow and later revoke the allowed flows when it is required. This chapter presents the previous work that investigates the idea of restricted delegation and revocation in access control policy, and examines existing approaches to provide delegation and revocation between principals in security typed programming languages with more focusing on the few attempts to restrict delegation and revocation in these languages and their limitation. 12
2.2. Restricted delegation and revocation in access control policy
2.2
Restricted delegation and revocation in access control policy
The idea of restricted and revocable delegation between principals was investigated in access control policy by different approaches. The following subsections describe some of them, by showing the way in which each one restricts delegation between users and later revokes this delegation when it is no longer required.
2.2.1
Delegation and revocation in RBDM
Ezedin Barka and Ravi Sandhu [43] presented RBDM0 (role-based delegation model using flat role) for user to user delegation in the simplest form of Role-Based Access Control(RBAC96)[44],called RBAC0. Their model focuses on delegation of role membership from one user in a certain role to another user in different role in order to let the work continue, even in the absence of the original member of the role. In RBAC0, the user is human being, a role is a job function and permission is an authorization of access to some objects or a right to perform certain task. In order to manage roles and permissions, the permissions are linked to roles and the users are assigned to roles. By this way the users gain the linked permissions. When the permission is no longer needed, it is revoked from the role. The delegation in RBDM0 is performed between users in flat roles(.i.e the permission are not inherited between roles)and it is total delegation( the user in a certain role has to delegate the total package of permissions in that role, or not to delegate all of them). In addition, it is one step delegation,as the delegated role can’t be further delegated(However the two step delegation is also modeled in RBDM0 as an extended feature). 13
Chapter 2. Delegation and revocation in language based security There are two types of members who can delegate a certain role: The original members (Users-O(r)) that originally assigned to this role by system administrator and the delegated members ((Users-D(r)) that are assigned to the role by the original member. The delegation process in this model can be restricted by time duration (T) which is under the control of delegating user. Once the time assigned for delegation expired, the delegation is automatically revoked. The original member in a role can revoke the delegation of any delegated member in that role, even if the time duration of delegation is still valid. This is called Grant-independent revocation which restricts the revocation only to the original member to give him or her the power to revoke the delegated member immediately, if he or she behaves badly in his or her role. RBDM0 restricts the delegation process from one user in a certain role to another user in a different role according to can-delegate⊆R×R relation, where R are sets of roles. For example,(x,y)∈can-delegate means that the original member of role x can delegate his/her role membership to the original member of role y. This relation is not reflexive, as there is no meaning to delegate from one user in certain role to another user in the same role. Although, the delegation process in RBDM0 is formalized by a set of relations, there is no proof for the delegation and revocation properties in that model. Ezedin Barka and Ravi Sandhu extended RBDM0 by introducing RBDM1 (Role-Based Delegation Model/Hierarchical Roles) [45]. Hierarchical roles are the most convenient way to deal with different kinds of responsibilities and authorities in a certain organization. In this scheme, the more powerful (senior) roles inherit the permissions of roles that are less powerful(junior) to them as shown in figure 2.1. As a result, the delegation between different roles in these hierarchies becomes more complicated and
14
2.2. Restricted delegation and revocation in access control policy has different types:downward delegation this type of delegation is carried out from the senior role to the role junior to it.cross sectional delegationthis type of delegation is performed from a certain role to another one incomparable to it.upward delegation this type of delegation occurs from the junior role to role senior to it and has no meaning as the senior role has all permission of its junior. RBDM1 is defined formally as RBDM0 in addition to new elements that address the issue of role-to-role delegation using hierarchical roles:RH⊆R×R which is a partial order role hierarchy that addresses the three different types of delegation between different roles in this hierarchy. In contrast to RBDM0, RBDM1 allows partial downward delegation, as the senior role can delegate a subset of its permissions to its junior role. RBDM1 introduces two new types of a user membership in a role:explicit role membership which addresses the direct user’s membership in a role and implicit membership which addresses the user’s membership in a role because of his or her membership in a role senior to that role and as a result he/she has all permissions associated with that role. By applying this two types of membership in RBDM1 to the original and delegate members for each delegating role, there will be four different combinations of user memberships:original/explicit,original/implicit, delegate/implicit and delegate/explicit. These four combinations refers to the status of the delegating and delegated roles which extremely affect the semantics of can-delegate relation(defined previously in RBDM0). Revocation in RBDM1 is similar to the situation in RBDM0, as it can occur automatically after the delegation time expired or by allowing users to revoke the membership of delegated roles (human revocation). The only difference from RBDM0 is that in case of human revocation RBDM1 dose not only authorize revocation by the original member of the role, but it allows cascading
15
Chapter 2. Delegation and revocation in language based security and multiple sponsering/supporting roles revocation. The former refers to automatic revocation of delegation to all junior roles as a result of revoking the their senior roles. The later refers to revoking the delegate membership as result to revoking any of the multiple supporting and sponsoring roles. The supporting roles concern with the original member of more than one role when he/she receive delegation more than once to the same role one for every role nonmembership involved. Multiple sponsoring roles is when the delegated member in a certain role receive delegation from more than one original member in that role. Similar to RBDM0,the delegation process is formalized by a set of relations in RBDM1, but there is no proof for the delegation and revocation properties in that model.
Director Project mangaer
Engineer
Programmer
Figure 2.1: Role-hierarchy
2.2.2
Delegation and revocation in RDM2000
Longhua Zhang,Gail-Joon Ahn and Bei-Tseng Chu [46] presented the role based delegation model 2000 (RDM2000) as an extension to RBDM0 in order to support user-to-user delegation on role hierarchies and multistep delegation. The delegation in this model is carried out from one user(delegator) to another user (delegated) by assigning the delegated role to him/her (A user-role assignment is carried out by activating the administrative role(s) by security administrator, while role delegation is carried out by activating 16
2.2. Restricted delegation and revocation in access control policy delegator’s regular role(s)). There are two types of delegation in RDM000: single-step delegation and multistep delegation. In the former, the delegator does not allow the delegated role to be further delegated, while in the later, he/she allows the delegated user to further delegate the delegated role for many times or up to the maximum delegation depth (the maximum delegation depth is a natural number defined to restrict delegation). The depth of the delegation path (the delegation path is generated in multistep delegation and it is a set of user-role assignment relations) is controlled by three ways: no control, Boolean control, and integer control. The first way imposes no restriction on the depth of the delegation path. In the second way, the delegating user decides whether the delegated user can delegate further the delegated role or not. The last one, is used to limit the maximum depth of a delegation. There is a new relation defined in RDM2000 called delegation relation (DLGT) to address the relationships between different components of delegation (those components include four elements: the delegator, the delegating role, a delegated user, and the delegated role). For example, the delegation relation D1 : (Alic, DIR, Bob, P M ) ∈ DLGT means that Alice in role DIR (Director) delegates role PM (project manager) to Bob. A set of function is built based on this relation such as: prior function that maps one user-to role assignment (UA) to another UA, the path function that maps the user-to role assignment (UA) to the delegation path, and depth function that returns the depth of the delegation path. Different delegation paths with the same original user to role assignment (delegator) construct a delegation tree which is user-to role assignment/delegation hierarchy as shown in figure 2.2. The nodes of the tree are user-to role assignment while its edges are delegation relation. To impose restriction on which users can be assigned to the
17
Chapter 2. Delegation and revocation in language based security
(Alice, DIR) D1 (Bob, PM) D3
D2 (John, ENG)
(Carol, PROG)
Figure 2.2: Delegation-tree
delegated role, a prerequisite condition adopted from ARBAC97 [47] has to be satisfied. The relation can-delegate⊆ R×CR×N authorizes delegation in RDM2000, where R is a delegator’s role, CR is the prerequisite condition and N is the delegation depth. Revocation in RDM2000 is similar to revocation in RBDM0, the only difference is that grant-dependent revocation is allowed (where the users in the delegation path prior to a user can revoke his /her role membership). In addition, there is two option for user revocation: cascading and non-cascading revocation. The former revokes a node from the delegation tree with the subtree below it, while the later only revokes the node. Cascading revocation is implemented by two approaches:an instant implementation and a dilatory implementation. The first approach revokes all related delegations involved in a cascading revocation by browsing the database for all delegations. The second one enforces a run-time revocation. This is achieved by revoking only the node, then the system will check the status of the delegation path to recover the revoked node and as a result all further delegated nodes below this node will be revoked.The relation can-revokeGI⊆R authorizes grant-independent revocation, while the relation can-revokeGD⊆R authorizes grant-dependent revocation. The delegation and revocation policies in RDM2000 are explicitly specified using a rule-based 18
2.2. Restricted delegation and revocation in access control policy specification language which facilitates incorporating such policies in individual organization. The language defines the policies as a set of authorization rules (such as user-user delegation authorization rule, automatic revocation rule ,cascading grant-dependent revocation authorization rule, and cascading grant-independent revocation authorization rule). Longhua Zhang,GailJoon Ahn and Bei-Tseng Chu [46] extend their work in [48] with a proof of concept prototype implementation of RDM2000 for crime-related information system. It investigates the feasibility of their proposed framework and provide secure protocols for managing delegation and revocation. The prototype is a secure web-based application enforcing secure role-based delegation and revocation. The application enables police officers to access problemoriented police projects information at real time. It consists of: front-end web server, a business application layer to provide a number of services such as delegation/revocation and role services, and back-end databases to store the problem-oriented policing projects needed to be managed in addition to RBAC and RDM2000 (Since RDM2000 extend RBAC96 [44]) components such as users,roles, permissions,constraints,user assignments,permission assignments,role hierarchies, delegation trees, and basic delegation/revocation rules .The core of delegation/revocation service is a rule-processing engine, which is an implementation of RDM2000 and the rule-based policy language. The rule engine produces a proof that the request complies with the authorization rules and it works as follows: first it accepts the user-role membership and basic authorization rules as a set of axioms and a user request as a theorem, then it tries to prove that theorem by showing that it can be derived from those axioms. There are three functional units included in the rule-processing engine:a preprocessor that transforms authorization-rules and user-role membership into a logic program, an inference engine that
19
Chapter 2. Delegation and revocation in language based security takes the user request and a logic program as input and returns the result of the program, and a postprocessor that saves the result of an authorized delegation or revocation the RBAC database and officially records the transaction.
2.2.3
Delegation and revocation in PBDM
Xinwen Zhang,Sejong Oh and Ravi Sandhu [49] presented the permission based delegation model(PBDM) to support user to user and role to role revocation. Their model covers also the issue of multistep delegation and multioption revocation in addition to permission level delegation (a piece of role delegation).The first version of PBDM was PBDM0 and it extends RBAC96 [44] to support user to user delegation. It provides single step as multistep delegation. The delegation in PBDM0 is performed in three phases: the delegator creates a temporary delegation role (DTR), then assigns a permission and role to that role, finally he/she assigns a certain user to DTR. Roles in DTR cannot be assigned to any other role as PBDM0 does not allow role to role delegation. PBDM0 revokes the delegation by reversing the delegation process in three steps: first the delegator revokes the user to DTR assignment. then remove the permission from DTR. finally, he/she revokes DTR. For multistep revocation in PBDM0, the delegator creates another DTR2 in addition to the first one DTR1 and assigns any permission from the first the second one. Then he/she assigns role to DTR2 . The multistep revocation is also supported in PBDM0 to revoke multistep delegation. The main limitation with PBDM0 is that a malicious delegator can assigns high level permission to DTR and assigns a low level user to this role without permission from the security administrator (as the security administrator has no permission to manage or monitor the delegator’s permission to DTR assignment or the 20
2.2. Restricted delegation and revocation in access control policy delegatee to DTR assignment). In addition, PBDM0 supports only user to user delegation (role to role delegation does not exist). As a result, PBDM0 is extended to address the first limitation with PBDM1 which involves the security administrator in the delegation and revocation processes. PBDM1 has a new layer of roles named delegatable role (DBR) in addition to the layer of regular role (RR), and the layer of temporary delegation role(DTR) similar to those in PBDM0. Unlike PBDM0, the permission assigned to RR cannot be delegated to other roles or users. Each DBR is based on a certain RR and it has a permission that can be delegated to other users or roles by assigning it to DTR. The pair (RR,DBR) in PBDM1 is equal to RR in PBDM0. DBR is created by security administrator and the different permissions assigned to it is also controlled by him/her. Similar to PBDM0, assigning permission and users to DTR is managed by individual users. The delegation process in PBDM1 is similar to that in PBDM0, except that the delegator assigns permission taken only from DBR to DTR. The security administrator is also involved in the revocation process of PBDM by removing one or more pieces of permission from a certain DBR, or revoking the user from this DBR and consequently its regular role. PBDM1 is extended to To address the second limitation in PBDM0 with PBDM2 that supports roleto-role delegation. unlike PBDM1, the layer of DBR in PBDM2 is divided in two layers: Fixed delegatable role(FDBR),and temporal delegatable role (TDBR). RR and FDBR in PBDM2 is similar to RR and DBR in PBDM1. DTR is similar to DTR in PBDM0 and PBDM1, but its owner is FDBR, not a user. FDBR delegated permissions to TDBR which has no role hierarchy. As a result, the role to role delegation can happen (as no invalid permission flow will happen). As PBDM2 supports role to role delegation, all the delegation authority will be managed by a security administrator. The delegation
21
Chapter 2. Delegation and revocation in language based security process is carried out by a security administrator in three phases: He/she creates DTR, then assign permission and FDBR to DTR, then assign DTR to TDBR which inherits all permission from DTR by temporal delegatable role-delegation role assignment(RAD). The revocation in PBDM2 is similar to PBDM1 in addition to providing revocation options in role laye. The revocation in PBDM2 is carried out in role layer by three possible mechanisms: remove one or more pieces of permission from DTR, or revoke TDBR owned by FDBR, or remove one or more pieces of permission from FDBR to its RR.
2.2.4
Delegation and revocation in ABDM
Chunxiao Ye, Zhongfu Wu and Yunqing Fu [50] introduced an Attributebased delegation model (ABDM) with an extended delegation constraints consisting of both delegation attribute expression (DAE) associated with permission and delegation prerequisite role(CR). In ABDM, the prerequisite role is not enough to distinguish one delegatee from another as it does not indicate anything about his/her qualifications to carry out this role . As a result, the delegator in this model also restricts the delegatee with a permissions DAE indicates his/her qualifications and abilities to carryout the delegating role. A delegatees prerequisite roles and DAE must match CR and permissions DAE of delegation constraint simultaneously when they are assigned to a temporary delegation role. Different roles can be delegated temporarily to delegatees with different DAEs. ABDM also allows users to have DAEs to indicates their qualifications and abilities. There are two types of delegation in ABDM:decided-delegatees and undecided-delegatees. In the former, the delegator delegate a part of his permission to the delegatee that satisfies the required qualification and abilities. In the later, the delegator does not know who has the required qualifications and abilities, so the 22
2.2. Restricted delegation and revocation in access control policy system can generate several delegatee candidates with the required qualifications and lets the delegator chooses one of them. The delegation in ABDM is carried out in three steps: first, the delegator creates a temporary delegation role (tdr), then assigns permissions to tdr, and finally he/she assign users to tdr. The delegation in ABDM can be permanent or temporary and the delegation constraint of tdr in these two types of delegations is identical. However, in the real situation, the delegation constraint of tdr in a permanent delegation is always more restrictive than that in a temporary delegation. As there is no difference between delegation constraints of tdr in both cases,a delegator sometimes cannot temporarily delegate their permissions to a delegatee with permanent delegation constraint. To prevent this limitation, ABDM is extended to a new model called ABDMx . The permissions in this model has two different types: monotonous permission(MP) and nonmonotonous permission (NMP). The delegator can delegate MP to a qualified person temporarily or permanently, but he can only delegate NMP temporarily to a low level delegatee candidate. As a result, a permission p a MP permission has an identical restriction on delegatees DAE both in a temporary and a permanent delegation, while NMP permission has restriction on delegatees DAE only in a permanent delegation (A delegator cannot delegate NMPs to unqualified delegatees permanently). ABDM has the lowest flexibility (As the delegator cannot delegate high level permissions to an unqualified user temporarily or permanently) but highest security in delegation, while ABDMx has a medium flexibility (as delegator can temporarily delegate NMPs to an unqualified low level delegatee candidate ),but the same level of security as that of ABDM in delegation. Revocation of delegation in ABDM and ABDMx are similar to that in PBDM.
23
Chapter 2. Delegation and revocation in language based security
2.2.5
Delegation and revocation in RBAC models
J.Crampton and H.Khambhammettu [51] studied a delegation operation in role-based access control (RBAC) models. They focused on transfer delegations in addition to delegations model. The later is the extensively studied in role-based access control model, as it allows the delegation access right to be available to both the delegator (user who delegates) and delegatee (the user who receives delegation). While in the former, the delegation access right is transferred totally to the delegatee and becomes no longer available to the delegator (as a way to solve the problem of unavailability of (at leat ) one of users that make him or her unable to complete the task). The delegation rights include delegating individual permissions or roles. The former gives the delegatee the ability to use the delegated permission, while the later give the delegatee the authority of role r, and as a result he/she can use the permissions assigned to role r. They assume that access control policy specifies which kind of delegation right is permitted. There are two issues involved in such specification. First, is the delegator authorized to delegate his role or permission. The second, can his role or permission be delegated to another user (the delegatee). To authorize role delegation they introduce, a role delegation relation. The relation can-delegate ⊆R×R specifies whether a user is authorized to delegate a role r’ , where R is the set of roles defined in the role hierarchy denoted by RH ⊆R×R introduced by RBAC1 model of RBAC96 family of models [44] and each role is presented by a tuple (r,r’). They define constraint on this relation that guarantees that no user can delegate a role r that the user is not assigned to. Moreover, they define the relation can-receive⊆R×C to specify whether a user is authorized to receive a role delegation, where C is the set of delegation conditions that must be satisfied by the delegatee to receive delegation (usually, role membership). 24
2.2. Restricted delegation and revocation in access control policy To authorize the permission delegation relation, they introduce a permission delegation relation. The relation can-delegatep⊆R×P speechifies the set of permissions P that can be delegated by user u, each permission is presented by a tuple(p,r). They define constraint on this relation that guarantees that no user can delegate a permission p that is not available to him or her. Similar to authorizing role delegation, the relation can-delegatep⊆P×C is defined to specify whether a user is authorized to receive a permission delegation or not. In addition, they introduced the concept of administrative scope of roles to control delegation. It is activated by the user to limit the extent to which the user can delegate roles and permissions. The administrative scope σ is defined per session s (A session is a mapping between a user and a set of roles) and in order for the delegation of role r by user u to succeed, it is required to r∈ σ(s), where s is the user’s current session. Similarly, in order for delegation of permission to succeed, it is required that there exist r∈s such that(p,r)∈ PA and r∈ σ(s), where PA is a permission-role assignment PA⊆P×R . For revoking role delegation, the appropriate tuple are deleted from the can-delegate relation, while to revoke permission delegation, the necessary tuples are deleted from can-receivep relation to specify that a permission p may not longer be delegated to the delegatee. Finally, they introduced two delegation relations, namely tempUA and tempUP to record temporary user-role and user-permission assignment arisen from delegation operations. tempUA contains tuples of the forms (i,u,r,s), where is identified in the delegation history DH that records all delegations that have been made and s can be - or +. For example, the tuple(i,v,r,+) grants or transfers of role r to delegatee v. On the other hand, a tuple of the form (i,u,r,-) transfers the role r from user u ( that now is disallowed to activate role r) to v. tempPA contains tuples of the form (i,u,p,s), where i is identified also in DH
25
Chapter 2. Delegation and revocation in language based security and s can be - or +. For instance, the tuple (i,v,p,+) grants or transfers the permission P to delegatee v. In contrast, a tuple of the form(i,u,p,-) transfers the permission p from user u (who is now disallowed to invoke permission p) to v.
2.2.6
Delegation and revocation in OrBAC
The main goal of OrBAC model [52] is to specify the security policy at organization level, not based on the implementation of this policy. There are eight basic sets of units in OrBAC: Org (a set of organizations),S (a set of subjects), A (a set of actions),O (a set of objects), R (a set of roles), A (a set of activities),V (a set of views) and C (a set of contexts). The proposed delegation model in this work, considers the policy is applied only to a single organization, so org unit is omitted. M.Talbi et al.[53] presented a delegation model based on the existing features of OrBAC formalism that facilitates modeling delegation, such as cascading revocation and temporary delegation. In addition to the ability to express a large number of delegation conditions using the adminstration model for OrBAC (AdOrBAC)[54]. For example, the administrator can restrict the delegation by specifying delegation constraints that grantor (the user who performs delegation) and grantee (the user who receives delegation) must satisfy. The administration functions are defined by considering different administrative views(the view is an access control entity used to apply the same authorization to a set of objects). So defining the administration function in AdOrBAC is corresponding to specifying which role is permitted to have an access to administrative views. In their model, delegation is managed using contexts and administrative views defined in AdOrBAC. They defined two administrative view, the license delegation view and the role-delegation 26
2.2. Restricted delegation and revocation in access control policy view. The former is to delegate rights (partial delegation), while the latter is to delegate roles (total delegation). The grantor is able to delegate permission to the grantee by inserting an object in the license-delegation view, while he is able to delegate role to him by inserting an object in the role delegation view. Thus, the grantor has to have access to both views in certain context and this is specified respectively in the delegation model by two forms:permission(gr; delegate; license delegation; context) and permission(gr; delegate; role delegation; context). This approach is specified by the following example, suppose that there are two users, Alice is physician and Bob is his assistant. The role assistant is not allowed to have an access to the view patient’s observation(which was made by Alice). However Alice decides to delegate to Bob a permission to update this observation. In this case Alice must have a permission to delegate her right. In oder to give Alice this permission, the administrator should give the role physician the permission to delegate license to update patient’s observation in this view by the following rule:permission(phys; delegate; observationdelegation; nominal), where nominal represents the default context. By this way, Alice will be able to delegate to Bob a permission to update her patient’s observation and as a result the following permission is created (BOb, update,Alice-obs, nominal)(it is important to note that Alice can delegate the permission to update her observation to Bob, because Alice-obs is subview of patient’observation). Moreover, there are different types of delegation parameters defined in this model such as: permanence to refer to permanent and temporary delegation that is revoked automatically after exceeding the deadline.montonicity to decide if the grantor will maintain the permission he/she delegated.multiple delegation to specify the number of grantees to whom a grantor can delegate
27
Chapter 2. Delegation and revocation in language based security his/her right at certain time (delegation chain).Level of delegation to decide whether or not the grantee is able to delegate the permission further and how many times. There also different revocation properties in this model. The first one is the grant dependency property which refers to who is allowed to revoke the delegation license or role. In case of the grantor is the only one allowed to revoke the delegation, a Grant-Dependent (gd) context is specified in the permission as follows:permission(subject,revoke,licensedelegation,gd). Otherwise a Grant independent (gid) context is specified in the permission as follows: permission(subject,revoke,license-delegation,gid). The second property is cascading revocation which is necessary in case of multi-step revocation to be able to revoke the delegation chain. However, although this model imposes many restrictions on delegation and revocation processes, there is no proof for the properties of delegation and revocation.
2.2.7
Delegation and revocation in DBWAC
Y.Wei and Q.Shu [55] presented a delegation-based workflow access control (DBWAC) model. In DBWAC, permissions to carry out tasks are associated with a virtual delegator(VD). Every task is associated with a VD which can delegate its permissions to a user who can carry out the task that the VD are associated with. The user who receives the right to perform a certain task by means of delegation (delegatee) can delegate this right further to other users. The right to execute the task will be removed totally when the task is submitted or the process is finished. This is achieved by VD as it enables dynamic granting of authorization, by associating the time intervals of valid authorization with the time during the task execution. There are two types of delegation relation in DBWAC model: original delegation relation(DLRO) 28
2.2. Restricted delegation and revocation in access control policy and delegated delegation relation(DLRD). In the formal, a user u1 is assigned vd by workflow management systems (WfMS)- the original delegation, while in the latter u1 delegates vd to another user u2 . When a user permits delegation further to another users (a multi-step delegation), a delegation path is implemented. The delegation depth is the number of elements in the delegation path. Similar to RDM2000, DBWAC model imposes restrictions on multi-step delegation by controlling the depth of the delegation path in three different ways: no control,Boolean control, and integer control. The first way imposes no restriction on the depth of the delegation path. In the second way, the delegating user decides whether the delegated user can delegate further the vd or not. The last one, is used to limit the maximum depth of a delegation. In addition, to impose restriction on the permissions allowed to be delegated further by a user or vd, there are two options: total and partial delegation. Total delegation means delegating all of the permissions that are assigned to the delegator. While partial delegation, means that only subsets of the permissions of the delegator are delegated. Normally, vd uses partial delegation if a task is a composite task. Moreover, the model introduced in this work allows for a delegation condition, so the delegatee is not free to delegate the delegation right to anyone. He or she has to satisfy all delegation constraints, otherwise the delegation request is rejected. For revocation, there are two ways to revoke delegation:Automatic revocation and user revocation. The the first one is simple self triggered process, as the permission will be revoked automatically, when the process is finished or the task is submitted. In the same time, the system automatically revokes the task right and the delegation right from every user in the delegation path and delete the delegation relation. The second one concerns with two types of delegation:grant-dependent and grant-independent revocation. The
29
Chapter 2. Delegation and revocation in language based security first type means only users in the delegation path before a certain one can revoke her/his task right and delegation right. In the second type, the security administrator can revoke the rights from a delegated user. If the delegator revokes her/his own delegation to other users, all the further delegation by those users will be revoked. Each user can revoke the task right and the effect of performing the task will not be saved and the task will rollback to its initial state. In this case, the user has to perform transaction revocation. While in non-transaction revocation, the result of performing the task will be saved after revocation. However similar to the work introduced in the previous section, there is no proof for the properties of delegation and revocation introduced in this model.
2.2.8
Delegation and revocation in DW-RBAC
J.Wainer, A.Kuma and P. Barthelmes [5] incorporated delegation into the RBAC model in a simple and straightforward way. They introduced a new extended model called RBAC with delegation in a workflow context (DWRBAC). It extends W-RBAC by introducing two types of delegation: specific and generic. The former allows for delegations of performing a certain task from one a user to another user who can further subdelegate the task to another one (delegation chaining).For example delegate(G;D;T+D; C)is an operation issued by the grantor G for case C (delegate) to delegate the right to execute the task T and delegate it further Dto user D. While the later allows delegation of certain right from one user to another for certain case. For Example, delegate(G,D,R): This is the operation issued by the user grantor G to delegate the right R to user D (delegate) for all cases. In addition,DW-RBACK allows later revoking delegation when it is 30
2.2. Restricted delegation and revocation in access control policy no longer required. For example,revoke(G,D,R,C) is an operation issued by the grantor G to revoke the delegation of right R to D for case C. While revoke(G,D,R)is an operation issued by the grantor G to revoke the generic delegation of right R to D. Their work presents different ways of to control delegation chaining. Besides that a proofs for the important properties of the delegation framework in DW-RBAC is derived.
2.2.9
Concluding remarks
There are different models presented to restrict delegation and revocation between principals in access control policy. These models includes RBDM, RDM2000, PBDM, ABDM, RBAC, OrBAC, DBWAC and DW-RBAC. Delegation in RBDM0 is performed totaly between users in flat roles and is restricted by time duration (T) which is under the control of delegating user. Once the time assigned for delegation expired, the delegation is automatically revoked. Also, the original member in a role can revoke the delegation of any delegated member in that role, even if the time duration of delegation is still valid. RBDM1 allows delegation between different hierarchical roles. It also allows cascading and multiple sponsering/supporting roles revocation. Delegation in RDM2000 is restricted to a a prerequisite condition adopted from ARBAC97. Revocation in RDM2000 is similar to revocation in RBDM0, the only difference is that grant-dependent revocation is allowed. Delegation in PBDM is restricted by assigning a user to a temporary delegation role (DTR) with an assigned permission. The revocation is performed by revoking the user to DTR assignment then removing this permission from DTR. 31
Chapter 2. Delegation and revocation in language based security Delegation in ABDM allows the delegator to restrict the delegatee with a permissions DAE to indicate his/her qualifications and abilities to carry out the delegating role. The concept of administrative scope of roles to control delegation was studied in RBAC model. It is activated by the user to limit the extent to which the user can delegate roles and permissions. This delegation can be revoked later if it is needed. The administrator can restrict the delegation in AdOrBAC model by specifying delegation constraints that grantor (the user who performs delegation) and grantee (the user who receives delegation) must satisfy. In addition the number of grantees to whom a grantor can delegate his/her right at certain time (i.e.,delegation chain) can be specified. There are also different revocation properties presented in this model. DBWAC model imposes restrictions on multi-step delegation by controlling the depth of the delegation path (the number of elements in the delegation path). In addition, it imposes restriction on the permissions allowed to be delegated further. Revoking delegation in this model is performed automatically (when the task is submitted) or by user (users in the delegation path) or security administrator. DW-RBAC model allows delegation of performing a certain task from one user to another user who can further subdelegate the task to another one (delegation chaining). It also allows delegation of certain right from one user to another. It allows later revoking both types of delegation when any one of them is no longer required. DW-RBAC presents different ways of to control delegation chaining. 32
2.3. Delegation and revocation in security typed languages
2.3
Delegation and revocation in security typed languages
There are several security typed programming languages proposed in the literature that permit delegation and revocation between principals. For example, a general form of delegation is already present in Jif [3],[4], a well known standard for security typed programming languages. Using delegation in this language a principal p can act for another principal q declared as p actsFor q (i.e., any action taken by principal q is also authorized for principal p). Delegation is also defined in flowCamel[17], another well know security typed programming language in such a way that allows sending flow from one principal to another. For instance, if one declares: flow !bob < !alice;; This means that Bob is allowed to transfer information to Alice. Ana Almeida Matos and Gerard Boudol [56] present delegation in a Core ML-like language with concurrent threads by a declassification mechanism that takes the form of a local flow policy declaration. They implement the information flow according to the local policy. They introduce in their language a flow declaration construct flow F in M for directly manipulating flow relations, where F is a flow policy (i.e., a binary relation on security levels) and M is any expression of the language. The meaning of this construct is that expression M is executed in the context of the current flow policy extended with F. For example flow A ≺ B in yB =!xA means that information is allowed to flow from A to B in the context of the relation A ≺ B. This construct for introducing flow policy is similar to the one mentioned above in Flow Caml. The only difference is that it allows the flow locally in the scope of a certain expression, while in case of FlowCaml it allows it 33
Chapter 2. Delegation and revocation in language based security globally. Stephen Tse and Steve Zdancewic [57] introduce a security typed programming language that supports delegation between runtime principals similar to the form of delegation presented in Jif. The only difference is that Jif does not support delegation between runtime principals. They implement run-time principals via public key infrastructure. They are represented by public keys, while authorized actions are presented as digitally signed certificates, and the delegation relation between principals is determined from certificate chains. However, the form of delegation in the languages mentioned above does not restrict the delegation between principals by means of chain, where a certain principal (the grantor) can delegate its authority to another principal (the delegate) and the later can delegate this authority further to another one only if the former permits this kind of delegation. In addition, there is no restriction on the actions permitted by delegation process. As all the actions taken by the grantor can be performed by the delegate, which may not be suitable for the practical application. The revocation between principals for the form of delegation presented in the languages mentioned in above does not exist. For example, in Jif a principal p can act for q, but a principal q can’t revoke principal p or consider any action taken by it as unauthorized during program execution if it has authorized it before. The support for revocation in this Language is defined only at the level of methods in the application program. For example if a method can be executed with some authority granted to it by a certain principal, it can never be executed by removing (revoking) the authority granted to it by this principal. However, there was an attempt to present delegation and revocation between principals in language based security by Hicks. et al.[15]. They introduced a new security-typed language that enforces delegation relation in 34
2.3. Delegation and revocation in security typed languages principal hierarchy and allows dynamic updating of information-flow policies according to this delegation and its revocation. Their language is a calculus λΠ ≤ , that formalizes the decentralized label model[58] (DLM) based on the simply-typed lambda calculus. Delegation between two principals p1 and p2 is presented by p1 ≤ p2. The list of delegations between principals p1 ≤ p2 in this language is presented in a permission context Π. The principal subtyping Π` p1 ≤ p2 means that a principal p1 is delegating to p2 under 00
Π. For example, if file labeled as p1: under Π = p1 ≤ p2, p1 ≤ p3, meaning principals p2 and p3 are allowed to read it. If principal p3 is fired and p4 is 00
hired, then the principal hierarchy has to be changed under Π to be p1 ≤ p2, p1 ≤ p4; i.e. to revoke the assertion p1 ≤ p3 and add the assertion p1 ≤ p4. However although revocation is presented in this attempts as a way to renounce delegation, the form of delegation and revocation introduced in the language they present is not restricted by means of delegation chain that allows the grantor to specify a predefined delegation chain of principals to whom the information may flow and later revokes this delegation.
2.3.1
Restricting delegation and revocation
Although the idea of restricted delegation and revocation was investigated in access control policy by several attempts (as mentioned in the previous section), it is not extended to information flow security policy. There exist only few attempts to accommodate these concepts in language-based information flow security. Following, those attempts are presented briefly. A.Benerjee and D.A.Numann[6] studied the connection between access control and information flow policies by investigating the permission-dependent information flow in class-based object-oriented language. The main rule of their work is to 35
Chapter 2. Delegation and revocation in language based security account for calls that may return high security information, but which uses access check to ensure that only low security information is returned unless the caller has been given access. Their work does not address delegation explicitly as a form of authorization between users or roles, but it considers it as a specified permission given to the caller in order to access sensitive information returned by a certain method in the class body while allowing public information to others. By this way accessing high security level data (delegation in this case) is restricted to satisfying the specified permission. This work formulated a type based static analysis using security types that are dependent on permissions (Class methods are given types that depend on permissions authorized for the caller to ensure that confidential information is only returned to him/her if he/she has the specified permission). The analysis track permissions and thus distinguishes certain information flows that are protected by permissions. However the principals in this work that are granted permissions in access control policy are programs rather than users or processes and there is no control over information leaked by granted permissions. G.Boudol [7] presented a simple higher-order imperative language that grants and tests access rights dynamically in addition to addressing delegation and revocation issues with respect to information flow policies. The memory locations (references) in this language are annotated with security levels (confidentiality levels). The confidentiality level is set of principals (permissions from access control point of view) that are subset of P (a given set of principals) and the information flow policy is a binary relation over P . A read access right rc is granted when reducing a program M of this language in addition to general flow policy G. By this way the introduced language addresses the relation between access control and information flow 36
2.3. Delegation and revocation in security typed languages policies in program evaluation. The access right to program M is restricted by ` using the language construct (restrict M to `), while it is extended by ` using the language construct (enable M to `). To check whether a given access right ` is granted during the current evaluation of M, the language construct (test ` then M else N) is used. The delegation in this language is issued using (flow F in M) which extends or relaxes the current flow policies with policy f, while revocation is issued by (revoke F in M) which is dual to the one for delegation as it disallows the flow policy f when evaluating M. However this work does not investigate the relation between access controls constructs and information flow security constructs in the introduced language in a clear way. In addition, it does not address the problem of delegation chaining between principals and revocation for such delegation. There was another attempt introduced by Swamy. et al.[16]. They introduced a new security-typed programming language, called RX with security. labels defined in terms of roles. As role-based security policies defined in the labels allow flexible delegation, their language provides constructs through which programs can robustly update policies according to delegation or revocation of privileges given by this delegation. For Example,the expressions E are extended to include collections ∆of policy mutation statements δs. The type of the language is extended to include the type poll which stands for the type of policy mutation statements at security level l, where l is defined by a metapolicy. The statement update E is used to change the current policy by adding or deleting a collection of policy statements s1, . . . , sn, where each si results from the evaluation of E to ∆ = δ1 s1 , . . . , δn sn . The statement transQ S creates a transaction with policy context Q. If the policy updates in S violate policy assumption stated in Q, then all memory affects of S will 37
Chapter 2. Delegation and revocation in language based security be rolled back. This is considered in case of revocation, as the semantics of transaction rollback mean that the policy is updated immediately, and only the state of memory rolled back. S.Bandhakavi et al.[39] presented a security typed language named RTI for using of RT (a trust management framework for representing authorization policies) roles[59] as a security types (a static security label annotating each variable) and supporting authority and delegation. In RTI, The policy creator controls who can access and update each policy statement using trust management concept and role-based label in the program. The principal is authorized to know that there is policy statement proves his/her role’s membership, and so there is no need for him/her to know about other members of the roles which keeps the privacy of role membership. RT family language is incorporated into RTI language in the form of policy statements (run-time labels). Each policy statement has the form ρ ← e, where ρ denotes the role and is presented by P.r (P stands for a principal that is a member of a role r), while e is a principal or a role. Each principal has a full authority to assign members to its roles. For example, B.r1 ← E states that B accepts E as a member of its role r1 . Another example is B.r1 ← E.r2 which presents delegation from B to E as B accepts that its role r1 to include all members of E’s r2 role. The policy statement ρ1 ← k is interpreted in context of confidentiality as a kind of delegation which permits flow from one variable annotated with label consists of a role ρ1 to another one annotated with a label k. While it is interpreted in context of integrity as a kind of permission to write to a variable annotated with a label consists of a role ρ1 by another variable annotated with a label k. The general policy of RTI,Π ,is presented by a set of (s,`) pairs, where s stands for policy statement and ` stands for a static security label. If there is (s,`)∈ Π, this means that s can be seen by
38
2.3. Delegation and revocation in security typed languages any high observer has a security leve `. Although this work restricts the delegation process by predetermining the principals or role members that are specified in the delegation statement (those are authorized to know about existence of such statement), it does not introduce a way to revoke this kind of delegation. It only introduces a way to break program execution when the policy is updated in such a way that violates the assumption under which the program is type checked. N.Broberg and D.sands [40] presented a policy language named Parlock as an extension to Flow Locks [8] (a mechanism for enforcing dynamic information flow policies), to be able to model roles (similar to those in role-based access control), relations (such as acts-for delegation relation in discretionary access control (DAC)) and runtime actors or principals. A policy in Flow Lock is a set of logical clauses. Each clause specifies the conditions under which data annotated with that policy may flow to a certain actor, where conditions are a set of locks(each lock presents one condition). The lock is open when the condition it presents is satisfied, otherwise it is closed.Roles in Parlocks are modeled by extending Flow Locks by: parameterized locks locks which model a certain actor as a member of a certain role,Actor polymorphism to quantify over all actors in a policy to specify that data annotated with that policy may flow unconditionally to the role presented as parameterized lock family in that policy. For example if the role manager is presented as parameterized lock family, then quantifying over all actors that are members of that role means that data annotated with a policy specify this parameterized lock may flow to any manager.Acts-for delegation relations are modeled in ParLock with two properties: reflexivity and transitivity. The former means each actor can act for him self, while the later specify if x acts-for y and y acts-for z, then x acts-for z ( x acts-for y means 39
Chapter 2. Delegation and revocation in language based security that x is delegated the same rights of y). The transitivity of flow from z to x according to acts for relation is presented by two open locks:ActsFor(y,x) and ActsFor(z,y). Runtime-actors are modeled in ParLock by dynamic creation of new actor using newactor command in the language and bounded it to a given variable name, then reuse this variable name by placing it inside loop for the same newactor command to represent many different run-time actors during execution. Although this work addresses the issue of restricting delegation between actors based on opened locks, the information leaked through a delegation goes beyond the control of the grantor and can be accessed after the revocation(closing locks).
2.4
Decided Study
In view of the previous section, it was decided to study and extend the existing approaches of language based information flow security with the concept of restricted delegation and revocation between principals. This will be accomplished by introducing a new security typed programming language RDR that may address this issue in application programs. A syntax of this language will be defined with new constructs for restricted delegation and revocation in addition to specifying its operational semantics. Also, the study will address the issues of protecting application programs against security breaches that result from normal delegation and revocation between principals by: 1. Defining the error semantics rules of RDR, by exploiting the dynamic analysis of information flow and enriching it with control-flow-sensitive checks borrowed from static checking. Such rules guarantee safe de40
2.5. Summary classification of data from a higher level to a lower level by means of delegation. Where they provide the error messages that specify the forbidden executions of the program which may result in (possibly implicit) information leakage to unauthorized users. 2. Practical implementation of RDR by presenting a prototype evaluator for RDR in ASF+SDF algebraic specification formalism and evaluating several programs written in RDR syntax using this evaluator.
2.5
Summary
This chapter investigates the idea of restricted delegation and revocation in language based security as an improvement to the general form of delegation and revocation in those languages. First, it introduces a survey on the previous approaches that investigates the idea of restricting delegation and revocation between different entities in access control policy. Then it introduces a survey on the previous approaches that supported the general form of delegation and revocation in language based security and studies their limitations. Finally, it presents the few attempts to restrict delegation and revocation in language based security and specifies their limitations in addition to the formalizing the decided study.
41
Chapter 3 RDR: A Language for Restricted Delegation and Revocation 3.1
Introduction
Currently, a general form of delegation is already present in some existing security typed programming languages such as Jif, where a principal p can act for another principal q (i.e., any action taken by principal q is also authorized for principal p). The specification of principals in those languages allows for modeling different roles in the application program with different security concerns such as users, groups and processes. However, this feature does not control the chaining of delegation by means of the access control rights, where a certain principal (the grantor) can delegate its authority to another principal (the delegatee) who can later delegate this authority further to another one only if the former permits this kind of delegation. In addition, this feature does not support the delegation of performing a specific action from 42
3.2. Motivating examples the grantor to the delegatee, as it permits all actions taken by the grantor to be performed by the delegatee which may not be suitable for a real application. More than that, the generic form of revocation between principals for the form of delegation mentioned above does not exist. For example, a principal p can act for q, but a principal q can’t revoke a principal p or consider any action taken by it as unauthorized during program execution if it has authorized it before. The support for revocation in the current security typed programming languages occurs at the level of methods in the application program. For example if a method can be executed with some authority granted to it by a certain principal, it can never be executed by removing (revoking) this authority. This thesis addresses these limitations by introducing a new security typed programming language RDR that allows a more restricted form of delegation and revocation based on delegation chain. This chapter focuses on presenting this language, by giving some motivating examples, introducing the language syntax as well as its operational semantics.
3.2
Motivating examples
In practical applications, it is often handy to temporarily modify the security policies (i.e., the security label) that annotates each variable in security typed programming languages. This is done to permit a temporary information flow to a certain principal and renounce a prior permission. We refer to the first phenomenon as delegation and to the second as revocation. given below, two practical examples of this phenomenon are mentioned. Example 1 Consider a clinical system in which a physician treating a patient can access the medical history of a patient. Suppose that, in a particular 43
Chapter 3. RDR: A Language for Restricted Delegation and Revocation case, the physician would like to delegate her authority to access the medical history to a colleague who can provide a second opinion and add it to the document. However, the physician in charge as well as the patient do not want to enable a second physician to delegate this authority further to a third person. This scenario illustrates the essence of restricted delegation; in practice the permitted chain/tree of delegation may of course be much more complicated than the simple chain sketched above. Example 2 As a second example, consider an online bookshop which receives the authorization from a customer to charge her credit card. Hence, during the transaction the customer delegates the authority of accessing her credit card information to the bookshop, with a further permission to authorize the transaction with (delegate the read and write permission to) the bank. However, upon finalizing the transaction, the client revokes this delegation. After revocation, the bookshop is not allowed to keep hold of and access the client’s credit card information. This is an example of a revocation.
3.3
RDR syntax
RDR [60, 61] is a simple imperative programming language. Its syntax is given in Figure 3.1. Next, the intuitive meaning of the constructs presented in Figure 3.1 is explained. A program is a sequential piece of code, whose body consists of a number of variable declarations and statements. Variables have a security type, which is an ordinary data type augmented with a security label. A security label consists of zero or more security policies to enforce confidentiality and integrity respectively. A security policy of the form “Alice : Bob! Carol” specifies that Alice is an owner of the declared 44
3.3. RDR syntax Prog ::=(VarDecl | Statement)∗ VarDecl ::=Var “:” SecType “:=” Val “;” SecType ::=“(”Type“,” Label“)” Type ::=“Bool” | “Int” | ... Label ::=Policy∗ Policy ::=Principal [“:” ([“!”]Principal)∗ ] Principal ::=“p” | “q” | “r” | ... Statement::=Var “:=” Exp “;” | if Exp then Body else Body fi| while Exp do Body od | Principal delegates Var(* | ! | “(*,!)”) Chain “;” | Principal revokes Var (“(*)” | “(!)” | “(*,!)”) Chain “;” Chain ::=Principal | Principal “→” Chain Exp ::=Var | Cons | Exp op Exp Figure 3.1: Syntax of RDR.
variable, while Bob and Carol can, respectively, read from and write to the information stored by Alice in this variable. The Multiple policies may define different owners for the same variable, with different readers and writers for each owner, where the reader can read the owner’s data, while the writer can edit her data. The read and write permission associated with each owner refers to the data values stored by the owner(s) in that variable. Intuitively multiple policies are taken to collectively define a set of owners, readers and writers; if desired, one could modify the proposed semantics to allow for readers and writers defined in each policy to read from and write on the values assigned by the owner in the same policy. Note that this initial policy can be changed later in the course of program execution by means of delegation and revocation. A statement can be an assignment, a conditional or a loop statement. Moreover, the owner principal of a variable can delegate read and write authority (denoted by ∗ and !, respectively) over the variable to a chain of 45
Chapter 3. RDR: A Language for Restricted Delegation and Revocation principals. Note that (∗, !) denotes delegation of both permissions. The initial element of the chain is the one receiving the authority but may delegate it further to the other elements of the chain depending on the privileges given to it by the granting principal. The dual to delegation is revocation and specifies that a certain delegation (sub-)chain is not valid anymore and moreover, no information obtained in the course of delegation may be leaked to the principals whose authorities are revoked. The delegation is assumed to be not necessarily transitive, i.e., by specifying a chain, the grantor does also specify the order in which delegation may happen. A transitive delegation operator can then be defined as syntactic sugar. Along the same line, a revocation of a sub-chain is defined to result in revoking all the chains following this sub-chain. Again, an alternative revocation statement can be defined where the chain is “patched” by concatenating the rest of the chain to its allowed pre-fix. For simplicity, it is assumed that each principal is mentioned only once in each delegation chain. To illustrate the syntax given above, the informal explanation of Example 1 is specified in this syntax. Example 3 The following program captures the scenario described in Example 1 using the syntax given in Figure 3.1. 1:
// patient visits phys1
2:
history : (String, patient) := SQLQuery;
3:
patient delegates history(*,!) phys1;
4:
obs1 : (String, phys1 patient) := Observation;
5:
history := history + obs1;
6:
// phys1 introduces phys2 to patient
7:
patient delegates history(*,!) phys1 → phys2;
8:
phys1 delegates history(*,!) phys2; 46
3.4. Preliminaries obs2 : (String, phys2 patient) := NewObs;
9: 10:
// phys2 makes some observations
11:
history := history + obs2;
12:
// phys2 takes a leave and delegates her tasks to phys3
13:
phys2 delegates history(*,!) phys3;
// phys2 delegates the patient’s
history to phys3 without any permission from patient : error
3.4
Preliminaries
Policies in RDR form a complete lattice of security levels. This gives a rise to two lattices one for confidentiality policy, while the other for integrity policy as shown in figure 3.2 . The information is prevented from flowing to a lower level (i.e., less secret in confidentiality lattice and dually more trusted integrity lattice.) The relation between security levels in each lattice is specified using the lattice ordering relation v, which reads “less restrictive than”, and intuitively means more readers and less writers. Definition 1 The security lattices LC and LI for confidentiality and integrity consist of P (A) with orders vC and vI respectively. These orders are
defined by ` vC `0 iff ` ⊇ `0 and ` vI `0 when ` ⊆ `0 .
A security policy is a triple ( p : q, ! r ) in P (A) × LC × LI , such that p (the owners) is included in both q (readers) and r (writers). Note that the join of two levels t is their intersection in confidentiality lattice but their union in an integrity lattice and vice versa their meet u is their union in the confidentiality lattice but their intersection in the integrity lattice. When drawing the lattices LC and LI we will always put the smaller sets on top meaning that for LI a downward flow actually represents a move to a higher security level. See figure 3.2 for an example. 47
Chapter 3. RDR: A Language for Restricted Delegation and Revocation Hence, one can take the join t and the meet u of two policies in order to obtain, respectively, more and less restrictive policies (the the least upper bound and the greatest lower bound of the two policies, to be precise) than the composed policies. For two labels of the form `1 = (o : R1 , W1 ) and `2 = (o : R2 , W2 ), where o stands for owner, R stands for a set of readers and W stands for a set of writers we define the join and meet of two policies as follows:
`1 t `2 = (o, R1 ∩ R2 , W1 ∪ W2 ) `1 u `2 = (o, R1 ∪ R2 , W1 ∩ W2 ) `1 v `2 if f R2 ⊆ R1 ∧ W1 ⊆ W2
The bottom element of the confidentiality lattice is denoted by ⊥, which is the least restrictive policy (i.e., allowing every principal to read according to each and every principal as owner). Dually, the top element of this lattice is denoted by >, which is the most restrictive policy (i.e., allowing no principal to read The bottom element of the integrity lattice is denoted by ⊥, which is the least restrictive policy (most trusted) (i.e., allowing no principal to write according to each and every principal as owner). Dually, the top element of this lattice is denoted by >, which is the most restrictive policy (less trusted) (i.e., allowing every principal to write, according to each and every principal as owner). Example 4 Consider the confidentiality and integrity lattices shown in figure 3.2 . Assuming a variable X has a security label (A:;B:) consists of two policies state that A and B are the owners of X respectively. Each policy is 48
3.5. RDR semantics expressed as an element in both lattices. The confidentiality lattice has two security levels specified by A and B. The security level A specifies that data may be read only by A, while the security level B specifies that data may be read only by B. The integrity lattice has two security levels specified by A and B. The security level A specifies that data may have written only by A, while security level B specifies that data may have written only by B. The least upper bound of the confidentiality lattice is presented by the security level φ which states no one may read the data (where A ∩ B = φ), while the greatest lower bound of that Lattice is presented by the security level {A, B} which states that both A or B may read the data. The greatest lower bound (more trusted) of the integrity lattice is presented by the security level φ which states no one may have touched this data (where A ∩ B = φ), while the least upper bound (less trusted) of that lattice is presented by the security level {A, B} which states that both A or B may have written to this data. The direction of confidentiality flow is shown in the figure, where data flows upward (.i.e less secret to more secret level). Dually, the direction of integrity flow is downward (.i.e from less tainted or more trusted level to more tainted or less trusted one).
3.5
RDR semantics
In order to provide an operational semantics for RDR; a Natural Semantics [62] is chosen. Using a bit more of book-keeping one could adapt the given semantics to the small-step setting. The semantics is supposed to control explicit and implicit information flow in addition to insecure flows caused by delegation and revocation (as it will be described in the next subsection) in order to prevent information 49
Chapter 3. RDR: A Language for Restricted Delegation and Revocation
φ
φ
Upward flow
A
B
B
A Downward flow
{A, B}
{A, B}
(a) Confidentiality Lattice LC
(b) Integrity Lattice LI
Figure 3.2: Security Lattice L leakage.
3.5.1
Information Flow Control
The semantics of RDR is supposed to control information flow in order to prevent information leakage. The different types of information leakage prevented by this semantics are stated below. Direct Flow This kind of flow is induced due an assignment of the form x := e where the security label of variable x does not incorporate (i.e., is not more restrictive than) the security label of variable e. Then, information stored in e is made available for reading and writing to principals that have been granted access by the owner of variable x. For the simplest case of (direct information leak), consider the following example. 50
3.5. RDR semantics Example 5 In the following code snippet patient has a variable called secret, from which phys1 is authorized to read. However, patient has another variable called public, from which both phys1 and insurance can read. Assigning secret to public may reveal the patient’s secret to insurance and hence should not be allowed. 1:
secret : (Boolean, patient: phys1) := mySecret;
2:
public : (Boolean, patient: phys1, insurance) := 0;
3:
public := secret; To prevent direct leakage for an assignment of the form x := e, the
security label of variable x should be at least as restrictive as the security label of each and every variable appearing in e. Implicit Flow Information leak might also be indirect and due to the control structure of the program. The following example illustrates this type of information leakage. Example 6 Consider the following code snippet. 1:
secret : (Boolean, patient: phys1) := true;
2:
public : (Boolean, patient: phys1, insurance) := false;
3:
...
4:
if secret == true then public := true
5: 6:
else public := false
7: 8:
fi
In this case, the information about variable secret is leaked into public via the if-then-else control structure, i.e., if the value of secret is true, then the 51
Chapter 3. RDR: A Language for Restricted Delegation and Revocation if-branch is chosen thereby assigning true to public, or otherwise false is assigned to public. In a well-known approach for preventing implicit flow [63], a fabricated variable called pc is used to record (the label of) all variables that have contributed to the control flow (i.e., the guard condition in conditional and loop constructs) and the variable pc is assumed to implicitly influence the right-hand-side of all assignments, i.e., the label of the left-hand-side should be more restrictive than both the label of the expression in the right-handside and the label of pc.
Termination and Timing Side Channels Loops may or may not terminate (may take longer or shorter) depending on the value of the variables used in their conditions. This provides another possible side channel [12] for revealing secrets to unauthorized principals. The following example illustrates the termination side channel. Example 7 Consider the following code snippet. 1:
secret : (Boolean, patient: phys1) := true;
2:
public : (Boolean, patient: phys1, insurance) := true;
3:
... modifying the value of secret
4:
while secret == true do secret := secret
5: 6:
od
7:
public := false
If secret is true, then the while-loop in the code snippet given above terminates and by reading the value of public, insurance will learn about the value of secret. 52
3.5. RDR semantics So far, there have been a number of proposals to prevent termination and timing side-channels [14, 12]. However, the information leakage due to those side channels is not the focus of the work presented in this thesis and due to this it is not considered. Delimited Release. RDR allows more flows by delegating the read/write authority of the delegated variable to a chain of principals. The delegation of read authority is considered as a kind of declassification [64, 13] since now the content of delegated variables may flow into the actual receivers of delegation. The extent to which the information can be propagated is determined by the delegation statement of read authority, due to which the flow is made possible. Following [13], this type of flow is called delimited release. It is enabled by delegation statement, which extends the information flow by relaxing the static label by allowing more readers due to delegation while at the same time determining the boundaries of the extended flow. In other words, the delegation statement requires that the information content of the delegated variable cannot be leaked further by the receivers to other unauthorized principals. Example 3 already shows an aspect of delimited information release. The last delegation statement in this example is one that goes beyond the boundaries specified by the patient and hence should be caught (as erroneous) by the semantics of RDR. The following example illustrates a more complicated aspect of this kind of flow. Example 8 In the following code snippet patient has a variable called secret, which is delegated by her to phys. Moreover, phys has another variable called shared-secret, which is initially owned by her. Due to delegation, the content of secret may flow into shared-secret. Suppose that phys delegates shared53
Chapter 3. RDR: A Language for Restricted Delegation and Revocation secret to insurance such that insurance can also make a copy of the content of shared-secret in the variable called public. This is clearly disallowed by patient who has defined the policy for secret. 1:
secret : (Integer, patient: ) := mySecret;
2:
shared-secret : (Integer, phys: patient) := 0;
3:
public : (Integer, insurance: patient, insurance) := 0;
4:
patient delegates secret * phys;
5:
shared-secret := secret;
6:
phys delegates shared-secret * insurance;
7:
public := shared-secret; Delegation statements turn the static structure of variable labels into a
dynamic structure, which is also control-flow dependent (see below for some issues). To reflect this in the semantics, one can take two approaches: either to make a static under-approximation of dynamic labels, and only allowing for flows that are safe with respect to this under-approximation. This approach is certainly very restrictive but imposes no run-time overhead. In this approach, delegation statements can be per-processed and removed once the static under-approximation is calculated. (This approach can be followed to some extent when deriving a type system for RDR ) An alternative approach adds a dynamic label component to the semantics and keeps track of this component throughout the execution of the program. This approach is followed in the operational semantics of RDR. The boundaries of delegation can be checked in two different ways. Either this is reflected in the semantics of delegation, e.g., in the above-given code snippet, delegating shared-secret to insurance is disallowed. Alternatively, this can be reflected in the semantics of assignment, e.g., the assignment of shared-secret to public is disallowed. Both alternatives are viable and each 54
3.5. RDR semantics has its advantages and drawbacks. The former option leads (disallowing delegation) to a cleaner semantics which separates the concerns of direct and implicit flow from delimited release: direct and implicit flow are dealt with in the semantics of assignment and the boundaries of delimited release are dealt with in the semantics of delegation. The latter imposes more run-time checks (assuming that assignments happen more often than delegations), but may allow for a more liberal semantics (can accept programs with potentially vulnerable delegations, if the vulnerability is never exploited). Both options are explored, but eventually decided to go for the former option since it seems that the added value of the latter option is not comparable to its imposed complexities. Hence, one keeps track of the flow of information to variables and disallow delegations that may result in breaching the specified boundaries for the propagation of the information content of the delegated variable. Finally, assuming the above-given design decision, the binding of labels to information flow can itself be static or dynamic. In the static binding approach, once the content of a variable is copied, the label of the variable is recorded in the information flow of the left-hand-side. In the dynamic binding approach, only the name of the assigned variable is recorded and each time a subsequent assignment is made, the dynamic label of the variable is reevaluated and used to check the information flow. The following example illustrates the difference between static and dynamic binding. Example 9 The following program is an alternative implementation of Example 3. 1:
// patient visits phys1
2:
history : (String, patient) := SQLQuery;
3:
patient delegates history * phys1; 55
Chapter 3. RDR: A Language for Restricted Delegation and Revocation 4:
newHistory : (String, patient: phys1) := ‘’;
5:
newHistory := history + ‘Observation’;
6:
patient delegates history * phys2;
7:
phys1 delegates newHistory * phys2; In line 3, the variable history is delegated to phys1; hence, the content of
newHistory after line 4 must be readable only for patient and phys1. If the binding of information flow is static, then despite the delegation of line 6, the final delegation in line 7 is considered harmful since it allows for revealing the content of history whose security label at the time of assignment did not allow the flow to phys2. However, in the dynamic approach, first the delegation in line 6 modifies the dynamic label of history and hence, the delegation in line 7 becomes justified because now patient has authorized phys2 to read the content of newHistory. Swapping lines 5 and 6 results in a program which is considered secure by both static and dynamic approaches to information flow binding. As it can be noted from Example 9, the static binding approach is a safe over-approximation of the allowed information flow while the dynamic approach is more precise and allows for more secure programs. Since RDR enforces revocation of temporary delegation, the static approach becomes infeasible, because its approximation stops to be safe (the recorded label of a variable is not necessarily more restrictive than the future labels of the same variable). Due to this, the dynamic binding approach is presented in semantics of RDR. Each of the above-mentioned three categories of information-leakage is prevented using a mechanism in the presented semantics. For simple and direct information leakage, static labels are checked in the premises of the assignment rule. For indirect information leakage due to control structures 56
3.5. RDR semantics the security label of guard condition is taken into account. This is presented by the label of the program counter, following the approach of [63]. To keep track of the dynamic nature of delegation and revocation and the information flow caused by temporary delegations, dynamic labels of variables are stored and updated in the course of variable assignments. Note that at this point, we have to depart from the more static nature of labels in the decentralized label model of [58]. The following types of information are relevant to establish the execution of the program and to track and control the information flow. 1. The program counter is a set of variables, (initially empty) that keeps track of the set of variables of the guard condition in if-then-else or while-do statements. This is a well-known approach in modeling and preventing undesired implicit information flows [63]. 2. The values of the program variables are relevant since these are needed to compute values of conditions in guards of if-then-else and while-do constructs and for determining the new values for variables in assignments. 3. The static label is the label of the variable from the variable declaration; this label defines which principals are initially own and allowed to read from and write to a variable respectively. 4. The dynamic label captures the label of the variable as it changed during the execution of the program due to delegation and revocation statements. 5. Information flow: to enforce the boundaries of delimited information release, this component is used to record the the label of the expression 57
Chapter 3. RDR: A Language for Restricted Delegation and Revocation that has contributed to the current value of each variable (through assignment). This information is then used to check whether a delegation statement breaches the boundaries of a specified policy. It also needed to prevent information flow from granting principals to the delegatees after the delegation is revoked as will be described later in this section. Dynamic Label Flow. As a consequence of including dynamic flow in the semantics, one can infer some information about the control flow of the program by trying and detecting the dynamic label of variables; similarly, an unauthorized principal may influence the control flow of the program in order to influence the dynamic labels of variables and allow for unintended control flows (see [16, 14] for a detailed account). The following example illustrates this type of flow. Example 10 As before, assume that patient has a variable called secret; insurance tries to learn about secret by inserting a delegation statement under a conditional of which the condition is determined by secret. Then by trying an assignment which is only allowed if the delegation has taken place, insurance can learn about the branch taken in the conditional and thereby learn about the value of secret. This kind of information leakage becomes more relevant, if there is an expression in the language which allows for checking the possibility of a flow, which is the case for some proposed security-typed programming languages, e.g., [15, 7]. 1:
secret : (Bool, patient:) := mySecret;
2:
public : (Bool, insurance: ) := true;
3:
aux : (Bool, insurance: dummy) := false;
4:
if secret = true then
5:
insurance delegates public * dummy; 58
3.5. RDR semantics 6:
else secret := secret;
7: 8:
fi
9:
aux := public;
Scope-Confined Information Release. The reader may already have noticed in Example 2 that introducing revocation drastically changes the setting for information flow security. Revocation requires blocking some previously allowed flows from flowing further even to a principal’s own variables. This in turn calls for a new type of delimited information release, which is called scope-confined information release. To cope with this kind of flow, a dynamic binding of program counter and information flow is imperative; at each operational state, in order to evaluate whether a certain flow is secure or not, the label of the program counter and the information flow content have to be evaluated at that particular configuration. The following example illustrates this issue for the information flow (and a similar example can be constructed for the program counter).
Example 11 Consider the following code snippet in which a copy of a variable called secret is made (in a variable called secretCopy) and the content secretCopy flows further into a variable called public. The flow is clearly disallowed since patient has revoked her delegation of secret to phys1. However, if the information flow of secretCopy is labeled statically at the time of assignment , then the subsequent revocation has no effect in the information content of secretCopy and hence the insecure flow cannot be prevented. 1: 2: 3:
secret : (Bool, patient) := true; // some computation involving secret secretCopy : (Bool, patient: phys1) := true; 59
Chapter 3. RDR: A Language for Restricted Delegation and Revocation 4:
patient delegates secret * phys1;
5:
secretCopy := secret;
6:
patient revokes secret * phys1;
7:
public : (Bool, phys1:) := true;
8:
public := secretCopy; Hence, in the semantics of RDR, to be presented below, the name of the
variables contributing the information flow content of the variable (as well as the program counter) are only recorded and the label of the information flow (program counter) is evaluated dynamically at the time of subsequent assignment.
3.5.2
Program configuration (Operational State)
The configurations that will be considered for the presented semantics are tuples of the following type:
Config
= Body × Environment
Environment = Valuation × StaticLabel × DynamicLabel × Flow The set Body describes the remaining part of the body of the program that still needs to be executed. For RDR language described in this chapter this is a (possibly empty) list of variable declarations and statements, as defined by the presented BNF syntax. The set Environment defines for each variable its valuation and the information regarding its allowed and its actual information flow. A valuation v : Var → p Val is a partial function from variable names 60
3.5. RDR semantics to values1 . This partial function is used in such a way that the variables for which the valuation is defined are declared (already) and those that are not in the domain of the valuation are not declared (yet). A static label is represented by a partial mapping from variables to their security label. A label can be either a basic label (i.e., a set of policies as mentioned in section 3.1) or the meet or join of two labels (see below for more explanation).
BL
= P(Policy)
Label = BL | Label u Label | Label t Label This means that the static label is nicely captured by StaticLabel = Var → p Label Here, the Decentralized Label Model (DLM) [58] is followed for the interpretation of confidentiality and integrity labels; an alternative interpretation of integrity is presented in [57] which could as well be adopted in this setting. Following the approach of DLM, labels form a lattice [34] using the ordering v as described in section 3.4. Hence, one can take the join t and meet u of two labels to obtain respectively, more and less restrictive labels (the the least upper bound and the greatest lower bound of the two labels, to be precise) than the composed labels. The bottom element of this lattice is denoted by ⊥ , which is the least 1
a Z-like notation [65] is used for mathematical expressions; in particular, → p stands for partial function, P stands for power set, Seq for a sequence, _ for sequence concatenation, and ⊕ for function update (i.e., re-defining the value for an element in the domain, or introducing a value for an element not in the domain). A sequence of elements is a mapping from natural numbers to the set of elements. Natural numbers (and hence the indices of sequences) start from 0.
61
Chapter 3. RDR: A Language for Restricted Delegation and Revocation restrictive label (i.e., a label with no policy which means allowing for all principals to read and no principal to write, according to each and every principal as owner). A variable labeled ⊥ is the most public and trusted one Dually, the top element of this lattice is denoted by >, which is the most restrictive label (i.e., allowing no principal to read and every principal to write, according to each and every principal as owner). The dynamic label is represented by a partial mapping from a variables to two sets of delegation chains of principals: the first one for recording the write delegation chains and is denoted by dw and the second one for the reader chains and is denoted by dr . For each variable, a delegation chain specifies possible delegations in the future; Each chain is a sequence of principal augmented with a natural number indicating the index of the present actual delegation; in other words, principals appearing on or before the index of write (read) delegation chain are those who are currently authorized to read (write) the variable in hand due to delegation. Such principals are the actual writers (readers) of the variable.
DynamicLabel = Var → p (P(Chain) × P(Chain)) Chain
= (Seq Principal ) × N
By abusing the notation, d(x) denotes the label induced by the delegation chains of x, i.e., the owners, actual readers and actual writers defined by the chains in d(x). An alternative semantic construction could consider delegation sequences only; then, each time a delegation takes place a suffix of the chain, in which delegation has taken place is added to the set of sequences. Without revocation, this can lead to a much cleaner semantics, but in the presence of 62
3.5. RDR semantics revocation, one should record “where the current delegation has come from”. Otherwise, one can revoke a delegation which could have been caused by her but in fact has come into being by another principal. This is efficiently achieved by the above-given semantic construction, which keeps the delegation structure, and only shifts it index forth, each time a delegation takes place. Finally, the last component of a configuration is informationFlow , which specifies, for each variable, the set of variables that contribute to its value through an assignment Flow = Var → p V(variable) For example, i(x) denotes the information flow of x (i.e., the set of variables that contributed to the value of x through an assignment). We use the notation i(x) to denote the label extracted from the information flow of x and it is the label of expression l(e) which influenced the variable x or contributed to its current value (through assignment). Such label is computed as follows:
l(e1 ⊕ e2 ) = (s(e1 ) u d(e1 )) t (s(e2 ) u d(e2 )) The program counter PC is a set of variables. It tracks the set of varibales of the guard condition in conditional and loop constructs (if-then-else and while-do, respectively, in RDR syntax) in order to prevent implicit flow. We use the notation P C to denote the label extracted from the program counter and it is the security label of the guard b of conditional or while-loop 63
Chapter 3. RDR: A Language for Restricted Delegation and Revocation constructs. Such label is computed as follows: P C = l(b) = s(b) u d(b) When PC is empty then this label presented by ⊥ which is the least restrictive label ⊥ [7] ( a variable labeled ⊥ is the most public and trusted one every principal is allowed to read it and no one has written to it) P C is only is initially an empty set of variables and updated only in course of if-then-else or while-loop.
The transition relation defined by the operational semantic rules given below is of the following type: PC ` Body × Environment → Environment I.e., it defines that under a certain context for program counter, when the body of a program is evaluated under an environment, the resulting environment is the one specified by the target of the transition. By default, the evaluation of a program P starts from the following configuration:
∅ ` (P C, (∅, ∅, ∅, ∅)), I.e., the label of PC is initially the least restrictive label ⊥ and valuation, static label, dynamic label and information flow are all partial functions with an empty domain. 64
3.5. RDR semantics
3.5.3
Variable declaration
A variable can de declared just once. This is expressed by checking whether or not the variable that is declared is already in the domain of the valuation. The declared variable is added to this valuation with the initial value assigned to it. Both delegation chains for the declared variable are initially empty and no variables contribute to its current value. x∈ / dom(v)P C v l
v 0 = v ⊕ {x 7→ val} s0 = s ⊕ {x 7→ l}
d0 = d ⊕ {x 7→ (∅, ∅)} i0 = i ⊕ {x 7→ ∅}
P C ` hS, v 0 , s0 , d0 , i0 i → hv 00 , s00 , d00 , i00 i P C ` hx : (T, l) := val; S, v, s, d, ii → hv 00 , s00 , d00 , i00 i In the above evaluation rule, we initialize the delegation chains of the variable at hand with empty sets and its information flow with an empty set. Note that T in the conclusion of the evaluation rule refers to the normal type of the declared variable (i.e., Integer, String,..etc), while l refers to the security label of the declared variabel. Example 12 Consider the first statement of the program presented in Example 3, given below. history : (String, patient) := SQLQuery; Starting from the above statement with the default initial state (i.e., the empty label for the PC and partial functions with empty domain for all components of the environment), we arrive in the following environment, by applying the above-given deduction rule: 65
Chapter 3. RDR: A Language for Restricted Delegation and Revocation
env0 =({history 7→ SQLQuery}, {history 7→ ({patient}, ∅, ∅)}, {history 7→ (∅, ∅)}, {history 7→ ∅})
3.5.4
Assignments
In order for an assignment x := e to make a successful operational step, one requires that x and all variables that occur freely in e are defined variables, the meet of the static label and the dynamic label of e joint with the label of program counter P C is less restrictive than meet of static label and dynamic label of x, and the label of information flow of expression e is less restrictive than meet of static label and dynamic label of x. Note that the static label, and the dynamic label of an expression e is defined inductively based on its structure, in the standard manner: for a constant c, those label of are defined to be ⊥. For a variable x they are is defined to be s(x) and d(x) (as defined before) and for a composition of a number of expressions, they are defined to be the join of the static labels of the sub-expressions and the join of dynamic labels of sub-expression respectively. Similarly, the label of information flow for a composition of a number of expressions are the join of the label of information flow of the sub-expressions as shown below:
s(e1 ⊕ e2 ) = s(e1 ) t s(e2 ) d(e1 ⊕ e2 ) = d(e1 ) t d(e2 ) i(e1 ⊕ e2 ) = i(e1 ) t i(e2 ) The reason for taking the meet of static and dynamic labels (of both 66
3.5. RDR semantics x and e) is to cater for the policies modified by delegation and revocation; the reason for taking the join with the P C is to disallow implicit information flows that leaks information about the expressions appearing in the condition of control statements. The reason for taking the label of information flow of e is to prevent leakage due to an assignment of x to a revoked expression e. The evaluation rule given below for an assignment realizes these items. x ∈ dom(v) vars(e) ⊆ dom(v) (s(e) u d(e)) t P C v s(x) u d(x) i(e) v s(x) u d(x)
v 0 = v ⊕ {x 7→ v(e)} i0 = i ⊕ {x 7→ s(e) u d(e)} P C ` hS, v 0 , s, d, i0 i → hv 00 , s0 , d0 , i00 i
P C ` hx := e; S, v, s, d, ii → hv 00 , s0 , d0 , i00 i Function v is a mapping that associates with an expression e (over variables from dom(v)) the value that is obtained by replacing the variables by their values from v. The above-given rule first checks whether the information leakage caused by this assignment is justified by the combination of static and delegation policies (static and dynamic labels) executed so far (i.e., the meet of static and dynamic labels of expression e joint with the program counter is less restrictive than meet of static and dynamic labels of variable x assigned to it). If so, it checks whether label of information flow content of expression e is less restrictive than the meet of static and dynamic label of variable x assigned to it. If so, the value of x is updated with the value of expression e and the information flow of x is updated with the set of variables that contributed to its value defined as vars(e) (.i.e the set of variables included in expression e). 67
Chapter 3. RDR: A Language for Restricted Delegation and Revocation
3.5.5
If-then-else statements
The semantics of if-then-else statements is presented by the following two evaluation rules, catering for the “then” and the “else” cases, respectively. Note in both cases that the program counter in the body of the conditional statement is updated with the set of variables of the guard condition vars(b) hence, within the scope of if-then-else, the of program counter is union with with vars(b). This union does not carry over to the statements executing after the conditional and hence the rest of the program is executed under the original value of the program counter. vars(b) ⊆ dom(v) v(b) = true
P C ∪ vars(b) ` hS, v, s, d, ii → hv 0 , s0 , d0 , i0 i P C ` hS 00 , v 0 , s0 , d0 , i0 i → hv 00 , s00 , d00 , i00 i
P C ` hif b then S else S 0 fi; S 00 , v, s, d, ii → hv 00 , s00 , d00 , i00 i
vars(b) ⊆ dom(v) v(b) = false
P C ∪ vars(b) ` hS 0 , v, s, d, ii → hv 0 , s0 , d0 , i0 i P C ` hS 00 , v 0 , s0 , d0 , i0 i → hv 00 , s00 , d00 , i00 i
P C ` hif b then S else S 0 fi; S 00 , v, s, d, ii → hv 00 , s00 , d00 , i00 i
3.5.6
While-do statements
The semantics of a while loop is presented by the following two evaluation rules. Besides the standard definition, the main source of complication in the following two definition is that the program counter entities is is updated with the set of variables of boolean condition vars(b) This has already been 68
3.5. RDR semantics observed in the semantics of the conditional statement. However, the program counter for the continuation of the program is also influenced by the condition of the while loop, because reaching the continuation depends on the termination of the while loop, and hence on its boolean condition. vars(b) ⊆ dom(v) v(b) = true
P C ∪ vars(b) ` hS; while b do S od;S 0 , v, s, d, ii → hv 0 , s0 , d0 , i0 i P C ` hwhile b do S od; S 0 , v, s, d, ii → hv 0 , s0 , d0 , i0 i
vars(b) ⊆ dom(v) v(b) = false
P C ∪ vars(b) ` hS 0 , v, s, d, ii → hv 0 , s0 , d0 , i0 i P C ` hwhile b do S od; S 0 , v, s, d, ii → hv 0 , s0 , d0 , i0 i
3.5.7
Delegation statements
The first three evaluation rules of the delegates construct allow for adding a delegation chain by the owner of the variable (for reading, writing or both reading and writing of the variable, respectively). Note that in those rules, the label of program counter is justified to be less restrictive than the meet of the static and dynamic label of the delegated variable, in order to prevent the implicit flow if the delegation occurs in the body of if-then-else or while loop constructs. In addition, the label of the information flow of the delegated variable has to more restrictive than its dynamic label, in order to prevent delegating that variable to a principal not defined in the chain of of another delegated variable assigned to it before delegation. 69
Chapter 3. RDR: A Language for Restricted Delegation and Revocation
x ∈ dom(v) p ∈ owner(s(x))
d0 = d ⊕ {x 7→ (dw (x), dr (x) ∪ {(p _ c, 1)})} P C v s(x) u d0 (x) i(x) v d0 (x)
P C ` hS, v, s, d0 , ii → hv 0 , s0 , d00 , i0 i P C ` hp delegates x ∗ c; S, v, s, d, ii → hv 0 , s0 , d00 , i0 i
x ∈ dom(v) p ∈ owner(s(x))
d0 = d ⊕ {x 7→ (dw (x) ∪ {(p _ c, 1)}, dr (x))} P C v s(x) u d0 (x) i(x) v d0 (x)
P C ` hS, v, s, d0 , ii → hv 0 , s0 , d00 , i0 i P C ` hp delegates x ! c; S, v, s, d, ii → hv 0 , s0 , d00 , i0 i
x ∈ dom(v) p ∈ owner(s(x))
d0 = d ⊕ {x 7→ (dw (x) ∪ {(p _ c, 1)}, dr (x) ∪ {(p _ c, 1)})} P C v s(x) u d0 (x) i(x) v d0 (x)
P C ` hS, v, s, d0 , ii → hv 0 , s0 , d00 , i0 i P C ` hp delegates x (∗, !) c; S, v, s, d, ii → hv 0 , s0 , d00 , i0 i In all three evaluation rules given above, P C is compared with the label of the delegated variable in order to make sure no information about the control context is leaked via delegation side channels such as the following. Example 13 In the following example, Bob tries a delegation statement within a context in which the value of x is known to be true. Hence, if Bob learns that the delegation has been successful, e.g., by trying an assignment 70
3.5. RDR semantics only allowed using the extended label, Bob will also know learn the value of x. Such delegation side-channels become more serious if one has a means to explicitly test the possible flows.
1:
x : (Bool, Alice:) := true;
2:
y : (Bool, Bob:) := true;
3:
z : (Bool, Carl:) := true;
4:
//some computation involving x
5:
if x == true then
6:
Bob delegates y * Carl
7:
else x := x // dummy expression
8:
endif
9:
z := y // dummy expression
10:
y := true
The remaining three evaluation rules specify further delegation by a principal previously authorized by the owner (the head of an existing delegation chain). Note that if a principal only delegates to a sub-chain (of the original chain specified by the owner), only the sub-chain will be added for further delegation. For brevity only the evaluation rule concerning the read-chain is presented. The other two evaluation rules, specifying the delegation of writing and both reading and writing, are almost identical to the one given below and are omitted here. 71
Chapter 3. RDR: A Language for Restricted Delegation and Revocation
x ∈ dom(v) p ∈ / owner(s(x))
(c0 , j) ∈ dr (x) c0 = c0 _ p _ c _ c1
c0 (j) = p
d0 =d ⊕ {x 7→ (dw (x), dr (x)\
{(c0 , j)} ∪ {(c0 _ p _ c, j + 1)})}
P C v s(x) u d0 (x) i(x) v d0 (x)
P C ` hS, v, s, d0 , ii → hv 0 , s0 , d00 , i0 i P C ` hp delegates x ∗ c; S, v, s, d, ii → hv 0 , s0 , d00 , i0 i The above-given evaluation rule requires a chain (c0 ) to be present in the set of read delegation chains of x such that p appears at the current index of delegation (is the last actual reader in the chain) in c0 , and p is immediately followed by c. If such is the case, those chains containing the delegated subchain c, preceded by p are taken out of dr(x) (defined using the difference of two sets symbol \). After that, they are put back with their indices moved forward and incremented by 1 (.i.e., J + 1, where j is the delegation index) thereby granting the read right to the first principal in c. (Delegating to an empty list shifts an arbitrary delegation chain starting with p one principal further. If this is considered undesired, it can be prevented by adding a premise requiring c to be non-empty.)
Example 14 Now, there is sufficient ingredients to go somewhat further (than Example 12) with the evaluation of the program in Example 3. To start with, consider a part of this program, given below. history : (String, patient) := SQLQuery; patient delegates history(*,!) phys1; obs1 : (String, phys1: patient) := Observation; 72
3.5. RDR semantics history = history + obs1; it had already shown that the execution of variable declaration results in the following environment.
env0 =({history 7→ SQLQuery}, {history 7→ ({patient}, ∅, ∅)}, {history 7→ (∅, ∅)}, {history 7→ ∅}) Hence, it can be continued with evaluating the rest of the program by using the empty label as P C and env0 as environment. Evaluating the delegation statement results in the following environment, due to the third deduction rule for delegation (note that patient is the owner of history):
env1 = ({history 7→ SQLQuery}, {history 7→ ({patient}, ∅, ∅)}, {history 7→ ({(phys1 , 0)}, {(phys1 , 0)})}, {history 7→ ∅}) Hence in env1 , the actual reader and writers in the delegation chain of history= {phys1 }. Evaluating the variable declaration adds obs1 to the set of declared variables with its initial value, i.e., the following environment:
env2 = ({history 7→ SQLQuery, obs1 7→ Observation}, {history 7→ ({patient}, ∅, ∅), obs1 7→ ({phys1 }, {patient}, ∅)}, {history 7→ ({(phys1 , 0)}, {(phys1 , 0)})}, obs1 7→ (∅, ∅)} {history 7→ ∅, obs1 7→ ∅}) Evaluating the assignment of addition (the value of history and obs1) to history, resulting in the following environment: 73
Chapter 3. RDR: A Language for Restricted Delegation and Revocation
env3 = ({history 7→ SQLQuery + Observation, obs1 7→ Observation}, {history 7→ ({phys1 , patient}, {phys1 , patient}, {phys1 , patient}), obs1 7→ ({phys1 }, {patient}, ∅)}, {history 7→ ({(phys1 , 0)}, {(phys1 , 0)}), obs1 7→ (∅, ∅)}, {history 7→ ({history, obs1 }, obs1 7→ ∅})
3.5.8
Revocation statements
The owner of a variable can revoke any delegation (sub-)chain declared before; the grantor of a delegation can revoke only the part of delegation authorized by herself. The grantor cannot revoke the delegation chain defined by the owner, however.
x ∈ dom(v) p ∈ owner(s(x))
d0 = (dw , dr ⊕ {x 7→ {((dr (x)\
{(c0 , j) | (c0 , j) ∈ dr (x) ∧ c0 = c0 _ c _ c1 })∪
{(c0 , k) | (c0 _ c _ c1 , j) ∈ dr (x) ∧ k = min(j, #c0 )})}}) P C v s(x) u d0 (x) P C ` hS, v, s, d0 , ii → hv 0 , s0 , d00 , i0 i P C ` hp revokes x ∗ c; S, v, s, d, ii → hv 0 , s0 , d00 , i0 i The evaluation rule given above, takes out all chains containing the subchain c and puts back their prefix (specified by c0 ) to the index k right before the sub-chain in case it has gone beyond the prefix. An alternative semantics for revocation could put back c0 _ c1 , thereby “patching” the remaining chains; this alternative semantics is more in-line with a transitive 74
3.5. RDR semantics view of delegation, i.e., if the chain p0 → p1 → p2 is authorized, then the delegation p0 → p2 is also implicitly authorized. This is considered somewhat counter-intuitive as it is quite natural to require a certain delegation to go via a specified principal.
x ∈ dom(v) p ∈ / owner(s(x))
d0 =(dw , dr ⊕ {x 7→ ((dr (x)\
{(c0 , i) | (c0 , i) ∈ dr (x) ∧ c0 = c0 _ p _ c1 _ c _ c2 ∧ #c0 _ p _ c1 < i})∪
{(c0 , #c0 _ p _ c1 ) |
(c0 , i) ∈ dr (x) ∧ c0 = c0 _ p _ c1 _ c _ c2 ∧ #c0 _ p _ c1 < i})})
P C v s(x) u d0 (x) P C ` hS, v, s, d0 , ii → hv 0 , s0 , d00 , i0 i P C ` hp revokes x ∗ c; S, v, s, d, ii → hv 0 , s0 , d00 , i0 i The rule given above removes those chains containing p and followed by c such that the current delegation has passed via p to c (and possibly beyond). After removing such chains, their prefix before reaching c is put back in the delegation chain and the index is moved back to the index before the start of c. There are two pairs of evaluation rules dedicated to revoking write and both write and read delegation, which are almost identical to the ones given above and hence, are omitted.
3.5.9
Termination
Finally, an empty program, denoted by , indicates successful termination, whose semantics is captured by the following evaluation rule. 75
Chapter 3. RDR: A Language for Restricted Delegation and Revocation
P C ` h, v, s, d, ii → hv, s, d, ii
3.6
Comparison matrix
The following table shows a comparison between RDR security features and other well known standards of security typed programming languages such as Jif and Flow Caml
Information flow control General delegation Restricted delegation Support of delegation chain Support of principal revocation Support of runtime principals Respect of noninterference Prevention of (termination/timing) channels
RDR X
Jif X
Flow Caml X
X
X
X
X
% % %
% % %
%
X
%
N/A
X
X
%
%
%
X X
Table 3.1: Comparison matrix between RDR and well know related languages
76
3.7. Summary
3.7
Summary
This chapter presents the idea of restricted delegation and revocation in language based security. This is done by introducing a new security typed programming language RDR that allows more restricted form of delegation and revocation. First, it introduces some motivating examples that shows the essence of restricted form of delegation and revocation in practice. Then the syntax and the operational semantics of RDR are introduced with some motivating examples written in RDR syntax.
77
Chapter 4 RDR Semantics Error Handling The current implementations of security typed programming languages rely mostly on statically analyzing the source code of a program before its execution to ensure that the program adheres to the user policies. Such an analysis is typically formalized using a type-system that verifies the code for the absence of insecure information-flow. Although such an approach offers no run-time cost, it lacks precision as it may reject programs that are safe [66]. As an alternative, dynamic analysis for information-flow security offers precision by rejecting only insecure executions and by providing the possibility to enforce dynamic information-flow policies. However, such analysis is usually unable to track implicit information flow paths [67, 68] (e.g., via branching on conditional or while loop constructs), because it only takes the current execution into account and does not use the global information about the program and its control-flow structure. RDR combines the benefits of static and dynamic analysis by introducing some elements of static checking (e.g., checking the control-flow) in the dynamic semantics of the language. In this chapter, the a formal error semantics for RDR is defined, by exploiting the dynamic analysis approach and enriching it with control-flow-sensitive 78
4.1. RDR Error Semantics checks . The error semantics denotes the executions that are prohibited because they may potentially leak sensitive information (possibly implicit) to unauthorized users. The error messages provided in this semantics may comprise sensitive information themselves and hence, are not supposed to be displayed to unauthorized users. They are meant for programmers (or system administrators) to detect possible security-breaches in the developed (deployed) programs.
4.1
RDR Error Semantics
In order to have an appropriate error handling, the RDR language is enriched with error semantics [61]. This semantics comprises deduction rules, which specify the forbidden executions due to insecure information flows. The error semantics rules are implemented in the prototype evaluator of RDR which is described in the next chapter. Programmers and system administrators can refer to the error messages thrown by these rules to discover insecure information flow during program development and deployment, respectively. They are essential for proper debugging of RDR programs and their definition has been motivated by the practical need for them. The predicates defined by the error semantics are of the form P C ` hS, v, s, d, ii ⇓ error(r), where S, v, s, d and i have the same intuition as in the operational semantics presented in chapter 3 and error(r) denotes the error indicating why S contains a possibly insecure information flow. 79
Chapter 4. RDR Semantics Error Handling
4.1.1
Variable declaration error rule
The following deduction rules indicate why a variable declaration cannot be executed. x ∈ dom(v) P C ` hx : (T, l) := val; S, v, s, d, ii ⇓ error(“variable” x “is already declared”)
P C 6v l P C ` hx : (T, l) := val; S, v, s, d, ii ⇓ error(“disallowed implicit flow in” x “: (”T, l “) :=”val) The first deduction rule specifies the failure of the evaluation of variable declaration rule due to usage of a variable x that already declared. The second deduction rule specifies the failure of the evaluation if the label of a program counter is not less restrictive than the static security label of the declared variable. Such condition is necessary to prevent an implicit information flow.
4.1.2
Error rule of assignment
The following deduction rules indicate why an assignment statement fails to execute. x∈ / dom(v) P C ` hx := e; S, v, s, d, ii ⇓ error(Variable x undefined in: x := e) 80
4.1. RDR Error Semantics
x ∈ dom(v) vars(e) * dom(v) P C ` hx := e; S, v, s, d, ii ⇓ error(Expression undefined in: x := e)
x ∈ dom(v) vars(e) ⊆ dom(v) (s(e) u d(e)) t P C 6v s(x) u d(x) P C ` hx := e; S, v, s, d, ii ⇓ error(Insecure information flow in: x := e)
x ∈ dom(v) vars(e) ⊆ dom(v) (s(e) u d(e)) t P C v s(x) u d(x) i(e) 6v s(x) u d(x) P C ` hx := e; S, v, s, d, ii ⇓ error(“disallowed information flow in”: x := e) The first two deduction rules specify the failure of the evaluation rule for the assignment construct x := e due to the undeclared variable x or an undeclared variable in expression e, respectively. The third deduction rule specifies when an insecure flow is encountered since either the label of e or the label P C is more restrictive than the label of x. In the former case, there is an explicit insecure information flow and in the latter case, there is the possibility of an implicit insecure information flow by exploiting the control flow of the program. The last deduction rule specifies the failure of the evaluation due unsatisfying the security condition of secure information flow specified in the third premises of the semantics rule of assignment. This condition is only satisfied if the label of information flow of e is less restrictive than the security label of x which is required to prevent an assignment to a 81
Chapter 4. RDR Semantics Error Handling revoked variable as will be illustrated in example 15. Moreover, the following deduction rule specifies the failure of the evaluation due to failure in the evaluation of continuation (i.e.,the rest of the program composed with the assignment construct).
x ∈ dom(v) vars(e) ⊆ dom(v) (s(e) u d(e)) t P C v s(x) u d(x)
v 0 = v ⊕ {x 7→ v(e)} i0 = i ⊕ {x 7→ i(r)} P C ` hS, v 0 , s, d, i0 i ⇓ error(r)
P C ` hx := e; S, v, s, d, ii ⇓ error(r)
4.1.3
Error rule of conditional
Similar to the previous cases, one has to cater for errors rising either in the evaluation of if-then-else statement or the subsequent statements in the program. The following deduction rule indicate why if-then-else cannot be executed. The symmetric versions of the rule for the else case is slipped.
vars(b) 6⊆ dom(v) P C ` hif b then S else S 0 fi; S 00 , v, s, d, ii ⇓
error(“expression” b “undefined in”: if b then S else S 0 fi) The deduction rule given above specifies the failure of the evaluation rule for the conditional construct if b then S else S 0 f i due to usage of undeclared variable occurs in boolean condition b. Moreover, one has to cater for errors rising throughout the execution of the body of the then case and the rest of the program respectively: 82
4.1. RDR Error Semantics
vars(b) ⊆ dom(v) v(b) = true
P C ∪ vars ` hS, v, s, d, iii ⇓ error(r)
P C ` hif b then S else S 0 fi; S 00 , v, s, d, ii ⇓ error(r)
vars(b) ⊆ dom(v) v(b) = true
P C ∪ vars ` hS, v, s, d, ii → hv 0 , s0 , d0 , i0 i
P C ` hS 00 , v 0 , s0 , d0 , i0 i ⇓ error(r)
P C ` hif b then S else S 0 fi; S 00 , v, s, d, ii ⇓ error(r)
4.1.4
Error rule of while-Loop
As before, the rules indicating the error in the evaluation of the while-do statement are specified.
vars(b) 6⊆ dom(v) P C ` hwhile b do S od; S 0 , v, s, d, ii ⇓ error(“expression” b “undefined” ) The deduction rule given above specifies the failure of the evaluation rule for the looping construct while b do S od due to usage of undeclared variable occurs in boolean condition b. Moreover, one has to cater for errors rising throughout the execution of the body of while-do and the rest of the program respectively:
vars(b) ⊆ dom(v) v(b) = true
P C ∪ vars(b) ` hS; while b do S od;S 0 , v, s, d, ii ⇓ error(r) P C ` hwhile b do S od; S 0 , v, s, d, ii ⇓ error(r) 83
Chapter 4. RDR Semantics Error Handling
vars(b) ⊆ dom(v) v(b) = false
P C ∪ vars(b) ` hS 0 , v, s, d, ii ⇓ error(r) P C ` hwhile b do S od; S 0 , v, s, d, ii ⇓ error(r)
4.1.5
Error rule of delegation
The following deduction rules indicate why delegation of reading permissions by an owner fails to execute. Due to space, the symmetric versions of the rules for “write” and “(read, write)” delegation are omitted.
x∈ / dom(v) P C ` hp delegates x ∗ c; S, v, s, d, ii ⇓ error(Variable x is not declared in: p delegates x ∗ c)
x ∈ dom(v) p ∈ owner(s(x))
d0 = d ⊕ {x 7→ (dw ∪ {(c, 0)}, dr (x))} P C 6v s(x) u d0 (x) P C ` hp delegates x ∗ c; S, v, s, d, ii ⇓ error(Disallowed implicit delegation flow in: p delegates x ∗ c) 84
4.1. RDR Error Semantics
x ∈ dom(v) p ∈ owner(s(x))
d0 = d ⊕ {x 7→ (dw ∪ {(c, 0)}, dr (x))} P C v s(x) u d0 (x) i(x) 6v d0 (x) P C ` hp delegates x ∗ c; S, v, s, d, ii ⇓ error(Disallowed information flow with delegation ) The first deduction rule specifies the failure of the evaluation rule for the delegation construct by an owner because of the usage of an undeclared delegated variable x. The second and third deduction rule specify the failure of the evaluation due unsatisfying the two security conditions for secure information flow in the third premise of the semantics rule of the delegation by the owner. The first condition is only satisfied if the program counter is less restrictive than the meet of the static and dynamic label of the delegated variable. The second condition is only satisfied if the label of the information flow of the delegated variable is less restrictive than its dynamic label.
The following three deduction rules indicate why delegation of reading permissions by non owner failed to be executed.
x ∈ dom(v) p ∈ / owner(s(x))
6 ∃(c0 , j) ∈ dr (x) c0 = c0 _ p _ c _ c1
c0 (j) = p
P C ` hp delegates x ∗ c; S, v, s, d, ii ⇓ error(The delegation is not allowed without a permission from the owner) 85
Chapter 4. RDR Semantics Error Handling
x ∈ dom(v) p ∈ / owner(s(x))
(c0 , j) ∈ dr (x) c0 = c0 _ p _ c _ c1
c0 (j) 6= p
P C ` hp delegates x ∗ c; S, v, s, d, ii ⇓ error(The delegation is not allowed by the delegatee anymore)
x ∈ dom(v) p ∈ / owner(s(x))
(c0 , j) ∈ dr (x) c0 = c0 _ p _ c _ c1
c0 (j) = p
d0 =d ⊕ {x 7→ (dw (x)\
{(c0 , j)} ∪ {(c0 _ p _ c, j + 1)}, dr (x))} P C 6v s(x) u d0 (x)
P C ` hp delegates x ∗ c; S, v, s, d, ii ⇓ error(Disallowed information flow with delegation) x ∈ dom(v) p ∈ / owner(s(x))
(c0 , j) ∈ dr (x) c0 = c0 _ p _ c _ c1
c0 (j) = p
d0 =d ⊕ {x 7→ (dw (x)\
{(c0 , j)} ∪ {(c0 _ p _ c, j + 1)}, dr (x))}
P C v s(x) u d0 (x) i(x) 6v d0 (x) P C ` hp delegates x ∗ c; S, v, s, d, ii ⇓ error(Disallowed information flow with delegation) The first deduction rule specifies the failure of the evaluation due to delegation by a non owner to another principal not defined in the delegation chain authorized by the owner delegator. The second and third deduction rule specify the failure of the evaluation due unsatisfying the two security conditions for secure information flow. Those conditions are similar to those 86
4.1. RDR Error Semantics in case of delegation by owner and are specified in the third premise of semantics rule of delegation by non-owner. Moreover, the following two deduction rule specify the failure of the evaluation due to failure in the evaluation of continuation (i.e.,the rest of the program composed with the delegation construct by owner and non-owner respectively).
p ∈ owner(s(x)) d0 = d ⊕ {x 7→ (dw , dr ∪ (c, 1))} P C v s(x) u d0 (x) i(x) v d0 (x) P C ` hS, v, s, d0 , ii ⇓ error(r)
P C ` hp delegates x ∗ c; S, v, s, d, ii ⇓ error(r)
p 6∈ owner(s(x)) (c0 , i) ∈ dr (x)
c0 = c0 _ p _ c _ c1
c0 (i) = p
d0 = d ⊕ {x 7→ (dw (x), dr (x) \ {(c0 , i)} ∪ {(c0 , i + 1)})} P C v s(x) u d0 (x) i(x) v d0 (x) P ` hS, v, s, d0 , ii ⇓ error(r)
P ` hp delegates x ∗ c; S, v, s, d, ii ⇓ error(r) Example 15 In the following program, the scenario of delegating the credit card information from the client to the bookshop and its revocation after finishing the transaction is modeled from Example 2. After the revocation, the bookshop should not be allowed to delegate the credit card information to the bank anymore (as bookshop is revoked from the delegation chain defined by the client) and this is supposed to prevented by the semantics of delegation by non-owner as shown before. In addition, the bookshop is not allowed to 87
Chapter 4. RDR Semantics Error Handling use the credit card information anymore and this is supposed to be prevented by the semantics of assignment as previously mentioned. 1:
cc : (CreditCard, client) := CCInfo;
2:
// client buys a book from the bookshop
3:
client delegates cc * bookshop → bank;
4:
ccCopy: (CreditCard, bookshop: client) := Empty;
5:
ccCopy := cc;
6:
bookshop delegates cc * bank;
7:
// bank processes and approves the transaction
8:
client revokes cc * bookshop
9:
//bookshop delegates cc * bank;
10:
ccCopy2: (CreditCard, bookshop: client) := Empty;
11:
ccCopy2 := ccCopy; After running this program, the following run-time error message will
appear. Disallowed information flow in ccCopy2:=ccCopy This error message is raised at line 11 due to assigning ccCopy to ccCopy. This is because ccCopy has the client’s credit card information due to the assignment at line 5 which is not allowed to use this information any more due revoking the bookshop at line 8. This error message is implemented in the fourth error semantics rule of an assignment as shown before. If the comment is removed from line 9 , then after reducing this program again, the following error message will appear. The delegation is not allowed by delegatee anymore. This error message is raised at line 9 due to delegation by non-owner principal which has been revoked (.i.e. the bookshop) from the owner’s (.i.e 88
4.1. RDR Error Semantics the client) delegation chain. This error message is implemented in the second error semantics rule of delegation by non-owner as shown before.
4.1.6
Error rule of revocation
Revocation itself can never fail: except if it reveals information about the control context via revocation side channels or it may refers to a non-existent delegation, in which case it is simply ignored. Following, the cases where a revocation of reading permission may fail are defined. The similar cases for “write” and “(read, write)” revocation are omitted below.
x∈ / dom(v) P C ` hp revocks x ∗ c; S, v, s, d, ii ⇓ error(“variable x is not declared“ )
x ∈ dom(v) p ∈ owner(s(x))
d0 = (dw , dr ⊕ {x 7→ {((dr (x)\
{(c0 , i) | (c0 , i) ∈ dr (x) ∧ c0 = c0 _ c _ c1 })∪
{(c0 , j) | (c0 _ c _ c1 , i) ∈ dr (x) ∧ j = max(i, #c0 )})}}) P C 6v (s(x) u d0 (x))
P ` hp revokes x ∗ c; S, v, s, d, ii ⇓ error(”Disallowed information flow with revocation”) 89
Chapter 4. RDR Semantics Error Handling
x ∈ dom(v) p ∈ / owner(s(x))
d0 =(dw , dr ⊕ {x 7→ ((dr (x)\
{(c0 , i) | (c0 , i) ∈ dr (x) ∧ c0 = c0 _ p _ c1 _ c _ c2 ∧ #c0 _ p _ c1 < i})∪ {(c0 _ p _ c1 , #c0 _ p _ c1 ) |
(c0 , i) ∈ dr (x) ∧ c0 = c0 _ p _ c1 _ c _ c2 ∧ #c0 _ p _ c1 < i})}) P C 6v (s(x) u d0 (x)) P ` hp revokes x ∗ c; S, v, s, d, ii ⇓
error(”Disallowed information flow with revocation”)
The failure of the continuation (.i.e.the rest of the program) is captured by the following deduction rules.
x ∈ dom(v) p ∈ owner(s(x))
d0 = (dw , dr ⊕ {x 7→ {((dr (x)\
{(c0 , i) | (c0 , i) ∈ dr (x) ∧ c0 = c0 _ c _ c1 })∪
{(c0 , j) | (c0 _ c _ c1 , i) ∈ dr (x) ∧ j = max(i, #c0 )})}}) P C v (s(x) u d0 (x)) P ` hS, v, s, d0 , ii ⇓ error(r) P ` hp revokes x ∗ c; S, v, s, d, ii ⇓ error(r) 90
4.2. Summary
x ∈ dom(v) p ∈ / owner(s(x))
d0 =(dw , dr ⊕ {x 7→ ((dr (x)\
{(c0 , i) | (c0 , i) ∈ dr (x) ∧ c0 = c0 _ p _ c1 _ c _ c2 ∧ #c0 _ p _ c1 < i})∪
{(c0 _ p _ c1 , #c0 _ p _ c1 ) |
(c0 , i) ∈ dr (x) ∧ c0 = c0 _ p _ c1 _ c _ c2 ∧ #c0 _ p _ c1 < i})})
P C v (s(x) u d0 (x)) P ` hS, v, s, d0 , ii ⇓ error(r) P ` hp revokes x ∗ c; S, v, s, d, ii ⇓ error(r)
4.2
Summary
This chapter presents the error semantics rules of RDR by exploiting the dynamic analysis approach and enriching it with control-flow-sensitive checks borrowed from static approach. These rules are a set of deduction rules that specify the forbidden executions of the program (Presented in a form of error messages) which may result in (possibly implicit) information leakage to unauthorized users. Such rules are particularly useful in the implementation of RDR (e.g.,the implementation of an evaluator for RDR) as it will be shown in the next chapter. The programmer can refer to the error messages thrown by those rules for debugging to discover insecure information flow during program execution.
91
Chapter 5 RDR Implementation 5.1
Introduction
Despite the extensive research in field of language based information flow security, currently there seems to be very little practical software in existence. This may be due in part to the limitations and restrictive nature of many existing information flow models. The work introduced in this thesis goes further in the direction of implementation of language based security. It introduces a new strategy for implementing security typed programming languages using the language specification formalism ASF+SDF [20]. This strategy is different from the common approaches for implementing such languages which relies on statically analyzing the source code of a program before its execution to verify the absence of insecure information flow. It relies on run-time analysis of information flow security with an ability to track the implicit flow paths (the main advantage of static approach of information flow analysis). The implementation is presented by a prototype of an evaluator for RDR. The prototype is developed using the language specification formalism ASF+SDF [20]. This evaluator is able to track insecure informa92
5.2. Existing approaches for Implementation tion flow during program execution and discover implicit flow paths. This chapter focuses on the implementation of RDR. First it introduces a survey on the current approaches for implementing security typed programming languages with describing briefly the few existing implementations. Then it introduces ASF+SDF algebraic specification formalism and how to use it to define the syntax of RDR language and implement its operational and error semantics. Then, the general implementation of RDR evaluator is introduced, including its different imported modules. Finally, the applicability of RDR in practice is shown by evaluating several programs written in RDR syntax using the presented evaluator, where this evaluator is able to raise error messages when insecure information flow is encountered.
5.2
Existing approaches for Implementation
The few existing implementations in language based security are confined to few security typed programming languages that are bale to analyze information flow in the application program such as Jif [3, 4], Flow Caml[17, 69], SELinks[70], Aura[71, 19] and gWhile[72]. Most of those implementations rely on analyzing the source code of a program statically before its execution to ensure that a program adheres to the user policy. The formalization of such analysis is performed using the type-system that verifies code for the absence of insecure information flow. Although such approach offers no runtime cost, it lacks precision as it may reject the entire program as insecure even if the program execution is safe [36] as shown in the example below. Example 16 Consider the following program which is rejected by type system:
93
Chapter 5. RDR Implementation {Alice :}x= true; {Bob : Alice} y= false; If (x==false){ y:=x; } The assignment in the body of if-statement is rejected by type system where `x 6v `y (.i.e. the security label of x is not less restrictive than the one of y) and so it rejects this program as insecure, although this assignment can not happen as the value of x is true (i.e. the program is safe). On the other hand, dynamic analysis for information flow security offers precision by rejecting only insecure execution and ability to enforce dynamic information flow policies. However such analysis (i.e., dynamic analysis for information flow security) is unable to track implicit information flow paths [67, 68] as not every branch is checked during program execution which makes dependencies among different branches are difficult to detect [68]. Shroff et al. [36, 67] represented a solution to this problem. They introduced λdeps a higher-order functional language with mutable state to track dependencies between program points at run-time and at the same time uses the collected set of dependencies to detect indirect information flows. λdeps might leak indirect information in the initial run(s) before capturing the appropriate dependencies. As an improvement to λdeps , they introduced λdeps+ which is initialized with a statically generated complete set of dependencies for a given program to detect all indirect information flows at run-time. However their work is not implemented. Austin and Flanagan [68] presented λinf o a variant of λ−calculus to tracks information flow dynamically. They present two semantics for λinf o : the first one uses universal labeling scheme, where every value has an associated 94
5.2. Existing approaches for Implementation information flow label to track information flow label in a straight forward manner. The second one uses Sparse labeling representation that leaves labels implicit and uses explicit labels when values migrate between different domains. However, λinf o is not implemented. Haldar et al. [73] used the dynamic checking technique to tag and track the user input at run-time to prevent insecure information flow caused by improper use of malicious user input. They applied their approach to java class-files, where a runtime taint error is raised in a form of java exception. This exception is raised when a tainted data is used as an argument to untainted method. However these run-time errors is not implemented in the semantics of Java language. Recently, the idea of dynamic information flow analysis was enforced in some existing security typed programming languages. For example, although Jif language relies on static type checking of information flow, it has a dynamic label mechanism. In this mechanism, labels and principals can be used as as first-class values, represented at runtime and used to specify other labels. Zheng and Myers [74] presented the Jif-DX language, which extends Jif with a more powerful dynamic label mechanism, including a statement for label testing. However, the dynamic label in both Jif and Jif-DX will contain a representation of a fixed label (i.e, the label content is known at runtime), while it can’t contain a representation of varying label with unknown content at run-time such as the one in case of delegation and revocation. The approach presented in this thesis for implementing RDR addresses the limitations mentioned before in this section in several ways: First, it utilizes the dynamic approach due to its ability to track the changes in the information flow policies during program execution by means delegation or revocation and enrich it with the ability to track implicit flows. Second, the 95
Chapter 5. RDR Implementation ability to raise error messages when insecure information flow encountered as a part of RDR error semantics and not based on the type of input data to RDR program (i.e., tainted or untainted). The implementation is presented by developing a prototype of an evaluator for RDR in the language specification formalism ASF+SDF. Both of RDR operational and error semantics rules (described in chapter 3,4) are implemented in this prototype. This evaluator is able to enforce dynamic information flow analysis, in addition to tracking implicit information flow paths during program execution. This is done by introducing some elements of static checking (e.g., checking the control-flow) in the dynamic semantics of RDR (e.g. the label of program counter introduced in chapter 3 to track implicit flows due to conditional or while-loop). In addition, the flows introduced by means of delegation and revocation (described in chapter 3) are tracked using the label of information flow as mentioned before. Moreover, the evaluator is able to track the change in the security label of each variable due to delegation or revocation by implementing RDR operational semantics. RDR semantics combines explicit labeling by static label (that annotates each declared variable) and implicit labeling by dynamic label with unknown content (determined by program context due to delegation and revocation). Finally, the presented evaluator is able to raise the run-time errors when insecure information flow is encountered by implementing RDR error semantics (described in chapter 4) which provides those error messages. The presented implementation of RDR evaluator follows the approach of Peter D. Mosses [75]. He outlined how to write action semantics (a hybrid of denotational and operational semantics) descriptions in ASF+SDF. However the presented implementation is different from his work in that it presents how to write natural semantics (including both regular and error semantics) 96
5.3. ASF+SDF Language Specification Formalism descriptions in ASF+SDF instead of action semantics. In addition, one of the main targets of the presented implementation for RDR is to analyse information flow dynamically and check insecure information flow using error semantics which was not investigated by his work.
5.3
ASF+SDF Language Specification Formalism
ASF+SDF formalism [20] is a combination of two formalisms: Algebraic Specification Formalism (ASF) [76] and Syntax Definition Formalism (SDF) [77]. The later allows the definition of concrete (lexical and context free) and abstract syntax of the implemented language, while the former allows a simultaneous definition of a set of conditional equations that defines its semantics. Furthermore, ASF+SDF is a modular algebraic specification formalism. There are in fact 2 types of ASF+SDF modules. There are ASF+SDF modules that only define the concrete syntax (lexical and context-free syntax) of a language and without ASF equations. The concrete syntax is always exported. There are also ASF+SDF modules that define the signature of functions defined in the ASF part. These functions can be either exported or hidden. The ASF equations are first-order conditional rewrite rules. These rewrite rules are evaluated using a leftmost innermost rewriting technique, there exists an ASF interpreter as well as an ASF compiler [78]. Each module is created by adding a new module with the form (module-name.sdf) , which defines its syntax part. The equation part of this module, is defined by adding another module that has the form (module-name.asf). The implementation of any module can be edited by selecting it from the module set 97
Chapter 5. RDR Implementation that defines the desired language. Figure 5.1 shows the module (Pico.sdf) which represents the syntax part of a type-checker for a toy language called Pico, and its corresponding ASF module (Pico.asf) for representing the equation part, where both of them are selected from the module set that defines Pico language. When editing the ASF+SDF specification of the language definition in the created module, two editors are created, one for editing the SDF part of the module (GSE1) (Generic syntax directed editor1), while the other one for editing its equation part (GSE2). The formalism ASF+SDF has an interactive development environment, called the ASF+SDF Meta-environment [42, 41]. It is a toolset, in which domain specific languages definitions can be constructed (given their formal specifications in ASF+SDF formalism ), edited, checked and compiled just like programs. In addition any modifications in the language definition will be translated immediately to a modification in the programming environment generated automatically for it A domain specific language is defined in ASF+SDF meta environment by a set of modules, where each one can be imported in the others. The global organization of the meta environment consists of the set of modules (M1,...,Mn) that defines the desired language and the programming environment generator. The programming environment generator of Meta-environment has three components:The module manager (MM) that manages the import relation between all modules included in the the global implementation and tracks each module definition and its rules usage. The syntax manager (SM) that manages the syntactical change to the definition of each module, including the lexical and context-free functions, declaration of priories and variable definition in addition to updating the scanner and parser derived from all modules (updating with syntax changes and hence 98
5.3. ASF+SDF Language Specification Formalism
(a) Pico.sdf module
(b) Pico.asf module
Figure 5.1: The Syntax and equation part of Pico type-checker module 99
Chapter 5. RDR Implementation grammar changes, as both of the generated scanner and parser accept the grammar specified in SDF). Finally the equation manager(EQM) manages the equations of each module and the rewrite rules that have been derived from them. Figure 5.2(partially taken from [41]) shows an example that applies this organization of different components of the programming environment generator.
Figure 5.2: ASF+SDF meta environment global organization
In this example, the modular generator passes all information related to the syntactic issues in each module to the syntax manager which saves two global sets of rules: lexical and context free rules. On the other hand, the modular manager passes all information related to equations to the equation manager, which saves the rewrite rules derived from this equations. Most of the operations of the modular managers depends on the corresponding operations of the syntax and equation manager. For example, when the modular manager selects a module from the modular structure of the language definition as the current module, this means the following for the syntax manager: determining the current grammar of this module and thus the corresponding 100
5.4. Implementation parts of the generated scanner an parser that accepts this grammar, while means the following for the equation manager: determining the current equations of the selected module and the corresponding compiled term-rewriting system (a part of ASF+SDF rewrite rule compiler) that uses the rewrite rules derived from those equations. The ASF+SDF meta environment is very useful tool for users who has no pre-knowledge about the effect of editing their language definition on their language implementation. In addition, since the parse generator is completely invisible to the users of the meta environment, the tool is very suitable to users who have no experience about scanners and parser generators. There is a considerable library of datatypes and build-in languages that comes with the Meta-environment and can be reused in the definition and implementation of other domain specific languages in ASF+SDF Metaenvironment.
5.4
Implementation
The language specification formalism ASF+SDF [20] has been used for developing a prototype of an evaluator for the RDR language. An important reason for this choice is the more or less one-to-one mapping of the operational semantics rules (including both regular and error semantics) to ASF equations. Another reason for choosing the formalism ASF+SDF is its interactive development environment, the ASF+SDF Meta-Environment [42, 41], which allows the interactive development of specifications, next to interpreting, debugging and compiling of specifications. The RDR prototype evaluator is implemented by 41 ASF equations, 20 of them represent the regular semantics rules of RDR and the remaining 101
Chapter 5. RDR Implementation equations represent the error semantics deduction rules of RDR. In addition to functions such as those that compute the value, static label, dynamic label and information flow of expressions. The evaluator of RDR is implemented in 19 SDF and 14 ASF modules in addition to ASF+SDF library modules. Appendix A presents the SDF definitions of the evaluator modules, while appendix B presents the ASF equations of the evaluator modules. The task of RDR prototype evaluator is to reduce a program written in the language syntax to its generated output if no insecure information flow is encountered. This implementation is handled in different steps as it will be introduced in the next subsections. The first step in implementation was to translate the BNF grammar given in Figure 3.1 into an SDF definition. This translation is rather straightforward as it will be discussed in 5.4.1. Per RDR language construct, assignment, conditional, loop, etc., a separate ASF+SDF module is created, consisting of an import section importing the SDF module containing the RDR syntax definition, a function definition of the form ev-body(Body,,PC) ->Result, a collection of typed variables used in the ASF equation, and the ASF equations. The translation of the SOS rules into ASF equations is discussed in Section 5.4.3. The individual ASF+SDF modules are imported in one main module evaluator, see Section 5.4.4 for more details. Figure 5.3 shows the different ASF+SDF modules (including the ASF+SDF library modules) used in implementation of this evaluator and their import structure.
5.4.1
Language Definition
RDR is summarized as follows: 1. A program in the presented language consists of a set of variable declarations and statements. 102
5.4. Implementation
Figure 5.3: Import structure of RDR evaluator
103
Chapter 5. RDR Implementation 2. The type of each variable is a composite type that consists of a normal data type (Integer, String, Boolean) and security type specified by a security label. The label consists of zero or more policies. Each policy is specified by an owner principal of that variable and a two sets of principals that states who is allowed to read from that variable and who is allowed to write to that variable. 3. Statements in the presented language are assignment, if-else-then, whiledo, delegation and revocation . 4. Expressions may contains integers, strings, boolean, variables, addition (+), substraction(-), multiplication(*), division (/), concatenation (||), and (&&), and compare (==, ! =, , S Table[[Var,D]]->Dl Table[[Var,Set[[Var]]]]->I 105
Chapter 5. RDR Implementation
context-free syntax %% Definition of program Body -> Program (VarDecl | Statement)* -> Body %% Definition of type "Integer"-> Type "String"-> Type "Boolean"-> Type %% Definition of policy Principal ":" {("!"? Principal)","}*-> Policy %% Definition of label {Policy";"}*-> Label %% Definition of SecType "(" Type "," Label ")" -> SecType %% Definition of VarDecl Var ":" SecType"=" Value ";" -> VarDecl %% Definition of Statement Var ":=" EXP ";"-> Statement "if" EXP "then" "{" Body "}" "else" "{" Body"}" -> Statement "while" EXP "do" "{" Body"}" -> Statement Principal "delegates" Var RWOP Chain ";" -> Statement Principal "revokes" Var RWOP Chain ";" -> Statement "(""*"")"-> RWOP "(""!"")"-> RWOP "(""*"",""!"")"-> RWOP %% Definition of chain {Principal "->"}* -> Chain lexical syntax %% Defintion of Principal [A-Za-z]+[0-9]* -> Principal
Figure 5.4: RDR syntax definition in SDF
106
5.4. Implementation
5.4.3
Semantics Implementation
The evaluation rule and the deduction rules which specify the semantics and error semantics respectively for each language construct (i.e., variable declaration or statement defined in RDR syntax) are implemented in a separated ASF+SDF module. The SDF part of this module imports the RDR.sdf module to take care of implementing the regular and error semantics rules of a specific language construct defined in RDR syntax. An equivalent equation for each semantics and error semantics rule is written in the ASF part of this module. ASF allows merging the implementation of the regular semantics and error semantics for each language construct in a very natural way. In the end, we have a number of ASF+SDF modules equal to the number of language constructs defined in RDR.sdf module. For example, the evaluation rule of delegation construct is implemented in the delegation module. The delegation.sdf module imports RDR.sdf to validate the usage of the delegation construct defined in RDR.sdf module in the delegation module. This construct is needed to implement its evaluation rule in addition to its error deduction rule. The semantics rule for delegation of reading permission by an owner (presented in section 3.5.7) and its corresponding equation in ASF are presented below:
x ∈ dom(v) p ∈ owner(s(x))
d0 = d ⊕ {x 7→ (dw (x), dr (x) ∪ {(p _ c, 1)})} P C v s(x) u d0 (x) i(x) v d0 (x)
P C ` hS, v, s, d0 , ii → hv 0 , s0 , d00 , i0 i P C ` hp delegates x ∗ c; S, v, s, d, ii → hv 0 , s0 , d00 , i0 i
107
Chapter 5. RDR Implementation [Delegate-read] 1
$VarList1:=listDeclaredVariables($v),
2
elem($var,$VarList1)==true,
3
$label1:=lookup($s,$var),
4
elem($princ,ext-ow($label1))==true,
5
($dw,$dr):=lookup($dl,$var),
6
$dl’:=store($dl,$var,($dw, union({(chainSeqPrinc($princ->$princ->*),1)},$dr))),
7
$label2:=dl2label($s,$dl’,$var),
8
$label3:=label($s,$dl,lookup($i,$var)),
9
$label4:=label($s,$dl,$pc),
10
LessRestrictive($label4,meet($label1,$label2))==true,
11
LessRestrictive($label3,$label2)==true,
12
====>
13
ev-body($princ delegates $var(*)$princ->* ; $body,,$pc)=
14
ev-body($body,,$pc)
As shown in the equation above, line 1 and 2 check that variable x presented by var belongs to the list of declared variables VarList1. This matches the condition x ∈ dom(v) in the first premise of the corresponding semantics rule. In line 3, the static label of the delegated variable is picked up, which is presented by a security label label1. Line 4 checks that the delegator of the variable is one of its owners. This matches the condition p ∈ owner(s(x)) in the semantics rule. The dynamic label of the delegated variable is picked up in line 5. It is presented by a pair of two delegation chains. The first one is the write delegation chain dw, while the second one is read delegation chain dr. The dynamic label of the delegated variable is updated in line 6. This matches the second premise of the corresponding semantics rule. In line 7, we compute the security label induced from the dynamic label of the 108
5.4. Implementation delegated variable using the function dl2label. This function takes the static label, dynamic label and the delegated variable as its arguments and returns a security label (presented by the owner delegator and those principals that have actually been granted the right to read/ write by means of delegation). The signature of this function is specified as follows: dl2label(S,Dl,Var)-> Label In line 8 and 9 we pick up the current security labels of information flow i and program counter P C respectively using the function label. This function takes the static label, dynamic label and the set of variables that represents the information flow i or the program counter P C as arguments and returns the security label of information flow or program counter. The signature of this function is specified as follows: label(S,Dl,Set[[Var]])-> Label Line 10, 11, the two security conditions P C v s(x)ud0 (x) and l(i(x)) v d0 (x) in the third premise of the corresponding semantics rule are evaluated. This is done using the function LessRestrictive. This function takes two security labels as its arguments and returns Boolean that states whether the relation v is satisfied or not. The signature of this function is specified as follows: LessRestrictive(Label,Label)-> Boolean In line 14 we evaluate the continuation . This done using the function evbody which will be described in the next section. This matches the transition step P C ` hS, v, s, d0 , ii → hv 0 , s0 , d00 , i0 i presented in the last premise of the corresponding semantics rule. In line 13, we evaluate the conclusion of this semantic rule. 109
Chapter 5. RDR Implementation Similarly, the first error semantics rule for delegation of reading permission by an owner presented in section 4.1.5 and its corresponding equation in ASF is presented below. This deduction rule raises an error message to indicate that the delegated variable is not declared.
x∈ / dom(v) P C ` hp delegates x ∗ c; S, v, s, d, ii ⇓ error(variable x is not declared )
[error-Delegate-read-1] 1 $VarList1:=listDeclaredVariables($v), 2 elem($var,$VarList1)==false 3 ====> 4 ev-body($princ delegates $var(*) $chain ; $body,,$pc)= 5 The variable $var is not declared
Moreover, the third error semantics rule for delegation of reading permission by an owner presented in section 4.1.5 and its corresponding equation in ASF are presented below. This deduction rule raises an error message to indicate that there is an insecure information flow due to unsatisfying the second condition in the third premise of the evaluation rule of reading permission by an owner.
x ∈ dom(v) p ∈ owner(s(x))
d0 = d ⊕ {x 7→ (dw ∪ {(c, 0)}, dr (x))} P C v s(x) u d0 (x) i(x) 6v d0 (x) P C ` hp delegates x ∗ c; S, v, s, d, ii ⇓ error(Disallowed information flow with delegation ) 110
5.4. Implementation [error-Delegate-read-3] 1
$VarList1:=listDeclaredVariables($v),
2
elem($var,$VarList1)==true,
3
$label1:=lookup($s,$var),
4
elem($princ,ext-ow($label1))==true,
5
$d:=lookup($dl,$var),
6
($dw,$dr):=$d,
7
$dl’:=store($dl,$var,($dw, union({(chainSeqPrinc($princ->$princ->*),2)},$dr))),
8
$label2:=dl2label($s,$dl’,$var),
8
$label3:=label($s,$dl,lookup($i,$var)),
10
$label4:=label($s,$dl,$pc),
11
LessRestrictive($label4,meet($label1,$label2))==true,
12
LessRestrictive($label3,$label2)==false
13
====>
14
ev-body($princ delegates $var(*) $princ->*; $body,,$pc)=
15
Disallowed information flow with delegation
Figure 5.5 presents the definition of the variables used in the equations [Delegate-read], [error-Delegate-read-1] and [error-Delegate-read-3] in SDF.
5.4.4
Evaluator Implementation
The functionality of the prototype evaluator of RDR is implemented in the evaluator module. The main purpose of this module is to implement the evaluator function that reduces each program written in RDR syntax to the output it generates. The SDF part of this module ( evaluator.sdf) imports the ASF+SDF modules that implement the evaluation rules and the error deduction rules of different RDR constructs (as mentioned before). The evaluator function evaluate is defined in the module evaluator.sdf, where it 111
Chapter 5. RDR Implementation variables "$var"[0-9]*->Var "$exp"[0-9]*->EXP "$label"[0-9]*->Label "$body"[0-9]*->(VarDecl | Statement)* "$pc"[0-9\’]*->Set[[Var]] "$princ"[0-9\’]*->Principal "$dr"[0-9]*->Set[["("List[[Principal]]","Integer")"]] "$dw"[0-9]*->Set[["("List[[Principal]]","Integer")"]] "$VarList"[0-9]*->Set[[Var]] "$s"[0-9\’]*->S "$dl"[0-9\’]*->Dl "$v"[0-9\’]*->V "$i"[0-9\’]*->I
Figure 5.5: Definition of variables used in [Delegate-read], [error-Delegateread-1] and and [error-Delegate-read-3] equations in SDF. takes RDR program as its argument and returns the result of evaluation as shown below: "evaluate"(Program)->Result The equations that implement this function are written in evaluator.asf module. One of those ASF equations looks like: $result:=ev-body($body,,{}) ====> evaluate($body)=$result The result of evaluation can be one of two: The resulting environment specified by the target of the transition from a certain environment in the evaluation rule (i.e., certain valuations, static label, dynamic label and information flow). An error message raised due to unsatisfying a certain condition specified in the premises of each evaluation rule. This is specified in Result module. A part of the SDF part of this module looks like: 112
5.5. Motivating examples (|ErrorMessage)->Result "ev-body"(Body,,PC)->Result
Note that the function ev-body specifies the transition state of the program from a certain environment to the resulting environment specified by the transition step. The ASF equation that implements this function looks like the following:
[Ev-body1] ev-body(,,$pc)=
When the body of a program is evaluated under a certain environment the output will be the resulting environment specified by the target of the transition.
5.5
Motivating examples
The program is reduced as a term in ASF+SDF Meta Environment. When evaluating a program, each of its constructs should be visited one by one and its effect on the output result is computed. To show the applicability of RDR in practice, several examples are written in its syntax and evaluated using the implemented evaluator in ASF+SDF environment. Following, are three examples of programs written in RDR syntax and reduced as terms in Meta-environment to their outputs using the presented evaluator. In those examples, various language constructs are used with more focusing on delegation, assignment and conditional constructs and their effects on information flow during program execution. 113
Chapter 5. RDR Implementation
5.5.1
Delegation example
This program specifies the informal explanation of Example 1 introduced in chapter 3 in language syntax. The focus of this example is on showing the delegation effect on information flow and specifying when the delegation is allowed and prevented according to the semantics of the presented language. The program is evaluated using the function evaluate implemented in the evaluator module as shown below: 1
evaluate(history : (Integer, patient:)=0 ;
2
patient delegates history(*) phys1;
3
obs1 : (Integer, phys1:patient)=0;
4
history := history + obs1;
5
patient delegates history(*) phys1 -> phys2;
6
phys1 delegates history(*) phys2;
7
obs2 : (Integer, phys2:patient)=0;
8
history := history + obs2;
9
%%phys2
delegates history(*) phys3;
10) After reducing this program as a term in ASF+SDF meta environment using evaluate function, the output is shown below: This output shows the final value for valuations, static label, dynamic label, and information flow of each variable respectively. If the comment is 114
5.5. Motivating examples removed from line 9 and program is reduced again using evaluate function, the following run-time error message will appear. The delegation is not allowed without a permission from the owner This error message is due to delegation to a principal (.i.e phys3) not specified in the chain of principal that was specified by the owner delegator as mentioned in subsection 4.1.5.
5.5.2
Assignment example
The focus of this example is on showing the explicit flow in an assignment. Such flow is prevented according to the operational semantics of RDR. The example presents a simple program that adds two variables and assign the result to another variable. The explicit flow in this example is induced because the left hand side of the assignment is not less restrictive than the right hand side of this assignment. The program is evaluated using the function evaluate implemented in the evaluator module as shown below: 1
evaluate(x : (Integer, Alice:Bob)=5 ;
2
y : (Integer, Bob:Alice)=6;
3
z : (Integer, Alice:Bob)=0;
4
z := x + y;
5
) After reducing this program as a term in ASF+SDF Meta-environment
using the evaluator function, the output is shown below: 115
Chapter 5. RDR Implementation This output shows the final value for valuations, static label, dynamic label, and information flow of each variable respectively. If the static label of z is relaxed more by adding Carol as reader of z and the program is reduced again using evaluate function, this will lead to the following run-time error. Disallowed information flow in z:=x+y This error message is raised at line 4 due to assigning the result of adding x and y to z. The reason is that the security label of z is not less restrictive than the label of x+y (i.e., the join of the security labels of x and y). Such kind of explicit flow is prevented by security condition presented in the second premise of the evaluation rule of assignment as introduced in section 3.5.4.
5.5.3
If-else-then example
The focus of this example is on showing the implicit flow due to an assignment in the body of if-then-else that is prevented according to the secure semantics of RDR. The program is evaluated using the function evaluate implemented in the evaluator module as shown below: 1
evaluate(a : (Integer, Alice:)=1 ;
2
b : (Integer,Bob: Alice )=0 ;
3
if(a!=0) then
4
{b:=1;}
5
else
6
{b:=2;})
After reducing this program as a term in ASF+SDF Meta-environment using the evaluate function, the following run-time error message will appear: Disallowed information flow in b:=1; 116
5.7. Language extension This error message is raised at line 4 due to assigning 1 to the variable b as this assignment is depending on the value of a (where a 6v b) which is considered a kind of implicit information flow prevented by the secure semantics.
5.6
Performance evaluation
The performance of RDR evaluator in checking information flow security is evaluated with the motivating examples introduced the previous section. This performance evaluation is done by measuring the execution-time in two cases: First when including security conditions in the semantics of RDR and the second case when excluding these conditions. The measurements were performed on intel Pentium (R) Dual-Core CPU (2.00GHz) with 3GB of memory running Lunix. The compilation time for the evaluator equations when the security conditions for checking information flow is included is 0.125s, while when those conditions are excluded is 0.110s. The results presented in table 5.1 shows that the execution time of each program is not affected too much when adding the security conditions to RDR semantics. This means that the presented evaluator is an efficient tool in evaluating information flow security. In addition, the results show that ASF+SDF language specification formalism does not consume too much time in reducing each program to its final output when checking information flow security. This means that ASF+SDF is an efficient tool for designing and implementing security typed programming languages. 117
Chapter 5. RDR Implementation Table 5.1: Execution time for the evaluation of some RDR terms Example Semantics characteristics 1 Assignment 2 Delegation 3 Conditional
5.7
Execution time without security checks real 0m0.142s real 0m0.161s real 0m0.172s
Execution time with security checks real 0m0.211s real 0m0.235s real 0m0.322s
Language extension
There are many directions to extend RDR language. First it can be extended to support run-time principals mechanism in order to make the information flow polices enforced by the program depend on the principals that currently interact with the system [57]. Second, RDR can be extended with a new construct that checks at run-time the eligibility of information flow before updating a certain variable like the one introduced in [7, 79]. As for implementation, currently RDR is implemented by a big-step evaluator. Implementing a type-checker for RDR can be also taken into account. It will help the programmer to write correct and safe programs. In addition, it will be more feasible to extend the implementation by integrating RDR with other general-purpose programming languages in order to make RDR available for practice. This can be achieved by implementing a compiler that translates this language to a common programming language. Such a compiler should be implemented in a way that takes into account the gap between the semantics of the source and targets language [80], specially those that are related to preventing insecure information flows. Finally, the C code produced by ASF+SDF compiler after evaluating each RDR program is a safe code (as it is checked against insecure information flow during program execution). 118
5.8. Summary Such code can be reused to write a secure application [81]. For example, it can be converted to a Common Gateway Interface (CGI) scripts in order to use RDR in developing secure web applications.
5.8
Summary
This chapter investigates the methodology of implementing RDR. First it states briefly the existing implementations in language based information flow security with more focusing on the common approaches for implementing security typed programming languages. Second, it gives a brief overview of ASF+SDF language specification formalism and its different purposes of usage. Third, it describes how it can be used to implement an evaluator for RDR. This is done by presenting the different implementation phases. Finally, it shows the applicability of this implementation in practice by evaluating several examples written in RDR syntax to their final states.
119
Chapter 6 Conclusions and future work 6.1
Conclusions
Recently, security-typed programming languages has been used as a promising new approach to enforce information flow security policies. In this thesis, the concept of restricted delegation and revocation has been accommodated in such languages, where by one can predefine a chain of entities (i.e., principals) to which the information may flow and later revoke the allowed flows. This has been done by introducing a new security typed programming language RDR, a language for restricted delegation and revocation. The syntax of this language and its operational semantics have been introduced. The error semantics rules of this language has been defined by utilizing the dynamic flow analysis approach and enriching it with control-flow-sensitive checks borrowed from static approach. These rules provide error messages that describe the forbidden executions of the program which may result in (possibly implicit) information leakage to unauthorized users. Such messages are meant for programmers (or system administrators) to detect possible security-breaches in the developed (deployed) programs. To show the appli120
6.1. Conclusions cability of RDR in practice, a prototype of an evaluator for RDR has been developed in the algebraic specification formalism ASD+SDF and several example written in RDR syntax have been evaluated by this evaluator. The operational and the error semantics of RDR are both implemented in this evaluator in the ASF+SDF Meta-environment, the interactive development environment of ASF+SDF formalism. The ASF+SDF Meta-environment allows to translate the formal semantics literally into the rules of the evaluator and also modularly combine the operational semantics with the error semantics without any influence on either of the two. This thesis has the following contributions: 1. It uses language based information flow security to design a new security typed programming language RDR that supports restricted delegation and revocation between principals in the application program. 2. It combines the static and runtime approaches to enforce information flow security policy in the application program. The former is achieved using a security label that annotates each declared variable to specify its initial security level, while the latter is achieved using a dynamic label that tracks the change in the initial security level of the variable during the program execution due to delegation and revocation. 3. It defines the error semantics of RDR, by exploiting the dynamic analysis approach and enriching it with control-flow-sensitive checks borrowed from static checks. The error semantics are deduction rules which specify the error messages raised when undeclared variables are used or insecure information flow is encountered during program execution. 4. It presents a prototype of an evaluator for RDR, where the formal semantics or RDR are translated literally into the rules of this evaluator. 121
Chapter 6. Conclusions and future work This evaluator has been developed using ASF+ASF algebraic specification formalism. The applicability of the RDR language in practice has been shown by evaluating several examples written in its syntax using this evaluator.
6.2
Future work
The future work is summarized as follows: 1. Deriving a type system for RDR and a proof of its soundness. The typesystem that verifies program at compile time (i.e., before its execution) for the absence of insecure information-flow. The type system of RDR can be used to check a program against a given (user) policy to ensure that a program will not reveal information more than allowed by its given policy. 2. A proof that the emission of error messages in the error semantics of RDR does not cause any further information flows is needed. 3. Investigating the general policies which can be interpreted (i.e. which information flow do they allow) independent from programs. 4. Extending the delegation and revocation model presented by RDR language to cover the different forms of delegation constraints introduced in access control policy models studied in chapter 2 of this thesis. For example, the delegation relation in RDR can be extended to cover the transferring of delegation existing in some access control models [51],[5]. In addition, the delegation can be restricted based on time duration. 5. The problem of delegation cycle is not addressed in RDR. For example, if a principle Alice delegates to Bob, who further delegates to Clark, 122
who delegates again to Alice. The semantics of the delegation construct should be edited to prevent such situation to occur. 6. Extending RDR to support restricted delegation and revocation between runtime principals instead of static or predefined principals [57]. 7. Extending the RDR language with a new construct that checks the eligibility of flow before updating variables through assignment. 8. For extending language implementation there are two directions: First a typechecker RDR can be implemented by writing equations for RDR types system in ASF. This typechecker can help the programmer to write correct and safe programs at compile time. Second RDR can be translated as a domain specific language to general purpose programming languages such as those that are suitable to develop web applications [21],[22]. This will increase the feasibility of this language to be used in real applications. To achieve this, a compiler that takes the presented language as its source can be implemented.
123
Bibliography [1] Steve Zdancewic. Challenges for information-flow security. In In Proceedings of the 1st International Workshop on the Programming Language Interference and Dependence (PLID’04), 2004. [2] Christian Hang Chung-Hung Tsai D. T. Lee Yao-Wen Huang, Fang Yu and Sy-Yen Kuo. Securing web application code by static analysis and runtime protection. In Proceedings of the 13th international conference on World Wide Web, volume 5156/2008, pages 40 – 52. ACM New York, NY, USA, 2004. [3] Andrew C. Myers. JFlow: Practical mostly-static information flow control. In Proceedings of the ACM Symposium On Principles of Programming Languages (POPL’99), pages 228–241. ACM Press, 1999. [4] Stephen Chong, Andrew C. Myers, K. Vikram, and Lantian Zheng. Jif reference manual, 2006. Available via: http://www.cs.cornell.edu/ jif/doc/jif-3.3.1/manual.html. [5] Jacques Wainer, Akhil Kumar, and Paulo Barthelmess. DW-RBAC: A formal security model of delegation and revocation in workflow systems. Information system Journal, 32:365–384, 2007. [6] Anindya Banerjee and David A.Naumann. Stack-based access control and secure information flow. Journal of Functional Programming, 15:131–177, 2005. [7] G´erard Boudol. Secure information flow as a safety property. In Proceedings of the 5th International Workshop in formal aspects in information security and trust (FAST’08), volume 5491 of Lecture Notes in Computer Science, pages 20–34. Springer, 2008. [8] Niklas Broberg and David Sands. Flow locks – towards a core calculus for dynamic flow policies. In Proceedings of THE 15th European Sym124
posium on Programming (ESOP06), pages 180–196. Springer-Verlag, March 2006. [9] Peng Li, Yun Mao, and Steve Zdancewic. Information integrity policies. In In Proceedings of the Workshop on Formal Aspects in Security and Trust (FAST), 2003. [10] Steve Zdancewic and Andrew C. Myers. Robust declassification. In Proceedings of the 14th IEEE Computer Security Foundations Workshop (CSFW’0), page 1523. IEEE Computer Society Washington, DC, USA, 2001. [11] Andrew C. Myers, Andrei Sabelfeld, and Steve Zdancewic. Enforcing robust declassification. Journal of Computer Security, 14(2):157 – 196, 2006. [12] Andrei Sabelfeld and Andrew C. Myers. Language-based informationflow security. IEEE Journal on Selected Areas in Communications, 21(1):5– 19, 2003. [13] Andrei Sabelfeld and Andrew C. Myers. A model for delimited information release. In In Proceedings of International Symposium on Software Security, Tokyo, Japan, volume 3233/2004, pages 174–191. Springer Berlin / Heidelberg, 2004. [14] Aslan Askarov and Andrei Sabelfeld. Tight enforcement of informationrelease policies for dynamic languages. In Proceedings of the 2009 22nd IEEE Computer Security Foundations Symposium, pages 43–59. IEEE Computer Society Washington, DC, USA, 2009. [15] Michael Hicks, Stephen Tse, Boniface Hicks, and Steve Zdancewic. Dynamic updating of information-flow policies. In Proceedings of the International Workshop on Foundations of Computer Security (FCS), June 2005. [16] Nikhil Swamy, Michael Hicks, Stephen Tse, and Steve Zdancewic. Managing policy updates in security-typed languages. In Proceedings of the 19th IEEE Computer Security Foundations Workshop (CSFW’06)., pages 202 – 216. IEEE Computer Society Washington, DC, USA, 2006. [17] Vincent Simonet. The flow caml system documentation and users manual, 2003. Available via: http://www.normalesup.org/~simonet/ soft/flowcaml/flowcaml-manual.pdf. 125
[18] Nikhil Swamy, Brian Corcoran, and Michael Hicks. Fable: A language for enforcing user-defined security policies. In Proceedings of the IEEE Symposium on Security and Privacy (Oakland), pages 369 – 383, 2008. [19] Limin Jia and Steve Zdancewic. Encoding information flow in aura. In In Proceedings of PLAS 2009, Dublin, Ireland, June 15, 2009. ACM New York, NY, USA, 2009. [20] Mark van den Brand, Paul Klint, and Jurgen Vinju. The language specification formalism asf+sdf, 2008. Available via: http://www.meta-environment.org/doc/books/ /extraction-transformation/asfsdf/asfsdf.pdf. [21] Danny M. Groenewegen, Zef Hemel, Lennart C. L. Kats, and Eelco Visser. Webdsl: A domain-specific language for dynamicweb applications. In Conference on Object Oriented Programming Systems Languages and Applications archive (OOPSLA08). Companion to the 23rd ACM SIGPLAN conference on Object-oriented programming systems languages and applications, pages 779–780. ACM New York, NY, USA, 2008. [22] Eelco Visser. Webdsl: A case study in domain-specific language engineering. In In Generative and Transformational Techniques in Software Engineering (GTTSE 2007), volume 5235/2008. Springer Berlin / Heidelberg, 2008. [23] J.A. Goguen and J. Meseguer. Security policies and security models. In In Proceedings of the 1982 Symposium on Security and Privacy, pages 11– 20, New York, NY, USA, 26-April 28 1982. IEEE Press. [24] Pierangela Samarati and De Capitani Di VimercatI. Access control: Policies, models, and mechanisms. In Riccardo Focardi and Roberto Gorrieri, editors, the IFIP WG 1.7 International School on Foundations of Security Analysis and Design on Foundations of Security Analysis and Design, volume 2171 of Lecture Notes in Computer Science, pages 137 – 196. Springer-Verlag London, UK, 2000. [25] Ramesh V. Peri and William A. Wulf. Formal specification of information flow security policies and their enforcement in security critical systems. In Proceedings of Computer Security Foundations Workshop VIICSFW 7., pages 118–125, 1994. 126
[26] Lee Badger, Daniel F. Sterne, David L. Sherman, Kenneth M. Walker, and Sheila A. Haghighat. A domain and type enforcement unix prototype. In the Fifth USENIX UNIX Security Symposium., volume 5. USENIX Association Berkeley, CA, USA, 1995. [27] Peter Loscocco and Stephen Smalley. Integrating flexible support for security policies into the linux operating systeme. In Proceedings of the FREENIX Track: 2001 USENIX Annual Technical Conference ., pages 29–42. USENIX Association Berkeley, CA, USA, 2001. [28] Umesh Shankar, Kunal Talwar, Jeffrey S. Foster, and David Wagner. Detecting format string vulnerabilities with type qualifiers. In Proceedings of the 10th conference on USENIX Security Symposium ., volume 10, pages 201–218. USENIX Association Berkeley, CA, USA, 2001. [29] Zhendong Su and Gary Wassermann. The essence of command injection attacks in web applications. In the 33rd ACM SIGPLAN-SIGACT symposium on Principles of programming languages ., pages 372 – 382. ACM New York, NY, USA, 2006. [30] Dan Ragle. Introduction to perl’s taint mode, May 2006. Available via: http://www.webreference.com/programming/perl/taint/. [31] James Cheney, Amal Ahmed, and Umut Acar. Provenance as dependency analysis. In Symposium on Database Programming Languages., 2007. [32] Cdric Fournet and Andrew D. Gordon . Stack inspection: theory and variants. In Proceedings of the 29th ACM SIGPLAN-SIGACT symposium on Principles of programming languages ., pages 307–318. ACM New York, NY, USA, 2002. [33] David Walker. A type system for expressive security policies. In Proceedings of the 27th ACM SIGPLAN-SIGACT symposium on Principles of programming languages ., pages 254–267. ACM New York, NY, USA, 2000. [34] Dorothy E. Denning. A lattice model of secure information flow. Communications of the ACM, 19(5):236 – 243, 1976. [35] Eric Poblenz. Language-based approaches to secure information flow. Technical report, 2004. 127
[36] Paritosh Shroff, Scott F. Smith, and Mark Thober. Securing information flow via dynamic capture of dependencies *. Journal of Computer Security, 16:673–688, 2008. [37] Stephan Zdancewic. Programming languages for information security. PhD thesis, Cornell University, Ithaca, NY, USA, 2002. [38] Franois Pottier and Vincent Simonet. Information flow inference for ml. In Proceedings of the 29th ACM Symposium on Principles of Programming Languages (POPL’02), pages 319–330. ACM New York, NY, USA, 2002. [39] Sruthi Bandhakavi, William Winsborough, and Marianne Winslett. A trust management approach for flexible policy management in securitytyped languages. In Proceedings of the 2008 21st IEEE Computer Security Foundations Symposium, pages 33–47. IEEE Computer Society Washington, DC, USA, 2008. [40] Niklas Broberg and David Sands. Paralocks: role-based information flow control and beyond. ACM SIGPLAN Notices, 45(1):431–444, January 2010. [41] Paul Klint. A meta-environment for generating programming environments. ACM Trans. Softw. Eng. Methodol., 2(2):176–201, 1993. [42] Mark G. J. van den Brand, Arie van Deursen, Jan Heering, H. A. de Jong, Merijn de Jonge, Tobias Kuipers, Paul Klint, Leon Moonen, Pieter A. Olivier, Jeroen Scheerder, Jurgen J. Vinju, Eelco Visser, and Joost Visser. The ASF+SDF meta-environment: A component-based language development environment. In Proceedings of the 10th International Conference on Compiler Construction, CC ’01, pages 365–370, London, UK, 2001. Springer-Verlag. [43] Ezedin Barka and Ravi Sandhu. A role-based delegation model and some extensions. In Proceedings of the 23rd National Information Systems Security Conference (NISSC00), Baltimore,MD, October 2000, October 2000. [44] Ravi S. Sandhu, Edward J. Coynek, Hal L. Feinsteink, and Charles E. Youmank. Role-based access control models. IEEE Computer, 29(2):38– 47, February 1996. [45] Ezedin Barka and Ravi Sandhu. Role-based delegation model/ hierarchical roles (rbdm1). In Proceedings of the 20th Annual Computer Security 128
Applications Conference (ACSAC04), pages 396 – 404. IEEE Computer Society Washington, DC, USA, 2004. [46] Longhua Zhang, Gail-Joon Ahn, and Bei-Tseng Chu. A rule-based framework for role based delegation. In Proceedings of the sixth ACM symposium on Access control models and technologies, pages 153 – 162. ACM New York, NY, USA, 2001. [47] Ravi Sandhu, Venkata Bhamidipati, and Qamar Munawer. The arbac97 model for role-based administration of roles. ACM Transactions on Information and System Security (TISSEC), 2(1):105 – 135, February 1999. [48] Longhua Zhang, Gail-Joon Ahn, and Bei-Tseng Chu. A rule-based framework for role based delegation and revocation. ACM Transactions on Information and System Security (TISSEC), 6(3):404 – 441, February 2003. [49] Xinwen Zhang, Sejong Oh, and Ravi Sandhu. Pbdm: A flexible delegation model in rbac. In Proceedings of the eighth ACM symposium on Access control models and technologies, pages 149 – 157. ACM New York, NY, USA, 2003. [50] Chunxiao Ye, Zhongfu Wu, and Yunqing Fu. An attribute-based delegation model and its extension. Journal of Research and Practice in Information Technology, 38(1), February 2006. [51] Jason Crampton and Hemanth Khambhammettu. Delegation in rolebased access control. In Proceedings of 11th European Symposium On Research In Computer Security (ESORICS 2006,), Hamburg, Germany, volume 4189/2006, pages 174–191. Springer Berlin / Heidelberg, September 18 20 2006. [52] Organization based access control. In 4th IEEE International Workshop on Policies for Distributed Systems and Networks (POLICY 2003), 4-6 June 2003, Lake Como, Italy, page 120. IEEE Computer Society Washington, DC, USA, 2003. [53] Meriam Ben Ghorbel-talbi, Frederic Cuppens, Nora Cuppens-Boulahia, Adel Bouhoula, and GET/ENST Bretagne. Managing delegation in access control models, 2007. 129
[54] Frederic Cuppens and Alexandre Mige. Administration model for or-bac. International Journal of Computer Science and Engineering(CSSE), 19:754–768, 2004. [55] Yonghe Wei and Qilin Shu. A delegation-based workflow access control model. In Proceedings of the First International Symposium on Data, Privacy, and E-Commerce (ISDPE 2007)., pages 478–483. IEEE Computer Society Washington, DC, USA, 2007. [56] Ana Almeida Matos and Gerard Boudol. On declassification and the non-disclosure policy. In Proceedings of the 18th IEEE Computer Security Foundations Workshop (CSFW05)., pages 226 – 240. IEEE Computer Society Washington, DC, USA, 2005. [57] Stephen Tse and Steve Zdancewic. Run-time principals in informationflow type systems. ACM Transaction on Programming Languages and Systems, 30(1), 2007. [58] Andrew C. Myers and Barbara Liskov. Protecting privacy using the decentralized label model. ACM Transactions on Software Engineering and Methodology (TOSEM), 9:410 – 442, 2000. [59] Ninghui Li, John C. Mitchell, and William H. Winsborough. Design of a role-based trust-management framework. In Proceedings of the 2002 IEEE Symposium on Security and Privacy, pages 114–130. IEEE Computer Society Washington, DC, USA, 2002. [60] D. Hassan, M.R. Mousavi, and M.A. Reniers. Restricted delegation and revocation in language-based security (position paper). In In Proceedings of PLAS 2010, Toronto, Canada, June, 2010. ACM Pressg, 2010. [61] Doaa Hassan and MohammadReza Mousavi. RDR: A language for restricted delegation and revocation. Technical report, 2011. Available via: http://www.win.tue.nl/~mousavi/rdr-tech-rep.pdf. [62] Natural semantics. In 4th Annual Symposium on Theoretical Aspects of Computer Sciences on STACS 87, volume 247 of Lecture Notes in Computer Science, pages 22–39. Springer, 1987. [63] David Molnar, Matt Piotrowski, David Schultz, and David Wagner. The program counter security model: Automatic detection and removal of control-flow side channel attacks. In Information Security and Cryptology - ICISC 2005, 8th International Conference, Seoul, Korea, December 1-2, 2005, Revised Selected Papers, 2005. 130
[64] Andrew C. Myers Stephen Chong. Security policies for downgrading. In Proceedings of the 11th ACM Conference on Computer and Communications Security (CCS), page 189209. ACM New York, NY, USA, 2004. [65] J. M. Spivey. The Z notation: a reference manual. Prentice Hall International (UK) Ltd., Hertfordshire, UK, UK, 1992. [66] Paritosh Shroff, Scott F. Smith, and Mark Thober. Securing information flow via dynamic capture of dependencies. Journal of Computer Security, 16:673–688, 2008. [67] Paritosh Shroff, Scott Smith, and Mark Thober. Dynamic dependency monitoring to secure information flow. In Proceedings of the 20th IEEE Computer Security Foundations Symposium, pages 203–217, Washington, DC, USA, 2007. IEEE Computer Society. [68] Thomas H. Austin and Cormac Flanagan. Efficient purely-dynamic information flow analysis. In Proceedings of the ACM SIGPLAN Fourth Workshop on Programming Languages and Analysis for Security, PLAS ’09, pages 113–124, New York, NY, USA, 2009. ACM. [69] Vincent Simonet and Inria Rocquencourt. Flow caml in a nutshell. In Proceedings of the first APPSEM-II workshop,Nottingham, United Kingdom., pages 152–165, March 2003 2003. [70] Brian J. Corcoran, Nikhil Swamy, and Michael Hicks. Cross-tier, labeldbased secuirty enforcement for web applications. In Proceedings of the ACM SIGMOD International Conference on Management of Data, pages 269–282. ACM New York, NY, USA, JUNE 2009. [71] Limin Jia, Jeffrey A. Vaughan, Karl Mazurak, Jianzhou Zhao, Luke Zarko, Joseph Schorr, and Steve Zdancewic. Aura: a programming language for authorization and audit. In Proceeding of the 13th ACM SIGPLAN international conference on Functional programming, pages 27–38. ACM New York, NY, USA, 2008. [72] J. Rabbe. Preventing illicit information flow in networked computer games using security annotations, 2005. [73] Vivek Haldar, Deepak Chandra, and Michael Franz. Dynamic taint propagation for java. In In Proceedings of the 21st Annual Computer Security Applications Conference, pages 303–311, 2005. 131
[74] Lantian Zheng and Andrew C. Myers. Dynamic security labels and static information flow control. Int. J. Inf. Secur., 6:67–84, March 2007. [75] Peter Mosses. Action semantics and asf+sdf. Electronic Notes in Theoretical Computer Science, 6(2), 2002. [76] A. Van Deursen, Jan Heering, and Paul Klint. Language Prototyping: An Algebraic Specification Approach, volume 5 of AMAST Series in Computing. World Scientific Publishing Company, June 1996. [77] J. Heering, P.R.H. Hendriks, P. Klint, and J. Rekers. The syntax definition formalism sdf - reference manual, November 1989. [78] Mark G. J. van den Brand, J. Heering, P. Klint, and P. A. Olivier. Compiling language definitions: the asf+sdf compiler. ACM Trans. Program. Lang. Syst., 24:334–368, July 2002. [79] Ana Almeida Matos and Gerard Boudol. On declassification and the non-disclosure policy. In Proceedings of the 18th IEEE workshop on Computer Security Foundations, pages 226–240, Washington, DC, USA, 2005. IEEE Computer Society. [80] M. F. Amstel, M. G. Brand, Z. Proti´c, and T. Verhoeff. Transforming process algebra models into uml state machines: Bridging a semantic gap? In Proceedings of the 1st international conference on Theory and Practice of Model Transformations, ICMT ’08, pages 61–75, Berlin, Heidelberg, 2008. Springer-Verlag. [81] Doaa Hassan, Sherif El-Kassas, and Ibrahim Ziedan. Developing a security typed java servlet. Journal of Information Assurance and security, 4:161–169, 2009.
132
Appendix A The SDF part of RDR-evaluator A.1
The expressions definition in SDF
module expressions imports basic/Integers imports basic/StrCon exports sorts EXP Var lexical syntax %% Definition of Variables [A-Za-z]([A-Za-z]|[0-9])* -> Var %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%In order to remove ambiguity, "true" and "false" are not considered IDENT %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% "true" -> Var {reject} "false" -> Var {reject} lexical restrictions %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %% These restrictions are added to make sure that "abc" is parsed as one %% variable and not as two variables "ab" and "c", etc. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Var -/- [A-Za-z0-9] context-free syntax %% Definition of Constant Expression Integer-> EXP StrCon->EXP BoolCon->EXP %% Definition of Variable Expression Var -> EXP
133
AppendixA. The SDF part of RDR-evaluator
%% Definition of Compare Expression EXP "==" EXP -> EXP {left} EXP "!=" EXP -> EXP {left} EXP "" EXP -> EXP {left} EXP "=" EXP -> EXP {left} %% Definition of And Expression EXP "&&" EXP -> EXP {left} %% Definition of concatenation Expression EXP "||" EXP -> EXP {left} %% Definition of Binary Expression EXP "+" EXP -> EXP {left} EXP "-" EXP -> EXP {left} EXP "*" EXP -> EXP {left} EXP "/" EXP -> EXP {left} context-free priorities %% The priorities of the operators in this module are as follows: %% "!" has the highest priority and "?" has the lowest priority "!" EXP -> EXP > {left: EXP "*" EXP -> EXP EXP "/" EXP -> EXP } >{left: EXP "+" EXP -> EXP EXP "-" EXP -> EXP }>{left: EXP "" EXP -> EXP EXP ">=" EXP -> EXP }>{left: EXP "==" EXP -> EXP EXP "!=" EXP -> EXP }>{left: EXP "&&" EXP -> EXP }>{left: EXP "||" EXP -> EXP }
A.2
The definition of StaticLabel module in SDF
module StaticLabel imports RDR imports containers/Set[Principal] imports containers/Set[("!"Principal)] exports sorts Set context-free syntax
134
A.3. The definition of DynamicLabel module in SDF
princ2w(Set[[Principal]])->Set[[("!"Principal)]] set2nonset(Set[[Principal]])->{Principal","}* setw2nonset(Set[[("!"Principal)]])->{("!"Principal)","}* topr({Principal","}*)->{("!"? Principal)","}* topw({("!"Principal)","}*)->{("!"? Principal)","}* Join(Label,Label )->Label meet(Label,Label)->Label LessRestrictive(Label,Label)->Boolean ext-ow(Label)->Set[[Principal]] owner(Policy)->Principal reader(Policy)->Set[[Principal]] writer(Policy)->Set[[("!"Principal)]] subsetr(Set[[Principal]],Set[[Principal]])->Boolean subsetw(Set[[("!"Principal)]],Set[[("!"Principal)]])->Boolean hiddens context-free start-symbols Set[[Principal]] Label exports variables "$prs"[0-9]*->{("!"? Principal)","}* "$principal*"[0-9\’]*->{Principal","}* "$policy*"[0-9]*->{Policy";"}* "$policy"[0-9]*->Policy "$princ*"[0-9\’]*->Set[[Principal]] "$owner"[0-9]*->Principal "$reader"[0-9]*->Principal "$writer"[0-9]*->("!"Principal) "$owner*"[0-9]*->Set[[Principal]] "$reader**"[0-9]*->Set[[Principal]] "$reader*"[0-9]*->{Principal","}* "$writer**"[0-9]*->Set[[("!"Principal)]] "$writer*"[0-9]*->{("!"Principal)","}* "$reader+"[0-9]*->{Principal","}+ "$writer+"[0-9]*->{("!"Principal)","}+ "$label"[0-9]*->Label hiddens variables "$princ"[0-9\’]*->Principal
A.3
The definition of DynamicLabel module in SDF
module DynamicLabel imports RDR imports containers/List[Principal]
135
AppendixA. The SDF part of RDR-evaluator
imports containers/Set[SemChain] imports containers/Set[Principal]
exports sorts SemChain D Set context-free syntax "("List[[Principal]]","Integer")"->SemChain appearInChain(Chain,Set[[SemChain]])->Boolean prePrincChain(Principal,Chain,Chain)->Chain postPrincChain(Principal,Chain,Chain)->Chain reportprefixChain(Set[[SemChain]],Principal,Chain)->Chain reportpostfixChain(Set[[SemChain]],Principal,Chain)->Chain semchainSeqPrinc(SemChain)->List[[Principal]] setSemchainSeqPrinc(Set[[SemChain]])->List[[Principal]] semchainSeqIndex(SemChain)->Integer prinipal2chain(List[[Principal]])->Chain returnSetofChains(Set[[SemChain]],List[[Principal]])->Set[[SemChain]] return2SetofChains(Set[[SemChain]],List[[Principal]])->Set[[SemChain]] return3SetofChains(Set[[SemChain]],List[[Principal]],Principal)->Set[[SemChain]] return4SetofChains(Set[[SemChain]],List[[Principal]],Principal)->Set[[SemChain]] chainElem(Principal,Chain)->Boolean subchain(Chain,Chain)->Boolean prechain(Chain,Chain)->Chain returnIndex(List[[Principal]],Integer)->Principal chainSeqPrinc(Chain)->List[[Principal]] "("List[[Principal]]","Integer")"->SemChain "null"->{SemChain","}* delegationIndex(List[[Principal]],Principal)->Integer "("Set[[SemChain]]","Set[[SemChain]]")"->D
subset2(Set[[Principal]],Set[[Principal]])->Boolean subset(List[[Principal]],List[[Principal]])->Boolean subset1(Set[[SemChain]],Set[[SemChain]])->Boolean %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%Evalute current(dr,dw)%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% curdwdr(SemChain)->Set[[Principal]] curSetdwdr(Set[[SemChain]])->Set[[Principal]]
list2Set(List[[Principal]])->Set[[Principal]] hiddens context-free start-symbols Integer Chain Boolean List[[Principal]] Set[[SemChain]] Boolean exports variables "$princ->*"[0-9\’]*-> {Principal "->"}* "$n"[0-9\’]*->Integer "$chain"[0-9\’]*-> Chain "$princ"[0-9\’]*->Principal
136
A.5. The definition of evaluate-exp-label module in SDF
"$princ*"[0-9\’]*->Set[[Principal]] "$princip*"[0-9\’]*->List[[Principal]] "$principal*"[0-9\’]*->{Principal","}* "$d"[0-9]*->D "$dr"[0-9]*->Set[[SemChain]] "$dw"[0-9]*->Set[[SemChain]] "semch*"[0-9]*->Set[[SemChain]] "$semchain*"[0-9]*->{SemChain","}*
hiddens variables "$j"[0-9\’]*->Integer "$semchain"[0-9\’]*->SemChain
A.4
The definition of evaluate-exp-value in SDF
module evaluate-exp-value imports RDR imports containers/Table[Var Value] imports containers/Set[Var] imports basic/Strings exports sorts V Set context-free syntax listDeclaredVariables(V)-> Set[[Var]] listExpressionVariables(EXP, Set[[Var]]) -> Set[[Var]] {traversal(accu, top-down, continue)} listExpressionVariables(Var, Set[[Var]]) -> Set[[Var]] {traversal(accu, top-down, continue)} subset(Set[[Var]],Set[[Var]])->Boolean "ev-exp-value"(EXP,V)->Value
variables "$VarList"[0-9]*->Set[[Var]] "$vars*"[0-9]*->{Var","}* "Pair*" [0-9]*-> { ","}* "$v"[0-9\’]*->V
aliases Table[[Var,Value]]->V hiddens context-free start-symbols Value
A.5
The definition of evaluate-exp-label module in SDF
module evaluate-exp-label imports RDR
137
AppendixA. The SDF part of RDR-evaluator
imports StaticLabel imports containers/Set[Principal] imports containers/Table[Var Label] exports sorts S context-free syntax listVariablesReaders(S)->Set[[Principal]] "ev-exp-label"(EXP,S)->Label variables "$s"[0-9\’]*->S "Pair*" [0-9]*-> { ","}* aliases Table[[Var,Label]]->S hiddens context-free start-symbols Set[[Principal]] Label
A.6
The definition of evaluate-exp-dl module in SDF
module evaluate-exp-dl imports RDR imports DynamicLabel imports evaluate-exp-label imports containers/Table[Var D] exports sorts Dl context-free syntax dl2label(S,Dl,Var)->Label ownerDl2label(S,Set[[SemChain]],Var)->Set[[Principal]] ev-exp-dlabel(S,Dl,EXP)->Label variables "$dl"[0-9\’]*->Dl "Pair*" [0-9]*-> { ","}* aliases Table[[Var,D]]->Dl hiddens context-free start-symbols EXP
A.7
The definition of evaluate-exp-flow module in SDF
module evaluate-exp-flow
138
A.8. The definition of ErrorMessage module in SDF
imports imports imports imports imports imports
evaluate-exp-label evaluate-exp-dl containers/Set[Principal] containers/Set[Var] containers/Table[Var Set[[Var]]] RDR
exports sorts I Set context-free syntax "ev-exp-flow"(EXP,I)-> Set[[Var]] Join2flow(Label,Label)->Label label(S,Dl,Set[[Var]])->Label vars(EXP)->Set[[Var]] variables "$i"[0-9\’]*->I "$flowlabel"[0-9\’]*->Label "$var*"[0-9\’]*->Set[[Var]] aliases Table[[Var,Set[[Var]]]]->I hiddens context-free start-symbols Set[[Var]] variables "$princ*"[0-9\’]*->Set[[Principal]] "$s"[0-9\’]*->S "$dl"[0-9\’]*->Dl "$var**" [0-9]*-> {Var","}*
A.8
The definition of ErrorMessage module in SDF
module ErrorMessage imports RDR exports sorts ErrorMessage context-free syntax %%%%%%%%%%%%list of error Message%%%%%%%%%%%%%%%%%%%%%%%%%% "Variable" Var "is undefined in" Var":="EXP->ErrorMessage "The variable" Var "is not declared"->ErrorMessage "Expression" EXP "undefined in" Var":="EXP->ErrorMessage "Disallowed information flow in" Var":="EXP->ErrorMessage "Information flow from a revoked delegation in" Var":="EXP->ErrorMessage "Expression" EXP "undefined in condition of if statement"->ErrorMessage "Expression $exp undefined in condition of While-loop"->ErrorMessage "The delegation is not allowed without a permission from the owner"->ErrorMessage "Disallowed information flow with delegation"->ErrorMessage "Error throughout program execution"->ErrorMessage "Disallowed information flow with revocation"->ErrorMessage
139
AppendixA. The SDF part of RDR-evaluator
"Disallowed mplicit information flow in" Var ":" SecType"=" Value ";"->ErrorMessage
hiddens variables "$error"[0-9]*->ErrorMessage
A.9
The definition of Result module in SDF
module Result imports ErrorMessage imports Value-environments imports containers/Set[Var] exports sorts Result Set PC context-free syntax (|ErrorMessage)->Result Set[[Var]]->PC "ev-body"(Body,,PC)->Result variables "$result"[0-9]*->Result "$body"[0-9]*->(VarDecl | Statement)* "$pc"[0-9\’]*->Set[[Var]] hiddens context-free start-symbols Result Body
A.10
The definition of evaluator module in SDF
module evaluator imports var-decleration imports assignment imports if-then-else imports while-do imports Delegation imports Revocation exports context-free syntax "evaluate"(Program)->Result hiddens context-free start-symbols Program Result variables "$prog"[0-9]*->Program
140
A.11. The values definition in SDF
A.11
The values definition in SDF
module values imports basic/Integers imports basic/StrCon exports sorts Value context-free syntax Integer->Value StrCon->Value BoolCon->Value "nil-value"->Value
141
Appendix B The equation part of language evaluator B.1
The equation part of StaticLabel module
equations [set2nonset-0] set2nonset({})= [set2nonset-1] set2nonset({$reader})=$reader
[set2nonset-33] set2nonset({$reader*})=$reader* [setw2nonset-0] setw2nonset({})= [setw2nonset-1] !$princ:=$writer ====> setw2nonset({$writer})=!$princ [setw2nonset-33] !$princ:=$writer ====> setw2nonset({$writer,$writer*})=!$princ,setw2nonset({$writer*}) [princ2w-0] $writer:=!$princ ====> princ2w({$princ})={$writer} [princ2w-1] $writer:=!$princ ====> princ2w({$princ,$principal*})=union({$writer},princ2w({$principal*})) [ext-ow-0]
142
B.1. The equation part of StaticLabel module
ext-ow()={} [ext-ow-1] $princ*:=ext-ow($policy*) ====> ext-ow($princ:;$policy*)= union({$princ},$princ*) [ext-ow-2] $princ*:=ext-ow($policy*) ====> ext-ow($princ:$prs;$policy*)= union({$princ},$princ*) [owner-0] owner($princ:)=$princ [owner-1] owner($princ:$prs)=$princ
[reader-0] reader($princ:)={} [reader-1] reader($princ:$princ1,$prs)=union({$princ1},reader($princ:$prs)) [reader-2] reader($princ:!$princ1,$prs)=reader($princ:$prs) [writer-0] writer($princ:)={} [writer-1] writer($princ:!$princ1,$prs)=union({!$princ1},writer($princ:$prs)) [writer-2] writer($princ:$princ1,$prs)=writer($princ:$prs) [Join-0] Join($label,)=$label [Join-1] Join(,$label)=$label [Join-2] owner($policy1)==owner($policy2), $reader**:=intersection(reader($policy1),reader($policy2)), $reader*:=set2nonset($reader**), $writer**:=union(writer($policy1),writer($policy2)), $writer*:=setw2nonset($writer**), $policy3:=owner($policy1):topr($reader*),topw($writer*) ====> Join($policy1,$policy2)=$policy3 [join-3] owner($policy1)!=owner($policy2) ====> Join($policy1,$policy2)=$policy1;$policy2
[join-4] Join($policy*1,$policy*2)=$policy*1;$policy*2
143
AppendixB. The equation part of language evaluator
[meet-0] meet($label,)= [meet-1] meet(,$label)= [meet-2] owner($policy1)==owner($policy2), $reader**:=union(reader($policy1),reader($policy2)), $reader*:=set2nonset($reader**), $writer**:=intersection(writer($policy1),writer($policy2)), $writer*:=setw2nonset($writer**), $policy3:=owner($policy1):topr($reader*),topw($writer*) ====> meet($policy1,$policy2)=$policy3
[meet-3] owner($policy1)!=owner($policy2), $reader**1:=reader($policy1), $reader*1:=set2nonset($reader**1), $writer**1:=writer($policy1), $writer*1:=setw2nonset($writer**1), $prs1:=topr($reader*1),topw($writer*1), $reader**2:=reader($policy2), $reader*2:=set2nonset($reader**2), $writer**2:=writer($policy2), $writer*2:=setw2nonset($writer**2), $prs2:=topr($reader*2),topw($writer*2) ====> meet($policy1,$policy2)=owner($policy1):$prs1,$prs2;owner($policy2):$prs1,$prs2 [meet-4] meet($policy1;$policy*1,$policy2;$policy*2)=Join(meet($policy1,$policy2),meet($policy*1,$policy*2)) [topr-0] topr()= [topr-00] topr($reader)=$reader [topr-1] topr($reader,$reader+)=$reader,topr($reader+) [topw-0] topw()= [topw-00] !$princ:=$writer ====> topw($writer)=!$princ [topw-1] !$princ:=$writer ====> topw($writer,$writer+)=!$princ,topw($writer+) [LessRestrictive-0] LessRestrictive(,$label)=true [LessRestrictive-00] LessRestrictive(,)=true
144
B.2. The equation part of DynamicLabel module
[LessRestrictive-1] owner($policy1)!=owner($policy2) ====> LessRestrictive($policy1,$policy2)=false [LessRestrictive-11] owner($policy1)!=owner($policy2), elem(owner($policy2),reader($policy1))==true ====> LessRestrictive($policy1,$policy2)=true [LessRestrictive-111] owner($policy1)==owner($policy2), subsetr(reader($policy2),reader($policy1))& subsetw(writer($policy1),writer($policy2))==true ====> LessRestrictive($policy1,$policy2)=true [LessRestrictive-11] owner($policy1)==owner($policy2), subsetr(reader($policy2),reader($policy1))& subsetw(writer($policy1),writer($policy2))==true ====> LessRestrictive($policy1;$policy*1,$policy2;$policy*2)=true [default-LessRestrictive] LessRestrictive($label,$label)=false [subr-nil] subsetr({}, $reader**) = true [subr-cons] elem($reader, $reader**) == true === subsetr({$reader, $reader*},$reader**) = subsetr({$reader*}, $reader**) [default-subr] subsetr($reader**1, $reader**2) = false
[subw-nil] %% Test this function subsetw({}, $writer**) = true [subw-cons] elem($writer, $writer**) == true === subsetw({$writer, $writer*},$writer**) = subsetw({$writer*}, $writer**) [default-subw] subsetw($writer**1, $writer**2) = false
B.2
The equation part of DynamicLabel module
equations [sub-1]
145
AppendixB. The equation part of language evaluator
subset([], $princip*) = true [sub-2] subset([$princ, $principal*], $princip*) = elem($princ, $princip*) & subset([$principal*], $princip*) [sub2-nil] subset2({}, $princ*) = true [sub2-cons] elem($princ, $princ*) == true === subset2({$princ, $principal*},$princ*) = subset2({$principal*}, $princ*) [default-sub2] subset2($princ*, $princ*1) = false [subset1-nil] %% Test this function subset1({}, semch*) = true [subset1-cons] elem($semchain, semch*) == true === subset1({$semchain, $semchain*},semch*) = subset1({$semchain*}, semch*) [default-subset1-rest] subset1(semch*, semch*1) = false [ChainPrinc-0] chainSeqPrinc()=[] [ChainPrinc-2] chainSeqPrinc($princ)=$princ:[] [ChainPrinc-2] $princip*:=chainSeqPrinc($princ->*) ====> chainSeqPrinc($princ->$princ->*)=$princ:$princip* [semchainSeqPrinc-1] semchainSeqPrinc(($princip*,$n))=$princip*
[setSemchainSeqPrinc-0] %% review this equation setSemchainSeqPrinc({})=[]
[setSemchainSeqPrinc-1] setSemchainSeqPrinc({$semchain,$semchain*})=concat(semchainSeqPrinc($semchain),setSemchainSeqPrinc({$semchain*}) [appearInChain-00] appearInChain($princ->*,{})=false [appearInChain-11] appearInChain($princ->*,{$semchain*})=subset(chainSeqPrinc($princ->*),setSemchainSeqPrinc({$semchain*})) [semchainSeqIndex-1] semchainSeqIndex(($princip*,$n))=$n
[DelegationIndex-1] $princ==head($princip*) ====>
146
B.2. The equation part of DynamicLabel module
delegationIndex($princip*,$princ)=1 [default-DelegationIndex] $n:=delegationIndex(tail($princip*),$princ)+1 ====> delegationIndex($princip*,$princ)=$n [prePrincChain-00] prePrincChain($princ,$princ->*,$princ->$princ->*)= [prePrincChain-0] prePrincChain($princ,$princ->*,$princ->$princ->*->$princ->*2)= [prePrincChain-1] prePrincChain($princ,$princ->*,$princ->*1->$princ->$princ->*->$princ->*2)=$princ->*1 [postPrincChain-00] postPrincChain($princ,$princ->*,$princ->$princ->*)= [postPrincChain-0] postPrincChain($princ,$princ->*,$princ->*1->$princ->$princ->*)= [postPrincChain-1] postPrincChain($princ,$princ->*,$princ->*1->$princ->$princ->*->$princ->*2)=$princ->*2 [reportprefixChain-0] reportprefixChain({},$princ,$chain)= [reportprefixChain-1] $princip*:=semchainSeqPrinc($semchain), $chain’:=prinipal2chain($princip*) ====> reportprefixChain({$semchain,$semchain*},$princ,$chain)=prePrincChain($princ,$chain,$chain’) [reportprefixChain-2] $princip*:=semchainSeqPrinc($semchain), $chain’:=prinipal2chain($princip*), subchain($princ->$princ->*,$chain’)==false ====> reportprefixChain({$semchain,$semchain*},$princ,$princ->*)=reportprefixChain({$semchain*},$princ,$princ->*) [reportpostfixChain-0] reportpostfixChain({},$princ,$chain)= [reportpostfixChain-1] $princip*:=semchainSeqPrinc($semchain), $chain’:=prinipal2chain($princip*) ====> reportpostfixChain({$semchain,$semchain*},$princ,$chain)=postPrincChain($princ,$chain,$chain’) [reportpostfixChain-2] $princip*:=semchainSeqPrinc($semchain), $chain’:=prinipal2chain($princip*), subchain($princ->$princ->*,$chain’)==false ====> reportpostfixChain({$semchain,$semchain*},$princ,$princ->*)= reportpostfixChain({$semchain*},$princ,$princ->*) [returnIndex-1] returnIndex($princip*,1)=head($princip*) [returnIndex-default]
147
AppendixB. The equation part of language evaluator
returnIndex($princip*,$n)=returnIndex(tail($princip*),$n-1) [chainElem-1] elem($princ,chainSeqPrinc($chain))==true ====> chainElem($princ,$chain)=true [chainElem-default] chainElem($princ,$chain)=false [subchain-0] subchain(,$chain’)=true [subchain-1] subchain($princ,$chain’)=chainElem($princ,$chain’) [subchain-2] subchain($princ->$princ->*,$chain’)= chainElem($princ,$chain’) & subchain($princ->*,$chain’) [prechain-00] prechain($chain,$chain)= [prechain-0] prechain($princ->*,$princ->*->$princ->*2)= [prechain-1] prechain($princ->*,$princ->$princ->*->$princ->*2)=$princ [prechain-2] prechain($princ->*,$princ->*1->$princ->*->$princ->*2)=$princ->*1 [returnSetofChains-0] returnSetofChains({},$princip*)={} [returnSetofChains-1] subchain(prinipal2chain($princip*),prinipal2chain($princip*’))==true ====> returnSetofChains({($princip*’,$n),$semchain*},$princip*)= union({($princip*’,$n)},returnSetofChains({$semchain*},$princip*)) [return2SetofChains-0] return2SetofChains({},$princip*)={} [return2SetofChains-1] $princip*0:=chainSeqPrinc(prechain(prinipal2chain($princip*),prinipal2chain($princip*’))), subchain(prinipal2chain($princip*),prinipal2chain($princip*’))==true ====> return2SetofChains({($princip*’,$n),$semchain*},$princip*)= union({($princip*0,min($n,length($princip*0)))},return2SetofChains({$semchain*},$princip*)) [return3SetofChains-0] return3SetofChains({},$princip*,$princ)={} [return3SetofChains-1] subchain(prinipal2chain($princip*),prinipal2chain($princip*’))==true, prinipal2chain($princip*1):=prechain(prinipal2chain($princip*),prinipal2chain($princip*’)), length($princip*1) return3SetofChains({($princip*’,$n),$semchain*},$princip*,$princ)=
148
B.2. The equation part of DynamicLabel module
union({($princip*’,$n)},return3SetofChains({$semchain*},$princip*,$princ)) [return3SetofChains-2] subchain(prinipal2chain($princip*),prinipal2chain($princip*’))==false ====> return3SetofChains({($princip*’,$n),$semchain*},$princip*,$princ)= return3SetofChains({$semchain*},$princip*,$princ) [return3SetofChains-3] subchain(prinipal2chain($princip*),prinipal2chain($princip*’))==true , prinipal2chain($princip*1):=prechain(prinipal2chain($princip*),prinipal2chain($princip*’)), subchain($princ,prinipal2chain($princip*1))==false ====> return3SetofChains({($princip*’,$n),$semchain*},$princip*,$princ)= return3SetofChains({$semchain*},$princip*,$princ) [return3SetofChains-4] subchain(prinipal2chain($princip*),prinipal2chain($princip*’))==true, prinipal2chain($princip*1):=prechain(prinipal2chain($princip*),prinipal2chain($princip*’)), length($princip*1) return3SetofChains({($princip*’,$n),$semchain*},$princip*,$princ)= return3SetofChains({$semchain*},$princip*,$princ) [return4SetofChains-0] return4SetofChains({},$princip*,$princ)={} [return4SetofChains-1] subchain(prinipal2chain($princip*),prinipal2chain($princip*’))==true , prinipal2chain($princip*1):=prechain(prinipal2chain($princip*),prinipal2chain($princip*’)), subchain($princ,prinipal2chain($princip*1))==true, length($princip*1) return4SetofChains({($princip*’,$n),$semchain*},$princip*,$princ)= union({($princip*’,length($princip*1))},return4SetofChains({$semchain*},$princip*,$princ)) [return4SetofChains-2] subchain(prinipal2chain($princip*),prinipal2chain($princip*’))==false ====> return4SetofChains({($princip*’,$n),$semchain*},$princip*,$princ)= return4SetofChains({$semchain*},$princip*,$princ) [return4SetofChains-3] subchain(prinipal2chain($princip*),prinipal2chain($princip*’))==true, prinipal2chain($princip*1):=prechain(prinipal2chain($princip*),prinipal2chain($princip*’)), length($princip*1) return4SetofChains({($princip*’,$n),$semchain*},$princip*,$princ)= return4SetofChains({$semchain*},$princip*,$princ) [return4SetofChains-4] subchain(prinipal2chain($princip*),prinipal2chain($princip*’))==true, prinipal2chain($princip*1):=prechain(prinipal2chain($princip*),prinipal2chain($princip*’)), subchain($princ,prinipal2chain($princip*1))==false ====> return4SetofChains({($princip*’,$n),$semchain*},$princip*,$princ)= return4SetofChains({$semchain*},$princip*,$princ) [returnSetofChains-0] returnSetofChains({},$princip*)={} %% it leads to embguity for returnSetofChains({},{})={}
149
AppendixB. The equation part of language evaluator
[returnSetofChains-1] subchain(prinipal2chain($princip*),prinipal2chain($princip*’))==true ====> returnSetofChains({($princip*’,$n),$semchain*},$princip*)=union({($princip*’,$n)}, returnSetofChains({$semchain*},$princip*)) [return2SetofChains-0] return2SetofChains({},$princip*)={} [return2SetofChains-1] $princip*0:=chainSeqPrinc(prechain(prinipal2chain($princip*), prinipal2chain($princip*’))), %% c0:=prechain(c,c’) subchain(prinipal2chain($princip*),prinipal2chain($princip*’))==true ====> return2SetofChains({($princip*’,$n),$semchain*},$princip*)= union({($princip*0,min($n,length($princip*0)))},return2SetofChains({$semchain*},$princip*)) [return3SetofChains-0] return3SetofChains({},$princip*,$princ)={} [return3SetofChains-1] subchain(prinipal2chain($princip*),prinipal2chain($princip*’))==true, prinipal2chain($princip*1):=prechain(prinipal2chain($princip*),prinipal2chain($princip*’)), length($princip*1) return3SetofChains({($princip*’,$n),$semchain*},$princip*,$princ)= union({($princip*’,$n)},return3SetofChains({$semchain*},$princip*,$princ)) [return3SetofChains-2] subchain(prinipal2chain($princip*),prinipal2chain($princip*’))==false ====> return3SetofChains({($princip*’,$n),$semchain*},$princip*,$princ)= return3SetofChains({$semchain*},$princip*,$princ) [return3SetofChains-3] subchain(prinipal2chain($princip*),prinipal2chain($princip*’))==true , prinipal2chain($princip*1):=prechain(prinipal2chain($princip*),prinipal2chain($princip*’)), subchain($princ,prinipal2chain($princip*1))==false ====> return3SetofChains({($princip*’,$n),$semchain*},$princip*,$princ)= return3SetofChains({$semchain*},$princip*,$princ) [return3SetofChains-4] subchain(prinipal2chain($princip*),prinipal2chain($princip*’))==true, prinipal2chain($princip*1):=prechain(prinipal2chain($princip*),prinipal2chain($princip*’)), length($princip*1) return3SetofChains({($princip*’,$n),$semchain*},$princip*,$princ)= return3SetofChains({$semchain*},$princip*,$princ) [return4SetofChains-0] return4SetofChains({},$princip*,$princ)={} [return4SetofChains-1] subchain(prinipal2chain($princip*),prinipal2chain($princip*’))==true , prinipal2chain($princip*1):=prechain(prinipal2chain($princip*),prinipal2chain($princip*’)), subchain($princ,prinipal2chain($princip*1))==true, length($princip*1)
150
B.3. The equation part of evaluate-exp-value module
return4SetofChains({($princip*’,$n),$semchain*},$princip*,$princ)= union({($princip*’,length($princip*1))},return4SetofChains({$semchain*},$princip*,$princ)) [return4SetofChains-2] subchain(prinipal2chain($princip*),prinipal2chain($princip*’))==false ====> return4SetofChains({($princip*’,$n),$semchain*},$princip*,$princ)= return4SetofChains({$semchain*},$princip*,$princ) [return4SetofChains-3] subchain(prinipal2chain($princip*),prinipal2chain($princip*’))==true, prinipal2chain($princip*1):=prechain(prinipal2chain($princip*),prinipal2chain($princip*’)), length($princip*1) return4SetofChains({($princip*’,$n),$semchain*},$princip*,$princ)= return4SetofChains({$semchain*},$princip*,$princ) [return4SetofChains-4] subchain(prinipal2chain($princip*),prinipal2chain($princip*’))==true, prinipal2chain($princip*1):=prechain(prinipal2chain($princip*),prinipal2chain($princip*’)), subchain($princ,prinipal2chain($princip*1))==false ====> return4SetofChains({($princip*’,$n),$semchain*},$princip*,$princ)= return4SetofChains({$semchain*},$princip*,$princ) [curdwdr-1] $princ1:=returnIndex($princip*,2) ====> curdwdr(($princip*,1))={$princ1} [default-curdwdr-2] $princ:=returnIndex($princip*,$n) ====> curdwdr(($princip*,$n))=union({$princ},curdwdr(($princip*,$n-1)))%%curdwdr((tail($princ*),$n-1)) [curSetdwdr-0] %% review this equation curSetdwdr({})={} [curSetdwdr-2] curSetdwdr({($princip*,$n),$semchain*})=union(curdwdr(($princip*,$n)),curSetdwdr({$semchain*})) [list2Set-1] list2Set([$principal*])={$principal*}
B.3
The equation part of evaluate-exp-value module
equations [sub-1] subset({}, $VarList2) = true [sub-2] subset({$var, $vars*}, $VarList2) = elem($var, $VarList2) & subset({$vars*}, $VarList2)
[listDeclaredVariables-0]
151
AppendixB. The equation part of language evaluator
listDeclaredVariables([])={} [listDeclaredVariables-1] listDeclaredVariables([])= union({$var},{}) [listDeclaredVariables-2] $VarList:=listDeclaredVariables([Pair*1]) ====> listDeclaredVariables([Pair*1,])=union({$var},$VarList) [listExpressionVariables-1] listExpressionVariables($var,$VarList)= union({$var},$VarList) %% evaluate expression values [ev-exp-value-1] ev-exp-value($var,$v)=lookup($v,$var) [ev-exp-value-2] ev-exp-value($Nat-con,$v)=$Nat-con [ev-exp-value-3] ev-exp-value($Str-con,$v)=$Str-con [ev-exp-value-4] $Nat1:=ev-exp-value($exp1,$v), $Nat2:=ev-exp-value($exp2,$v) ====> ev-exp-value($exp1+$exp2,$v)=$Nat1+$Nat2 [ev-exp-value-5] $Nat1:=ev-exp-value($exp1,$v), $Nat2:=ev-exp-value($exp2,$v) ====> ev-exp-value($exp1-$exp2,$v)=$Nat1-$Nat2 [ev-exp-value-6] $Nat1:=ev-exp-value($exp1,$v), $Nat2:=ev-exp-value($exp2,$v) ====> ev-exp-value($exp1*$exp2,$v)=$Nat1*$Nat2 [ev-exp-value-7] ev-exp-value($exp2,$v)!=0, $Nat1:=ev-exp-value($exp1,$v), $Nat2:=ev-exp-value($exp2,$v) ====> ev-exp-value($exp1/$exp2,$v)=$Nat1/$Nat2 [ev-exp-value-8] $Str1:=ev-exp-value($exp1,$v), $Str2:=ev-exp-value($exp2,$v), $Str3:=concat($Str1,$Str2) ====> ev-exp-value($exp1||$exp2,$v)=$Str3 [ev-exp-value-9] ev-exp-value($exp1,$v)==ev-exp-value($exp2,$v) ====> ev-exp-value($exp1==$exp2,$v)=true
152
B.5. The equation part of ev-exp-dl module
[default-ev-exp-value-9] ev-exp-value($exp1==$exp2,$v)=false
B.4
The equation part of evaluate-exp-label module
equations
[ev-exp-label-1] $label :=lookup($s,$var) ====> ev-exp-label($var,$s)=$label [ev-exp-label-2] ev-exp-label($Nat-con,$s)= [ev-exp-label-3] ev-exp-label($Str-con,$s)= [ev-exp-label-4] $label1:=ev-exp-label($exp1,$s), $label2:=ev-exp-label($exp2,$s) ====> ev-exp-label($exp1+$exp2,$s)= Join($label1,$label2) [ev-exp-label-5] $label1:=ev-exp-label($exp1,$s), $label2:=ev-exp-label($exp2,$s) ====> ev-exp-label($exp1==$exp2,$s)= Join($label1,$label2) [ev-exp-label-5] $label2:=ev-exp-label($exp1,$s), $label1:=ev-exp-label($exp2,$s) ====> ev-exp-label($exp1!=$exp2,$s)= Join($label1,$label2)
B.5
The equation part of ev-exp-dl module
equations [ev-exp-dlabel-1] ev-exp-dlabel($s,$dl,$var)=dl2label($s,$dl,$var) [ev-exp-dlabel-2] ev-exp-dlabel($s,$dl,$Nat-con)= [ev-exp-dlabel-3] ev-exp-dlabel($s,$dl,$Str-con)= [ev-exp-dlabel-4] $label1:=ev-exp-dlabel($s,$dl,$exp1), $label2:=ev-exp-dlabel($s,$dl,$exp2) ====> ev-exp-dlabel($s,$dl,$exp1+$exp2)=Join($label1,$label2) [ev-exp-dlabel-4]
153
AppendixB. The equation part of language evaluator
$label1:=ev-exp-dlabel($s,$dl,$exp1), $label2:=ev-exp-dlabel($s,$dl,$exp2) ====> ev-exp-dlabel($s,$dl,$exp1-$exp2)=Join($label1,$label2) [ev-exp-dlabel-4] $label1:=ev-exp-dlabel($s,$dl,$exp1), $label2:=ev-exp-dlabel($s,$dl,$exp2) ====> ev-exp-dlabel($s,$dl,$exp1*$exp2)=Join($label1,$label2) [ev-exp-dlabel-4] $label1:=ev-exp-dlabel($s,$dl,$exp1), $label2:=ev-exp-dlabel($s,$dl,$exp2) ====> ev-exp-dlabel($s,$dl,$exp1/$exp2)=Join($label1,$label2) [ev-exp-dlabel-4] $label1:=ev-exp-dlabel($s,$dl,$exp1), $label2:=ev-exp-dlabel($s,$dl,$exp2) ====> ev-exp-dlabel($s,$dl,$exp1||$exp2)=Join($label1,$label2) [ev-exp-dlabel-4] $label1:=ev-exp-dlabel($s,$dl,$exp1), $label2:=ev-exp-dlabel($s,$dl,$exp2) ====> ev-exp-dlabel($s,$dl,$exp1==$exp2)=Join($label1,$label2) [ev-exp-dlabel-4] $label1:=ev-exp-dlabel($s,$dl,$exp1), $label2:=ev-exp-dlabel($s,$dl,$exp2) ====> ev-exp-dlabel($s,$dl,$exp1!=$exp2)=Join($label1,$label2) [dl2label-0] ($dw1,$dr1):=lookup($dl,$var), $princ*1:=curSetdwdr($dw1), $writer**:=princ2w($princ*1), $writer*:=setw2nonset($writer**), $reader**:=curSetdwdr($dr1), $reader*:=set2nonset($reader**), {$owner}:=ownerDl2label($s,$dr1,$var) ====> dl2label($s,$dl,$var)=$owner:topr($reader*),topw($writer*) [dl2label-1] ($dw1,$dr1):=lookup($dl,$var), $dw1=={}, $reader**:=curSetdwdr($dr1), $reader*:=set2nonset($reader**), {$owner}:=ownerDl2label($s,$dr1,$var) ====> dl2label($s,$dl,$var)=$owner:topr($reader*) [dl2label-2] ($dw1,$dr1):=lookup($dl,$var), $dr1=={}, $princ*1:=curSetdwdr($dw1), $writer**:=princ2w($princ*1), $writer*:=setw2nonset($writer**), {$owner}:=ownerDl2label($s,$dw1,$var)
154
B.6. The equation part of evaluate-exp-flow
====> dl2label($s,$dl,$var)=$owner:topw($writer*) [default-dl2label] ($dw1,$dr1):=lookup($dl,$var), $dw1=={}, $dr1=={} ====> dl2label($s,$dl,$var)= [ownerDl2label-0] ownerDl2label($s,{},$var)={} [ownerDl2label-1] $princ:=head($princip*), $label:=lookup($s,$var), elem($princ,ext-ow($label))==true ====> ownerDl2label($s,{($princip*,$n),$semchain*},$var)={$princ}
B.6
The equation part of evaluate-exp-flow
equations [ev-exp-flow-1] ev-exp-flow($var,$i)=lookup($i,$var) [ev-exp-flowl-2] ev-exp-flow($Nat-con,$i)={} [ev-exp-flowl-3] ev-exp-flow($Str-con,$i)={} [ev-exp-label-4] $var*1:=ev-exp-flow($exp1,$i), $var*2:=ev-exp-flow($exp2,$i) ====> ev-exp-flow($exp1+$exp2,$i)=union($var*1,$var*2) %%Join2flow($flowlabel1,$flowlabel2) [ev-exp-label-4] $var*1:=ev-exp-flow($exp1,$i), $var*2:=ev-exp-flow($exp2,$i) ====> ev-exp-flow($exp1-$exp2,$i)=union($var*1,$var*2) [ev-exp-label-4] $var*1:=ev-exp-flow($exp1,$i), $var*2:=ev-exp-flow($exp2,$i) ====> ev-exp-flow($exp1*$exp2,$i)=union($var*1,$var*2) [ev-exp-label-4] $var*1:=ev-exp-flow($exp1,$i), $var*2:=ev-exp-flow($exp2,$i) ====> ev-exp-flow($exp1/$exp2,$i)=union($var*1,$var*2) [ev-exp-label-4] $var*1:=ev-exp-flow($exp1,$i), $var*2:=ev-exp-flow($exp2,$i) ====>
155
AppendixB. The equation part of language evaluator
ev-exp-flow($exp1||$exp2,$i)=union($var*1,$var*2) [ev-exp-label-5] $var*1:=ev-exp-flow($exp1,$i), $var*2:=ev-exp-flow($exp2,$i) ====> ev-exp-flow($exp1==$exp2,$i)=union($var*1,$var*2) [ev-exp-label-6] $var*1:=ev-exp-flow($exp1,$i), $var*2:=ev-exp-flow($exp2,$i) ====> ev-exp-flow($exp1!=$exp2,$i)=union($var*1,$var*2) [vars-1] vars($Nat-con)={} [vars-2] vars($Str-con)={} [vars-3] vars($var)={$var} [vars-4] vars($var1+$var2)={$var1,$var2} [vars-5] vars($var1==$Nat-con)={$var1} [vars-6] vars($var1==$Str-con)={$var1} [vars-7] vars($var1==$var2)={$var1,$var2} [vars-8] vars($var1!=$Nat-con)={$var1} [vars-9] vars($var1!=$Str-con)={$var1} [label-0] label($s,$dl,{})= %% [label-1] ($dw1,$dr1):=lookup($dl,$var), $label2:=dl2label($s,$dl,$var), $label1:=lookup($s,$var), $label:=meet($label1,$label2) ====> label($s,$dl,{$var})=$label [label-2] {$var**,$var2}:=$var*, $label1:=label($s,$dl,{$var**}), $label2:=label($s,$dl,{$var2}) ====> label($s,$dl,$var*)=Join($label1,$label2)
156
B.8. The equation part of Variable-declaration module
B.7
The equation part of Result module
equations [Ev-body1] ev-body(,,$pc)=
[default] ev-body($body,,$pc)=Error throughout program execution
B.8
The equation part of Variable-declaration module
equations [Ev-decleration-String] $v’:=store($v,$var,$value), $s’:=store($s,$var,$policy*), $dl’:=store($dl,$var,({},{})), $i’:=store($i,$var,{}), $label1:=label($s,$dl,$pc), $label2:=lookup($s,$var), LessRestrictive($label1,$label2)==true, $result:=ev-body($body,,$pc) ====> ev-body($var:(String,$policy*)=$value;$body,,$pc)=$result
[Error-Ev-decleration-String] $v’:=store($v,$var,$value), $s’:=store($s,$var,$policy*), $dl’:=store($dl,$var,({},{})), $i’:=store($i,$var,{}), $label1:=label($s,$dl,$pc), $label2:=lookup($s,$var), LessRestrictive($label1,$label2)==false ====> ev-body($var:(String,$policy*)=$value;$body,,$pc)= Disallowed implicit information flow in $var:(String,$policy*)=$value;
[Ev-decleration-Integer] $v’:=store($v,$var,$value), $s’:=store($s,$var,$policy*), $dl’:=store($dl,$var,({},{})), $i’:=store($i,$var,{}), $label1:=label($s,$dl,$pc), $label2:=lookup($s,$var), LessRestrictive($label1,$label2)==true, $result:=ev-body($body,,$pc) ====> ev-body($var:(Integer,$policy*)=$value;$body,,$pc)=$result
157
AppendixB. The equation part of language evaluator
[Error-Ev-decleration-Integer] $v’:=store($v,$var,$value), $s’:=store($s,$var,$policy*), $dl’:=store($dl,$var,({},{})), $i’:=store($i,$var,{}), $label1:=label($s,$dl,$pc), $label2:=lookup($s,$var), LessRestrictive($label1,$label2)==false ====> ev-body($var:(Integer,$policy*)=$value;$body,,$pc)= Disallowed implicit information flow in $var:(Integer,$policy*)=$value;
B.9
The equation part of Assignment module
equations [Ev-assignments-1] $VarList1:=listDeclaredVariables($v), $VarList2:=listExpressionVariables($exp,{}), subset($VarList2,$VarList1)==true, elem($var,$VarList1)==true, $label1:=lookup($s,$var), $label2:=ev-exp-label($exp,$s), ($dw1,$dr1):=lookup($dl,$var), $label3:=dl2label($s,$dl,$var), $label4:=ev-exp-dlabel($s,$dl,$exp), $label5:=label($s,$dl,ev-exp-flow($exp,$i)), $label:=label($s,$dl,$pc), LessRestrictive(Join($label,meet($label2,$label4)),meet($label1,$label3))==true, LessRestrictive($label5,meet($label1,$label3))==true, $value:=ev-exp-value($exp,$v), $v’:=store($v,$var,$value), $i’:=store($i,$var,vars($exp)) ====> ev-body($var:=$exp;$body,,$pc)=ev-body($body,,$pc)
[error-ass-1] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==false ====> ev-body($var:=$exp;$body,,$pc)= The variable $var is not declared [error-ass-2] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $VarList2:=listExpressionVariables($exp,{}), subset($VarList2,$VarList1)==false ====> ev-body($var:=$exp;$body,,$pc)= Expression $exp undefined in $var:=$exp
[error-ass-3] $VarList1:=listDeclaredVariables($v), $VarList2:=listExpressionVariables($exp,{}), subset($VarList2,$VarList1)==true, elem($var,$VarList1)==true, $label1:=lookup($s,$var), $label2:=ev-exp-label($exp,$s),
158
B.10. The equation part of if-then-else module
($dw1,$dr1):=lookup($dl,$var), $label3:=dl2label($s,$dl,$var), $label4:=ev-exp-dlabel($s,$dl,$var), %% test this function $label5:=label($s,$dl,lookup($i,$var)), %% also test this function $label:=label($s,$dl,$pc), LessRestrictive(Join($label,meet($label2,$label4)),meet($label1,$label3))==false ====> ev-body($var:=$exp;$body,,$pc)=Disallowed information flow in $var:=$exp [error-ass-4] $VarList1:=listDeclaredVariables($v), $VarList2:=listExpressionVariables($exp,{}), subset($VarList2,$VarList1)==true, elem($var,$VarList1)==true, $label1:=lookup($s,$var), $label2:=ev-exp-label($exp,$s), ($dw1,$dr1):=lookup($dl,$var), $label3:=dl2label($s,$dl,$var), $label4:=ev-exp-dlabel($s,$dl,$var), $label5:=label($s,$dl,lookup($i,$var)), $label:=label($s,$dl,$pc), LessRestrictive(Join($label,meet($label2,$label4)),meet($label1,$label3))==true, LessRestrictive($label5,meet($label1,$label3))==false ====> ev-body($var:=$exp;$body,,$pc)=Disallowed information flow in $var:=$exp
B.10
The equation part of if-then-else module
equations [If-then-1] $VarList1:=listDeclaredVariables($v), $VarList2:=listExpressionVariables($exp,{}), subset($VarList2,$VarList1)==true, ev-exp-value($exp,$v)!=false, :=ev-body($body1,,union($pc,vars($exp))), $result:=ev-body($body,,$pc) ====> ev-body(if ($exp) then {$body1} else {$body2} $body,,$pc)=$result
[error-if-2] $VarList1:=listDeclaredVariables($v), $VarList2:=listExpressionVariables($exp,{}), subset($VarList2,$VarList1)==true, ev-exp-value($exp,$v)!=false, $result:=ev-body($body1,,union($pc,vars($exp))) ====> ev-body(if ($exp) then {$body1} else {$body2} $body,,$pc)=$result [If-then-2] $VarList1:=listDeclaredVariables($v), $VarList2:=listExpressionVariables($exp,{}), subset($VarList2,$VarList1)==true, ev-exp-value($exp,$v)==false, :=ev-body($body2,,union($pc,vars($exp))) ====> ev-body(if ($exp) then {$body1} else {$body2} $body,,$pc)=
159
AppendixB. The equation part of language evaluator
ev-body($body,,$pc) [error-if-1] $VarList1:=listDeclaredVariables($v), $VarList2:=listExpressionVariables($exp,{}), subset($VarList2,$VarList1)==false ====> ev-body(if ($exp) then {$body1} else {$body2} $body,,$pc)= Expression $exp undefined in condition of if statement
[error-if-3] $VarList1:=listDeclaredVariables($v), $VarList2:=listExpressionVariables($exp,{}), subset($VarList2,$VarList1)==true, ev-exp-value($exp,$v)==false, $result:=ev-body($body2,,union($pc,vars($exp))) ====> ev-body(if ($exp) then {$body1} else {$body2} $body,,$pc)=$result
B.11
The equation part of while-do module
equations [While-1] $VarList1:=listDeclaredVariables($v), $VarList2:=listExpressionVariables($exp,{}), subset($VarList2,$VarList1)==true, ev-exp-value($exp,$v)!=false, ====> ev-body(while ($exp) do {$body1} $body,,$pc)= ev-body($body1 while ($exp) do {$body1} $body,,union($pc,vars($exp))) [While-2] $VarList1:=listDeclaredVariables($v), $VarList2:=listExpressionVariables($exp,{}), subset($VarList2,$VarList1)==true, ev-exp-value($exp,$v)==false, $result:=ev-body($body,,union($pc,vars($exp))) ====> ev-body(while ($exp) do {$body1} $body,,$pc)=$result [error-While-1] $VarList1:=listDeclaredVariables($v), $VarList2:=listExpressionVariables($exp,{}), subset($VarList2,$VarList1)==false ====> ev-body(while ($exp) do {$body1} $body,,$pc)= Expression $exp undefined in condition of While-loop
B.12
The equation part of Delegation module
equations [Delegate-write] $VarList1:=listDeclaredVariables($v),
160
B.12. The equation part of Delegation module
elem($var,$VarList1)==true, $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==true, $d:=lookup($dl,$var), ($dw,$dr):=$d, $dl’:=store($dl,$var,(union({(chainSeqPrinc($princ->$princ->*),1)},$dw),$dr)), $label2:=dl2label($s,$dl’,$var), $label3:=label($s,$dl,lookup($i,$var)), $label4:=label($s,$dl,$pc), LessRestrictive($label4,meet($label1,$label2))==true, LessRestrictive($label3,$label2)==true, $result:=ev-body($body,,$pc) ====> ev-body($princ delegates $var(!)$princ->*; $body,,$pc)=$result
[Delegate-write-1] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==false, $d:=lookup($dl,$var), ($dw,$dr):=$d, $princ->*:=$chain, appearInChain($princ->$princ->*,$dw)==true, $princ->*1:=reportprefixChain($dw,$princ,$chain), $princ->*2:=reportpostfixChain($dw,$princ,$chain), $chain’:=$princ->*1->$princ->$princ->*->$princ->*2, $chain’’:=$princ->*1->$princ->$princ->*, $n:=delegationIndex(chainSeqPrinc($chain’),$princ), returnIndex(chainSeqPrinc($chain’),$n)==$princ, $dl’:=store($dl,$var,(union({(chainSeqPrinc($chain’’),$n+1)},$dw),$dr)), $label2:=dl2label($s,$dl’,$var), $label3:=label($s,$dl,lookup($i,$var)), $label4:=label($s,$dl,$pc), LessRestrictive($label4,meet($label1,$label2))==true, LessRestrictive($label3,$label2)==true, $result:=ev-body($body,,$pc) ====> ev-body($princ delegates $var(!) $chain ; $body,,$pc)=$result [error-Delegate-write-1] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==false ====> ev-body($princ delegates $var(!) $chain ; $body,,$pc)= The variable $var is not declared [error-Delegate-write-2] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==false, $d:=lookup($dl,$var), ($dw,$dr):=$d, $princ->*:=$chain, appearInChain($princ->$princ->*,$dw)==false ====> ev-body($princ delegates $var(!) $chain ; $body,,$pc)= The delegation is not allowed without a permission from the owner
161
AppendixB. The equation part of language evaluator
[error-Delegate-write-3] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==true, $d:=lookup($dl,$var), ($dw,$dr):=$d, $dl’:=store($dl,$var,(union({(chainSeqPrinc($princ->$princ->*),2)},$dw),$dr)), $label2:=dl2label($s,$dl’,$var), $label3:=label($s,$dl,lookup($i,$var)), $label4:=label($s,$dl,$pc), LessRestrictive($label4,meet($label1,$label2))==false ====> ev-body($princ delegates $var(!)$princ->*; $body,,$pc)= Disallowed information flow with delegation [error-Delegate-write-4] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==true, $d:=lookup($dl,$var), ($dw,$dr):=$d, $dl’:=store($dl,$var,(union({(chainSeqPrinc($princ->$princ->*),2)},$dw),$dr)), $label2:=dl2label($s,$dl’,$var), $label3:=label($s,$dl,lookup($i,$var)), $label4:=label($s,$dl,$pc), LessRestrictive($label4,meet($label1,$label2))==true, LessRestrictive($label3,$label2)==false ====> ev-body($princ delegates $var(!)$princ->*; $body,,$pc)= Disallowed information flow with delegation
[Delegate-read] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==true, ($dw,$dr):=lookup($dl,$var), $dl’:=store($dl,$var,($dw,union({(chainSeqPrinc($princ->$princ->*),1)},$dr))), $label2:=dl2label($s,$dl’,$var), $label3:=label($s,$dl,lookup($i,$var)), $label4:=label($s,$dl,$pc), LessRestrictive($label4,meet($label1,$label2))==true, LessRestrictive($label3,$label2)==true, $result:=ev-body($body,,$pc) ====> ev-body($princ delegates $var(*)$princ->* ; $body,,$pc)=$result
[Delegate-read-1] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==false, ($dw,$dr):=lookup($dl,$var), appearInChain($princ->$princ->*,$dr)==true, $princ->*1:=reportprefixChain($dr,$princ,$princ->*), $princ->*2:=reportpostfixChain($dr,$princ,$princ->*), $chain’:=$princ->*1->$princ->$princ->*->$princ->*2, $chain’’:=$princ->*1->$princ->$princ->*, %%I changed $princ to $princ->*
162
B.12. The equation part of Delegation module
$n:=delegationIndex(chainSeqPrinc($chain’),$princ), returnIndex(chainSeqPrinc($chain’),$n)==$princ, $dl’:=store($dl,$var,($dw,union({(chainSeqPrinc($chain’’),$n+1)},$dr))), $label2:=dl2label($s,$dl’,$var), %% check this function %%$label2:=patient:phys1,phys2, $label3:=label($s,$dl,lookup($i,$var)), $label4:=label($s,$dl,$pc), LessRestrictive($label4,meet($label1,$label2))==true, LessRestrictive($label3,$label2)==true ====> ev-body($princ delegates $var(*)$princ->* ; $body,,$pc)= ev-body($body,,$pc)
[error-Delegate-read-1] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==false ====> ev-body($princ delegates $var(*) $chain ; $body,,$pc)= The variable $var is not declared [error-Delegate-read-2] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==false, ($dw,$dr):=lookup($dl,$var), appearInChain($princ->$princ->*,$dr)==false ====> ev-body($princ delegates $var(*) $princ->* ; $body,,$pc)= The delegation is not allowed without a permission from the owner [error-Delegate-read-3] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==true, $d:=lookup($dl,$var), ($dw,$dr):=$d, $dl’:=store($dl,$var,($dw,union({(chainSeqPrinc($princ->$princ->*),2)},$dr))), $label2:=dl2label($s,$dl’,$var), $label3:=label($s,$dl,lookup($i,$var)), $label4:=label($s,$dl,$pc), LessRestrictive($label4,meet($label1,$label2))==false ====> ev-body($princ delegates $var(*) $princ->*; $body,,$pc)= Disallowed information flow with delegation [error-Delegate-read-4] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==true, $d:=lookup($dl,$var), ($dw,$dr):=$d, $dl’:=store($dl,$var,($dw,union({(chainSeqPrinc($princ->$princ->*),2)},$dr))), $label2:=dl2label($s,$dl’,$var), $label3:=label($s,$dl,lookup($i,$var)), $label4:=label($s,$dl,$pc), LessRestrictive($label4,meet($label1,$label2))==true, LessRestrictive($label3,$label2)==false ====>
163
AppendixB. The equation part of language evaluator
ev-body($princ delegates $var(*) $princ->*; $body,,$pc)= Disallowed information flow with delegation
[error-Delegate-read-5] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==false, ($dw,$dr):=lookup($dl,$var), appearInChain($princ->$princ->*,$dr)==true, $princ->*1:=reportprefixChain($dr,$princ,$princ->*), $princ->*2:=reportpostfixChain($dr,$princ,$princ->*), $chain’:=$princ->*1->$princ->$princ->*->$princ->*2, $chain’’:=$princ->*1->$princ->$princ->*, $n:=delegationIndex(chainSeqPrinc($chain’),$princ), returnIndex(chainSeqPrinc($chain’),$n)==$princ, $dl’:=store($dl,$var,($dw,union({(chainSeqPrinc($chain’’),$n+2)},$dr))), $label2:=dl2label($s,$dl’,$var), $label3:=label($s,$dl,lookup($i,$var)), $label4:=label($s,$dl,$pc), LessRestrictive($label4,meet($label1,$label2))==false ====> ev-body($princ delegates $var(*)$princ->* ; $body,,$pc)= Disallowed information flow with delegation [error-Delegate-read-6] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==false, ($dw,$dr):=lookup($dl,$var), appearInChain($princ->$princ->*,$dr)==true, $princ->*1:=reportprefixChain($dr,$princ,$princ->*), $princ->*2:=reportpostfixChain($dr,$princ,$princ->*), $chain’:=$princ->*1->$princ->$princ->*->$princ->*2, $chain’’:=$princ->*1->$princ->$princ->*, %%I changed $princ to $princ->* $n:=delegationIndex(chainSeqPrinc($chain’),$princ), returnIndex(chainSeqPrinc($chain’),$n)==$princ, $dl’:=store($dl,$var,($dw,union({(chainSeqPrinc($chain’’),$n+2)},$dr))), $label2:=dl2label($s,$dl’,$var), $label3:=label($s,$dl,lookup($i,$var)), $label4:=label($s,$dl,$pc), LessRestrictive($label4,meet($label1,$label2))==true, LessRestrictive($label3,$label2)==false ====> ev-body($princ delegates $var(*)$princ->* ; $body,,$pc)= Disallowed information flow with delegation
[Delegate-read-write] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==true, $d:=lookup($dl,$var), ($dr,$dw):=$d, $dl’:=store($dl,$var,(union({(chainSeqPrinc($princ->$princ->*),1)},$dw), union({(chainSeqPrinc($princ->$princ->*),1)},$dr))), $label2:=dl2label($s,$dl’,$var), $label3:=label($s,$dl,lookup($i,$var)), $label4:=label($s,$dl,$pc),
164
B.12. The equation part of Delegation module
LessRestrictive($label4,meet($label1,$label2))==true, LessRestrictive($label3,$label2)==true ====> ev-body($princ delegates $var(*,!) $princ->* ; $body,,$pc)= ev-body($body,,$pc)
[Delegate-read-write-1] $label1:=lookup($s,$var), %%$princ*:=$owner*1, elem($princ,ext-ow($label1))==false, $d:=lookup($dl,$var), ($dw,$dr):=$d, $princ->*:=$chain, appearInChain($princ->$princ->*,$dr)==true, appearInChain($princ->$princ->*,$dw)==true, $princ->*1:=reportprefixChain($dr,$princ,$chain), $princ->*2:=reportpostfixChain($dr,$princ,$chain), $princ->*3:=reportprefixChain($dw,$princ,$chain), $princ->*4:=reportpostfixChain($dw,$princ,$chain), $chain’:=$princ->*1->$princ->$princ->*->$princ->*2, $chain’’:=$princ->*3->$princ->$princ->*->$princ->*4, $chain1:=$princ->*1->$princ->$princ->*, $chain2:=$princ->*3->$princ->$princ->*, $n1:=delegationIndex(chainSeqPrinc($chain’),$princ), $n:=delegationIndex(chainSeqPrinc($chain’’),$princ), returnIndex(chainSeqPrinc($chain’),$n1)==$princ, returnIndex(chainSeqPrinc($chain’’),$n)==$princ, $dl’:=store($dl,$var,(union({(chainSeqPrinc($chain1),$n1+1)},$dw), union({(chainSeqPrinc($chain2),$n+1)},$dr))), $label2:=dl2label($s,$dl’,$var), $label3:=label($s,$dl,lookup($i,$var)), $label4:=label($s,$dl,$pc), LessRestrictive($label4,meet($label1,$label2))==true, LessRestrictive($label3,$label2)==true ====> ev-body($princ delegates $var(*,!) $chain ; $body,,$pc)= ev-body($body,,$pc)
[error-Delegate-read-write-1] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==false ====> ev-body($princ delegates $var(*,!) $chain ; $body,,$pc)= The variable $var is not declared [error-Delegate-read-write-2] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==false, $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==false, $d:=lookup($dl,$var), ($dw,$dr):=$d, $princ->*:=$chain, appearInChain($princ->$princ->*,$dr)==false, appearInChain($princ->$princ->*,$dw)==false ====> ev-body($princ delegates $var(*,!) $chain ; $body,,$pc)= The delegation is not allowed without a permission from the owner
165
AppendixB. The equation part of language evaluator
[error-Delegate-read-write-3] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==true, $d:=lookup($dl,$var), ($dr,$dw):=$d, $dl’:=store($dl,$var,(union({(chainSeqPrinc($princ->$princ->*),2)},$dw), union({(chainSeqPrinc($princ->$princ->*),1)},$dr))), $label2:=dl2label($s,$dl’,$var), $label3:=label($s,$dl,lookup($i,$var)), $label4:=label($s,$dl,$pc), LessRestrictive($label4,meet($label1,$label2))==false ====> ev-body($princ delegates $var(*,!) $princ->* ; $body,,$pc)= Disallowed information flow with delegation
[error-Delegate-read-write-4] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==true, $d:=lookup($dl,$var), ($dr,$dw):=$d, $dl’:=store($dl,$var,(union({(chainSeqPrinc($princ->$princ->*),2)},$dw), union({(chainSeqPrinc($princ->$princ->*),1)},$dr))), $label2:=dl2label($s,$dl’,$var), $label3:=label($s,$dl,lookup($i,$var)), $label4:=label($s,$dl,$pc), LessRestrictive($label4,meet($label1,$label2))==true, LessRestrictive($label3,$label2)==false ====> ev-body($princ delegates $var(*,!) $princ->* ; $body,,$pc)= Disallowed information flow with delegation
B.13
The equation part of Revocation module
equations [Revoke-write] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $d:=lookup($dl,$var), ($dw,$dr):=$d, $princip*2:=chainSeqPrinc($chain), $dl’:=store($dl,$var,(union(difference($dw,returnSetofChains($dw,$princip*2)), return2SetofChains($dw,$princip*2)),$dr)), $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==true, $label2:=dl2label($s,$dl,$var), $label3:=label($s,$dl,$pc), LessRestrictive($label3,meet($label1,$label2))==true, $result:=ev-body($body,,$pc) ====> ev-body($princ revokes $var(!) $chain ; $body,,$pc)=$result
166
B.13. The equation part of Revocation module
[Error-Revoke-write-00] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==false ====> ev-body($princ revokes $var(!) $chain; $body,,$pc)= The variable $var is not declared [Error-Revoke-write] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $d:=lookup($dl,$var), ($dw,$dr):=$d, $princip*2:=chainSeqPrinc($chain), $dl’:=store($dl,$var,(union(difference($dw,returnSetofChains($dw,$princip*2)), return2SetofChains($dw,$princip*2)),$dr)), $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==true, $label2:=dl2label($s,$dl,$var), $label3:=label($s,$dl,$pc), LessRestrictive($label3,meet($label1,$label2))==false ====> ev-body($princ revokes $var(!) $chain ; $body,,$pc)= Disallowed information flow with revocation
[Revoke-write-1] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $d:=lookup($dl,$var), ($dw,$dr):=$d, $princip*2:=chainSeqPrinc($chain), $dl’:=store($dl,$var,(union(difference($dw,return3SetofChains($dw,$princip*2,$princ)), return4SetofChains($dw,$princip*2,$princ)),$dr)), $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==false, $label2:=dl2label($s,$dl,$var), $label3:=label($s,$dl,$pc), LessRestrictive($label3,meet($label1,$label2))==true, ====> ev-body($princ revokes $var(!) $chain ; $body,,$pc)= ev-body($body,,$pc)
[Error-revoke-write-1] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $d:=lookup($dl,$var), ($dw,$dr):=$d, $princip*2:=chainSeqPrinc($chain), $dl’:=store($dl,$var,(union(difference($dw,return3SetofChains($dw,$princip*2,$princ)), return4SetofChains($dw,$princip*2,$princ)),$dr)), $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==false, $label2:=dl2label($s,$dl,$var), $label3:=label($s,$dl,$pc), LessRestrictive($label3,meet($label1,$label2))==false ====> ev-body($princ revokes $var(!) $chain ; $body,,$pc)= Disallowed information flow with revocation [Revoke-read] $VarList1:=listDeclaredVariables($v),
167
AppendixB. The equation part of language evaluator
elem($var,$VarList1)==true, $d:=lookup($dl,$var), ($dw,$dr):=$d, $princip*2:=chainSeqPrinc($chain), semch*:={([],0),([client],1)}, $dr1:=union(difference($dr,returnSetofChains($dr,$princip*2)),semch*), $dl’:=store($dl,$var,($dw,$dr1)),%%%union(difference($dr,returnSetofChains($dr,$princip*2)), return2SetofChains($dr,$princip*2)))), $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==true, $label2:=dl2label($s,$dl,$var), $label3:=label($s,$dl,$pc), LessRestrictive($label3,meet($label1,$label2))==true, $result:=ev-body($body,,$pc) ====> ev-body($princ revokes $var(*) $chain ; $body,,$pc)=$result [Error-Revoke-read-00] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==false ====> ev-body($princ revokes $var(*) $chain; $body,,$pc)= The variable $var is not declared [Error-Revoke-read] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $d:=lookup($dl,$var), ($dw,$dr):=$d, $princip*2:=chainSeqPrinc($chain), semch*:={([],0),([client],1)}, $dr1:=union(difference($dr,returnSetofChains($dr,$princip*2)),semch*), $dl’:=store($dl,$var,($dw,$dr1)), return2SetofChains($dr,$princip*2)))), $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==true, $label2:=dl2label($s,$dl,$var), $label3:=label($s,$dl,$pc), LessRestrictive($label3,meet($label1,$label2))==false ====> ev-body($princ revokes $var(*) $chain ; $body,,$pc)= Disallowed information flow with revocation
[Revoke-read-1] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $d:=lookup($dl,$var), ($dw,$dr):=$d, $princip*2:=chainSeqPrinc($chain), $dl’:=store($dl,$var,($dw,union(difference($dr,return3SetofChains($dr,$princip*2,$princ)), return4SetofChains($dr,$princip*2,$princ)))), $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==false, $label2:=dl2label($s,$dl,$var), $label3:=label($s,$dl,$pc), LessRestrictive($label3,meet($label1,$label2))==true, $result:=ev-body($body,,$pc) ====> ev-body($princ revokes $var(*) $chain ; $body,,$pc)=$result [Error-Revoke-read-1]
168
B.13. The equation part of Revocation module
$VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $d:=lookup($dl,$var), ($dw,$dr):=$d, $princip*2:=chainSeqPrinc($chain), $dl’:=store($dl,$var,($dw,union(difference($dr,return3SetofChains($dr,$princip*2,$princ)), return4SetofChains($dr,$princip*2,$princ)))), $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==false, $label2:=dl2label($s,$dl,$var), $label3:=label($s,$dl,$pc), LessRestrictive($label3,meet($label1,$label2))==false ====> ev-body($princ revokes $var(*) $chain ; $body,,$pc)= Disallowed information flow with revocation
[Revoke-read-write] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $d:=lookup($dl,$var), ($dw,$dr):=$d, $princip*2:=chainSeqPrinc($chain), $dl’:=store($dl,$var,(union(difference($dw,returnSetofChains($dw,$princip*2)), return2SetofChains($dw,$princip*2)),union(difference($dr,returnSetofChains($dr,$princip*2)), return2SetofChains($dr,$princip*2)))), $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==true, $label2:=dl2label($s,$dl,$var), $label3:=label($s,$dl,$pc), LessRestrictive($label3,meet($label1,$label2))==true, ====> ev-body($princ revokes $var(*,!) $chain ; $body,,$pc)= ev-body($body,,$pc)
[Error-Revoke-read-write-00] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==false ====> ev-body($princ revokes $var(*,!) $chain ; $body,,$pc)= The variable $var is not declared
[Error-revoke-read-write] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $d:=lookup($dl,$var), ($dw,$dr):=$d, $princip*2:=chainSeqPrinc($chain), $dl’:=store($dl,$var,(union(difference($dw,returnSetofChains($dw,$princip*2)), return2SetofChains($dw,$princip*2)),union(difference($dr,returnSetofChains($dr,$princip*2)), return2SetofChains($dr,$princip*2)))), $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==true, $label2:=dl2label($s,$dl,$var), $label3:=label($s,$dl,$pc), LessRestrictive($label3,meet($label1,$label2))==false ====> ev-body($princ revokes $var(*,!) $chain ; $body,,$pc)= Disallowed information flow with revocation
169
Appendix6. The equation part of language evaluator
[Revoke-read-write-1] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $d:=lookup($dl,$var), ($dw,$dr):=$d, $princip*2:=chainSeqPrinc($chain), $dl’:=store($dl,$var,(union(difference($dw,return3SetofChains($dw,$princip*2,$princ)), return4SetofChains($dw,$princip*2,$princ)),union(difference($dr,return3SetofChains($dr,$princip*2,$princ)), return4SetofChains($dr,$princip*2,$princ)))), $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==false, $label2:=dl2label($s,$dl,$var), $label3:=label($s,$dl,$pc), LessRestrictive($label3,meet($label1,$label2))==true, $result:=ev-body($body,,$pc) ====> ev-body($princ revokes $var(*,!) $chain ; $body,,$pc)=$result
[Error-revoke-read-write-1] $VarList1:=listDeclaredVariables($v), elem($var,$VarList1)==true, $d:=lookup($dl,$var), ($dw,$dr):=$d, $princip*2:=chainSeqPrinc($chain), $dl’:=store($dl,$var,(union(difference($dw,return3SetofChains($dw,$princip*2,$princ)), return4SetofChains($dw,$princip*2,$princ)),union(difference($dr,return3SetofChains($dr,$princip*2,$princ)), return4SetofChains($dr,$princip*2,$princ)))), $label1:=lookup($s,$var), elem($princ,ext-ow($label1))==false, $label2:=dl2label($s,$dl,$var), $label3:=label($s,$dl,$pc), LessRestrictive($label3,meet($label1,$label2))==false ====> ev-body($princ revokes $var(*,!) $chain ; $body,,$pc)= Disallowed information flow with revocation
170
هك ا اات ا ا م و ا ت ا ! " #$% آ'& ت ) * وا * ت +ا ./ ,-ا 2' 0"1ا ل أو ا $5 ) آ' 7ن &'%ت * . ،; 8 #9 /+وه ا ا .ASF2' T " 2ض ا = !-ا 0 % 0 ، D RDR. 2ا ا /ا " )H ا ء RDR.ا< ا 0ا "ن ' q 2ال .ASF+SDF
ﺟﺎﻣﻌﺔ ﺍﻟﺰﻗﺎﺯﻳﻖ ﻛﻠﻴﺔ ﺍﳍﻨﺪﺳﺔ ﻗﺴﻢ ﺍﳊﺎﺳﺒﺎﺕ ﻭﺍﳌﻨﻈﻮﻣﺎﺕ
מא
:א
א
א
ﺭﺳﺎﻟﺔ ﺩﻛﺘﻮﺭﺍﻩ ﻣﻘﺪﻣﺔ ﻣﻦ ﺍﳌﻬﻨﺪﺳﺔ
ﺩﻋﺎﺀ ﺣﺴﻦ ﺳﺎﱂ ﳏﻤﺪ ﺗﻮﻃﺌﺔ ﻟﻠﺤﺼﻮﻝ ﻋﻠﻰ
ﺩﺭﺟﺔ ﺩﻛﺘﻮﺭﺍﻩ ﺍﻟﻔﻠﺴﻔﺔ ﰱ
ﻫﻨﺪﺳﺔ ﺍﳊﺎﺳﺒﺎﺕ ﻭﺍﻟﺘﺤﻜﻢ ﺇﺷﺮﺍﻑ
ﺃ.ﺩ /ﺇﺑﺮﺍﻫﻴﻢ ﺍﻟﺴﻴﺪ ﺯﻳﺪﺍﻥ ﻗﺴﻢ ﺍﳊﺎﺳﺒﺎﺕ ﻭﺍﳌﻨﻈﻮﻣﺎﺕ ﻛﻠﻴﺔ ﺍﳍﻨﺪﺳﺔ -ﺟﺎﻣﻌﺔ ﺍﻟﺰﻗﺎﺯﻳﻖ
ﺃ.ﺩ .ﻡ /ﺷﺮﻳﻒ ﳏﻤﺪ ﺍﻟﻘﺼﺎﺹ ﻗﺴﻢ ﻋﻠﻮﻡ ﺍﳊﺎﺳﺐ ﺍﳉﺎﻣﻌﺔ ﺍﻷﻣﺮﻳﻜﻴﺔ ﺑﺎﻟﻘﺎﻫﺮﺓ
٢٠١١م
א א
