Date post: | 14-Jan-2016 |
Category: |
Documents |
Upload: | jacob-french |
View: | 217 times |
Download: | 4 times |
FlexFlow: A Flexible Flow Policy Specification Framework
Shipping Chen, Duminda Wijesekera and Sushil Jajodia
Center for Secure Information Systems
George Mason University
2IFIP11.3-2003
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.
3IFIP11.3-2003
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.
4IFIP11.3-2003
Issues with Existing Proposals
• Security labels or access control lists limits for applications.
• Application/model specificity.
• No prohibitions.
• Cannot combine policies across levels.
5IFIP11.3-2003
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.
6IFIP11.3-2003
FlexFlow System Architecture
7IFIP11.3-2003
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.
•o5
•o4•o3
•o2•o1
8IFIP11.3-2003
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.
•o1
•o2
•o5
•o3
•o2
•0
•1
•2
9IFIP11.3-2003
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.
10IFIP11.3-2003
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].
11IFIP11.3-2003
An Example Flow Tree
12IFIP11.3-2003
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).
13IFIP11.3-2003
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.
14IFIP11.3-2003
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.
15IFIP11.3-2003
An Example
• Assumption.– Using nodes xn as object and environment xe as
subject, the owner of the object.
• Base relations specification rules.
16IFIP11.3-2003
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.
17IFIP11.3-2003
Example Continued
• Conflict resolution rules.
From rule (10) we can get.Flow [(file1,Alice),(file2,Bob)] should be authorized.
• Decision rules.
18IFIP11.3-2003
Express Denning’s Lattice Model
19IFIP11.3-2003
Express Decentralized Label Model Mayer&Liskov
20IFIP11.3-2003
Flexible Flow Control of Ferrari et al.
21IFIP11.3-2003
Express Flexible Flow Control Model Ferrari et al.
22IFIP11.3-2003
Express Flexible Flow Control of Ferrari et al.
23IFIP11.3-2003
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.