Department of Computer Science Security Policy Cognizant Module
Total Page:16
File Type:pdf, Size:1020Kb
Department of Computer Science 4400 University Drive MS#4A5 Fairfax, VA 22030-4444 USA George Mason University http://cs.gmu.edu/ Technical Report Series 703-993-1530 Security Policy Cognizant Module Composition Paul Seymer, Angelos Stavrou, Duminda Wijesekera, and Sushil Jajodia {pseymer|astavrou|dwijesek|jajodia}@gmu.edu Technical Report GMU-CS-TR-2010-1 Abstract curity and performance policies. For QoP, we show two kinds policies; viz., access to individual modules and in- Component-based software development and deploy- formation flown between them as a consequent to com- ment is based on developing individual software mod- position. For QoS, we show how to integrate local re- ules that are composed on an as needed basis. Such source control policies of individual modules and com- modules expose the computations they provide and their munication resource policies between them. Figure 1 dependencies on providing these computations - that re- shows our overall architecture. sults in a well known requires-provides specifications As an example, consider multimedia conferencing, for modules. This paper provides a framework to com- where the conference coordinator residing at one site bine modules that specify their requires-provides inter- wants to use two other conferees with differing comput- faces in a policy dependent way. Our framework specify ing and communicating resources that are subjected to policies as combinations of Constraint Logic Program- different access control and communication policies. For ming (CLP) based rules and our policies can cover mul- example, the coordinator may reside at a site that allows tiple aspects associated of compositions, such as secu- video, audio, and HAIPE encryption, where one partici- rity and quality of service. We apply our framework to pantwith a land-linemay only be allowed to use DES en- specify Quality of Protection (QoP) and Quality of Ser- cryption with audio and video capabilities and the other vice (QoP) policies. An example shows the applicability participant joining by mobile telephone may only have of our policy language to a teleconferencing application the audio stream, but no video or encryption capabilities. with multiple security and resource usage policies. Consequently, for the modules to be correctly composed, the conference should deliver both audio and video en- crypted using DES to the second participant and only an 1 Introduction audio stream to the third participant. In component-based software development, modules are The advantage of this framework are many. Firstly, it developed independently and composed on an as needed separates independent aspects of composition (e.g. QoP basis [30]. In order to facilitate such compositions (ei- and QoS) from structural composability criteria. Sec- ther statically or dynamically), the composer needs to ondly, it further provides a framework to separates dif- be aware of what each module provides as a service and ferent sub-aspects within an aspects. Thirdly, it provides what it requires in order to provide that service - result- a basis to reason about all aspects and sub-aspects uni- ing in the well known requires-provides specification of formly. Lastly, it adds policies to aspect-oriented com- modules. Making these requires-provides interfaces pol- position. icy dependentis the objectiveof this paper. In order to do The rest of the paper is written as follows. Section 2 so, we propose a Constraint Logic Programming based presents the formal language of the rule-based composi- rule language to specify the requires-provides policies. tion framework that is sufficiently expressible to accom- Our sample policies shown in this paper addresses two modate many notions of module composition mostly re- aspects of software composition; viz., Quality of Protec- flecting existing definitions. Section 3 presents the sub- tion (QoP) and Quality of Service (QoS), specifying se- language for security policies. Section 4 presents the 1 QoS QoS n. Policy E x po rt The rest of the paper uses names starting with an upper rt E xpo x E p o r t case letter for variables and names starting with a lower Local Local QoS Communication QoS QoS case letter for constants, and sometimes use a name with a hat above (for example ReqM) to describe a term with Export d Composition variables and constants, when it is too long the write out Provides Module1 Module2 Requires Requires Provides the details within a rule. We now describe the other parts of our language. Export Global flow module(Name,Location,Req,Prov,Depth): Local Local control policy Security access control access control policy policy is a 5-ary predicate where the Name is a constant or Export variable from Set representing a name. Similarly, Exp ort N ort Security Exp Policy Location is a constant or a variable from SetL, representing a location (or a set of locations). Req Figure 1: Architecture of the Policy Framework is a constant or a variable representing an ordered triple of the type SetI × SetQoP × SecQoS used to model a set with elements of the form (interface, Set of QoP and QoS options) representing the collection sub-language for QoS policies. Section 5 presents the of requires interfaces with their options and Depth semantics and models for module composition syntax. (sometimes denoted as ’Z’) is a set term used to encode Section 6 presents an example composition of a telecon- the recursive depth. Similarly, Prov is a constant or ference. Section 7 presents related work and Section 8 variable from the same type as that of Req, representing presents our conclusions. the interfaces and the options of the provides interfaces of the component. In this version where we do not use recursive compositions, we use the value of ∅ for the 2 A Rule-based Language to Spec- Depth attribute. ify Module Composition cModule(Name,Location,Req,Prov,Depth):] is a 5-ary predicate with the same type of predicates We propose using a set constraint based logic program- as the module predicate, representing a composed ming language to specify policies. The version of set module. In this version where we do not use recursive theory we use is CLP(SET ), the hereditarily finite set compositions, we use the value of ∅ for the Depth theory developed by Dovier et al. [15, 16, 17], where the attribute. hereditarily finiteness refers to the fact that all sets are composable2(Name1,Location1,Req1,Prov1, constructed out of a finite universe (of so called urele- Name2,Location2,Req2,Prov2,Depth): ments) by applying a finite collection of composition op- is an 9-ary predicate where erators. The set of operators we use are {=, 6=, ∈, 6∈, ∪3, 6 (Name1,Location1,Req1,Prov1), ∪3, k, 6k}, where ∪3 is the ternary predicate X ∪3 Y = Z, (Name2,Location2,Req2,Prov2) are the An analogous explanation applies for ∩3. Similarly X k two components, and the provides interfaces of Y holds iff X ∩ Y = ∅. Our constraints are conjunctions the second are connected to the requires interfaces and disjunctions of these constraint predicates, instanti- of the first and Depth is a set term used to en- ated with terms belonging to a chosen set of sorts. We code the recursive depth. We also use another use five sorts for Modules (N), Locations (L), Interfaces predicate composable3(Name1,Location1, (I), QoP policies (QoP )and QoS options(QoS), respec- Req1,Prov1,Name2,Location2,Req2,Prov2, tively refereed to as KerN ,KerL,KerI ,KerQoP and Name3,Location3,Req3,Prov3,Depth) that KerQoS. Each sort has its own constants and function composes three modules where the provides interfaces symbols. We use five constant symbols to denote un- of the second and the third modules are connected to the defined values ⊥N , ⊥L, ⊥I , ⊥QoP and ⊥QoS to model requires interfaces of the first. partial functions. structOK2(Name1,Location1,Req1,Prov1, In addition, we use sets created with the ∅, such as Name2,Location2,Req2,Prov2,Depth): {∅, {∅}} to model the structure of any well-founded is an 9-ary predicate where finitely branching tree. As will be seen shortly, we (Name1,Location1,Req1,Prov1), use such nested sets to limit the recursive backtracking (Name2,Location2,Req2,Prov2) belong to two through rule chains. We also use nested sets to code in- components and Depth is a set term used to encode the tegers. For example {{. {∅} . .}} where the empty set recursive depth. This predicate specifies the structural ∅ is embedded in n braces is used to represent the integer compatibility requirements between the provider and the 2 requester modules. Similarly, we use a 12-ary predicate 2.2 Structural Composition Policies structOK3(Name1,Location1,Req1,Prov1, Name2,Location2,Req2,Prov2,Name3,, Structural composability can be specified using the set Location3,Req3,Prov3) to model the structural constraint language and other user defined predicates as integrity of a module composed from three sub-modules. given in the following two examples: qopOK2(Name1,Location1,Req1,Prov1, structOK2(N1,L1,Re1, P r1,N2,L2,Re2, P r2,Z) ← Name2,Location2,Req2,Prov2,Depth): cModule(N1,L1,Re1, P r1,S1), is an 9-ary predicate where each of cModule(N2,L2,Re2, P r2,S2), (Name1,Location1,Req1,Prov1) and typeOK2(N1,L1,Re1, P r1,N2,L2, Re2, P r2,Stype), (Name2,Location2,Req2,Prov2) belong to P r1 ∩ P r2= ∅,Re1 ∩ Re2= ∅,Re1 ⊆ P r2, two modules. The predicate qopOK2is used to specify S1,S2,Stype ∈ S. the security policy for module composition. Similarly, we use a 12-ary qopOK3() predicate for composing This example says that two modules N1 and N2 are three modules. structurally compassable iff they do not share any pro- vides interfaces or requires interfaces and the requires qosOK2(Name1,Location1,Req1,Prov1, interfaces of the first module N1 are providedby the sec- Name2,Location2,Req2,Prov2, Depth): is ond module N2.