230 likes | 440 Views
FlexFlow: A Flexible Flow Policy Specification Framework. Shipping Chen, Duminda Wijesekera and Sushil Jajodia Center for Secure Information Systems George Mason University. Introduction. Information flow control policies specify under what conditions information may be exchanged.
E N D
FlexFlow: A Flexible Flow Policy Specification Framework Shipping Chen, Duminda Wijesekera and Sushil Jajodia Center for Secure Information Systems George Mason University
Introduction • Information flow control policies specify under what conditions information may be exchanged. • Policies vary on: • System levels at which information transfers, • Types and units of information transfer, • Single/multiple destinations. • Objective to model commonalities among policies that govern information flow between abstract entities.
Previous Work • Denning’s lattice model for secure flows. • Flow control based on the security classes of objects. • Ferrari et al.’s model for object-oriented systems. • Flow control based on ACL’s of objects. • Myers+Liskov’s language based flow control. • Flow control based on decentralized labels of program variables. • Bertino et al.’s work on RBAC for work flow systems. • Various type theory based systems.
Issues with Existing Proposals • Security labels or access control lists limits for applications. • Application/model specificity. • No prohibitions. • Cannot combine policies across levels.
What FlexFlow Adds • Provide a logic programming based flow control policies specification language. • Allow permissions and prohibitions. • Does not depend on a specific meta-policy. • Not confined to an application domain. • Can model policies in other frameworks. • Therefore, can mix policies at different system levels.
o5 o3 o4 o1 o2 Flow Trees • FlexFlow has trees referred to as flow trees build up from nodes and branches. • Nodes represent information sources and sinks. • Branches represent pathways taken by information flowing between nodes. • Information flows from the leaves of a tree via intermediate nodes to its root.
o1 o2 0 o5 1 o3 2 o2 Flow Trees (Cont.) • A flow tree can have flow sub-trees. • Depth one flow trees make up the basic units, called one-step flow trees. • Can build larger trees by recursively merging one -step flow trees.
Two Environments • Local Data: node environments have data related to a node. • E.g. ACL of an object, execution role of a task. • Global Data: Tree environments have data related to a whole tree. • E.g. execution time of a flow tree, execution process. • Environments are user definable. • Type and number of variables not specified.
List Representation of Flow Tree • A flow tree is represented as a list. • The head of the list = the root (node, node environment) pair. • The tail of the list includes the leave (node, node environment) pairs or sub-trees encoded as sub-lists. • E.g. [o5, o4, [o3, o2, o1]] represents a tree which rooted at o5 and has leave node o4 and sub-tree [o3, o2, o1].
FlexFlow Syntax • Terms: • Terms made up from constants and variables for nodes, environments and actions. • Constants and variables over lists of (node, env) pairs. • Predicates. • Application specific predicates. • E.g. playRole(xs,xr), isMember((xn,xe),XL).
Special Predicates • safeFlow(xn, xe, XL, <sign>action). • Represents grantable/deniable one-step flow. • xn, xe= destination node,destination env. • XL= a finite list of source (node,env) pairs. • <sign>= flow permission/prohibition. • xaction= name of the one-step flow, e.g. copy, assign.
Predicates of the Framework • safeFlow*(xflowH, xflowEnv,<sign>xaction). • Permitted/prohibited flow tree. • xflowH =A flow tree represented as a list. • xflowEnv =flow tree environment. • finalSafeFlow(xflowH, xflowEnv ,<sign>xaction). • With the same arguments as safeFlow*, • Representing decision made by FlexFlow.
An Example • Assumption. • Using nodes xn as object and environment xe as subject, the owner of the object. • Base relations specification rules.
Example Continued • One-step flow specification rules • Flow tree construction rules From rules (1)—(6) and (7), safeFlow*([(file1,Alice),(file2,Bob)],[ ],+copy) is derivable. From rules (1)—(6) and (9), safeFlow*([(file1,Alice),(file2,Bob)],[ ],-copy) is derivable.
Example Continued • Conflict resolution rules. From rule (10) we can get. Flow [(file1,Alice),(file2,Bob)] should be authorized. • Decision rules.
Ongoing Work • Add constraints specification+resolution capability. • Integrity constraints are an essential part of flow control specification. • E.g. Chinese Wall Model. • Static vs. Dynamic constraints. • Construct Materializations.