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.