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

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

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

4. Owned Policies for Information Security A Framework for Owned Policies This work: general framework for owned policies that 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 Policies for Information Security 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 o 1 ¸ o o 2 then o 1 can act on behalf of o 2 Set P is a finite set of policies A policy hierarchy ¸ p is a pre-order on P if p 1 ¸ p p 2 then p 1 is at least as restrictive as p 2 A hierarchy H is a pair ( ¸ o, ¸ p )

6. Owned Policies for Information Security 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 label L is a set of owned policies L = {o 1 :p 1, …, o n :p n } Labels can be associated with data

7. Owned Policies for Information Security 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 TopSecret Classified Unclassified AliceCharlie Bob

8. Owned Policies for Information Security 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) 2 X(H, L) if all owners who can act for o allow the data to be used according to p X(H, L) = {(o,p) | 8 o i :p i 2 L. o i ¸ o o ) p ¸ p p i } Captures intuition that i. o i :p i means o i wants p i or something more restrictive enforced ii.if o’ can act for o, then o must “agree with” o’

9. Owned Policies for Information Security Semantics Example Label L = {Alice: Classified, Charlie: TopSecret} With hierarchy H 1 X(H 1, L) = {(Alice,Classified), (Alice,TopSecret), (Charlie,TopSecret), (Bob,TopSecret) } With hierarchy H 2 X(H 2, L) = {(Alice,Classified), (Alice,TopSecret), (Charlie,TopSecret), (Bob,Unclassified), (Bob,Classified), (Bob,TopSecret) } AliceCharlie Bob TopSecret Classified Unclassified TopSecret Classified Unclassified CharlieAliceBob

10. Owned Policies for Information Security 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. Owned Policies for Information Security Structure of Labels For a hierarchy H, can define an ordering on labels! L 1 v H L 2 means “L 2 is at least as restrictive as L 1 in H” Formally: L 1 v H L 2 if (o,p) 2 X(H,L 2 ) ) (o,p) 2 X(H,L 1 ) For any hierarchy H, v H 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. Owned Policies for Information Security Partial Knowledge of Hierarchies Good news: for any H, v H 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. Owned Policies for Information Security 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 L 1 and L 2 L 1 t H L 2 = L 1 [ L 2 Set union [ is a universal join operation

14. Owned Policies for Information Security int{Bob: TopSecret} x := …; int{Charlie: TopSecret} y := …; if (Charlie actsfor Bob) { y := x; } else { y := 0; } Runtime Hierarchy Example runtime test of security hierarchy // Executes if Charlie ¸ o Bob {Bob: TopSecret} v H {Charlie: TopSecret}Charlie ¸ o Bob ) {Bob: TopSecret} v H {Charlie: TopSecret}

15. Owned Policies for Information Security 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. Owned Policies for Information Security 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 hierarchies H: a v H b where a, b are each a constant label or variable But also need to deal with partial knowledge for all possible hierarchies H more specific than H’: a v H b where H’ is a hierarchy representing partial knowledge

17. Owned Policies for Information Security 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: L 1 t H L 2 = L 1 [ L 2

18. Owned Policies for Information Security 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. Owned Policies for Information Security 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