Owned Policies for Information Security

1. Owned Policies for Information Security Hubie Chen Stephen Chong Cornell University

2. Owned Policies • Information often has owners • Owners may want system to enforce a policy that restricts use of info)owned policy

3. Access control Principals Access control lists(restrict access to info) ORAC [MMN90] Software components Software producers Software licenses (restrict software composition) Gnu Public License Owned Policies Examples Example Owners Policies Information flow Principals Restrict flow of info Decentralized Label Model [ML98] sets of readers

4. A Framework for Owned Policies • This work: general framework for owned policiesthat allows • reasoning about owned policies • even with only partial knowledge of security policy structure • inference of owned policies • Results apply to all instantiations of framework • Generalizes and inspired by decentralized label model [Myers+Liskov ’98]

5. Owned Policy Model • Set O is a finite set of owners • typically principals • can represent groups and roles • An owner hierarchy ¸o is a pre-order on O • if o1¸oo2 then o1 can act on behalf of o2 • Set P is a finite set of policies • A policy hierarchy ¸p is a pre-order on P • if p1¸pp2 then p1 is at least as restrictive as p2 • A hierarchyH is a pair (¸o, ¸p)

6. Owned Policy Model ctd. • An owned policy is a pair o:p • Owner o wants policy p or a more restrictive policy (wrt ¸p) enforced • A labelL is a set of owned policies L = {o1:p1, …, on:pn} • Labels can be associated with data

7. TopSecret Charlie Alice Classified Bob Unclassified Example • Owner hierarchy ¸o Policy hierarchy ¸p • Consider label {Alice: Classified, Charlie: TopSecret} • Alice specifies at least policy Classified should be enforced • Bob does not specify any policy • Charlie specifies at least policy TopSecret should be enforced

8. Semantics • Semantics of a label L are relative to a hierarchy H = (¸o, ¸p) • Semantics are a set of permissions • Permission (o, p) means o allows the data to be used according to p • Semantics X(H, L) • (o,p)2X(H, L) if all owners who can act for o allow the data to be used according to p • X(H, L) = {(o,p) | 8oi:pi2L. oi¸oo)p¸ppi} • Captures intuition that • oi:pi means oi wants pi or something more restrictive enforced • if o’ can act for o, then o must “agree with” o’

9. TopSecret TopSecret Alice Charlie Classified Classified Bob Unclassified Unclassified Alice Bob Charlie Semantics Example • Label L = {Alice: Classified, Charlie: TopSecret} • With hierarchy H1 X(H1, L) = { (Alice,Classified), (Alice,TopSecret), (Charlie,TopSecret), (Bob,TopSecret) } • With hierarchy H2 X(H2, L) = { (Alice,Classified), (Alice,TopSecret), (Charlie,TopSecret), (Bob,Unclassified), (Bob,Classified), (Bob,TopSecret) }

10. Using Labels int{Alice: Classified}x := …; int{Bob: TopSecret} y := …; int{ ????????? }z := x + y; • Question: What should the label for z be? • z should be: • at least as restrictive as {Alice: Classified}; and • at least as restrictive as {Bob: TopSecret} • )z should be at least {Alice: Classified} “join” {Bob: TopSecret}

11. Structure of Labels • For a hierarchy H, can define an ordering on labels! • L1vHL2 means “L2 is at least as restrictive as L1 in H” • Formally: L1vHL2 if (o,p) 2 X(H,L2) ) (o,p) 2 X(H,L1) • For any hierarchy H, vH forms a lattice • Very few restrictions on H, O or P! • This lattice structure is useful when info is combined (e.g., composition, computation) • Joins arise when many labeled input produces an output • Label of output should be at least as restrictive as label of inputs

12. Partial Knowledge of Hierarchies • Good news: for any H, vH forms a lattice • Bad news : don’t know everything about H! • Runtime hierarchy often unknown at compile-time • E.g., • only managers are allowed to see info • ⇒ Alice can see info only if Alice is a manager • But Alice may be promoted or fired between runs of the system! • Framework permits reasoning with only partial knowledge of runtime hierarchy

13. Universal Join int{Alice: Classified}x := …; int{Bob: TopSecret} y := …; int{Alice: Classified; Bob: TopSecret}z := x + y; • Thm:For any hierarchy H and all labels L1 and L2L1tHL2 = L1[L2 • Set union [ is a universal join operation

14. Runtime Hierarchy Example int{Bob: TopSecret}x := …; int{Charlie: TopSecret}y := …; if (CharlieactsforBob) { y := x; } else { y := 0; } runtime test of security hierarchy // Executes ifCharlie¸oBob Charlie¸oBob) {Bob: TopSecret}vH{Charlie: TopSecret} {Bob: TopSecret}vH{Charlie: TopSecret}

15. Label Inference • Program analysis generally requires explicit security labels • Burden on programmer to provide them • Clutters program code • Automatic inference of labels can reduce need for explicit labels

16. Label Inference Constraints • Infer labels by generating and solving a set of constraints. • Constraints need to deal with unknown run-time hierarchy for all possible hierarchiesH: avHb where a, b are each a constant label or variable • But also need to deal with partial knowledge for all possible hierarchiesH more specific thanH’: avHb where H’ is a hierarchy representing partial knowledge

17. Label Inference • Determining if set of constraints has solution is poly-time tractable • Finding most-restrictive solution is poly-time tractable • Existence of universal join [ is crucial to results • Set union [ has property: for all hierarchies H: L1tH L2 = L1[L2

18. Dynamic Owners, Policies, Labels • Can reason about dynamic owners and dynamic policies • Just a lack of knowledge of runtime hierarchy • Future work: incorporation of dynamic labels…

19. Conclusions • General framework for owned policies • General results, applicable to any instantiation • Lot of structure in labels with few restrictions on owners or policies • Tractability results for inference