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.
IFIP11.3-2003
2
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.
IFIP11.3-2003
3
Issues with Existing Proposals
• Security labels or access control lists limits
for applications.
• Application/model specificity.
• No prohibitions.
• Cannot combine policies across levels.
IFIP11.3-2003
4
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.
IFIP11.3-2003
5
FlexFlow System Architecture
IFIP11.3-2003
6
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.
IFIP11.3-2003
•o5
•o3
•o4
•o2
•o1
7
Flow Trees (Cont.)
•o1
• 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.
•o2
•0
•o5
•o3
•1
•2
•o2
IFIP11.3-2003
8
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.
IFIP11.3-2003
9
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 subtrees 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].
IFIP11.3-2003
10
An Example Flow Tree
IFIP11.3-2003
11
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).
IFIP11.3-2003
12
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.
IFIP11.3-2003
13
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.
IFIP11.3-2003
14
An Example
• Assumption.
– Using nodes xn as object and environment xe as
subject, the owner of the object.
• Base relations specification rules.
IFIP11.3-2003
15
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.
IFIP11.3-2003
16
Example Continued
• Conflict resolution rules.
From rule (10) we can get.
Flow [(file1,Alice),(file2,Bob)] should be authorized.
• Decision rules.
IFIP11.3-2003
17
Express Denning’s Lattice Model
IFIP11.3-2003
18
Express Decentralized Label Model Mayer&Liskov
IFIP11.3-2003
19
Flexible Flow Control of Ferrari et al.
IFIP11.3-2003
20
Express Flexible Flow Control Model Ferrari et al.
IFIP11.3-2003
21
Express Flexible Flow Control of Ferrari et al.
IFIP11.3-2003
22
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.
IFIP11.3-2003
23