A Configuration-based Environment for Dealing with Multiple Security ...

A Con guration-based Environment for Dealing with Multiple Security Policies in Open Distributed Systems Position Paper

C. Bidan, and V. Issarny IRISA Campus de Beaulieu, Rennes Cedex 35042, FRANCE

Abstract

In today's eld of distributed architectures there is a need for environments allowing the easy development of applications consisting of heterogeneous software modules and running on heterogeneous hardware platforms. From the security point of view, the challenge for such environments is to permit the interoperation between applications specifying dierent, possibly inconsistent security policies. This paper proposes a practical approach for dealing with the coexistence of dierent security policies in distributed architectures. In particular, we integrate security in a con guration-based distributed programming environment, and we demonstrate the capabilities of resulting environment to allow easy speci cations and compositions of security policies. Keywords: Distributed systems, Security policies.

1 Introduction A number of solutions have been proposed to provide the programmer with an environment for building distributed applications from heterogeneous software components and having them running over a set of heterogeneous hardware components. In the context of heterogeneous distributed environments, the goals of distributed architectures is to allow easy interoperation between software components (e.g. [17, 22]). From the security point of view, the interoperability promoted by the above architectures stresses the complexity of security policies which have to be implemented [18, 4], as well as the necessity to cope with the coexistence of multiple security policies. This coexistence results from the interoperation between systems (or software components) having dierent security policy requirements, possibly with dierent granularity. In this paper, we introduce an approach enabling

security managers to implement distributed systems which support multiple security policies. In the framework of con guration-based distributed programming environment, we propose a way to specify access control security policies, and to compose them in a controlled and secure manner. This paper is structured as follows: section 2 gives an overview on security policies composition. Section 3 focuses on the use of a con guration-based distributed programming environment to deal with security policies. We present related work in section 4, and we summarize our contribution and refer to future work in section 5.

2 Composition of security policies Because open distributed systems are unlimited in scale and may be continuously evolving, multiple security policies may coexist, each of them being speci ed for a set of software components. To allow interoperation between software components in such environments without sacri cing security, security managers should be able to deal with the composition of the interoperating systems' security policies. However, various policies can result from the combination of two security policies, as exempli ed below.

Examples. Let us consider a le system where we have two sets of users A and C , and two sets of les B and D. We de ne two access control policies PF1 and PF2 : PF1 authorizes users in A to access les in B , and PF2 authorizes users in C to access les in D. First, we compose these sub-policies so as to build the following composed policy, called PF : the users belonging to both sets A and C (denoted as A \ C ) are authorized to access les in B \ D, users in A

but not in C (denoted as A ; C ) are authorized to access les in B ; D, and nally, users in C ; A are authorized to access les in D ; B . PF is a restriction of the participating policies: some accesses which are authorized in the sub-policies are denied by the policy PF . Let us now compose the sub-policies PF1 and PF2 so as to obtain the following policy, called PF : the users belonging to A\C are authorized to access les in B or in D (denoted as B [ D), users in A ; C are authorized to access les in B ; D, and nally, users in C ; A are authorized to access les in D ; B . PF is consistent with both sub-policies: a user is authorized to access a le in PF if and only if the user is authorized to access this le in both PF1 and PF2 . Another composition of the sub-policies PF1 and PF2 could result in the following policy PF : the users belonging to A [ C are authorized to access les in B [ D. PF is an extension of the participating sub-policies (i.e.. A's users can access D's les). Note that all the above composed policies may be regarded as secure in the context in which they are speci ed. Thus, there is a need for a framework allowing security managers to compose security policies in a controlled and secure way. Our approach relies on the speci cation of security policies and on the de nition of composition operators between these speci cations. The next subsection de nes brie y the speci cation of security policies. De nition of the operators allowing to compose policy speci cations is then proposed. 0

0

0

00

00

2.1 Specifying security policies A security policy de nes a set of rules that specify for each pair of system entities (1 ; 2) (e.g. users, processes, les, software components, etc) whether the 1 entity is authorized to access the 2 entity1 . Since in open distributed architectures, it is not possible to specify a security policy that takes into account the whole set of the system's entities, we de ne a security policy not solely in terms of its access control rules but also in terms of its security domain, that sets the system's entities to which the policy applies. The security domain of a policy is de ned formally in terms of security classi cations. Given a security property P (i.e. a predicate) de ned on the set E of the system's entities, the set of entities holding this property is termed the P classi cation and is noted ClP : ClP = f" 2 E j P (")  trueg = f" 2 E j P g 1 We

do not consider rules denying accesses in the following.

Given the de nition of classi cation, a security domain is de ned as a set of classi cations: Dom = fCli gni=1 . An access control rule  of a given security policy

P is a set of couples of system's entities verifying an

access control predicate P , i.e. a security property bearing on system's entities. Formally,  takes the form  = f(1; 2 ) j (1 2 Cl1 ) ^ (2 2 Cl2 ) ^ P (1 ; 2 )g where Cl1 and Cl2 are two classi cations of P 's security domain. In the remainder, if we let P be an access control policy, its domain is noted Dom , and R is it set of access control rules. P

P

Example.

We now illustrate the previous approach to the policy speci cation with the example of the le system. In the following, we do not specify re exive accesses. Given the previous notation, the two access control policies of the le system example are de ned by:  The security domain of the policy PF1 consists of the users' classi cation A and the les' classi cation C . The policy PF1 has a single access control rule 1 = f(1; 2 ) = (1 2 A) ^ (2 2 B )g, that authorizes A entities to access B entities.  The security domain of the policy PF2 consists of the users' classi cation C and the les' classi cation D. The policy PF2 has a single access control rule 2 = f(1; 2 ) = (1 2 C ) ^ (2 2 D)g, that authorizes C 's entities to access D's entities.

2.2 Composing security policies In our approach, a composed security policy is built by composing two sub-policies. The domain and rules of the composed policy are de ned in terms of the composition of its sub-policies' domains and rules.

2.2.1 Composing access control domain Given two classi cations Cl1 = f" 2 E j P1 g and Cl2 = f" 2 E j P2 g, we de ne three types of composition:  The union operator noted [: Cl1 [ Cl2 = f" 2 E j P1 _ P2 g,  The intersection operator noted \: Cl1 \ Cl2 = f" 2 E j P1 ^ P2 g, and  the product operator noted ] allowing to compute three classi cations: the entities belonging to both classi cations (Cl1 \Cl2 ), the entities only

in Cl1 (i.e. Cl1 ; (Cl1 \ Cl2 )) and the entities only in Cl2 (i.e. Cl2 ; (Cl1 \ Cl2 )). Finally, we de ne denial of composition of two classi cations, with the operator 6 [ (Cl1 6 [Cl2 = ;). The [ operator allows to extend the sub-classi cations. On the other hand, the classi cation obtained by the use of the \ operator is a restriction of the sub-classi cations. The ] operator permits to distinguish the entities belonging to a single subclassi cation from the entities belonging to both subclassi cations. The de nition of the composition of security domains follows directly: it amounts to specify the type of composition for each pair of classi cations of the sub-policies' domains. Let Dom1 = fCli gni=1 and Dom2 = fClj gmj=1 be two security domains. Let
= fi;j 2 f[; \; ]; 6 [g; i = 1; :::; n; j = 1; :::; mg be the set specifying the composition of classi cations Cli with Clj . The composed security domain Dom resulting from the composition of Dom1 with Dom2 with respect to
, is given by: Dom = f8 i = 1; :::; n; 8 j = 1; :::; m; Cli;j = Cli i;j Clj g. Notice that the composed domain can then be composed with another security domain.

2.2.2 Composing access control rules

Let 1 and 2 be two access control rules:  1 = f(1; 2 ) j (1 2 Cl1 ) ^ (2 2 Cl1 )^ P1 (1 ; 2 )g and  2 = f(1; 2 ) j (1 2 Cl2 ) ^ (2 2 Cl2 )^ P2 (1 ; 2 )g. Let us rst suppose that Cl1 = Cl2 and Cl1 = Cl2 . Then, composing 1 and 2 consists of composing their access control predicates P1 and P2 . The logical or operator between predicates allows to compose two access control rules in such a way that the resulting access control rule preserves all the accesses of the subrules. On the other hand, the access control rule resulting from the logical and operator authorizes access if and only if both sub-rules authorize the access. Let us now suppose that Cl1 6= Cl2 and Cl1 6= Cl2 . Then, composing 1 and 2 consists not only in composing the access control predicates, but also in composing the classi cations. Let 1;2 (resp. 1;2 ) be the operator de ned for the composition of the classi cations Cl1 and Cl2 (resp. Cl1 and Cl2 ). If 1;2 = 6 [ or 1;2 = 6 [, then the composition is forbidden. If 1;2 2 f[; \g and 1;2 2 f[; \g, then the composed rule is equivalent to the one computed by composing the rules: 0

0

0

0

0

0

 1 = f(1 ; 2 ) j (1 2 Cl1 1;2 Cl2 )^ (2 2 Cl1 1;2 Cl2 )^ P1 (1 ; 2 )g and  2 = f(1 ; 2 ) j (1 2 Cl1 1;2 Cl2 )^ (2 2 Cl1 1;2 Cl2 )^ P2 (1 ; 2 )g. Finally, if 1;2 = ] or 1;2 = ], we compose the access control predicates only for entities belonging to Cl1 \ Cl2 or to Cl1 \ Cl2 . 0

0

0

0

0

0

0

0

0

0

0

Coupling the operators for composing classi cations and the ones for composing access control predicates allows either to restrict or to extend the access control rules of the sub-policies. In particular, using 1;2 = 1;2 = \ and the logical and operator for composing access control predicates, the  access control rule resulting of the composition of 1 and 2 veri es that: (1 ; 2 ) 2  () (1 ; 2 ) 2 1 and (1 ; 2 ) 2 2 , i.e. the access is authorized if and only if it is authorized by both 1 and 2 ( is more specialized than 1 and 2 in the sense that it provides nest classi cations). 0

Example.

We now illustrate the use of composition operators with the le system example. The composed policy PF authorizes accesses between (A ; C ) and (B ; D), between (A \ C ) and (B \ D), and between (C ; A) and (D ; B ). The speci cations of the PF1 and PF2 policies can be composed to give PF . The distinction between the classi cations (A ; C ), (A \ C ) and (C ; A) (resp. (B ; D), (B \ D) and (D ; B )) is obtained by the operator A;C = ] (resp. B;D = ]). The use of the logical and operator between the rules 1 and 2 enables us to generate the following access control rules:   = f(1 ; 2 ) j (1 2 (A ; C ) ^ (2 2 B ; D)g,   = f(1 ; 2 ) j (1 2 (A \ C ) ^ (2 2 B \ D)g,   = f(1 ; 2 ) j (1 2 C ; A) ^ (2 2 D ; B )g, that is the access control rules of the policy PF . 0

00

Let us note that we do not address the completeness and the soundness of the policy speci cations. These properties are formally de ne elsewhere [3], in which we introduce the notion of secure policy with respect to the proposed speci cations of policy.

0

0

0

0

3 Con guration-based and security

environment

The previous section has introduced a model to specify security policies and a set of composition op-

erators allowing to compose security policy speci cations. In this section, we deal with the integration of this model in a con guration-based environment and we demonstrate the capabilities of the resulting environment for addressing security of interoperating systems.

3.1 What is a con guration-based environment The model of con guration-based distributed programming allows to decouple the interconnection of the application modules from their implementations (e.g. [19, 14, 2, 11]). More speci cally, a con guration-based distributed programming environment consists of i) a Module Interconnection Language (MIL) [19, 6] which allows the programmer to describe the interfaces of its modules, and the interactions among them, and ii) the run-time system or software bus which is possibly customized to satisfy the needs of a given application (e.g. security policy requirements) [10].

interface clt-FS f client typeFD read(typeFD fd, typeBUF buf) client typeINT write(typeFD fd, typeBUF buf) g

that participate, and ii) the bindings between requests and services.

3.2 Integrating security in con gurationbased environment We extend the MIL in order to integrate speci cations of security policies within the declaration of software components. The corresponding security clause de nes the policy's domain and access control rules. Furthermore, in order to address automatic composition of policies, the speci cation of a policy further states the operators that should be used for composing domains and rules. The composition of two policies is then achieved by detecting the smallest composition operators among the one stated for the two policies, according to the following ordering:

 the order between classi cations is inherited from the relation of inclusion: [  ]  \  6 [, and  the order between predicates is based on the relation of implication: _  ^. hierarchical FS-A users-B les f constituents clt-FS; srv-FS; bind

(clt-FS)read : (srv-FS)read; (clt-FS)write : (srv-FS)write;

interface srv-FS f typeFD read(typeFD fd, typeBUF buf) typeINT write(typeFD fd, typeBUF buf)

g

hierarchical File-System f constituents clt-FS; srv-FS; bind g

(clt-FS)read : (srv-FS)read; (clt-FS)write : (srv-FS)write;

Figure 1: Declaring FS's software components.

Example.

Figure 1 contains an example of interface declarations of the le system FS using the MIL. First, the client's interface is declared. The keyword client denotes that the speci c module will issue requests for the declared operation. The declaration of the server FS's interface follows. The third block contains the construction of the le system application based on the declared interfaces, and it is divided in two regions: i) the modules

g

security domain classif Cl-clt : PropertyA composed with union classif Cl-srv : PropertyB composed with union authorized (clt-FS in Cl-clt) to (srv-FS in Cl-srv) : P-access true composed with and Figure 2: Declaring FS's security policy.

Example.

Figure 2 gives the interface of the le system, including the speci cations of the PF1 security policy (see x2). The clause classif allows to associate a name to a security property (i.e. PropertyA or propertyB in the gure). The access control rules can be speci ed in the authorized clause: we specify the entities' classi cation and the access control predicate of each rule. Finally, we give the composition operators for each

classi cation (with the keywords intersection, union, product or none) and for each rule (with the keywords and or or). If we now assume that the speci cations of the security policy PF2 have the same composition operators as the ones of PF1 , the security policy resulting from the composition of PF1 with PF2 policies takes the following form (see the policy PF of the section 2):  The policy's domain consists of two classi cation Cl-clt = A [ C and Cl-srv = B [ D.  The policy has a single access control rule:  = f(1 ; 2 ) j (1 2 Cl-clt) ^ (2 2 Cl-srv) ^ trueg 00

00

Based on the previous model and its integration in a con guration-based environment, we are able to specify and to compose security policy requirements. Then, given the speci cation of a (composed) security policy, we select system components belonging to the Trusted Computing Based [5] in order to implement the required security policy.

4 Related Work Concerning the de nition of a security policy resulting from the composition of security policies, McLean [15] seems to be the rst to propose a formal approach including composition operators: he introduces an algebra of security which enables him to reason about the problem of policy con ict, but he does not resolve the con ict. Hosmer [9] has introduced the notion of metapolicies, or "policies about policies", an informal framework for composing security policies. Bell formalizes this notion by considering the composition of two sub-policies as a function (policy combiner) [1]. Our approach is a practical alternative to Bell's proposal: we clearly identify the set of operators enabling security managers to compose access control policy in a controlled and secure way. The integration of security in large scale distributed systems is not a new concern [16]. The emerging object-based architectures [17, 22] renew the interest in security issues, and lead to the dissociation of implementation from security constraints [18, 4]. However, existing work does not deal with the composition of security policies, which must be addressed in order to allow the interoperation of software components. On the other hand, recent work uses the object paradigm, and especially the abstract data type so as to ease the security implementation [23]. Like Bell's approach, this work does not propose a set of operators for composing security policies.

Similar to the con guration-based paradigm, the re ective approach enable application programming to be transparently separated from non-functional requirements [13]. More speci cally, re ective programming is interested in the context of object-oriented programming: the notion of meta-object to specify object behaviors allows to use the object paradigm (i.e., the inheritance and the abstract-types) to provide a framework easing the implementation of distributed applications. In particular, Fabre et al. use the re ective approach for implementing reliable and secure distributed applications [7]. Comparing to the above approach, con guration-based environments (e.g., the Aster environment) are able to manage software architectures which are not re ective. In general, con guration-based environments are more

exible when dealing with execution properties (e.g., timeliness, availability, security) than the re ective paradigm. Nevertheless, our approach can be implemented over an re ective operating system as the Apertos system [24]. Finally, to our knowledge, the integration of security speci cation in a con guration-based environment is not addressed elsewhere.

5 Summary Integrating security in a con guration-based distributed environment is a practical approach. It allows to specify, at the application level, the security policy having to be implemented. The set of composition operators enables us to compute the speci cation of the security policy corresponding to the interconnection of two software components. We remark that a similar approach can be used for reasoning about other execution properties (e.g., timeliness, availability). In the Aster framework, we have already considered execution properties relating to Rpc failure semantics [10], and we also investigate availability requirements [20]. We illustrated our approach by an example of a le system. More generally, such an approach can be used to reason about coordination in any distributed system. In particular, one application area for our results can be the World-Wide Web (Www). We are currently examining the automatic customization of a base Www platform for ensuring information exchanges in a secure way. We also consider the use of our approach for reasoning about Java-applets [8], in order to customize the Java Virtual Machine [21] in a controlled and secure way. From the implementation standpoint, we are currently integrating the presented model in Aster en-

vironment [12]. From the theoretical perspective, we are currently working on an extension of the above approach so as to specify and to compose information

ow policies. More information on Aster is available at: http://www.irisa.fr/solidor/work/aster.html

References [1] D. E. Bell. Modeling the Multipolicy Machine. In Proceedings of the New Security Paradigm Workshop, pages 2{9, Aug. 1994. [2] P. Bernstein. Middleware: a Model for Distributed System Services. Communication of the ACM, 39(2), Feb. 1996. [3] C. Bidan and V. Issarny. Dealing with Multi-Policy Security in Large Open Distributed Systems. (Submitted for publication), 1997. [4] R. Deng, S. Bhonsle, W. Wang, and A. Lazar. Integrating Security in CORBA Based Object Architectures. In Proceedings of the IEEE Symposium on Security and Privacy, pages 50{61, May 1995. [5] Department of Defense Standard. Trusted Computer System Evaluation Criteria. Technical Report DoD 5200.28-STD, Dec. 1985. [6] F. DeRemer and H. Kron. Programming-in-the-Large versus Programming-in-the-Small. IEEE Transactions on Software Engineering, 2(2):80{86, June 1976. [7] J. Fabre, T. Perennou, and L. Blain. Meta-Object Protocols for Implementing Reliable and Secure Distributed Applications. Laas Report 95037, Feb. 1995. [8] J. Gosling and H. McGilton. The Java Language Environment. Technical white paper, Sun Document, 1995. [9] H. Hosmer. Metapolicies II. In Proceedings of the 15th National Computer Security Conference, pages 369{378, 1992. [10] V. Issarny and C. Bidan. Aster: A Framework for Sound Customization of Distributed Runtime Systems. In Proceedings of the Sixteenth IEEE International Conference on Distributed Computing Systems, 1996. [11] V. Issarny and C. Bidan. Aster: A Corba-Based Software Interconnection System Supporting Distributed System Customization. In Proceedings of the Third International Conference on Con gurable Distributed Systems, 1996. [12] V. Issarny, C. Bidan, and T. Saridakis. Customizing Middleware to Meet Quality of Service Constraints. (Submitted for publication), 1997. [13] P. Maes. Concepts and Experiments in Computational Re ection. In Proceedings of Object-Oriented Programming Systems, Languages and Applications Conference, pages 147{155, 1987.

[14] J. Magee, N. Dulay, and J. Kramer. A Constructive Development for Parallel and Distributed Programs. In Proceedings of the International Workshop on Con gurable Distributed Systems, 1994. [15] J. McLean. The Algebra of Security. In Proceedings of the 1988 IEEE Computer Society Symposium on Security and Privacy, pages 2{7, Apr. 1988. [16] National Computer Security Center. Trusted Network Interpretation of the TCSEC. Technical Report NCSC-TG-005, July 1987. [17] OMG. The Common Object Request Broker: Architecture and Speci cation { Revision 2.0. Technical report, OMG Document, 1995. [18] OMG Security Working Group. White Paper on Security. TC Document 94.4.16, OMG, Apr. 1994. Available by ftp at ftp.omg.org:/pub/docs. [19] J. M. Purtilo. The Polylith software bus. ACM Transactions on Programming Languages and Systems, 16(1):151{174, 1994. [20] T. Saridakis and V. Issarny. Towards Formal Reasoning on Failure Behaviors. In Proceedings of the 2nd European Research Seminar on Advances in Distributed Systems, 1997. [21] Sun Microsystems Inc. The Java Virtual Machine Speci cation. Technical report, Sun Document, 1995. [22] TINA-C. TINA Object De nition Language (TinaOdl) Manual { Version 1.3. Technical Report TR NM.002 1.3 95, TINA-C Document, 1995. [23] L. van Doorn, M. Abadi, M. Burrows, and E. Wobber. Secure Network Objects. In Proceedings of the IEEE Symposium on Security and Privacy, pages 211{221, May 1996. [24] Y. Yokote. The Apertos re ective operating system: The concept and its implementation. In Proceedings of the 1992 ACM Conference on Object-Oriented Programming Systems, Languages, and Applications, 1992.