collaborative programming

92
Collaborative Programming Tim Hinrichs University of Chicago

Upload: snow

Post on 06-Jan-2016

29 views

Category:

Documents


0 download

DESCRIPTION

Collaborative Programming. Tim Hinrichs University of Chicago. Collaborative Programming. Settings in which groups of people issue instructions to computer systems. Cooperative goals Competitive goals. Collaborative Programming Languages. Principles of Collaboration - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Collaborative Programming

Collaborative Programming

Tim HinrichsUniversity of Chicago

Page 2: Collaborative Programming

2

Collaborative Programming

Settings in which groups of people issue instructions to computer systems.– Cooperative goals– Competitive goals

Page 3: Collaborative Programming

3

Collaborative Programming Languages

Principles of Collaboration– Information is combined.– No one knows everything.– People never agree on everything.

Required Properties of Collaborative Programming Languages

– Combinable instruction sets– Partial instruction sets– Conflicting instruction sets

Page 4: Collaborative Programming

4

Logical Languages

Benefits:– Combination is relatively straightforward.– Can express partial instruction sets.– Can express conflicting instruction sets.

Drawback:Processing logical languages, especially with

conflicts and incompleteness, can be expensive relative to traditional programming languages.

Page 5: Collaborative Programming

5

Example: Access Control for Files

/common/alice/bob

/common/alice/bob

Files of interest:

/alice Alice rw, Bob r/common Everyone r

/alice Alice rw, Bob r/common Everyone r

/bob Bob rw, Alice r/common Everyone rw

/bob Bob rw, Alice r/common Everyone rw

Page 6: Collaborative Programming

6

Example: Access Control for Files

/common/alice/bob

/common/alice/bob

Files of interest:

/alice Alice +rw, Bob +r-w/common Everyone +r-w

/alice Alice +rw, Bob +r-w/common Everyone +r-w

/bob Bob +rw, Alice +r-w/common Everyone +rw

/bob Bob +rw, Alice +r-w/common Everyone +rw

Page 7: Collaborative Programming

7

Applications

Applications– Security (Authorization Policies)– World Wide Web (Web forms)

Non-Applications– Operating systems– Compilers

Page 8: Collaborative Programming

Network Security

Page 9: Collaborative Programming

9

Local Area Networks

Page 10: Collaborative Programming

10

Network Policy Examples

“Every wireless guest user must send HTTP requests through an HTTP proxy.”

“No phone can communicate with any private computer.”

“Superusers have no communication restrictions.”

Page 11: Collaborative Programming

11

Enforcement Today

10.0.0.1

10.0.0.25

Src IP Port Forward10.0.0.1 80 10.0.0.25

Page 12: Collaborative Programming

12

NOX

Network Operating System • Gives administrators control of the network by

exposing network events, e.g. new-flow, host-join, host-leave, user-authenticate.

• Requires no changes to current OSes.

• Does require changes to current routers.

• Relies on central controller.

Page 13: Collaborative Programming

13

NOX Operation

Page 14: Collaborative Programming

14

NOX Operation

SECURITYPOLICY

Page 15: Collaborative Programming

15

NOX Operation

Page 16: Collaborative Programming

16

Collaborative Programming?

Collaboration– Standard network security approaches

allow admins a great deal of autonomy.– Collaborative Programming techniques

preserve that sense of autonomy.

Programming– Instructions tell computer system how to

route network communications.

Page 17: Collaborative Programming

17

FSL

FSL: Flow Security Language [Hinrichs2009]Balances the desires to make expressing policies natural and implementing policies efficient.

•User source•Host source•Access point source

•User target•Host target•Access point target

•Protocol

Page 18: Collaborative Programming

18

Features

• Distributed policy authorship• External references• Conflict detection/resolution• Incremental policy authorship via priorities• High Performance: 104 queries/second

Layered language:

Logic Data

Keywords

Conflict Resolution

Prioritization

Page 19: Collaborative Programming

19

Datalog with Attachments

Syntaxh :- b1,…,bn,c1,…,cm

• h must exist.• Every variable in the body must occur in h. • No external reference occurs in h. • Nonrecursive sentence sets.

Semantics– Statement order is irrelevant.– Every sentence set is satisfied by exactly one model.

Page 20: Collaborative Programming

20

Keyword: allow

“Superusers have no communication restrictions.”

allow(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) :-superuser(Usrc)

superuser(bob)superuser(alice)

Page 21: Collaborative Programming

21

Keyword: deny

“No phone can communicate with any private computer.”

deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) :-phone(Hsrc) , private(Htgt)

deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) :-private(Hsrc) , phone(Htgt)

private(X) :- laptop(X)private(X) :- desktop(X)

Page 22: Collaborative Programming

22

Keyword: visit

“Every wireless guest user must send HTTP requests through a proxy.”

visit(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot,httpproxy) :-guest(Usrc) , wireless(Asrc) , Prot=http

Page 23: Collaborative Programming

23

Current Keyword List

• allow: allow the flow

• deny: deny the flow

• visit: force the flow to pass through an intermediary

• avoid: forbid the flow from passing through an intermediary

• ratelimit: limit on Mb/second

Page 24: Collaborative Programming

24

Collaborative Programming versus Policy Enforcement

FSL is a Collaborative Programming languageCombinable, partial, conflicting instruction sets

Authorization systems cannot enforce partial or conflicting security policies.

denyavoid

visitallow

ratelimit

denyavoidvisitallowratelimit

Page 25: Collaborative Programming

25

FSL Usage Overview

CombinedPolicy

AnalysisEngine

AuthorizationSystem

Policy1

Policyn

Page 26: Collaborative Programming

26

Conflict Resolution

• Most restrictive: choose instructions that give users the least rights.

• Most permissive: choose policy instructions that give users the most rights.

Implementable using standard Datalog tools.

Most restrictive for just allow and deny…P |=c deny(…) if P |= deny(…)

P |=c allow(…) if P |/= deny(…)

Page 27: Collaborative Programming

27

Deployment Experiences

• FSL has been used for 10 months on a small internal network (about 50 hosts).

• We are preparing for two larger deployments (of hundreds and thousands of hosts).

• So far, policies are expressed over just a few classes of objects. Thus, we expect policies to grow slowly with the

number of principals.

Page 28: Collaborative Programming

28

Related Work

Authorization Language Features in Literature

• Logic: Logic programming, FOL, Modal, Linear• With or without recursion• With or without negation• Handling conflicts• Delegation• History and future-dependent policies• Several metalevel operations• Centralized/decentralized enforcement• Efficiency

For citations, see [Hinrichs2009].

Page 29: Collaborative Programming

29

Datalog as a Collaborative Programming LanguageExpressing conflicts requires keywords.

Benefit:Conflicts can be detected and resolved using traditional inference tools.

Drawback:All possible conflicts must be anticipated at language-design time.

Page 30: Collaborative Programming

World Wide Web Forms

Page 31: Collaborative Programming

31

Web Forms

Page 32: Collaborative Programming

32

Page 33: Collaborative Programming

33

Construction and Maintenance

Central difficulty: constraints interact.

Small constraint changes can correspond to large implementation changes.

Approach: users specify constraints and the computer system generates a spreadsheet.

Small constraint changes now correspond to little work for users.

Page 34: Collaborative Programming

34

Websheet Demo

Live Demo

Page 35: Collaborative Programming

35

Collaborative Programming?

CollaborationMaintenance of web forms requires

collaboration, whether between different people or different instances of the same person.

ProgrammingSpecification-based programming

Page 36: Collaborative Programming

36

Logical Foundations

Cells: unary predicates, e.g. drive and engine.

Constraint: quantifier-free, function-free first-order formula, e.g.

“if the engine is small then the drive is 4x2.”

drive(4x2) V engine(small)

Cell assignment: ground literals, e.g. drive(4x4)

drive(4x2)

Page 37: Collaborative Programming

37

Conflict Detection Proposal

Check if for spreadsheet S S |= drive(4x4) and S |= drive(4x4)

Page 38: Collaborative Programming

38

Problem

Page 39: Collaborative Programming

39

Problem Explanation

S: drive(4x2) V engine(small) drive(4x4) drive(4x2) engine(small) engine(large)

S is inconsistent. Therefore for every predicate p and value a,

S |= p(a) and S |= p(a)

Page 40: Collaborative Programming

40

Paraconsistent Entailment

Definition (Existential Entailment [Hunter98])

existentially entails if there is some satisfiable subset of that entails .

Page 41: Collaborative Programming

41

Performance Demands

Need to compute existential entailment in real-time.

Each cell click requires computing 2n entailment queries, where n is the domain of the cell.

A change to one cell may require updates to many other cells.

Page 42: Collaborative Programming

42

Related Work

Logical spreadsheets– Stanford (Kassoff and Genesereth)– Stony Brook (Ramakrishnan, Ramakrishnan,

Warren)– University of Texas (Gupta and Akhter)– Carnegie Mellon-Qatar (Cervesato)– Several in industry

DARPA small business program in 2004Logical Spreadsheets Workshop in 2005 See [Kassoff2007]

Page 43: Collaborative Programming

43

Classical Logic as a Collaborative Programming LanguageConflicts require no special machinery.

Benefit:Conflicts do not need to be anticipated by the language designer.

Drawback:Automated reasoning tools must implement a paraconsistent version of entailment.

Page 44: Collaborative Programming

Final Words

Page 45: Collaborative Programming

45

Comparison

Logic Conflicts Reasoning Semantics

Datalog keywords standard 1 model

FOL built-in paraconsistent0,1,2,… models

How do we leverage the strength of Datalogwhile retaining the strength of FOL?

Page 46: Collaborative Programming

46

Compilation Approach

FOL Datalog

Two phases:1. Compilation for traditional entailment.2. Compilation for existential entailment.

Page 47: Collaborative Programming

47

Compiler

Definition (Parameterized Theory-Completion): Suppose I is a satisfiable set of constraints. A complete

theory is a parameterized theory-completion of I if

for each predicate p, there are predicates p+ and p- s.t.for every complete theory C,

C U I |=E p(a) iff C U |= p+(a)

C U I |=E p(a) iff C U |= p-(a)

Page 48: Collaborative Programming

48

Summary

Language CompilerRun-time

Environment

Datalog First-order logic

FOL to Datalog

Logic Conflicts Reasoning Example

Datalog keywords standardNetwork Security

FOL built-in paraconsistentLogical

Spreadsheets

Page 49: Collaborative Programming

49

[Hinrichs2008a] T. Hinrichs. Collaborative Programming. IJCAR Workshop on Practical Aspects of Automated Reasoning, 2008. http://people.cs.uchicago.edu/~thinrich/papers/hinrichs2008collaborative.pdf

[Hinrichs2009] T. Hinrichs, et. al. Design and Implementation of a Flow-based Security Language. Under review. Available upon request.

[Kassoff2007a] M. Kassoff and M. Genesereth. PrediCalc: A Logical Spreadsheet Management System. Knowledge Engineering Review, 22(3), 2007, pp. 281-295. http://logic.stanford.edu/~mkassoff/papers/predicalc.pdf

[Kassoff2007b] M. Kassoff and A. Valente. An introduction to logical spreadsheets. Knowledge Engineering Review, 22(3), 2007, pp. 213-219.

[Hunter1998] A. Hunter. Paraconsistent Logics. In Handbook of Defeasible Reasoning and Uncertain Information. http://www.cs.ucl.ac.uk/staff/a.hunter/papers/para.ps

[Hinrichs2008b] T. Hinrichs and M. Genesereth. Injecting the How into the What. KR 2008. http://people.cs.uchicago.edu/~thinrich/papers/hinrichs2008injecting.pdf

Page 50: Collaborative Programming

50

Questions

Page 51: Collaborative Programming

Backup

Page 52: Collaborative Programming

52

According to Webster’s…

col•lab•o•ra•tiveproduced or conducted by two or more parties; can be cooperative or competitive.

pro•gram•mingthe act of issuing instructions, esp. to computer systems.

in•struc•tionsdetailed information telling how something should be done, operated, or assembled.

Page 53: Collaborative Programming

53

Collaborative Programming Overview

Language CompilerRun-time

Environment

First-order logicLogic programmingDescription logics

SAT solversPrologTraditional PL

Use Case (Scripting Language)

LanguageCompiler Run-time

Software

Components

Page 54: Collaborative Programming

Web Form Implementation

Page 55: Collaborative Programming

55

Comparison

Logic Conflicts Reasoning Semantics

Datalog keywords standard 1 model

FOL built-in paraconsistent0,1,2,… models

How do we leverage the strength of Datalogwhile retaining the strength of FOL?

Page 56: Collaborative Programming

56

Compilation Approach

FOL Datalog

Two phases:1. Compilation for traditional entailment.2. Compilation for existential entailment.

Page 57: Collaborative Programming

57

Theory Completion

Central difficulty:A theory with many models (FOL) must be converted to a theory with one model (Datalog).

Consequently:• Compiling FOL to Datalog is a form of theory

completion.• Spreadsheet compilation is a parameterized form of

theory completion.

Page 58: Collaborative Programming

58

Parameterized Theories

The theory that is queried to determine conflicts is comprised of two pieces:

Need a compiler that produces a Datalog program that enumerates the logical consequences for ANY complete theory C.

Incomplete (I)

Complete (C)

FOL Constraints

Current Cell Values

Page 59: Collaborative Programming

59

Compiler

Definition (Parameterized Theory-Completion): Suppose I is a satisfiable set of constraints. A complete

theory is a parameterized theory-completion of I if

for each predicate p, there are predicates p+ and p- s.t.for every complete theory C s.t. C U I is

satisfiable,

C U I |= p(a) iff C U |= p+(a)

C U I |= p(a) iff C U |= p-(a)

Page 60: Collaborative Programming

60

Example

Datalog when engine has a value.

engine+(X) :- engine(X)engine-(X) :- engine(X)trans+(X) :- X=5-speed, engine(small)trans-(X) :- X=5-speed, engine(small)

engine(small) trans(5-speed)FOLConstraints:

Page 61: Collaborative Programming

61

Compiler

Given constraints I,1. Compute resolution closure of I (Res[I]).

2. For each clause in Res[I], produce a series of Datalog queries, introducing 2 keywords per predicate.

NB: Res[I] is always finite because I has only unary predicates.

See [Hinrichs2008b] for more details.

Page 62: Collaborative Programming

62

Existential Entailment

Two possible sources of inconsistency:• Constraints (I)• Cell assignment (C)• Constraints and cell assignments (C U I)

It turns out that the compilation technique just described implements a form of Existential Entailment.

Page 63: Collaborative Programming

63

Summary

Language CompilerRun-time

Environment

Datalog First-order logic

FOL to Datalog Datalog eval

Logic Conflicts Reasoning Example

Datalog keywords standardNetwork Security

FOL built-in paraconsistentLogical

Spreadsheets

Page 64: Collaborative Programming

Intro Backup

Page 65: Collaborative Programming

65

Database Applications

Page 66: Collaborative Programming

66

WWW Privacy

Page 67: Collaborative Programming

FSL Backup

Page 68: Collaborative Programming

68

Negation

“Every user except a guest can ssh into any server.”

allow(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,ssh) :-guest(Usrc) , server(Htgt)

Page 69: Collaborative Programming

69

Traditional Security Mechanisms

NAT: disable incoming connections for laptopsdeny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) :-

laptop(Htgt)

VLAN: isolate machines a,b,cvlan(a), vlan(b), vlan(c)

deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) :-

vlan(Hsrc), vlan(Htgt)

deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) :-

vlan(Hsrc), vlan(Htgt)

Page 70: Collaborative Programming

70

Query Processing Example

“No phone can communicate with any private computer.”

deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) :-phone(Hsrc) , private(Htgt)

deny(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) :-private(Hsrc) , phone(Htgt)

private(X) :- laptop(X)

private(X) :- desktop(X)

Page 71: Collaborative Programming

71

Example Compiled

bool deny (Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) {

return (phone(Hsrc) && private(Htgt)) ||

(private(Hsrc) && phone(Htgt));}

bool private(X) {return laptop(X) || desktop(X);

}

Assume the existence of functions for phone, laptop, desktop.

Page 72: Collaborative Programming

72

Access Control Decision-Making Complexity

Query processing is PSPACE-complete in the size of the policy.

If the number of arguments are bounded by a constant, query processing takes polynomial time in the size of the policy.

If the tallest possible call stack is 1 (ignoring external references), then query processing takes linear time in the size of the policy.

Page 73: Collaborative Programming

73

Implementation Tests

Flows/s Mem (MB)

Rule Matches

0 rules 103,699 0 0

100 rules 100,942 1 2

500 rules 85,373 1 4

1,000 rules 76,336 2 10

5,000 rules 54,416 9 30

10,000 rules 46,956 38 52

Page 74: Collaborative Programming

74

Additive Elaboration

To tighten a FSL security policy, one needs only to add statements to it.

The conflict resolution strategy ensures that the most restrictive constraints are used.

To relax a FSL policy, it is therefore insufficient to simply add statements.

Page 75: Collaborative Programming

75

Relaxing Security

Borrow a mechanism from Cascading Style Sheets (CSS): cascades.

To relax security, FSL allows one policy to be overridden by another policy.

P1 < P2

Any request constrained by P2 is only constrained by P2.

Page 76: Collaborative Programming

76

AlgorithmsGroup Normal Form: every rule body consists

only of external references (and =).

Flattened Cascades: a policy cascade expressed as a flat policy.

Conflict Conditions: conditions on external references under which there will be a conflict.

Conflict-free Normal Form: equivalent policy (under conflict resolution) without conflicts.

Page 77: Collaborative Programming

77

Related Work Comparison

• Not using FOL, Modal logic, Linear logic• No existential variables• No recursion• Fixed conflict resolution scheme• No delegation• No history/future-dependent policies• Centralized enforcement• Limited metalevel operations

• Access control decisions are constraints.• Conflict resolution produces constraint set

Page 78: Collaborative Programming

78

Core Language Application:Conflict Resolution Language

One keyword: resolve, and one external reference: constraint

P1

resolve(deny) :- constraint(deny)resolve(deny) :- constraint(avoid(X)),

constraint(visit(X))P2

resolve(avoid(X)) :- constraint(avoid(X))resolve(visit(X)) :- constraint(visit(X))P3 resolve(allow) :- constraint(allow)

Page 79: Collaborative Programming

79

Ongoing Work

Currently, each flow initiation requires contacting a central controller.

The route for that flow is cached at the router.

Working to generalize this caching scheme. Each trip to the central controller caches more than

just the route for one flow.

Page 80: Collaborative Programming

Spreadsheet Backup

Page 81: Collaborative Programming

81

Mathematical Model

• Each cell is a variable: V

• Each variable has a domain: DV

• Constraints require that certain combinations of variables be assigned certain combinations of values: CV

The purpose of a spreadsheet is to help users enter data by providing feedback when constraints are violated.

Page 82: Collaborative Programming

82

Performance Demands

Need to compute existential entailment in real-time.

Each cell click requires computing O(n) entailment queries, where n is the domain size of the cell.

A change to one cell may require updates to many other cells.

Page 83: Collaborative Programming

Compilation Backup

Page 84: Collaborative Programming

84

Experiments: Two FormulationsFHL:

color(X,Y) adj(X,Z) color(Z,Y)

color(X,Y) node(X) hue(Y)

node(X) X=a1 … X=an

hue(X) X=b1 … X=bm

adj(X,Y) …

X1…Xn. color(a1,X1) … color(an,Xn)

Datalog: ans(X,Y,Z) :- hue(X), hue(Y), XY, hue(Z), YZ

hue(b1) hue(b2) … hue(bm)

Page 85: Collaborative Programming

85

Experiments: Details

• For graph sizes 25, 30, 35,…, 60, tested 20 randomly generated graphs.

• For each graph, tested 3 different hue sets.– k is the maximum degree of the graph.– Graph can always be colored with k+1 colors.– Tested k+1, 2/3k, and 1/3k hues.

• Compilation cost not counted

Page 86: Collaborative Programming

86

Experiments: Results I

Page 87: Collaborative Programming

87

Experiments: Results II

Page 88: Collaborative Programming

Scrap

Page 89: Collaborative Programming

89

External References

Group definitions change far more frequently than security policies.

External references allow a policy to remain unchanged even if the groups it relies upon change often.

visit(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot,httpproxy) :-guest(Usrc) , wireless(Asrc) , Prot=http

Page 90: Collaborative Programming

90

Implementing Existential Entailment

Resolution-based approach: only generate resolvents whose premises are consistent.

DATALOG-based approach: generate database queries that enumerate the existentially-entailed consequences.

Page 91: Collaborative Programming

91

Spreadsheet Compilation

Problem: Compile FOL constraints C to Datalog D s.t. for every cell assignment A

D U A |=D []p(a) iff C U A |=E []p(a)

drive(4x2) V engine(small)

drive(4x4)drive(4x2)engine(small)engine(large)

FOLConstraints:

CellAssignments:

Page 92: Collaborative Programming

92

Message

Logical languages are powerful tools in collaborative settings.

Collaboration breeds conflict.

Embrace conflicts!