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 • 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
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.
Example: Access Control for Files /common /alice /bob Files of interest: /alice Alice rw, Bob r /common Everyone r /bob Bob rw, Alice r /common Everyone rw
Example: Access Control for Files /common /alice /bob Files of interest: /alice Alice +rw, Bob +r-w /common Everyone +r-w /bob Bob +rw, Alice +r-w /common Everyone +rw
Applications Applications • Security (Authorization Policies) • World Wide Web (Web forms) Non-Applications • Operating systems • Compilers
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.”
Enforcement Today 10.0.0.1 Src IPPort Forward 10.0.0.1 80 10.0.0.25 10.0.0.25
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.
NOX Operation SECURITY POLICY
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.
FSL FSL: Flow Security Language [Hinrichs2009] Balances the desires to make expressing policies natural and implementing policies efficient. • Protocol • User source • Host source • Access point source • User target • Host target • Access point target
Features • Distributed policy authorship • External references • Conflict detection/resolution • Incremental policy authorship via priorities • High Performance: 104 queries/second Layered language: Prioritization Conflict Resolution Keywords Logic Data
Datalog with Attachments Syntax h :- 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.
Keyword: allow “Superusers have no communication restrictions.” allow(Usrc,Hsrc,Asrc,Utgt,Htgt,Atgt,Prot) :- superuser(Usrc) superuser(bob) superuser(alice)
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)
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
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
Collaborative Programming versus Policy Enforcement deny avoid visit allow ratelimit deny avoid visit allow ratelimit FSL is a Collaborative Programming language Combinable, partial, conflicting instruction sets Authorization systems cannot enforce partial or conflicting security policies.
FSL Usage Overview Policy 1 Policy n Combined Policy Analysis Engine Authorization System
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(…)
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.
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].
Datalog as a Collaborative Programming Language Expressing 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.
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.
Websheet Demo Live Demo
Collaborative Programming? Collaboration Maintenance of web forms requires collaboration, whether between different people or different instances of the same person. Programming Specification-based programming
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)
Conflict Detection Proposal Check if for spreadsheet S S |= drive(4x4) and S |= drive(4x4)
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)
Paraconsistent Entailment Definition (Existential Entailment [Hunter98]) existentially entails if there is some satisfiable subset of that entails.
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.
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 2004 Logical Spreadsheets Workshop in 2005 See [Kassoff2007]
Classical Logic as a Collaborative Programming Language Conflicts 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.
Comparison How do we leverage the strength of Datalog while retaining the strength of FOL?
Compilation Approach FOL Datalog Two phases: Compilation for traditional entailment. Compilation for existential entailment.
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 |=Ep(a) iff C U |= p-(a)
Summary Language Compiler Run-time Environment Datalog First-order logic FOL to Datalog
[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