Type-Based Discretionary Access Control Silvia Crafa joint work - PowerPoint PPT Presentation

Type-Based Discretionary Access Control Silvia Crafa joint work with M. Bugliesi and D. Colazzo MYTHS Dipartimento di Informatica Universit` a di Venezia, Ca’ Foscari

Access Control in the pi calculus Printing jobs via a spooler: � Print Spooler S ! spool ( x ) . print � x � � Print Client spool � j 1 � . spool � j 2 � . . . . C • Spooling channel spool publicly known • Can we guarantee that client jobs are printed? • No! ... clients may steel jobs: S | C | ! spool ( x ) . 0 1

Types for Access Control Associate names with capabilities • deliver spooling channel with read-only capabilities � S ( ν spool ) !( p � spool � | spool ( y ) .print � y � ) p ( x : T w ) . x � j 1 � . x � j 2 � . . . . � C • p is the connecting port, publicly known; spool is the spooling channel, now private • Can we guarantee that client jobs are printed? • Yes: S | C | p ( x ) . ! x ( y ) . 0 is not type correct ... in all contexts to which p is known as p : (( T ) w ) rw 2

Stronger guarantees may be desirable • Client jobs should not be logged or leaked = ⇒ disallow leaking spoolers like ! spool ( x ) . log � x � . print � x � | log ( y ) .SPY Clients want to receive reliable ackowledgements as in ! s ( x ) .pr � x � | ! pr ( x ) . ( print | ack � x � ) � �� � � �� � print spool must disallow cheating spoolers like the following ! s ( x ) .ack � x � 3

Stronger guarantees may be desirable • Client jobs should not be logged or leaked = ⇒ must disallow leaking spoolers like ! spool ( x ) . log � x � . print � x � | log ( y ) .SPY • Clients want to receive reliable ackowledgements as in ! spool ( x ) . print � x � | ! print ( x ) . ( P | ack � x � ) � �� � � �� � printer spooler = ⇒ must disallow cheating spoolers like ! spool ( x ) . ack � x � 4

Need more informative types • Control the flow of names among system components • One needs the ability to express/enforce discretionary policies of access control governing – which authorities may legally receive values of a given type – what (type) capabilities should be passed along with the values • Capability types, ` a la Pierce-Sangiorgi, do not help provide the intended guarantees 5

Controlling delivery of names Associate names with delivery policies • Capability-based control system + new information to describe/prescribe the ways that values may be exchanged among system components. • the new types generalize Group Types [CGG00] G [ T � ∆ ] – G : the authority in control of the values of the type – T : structural information about values – ∆ : delivery policy, to control how values are passed around (to which authorities, with which capabilities) 6

Type based control of the spooler j : Job [ fd � Spool → Print → Client ] ✒ ✻ to be first delivered to the spooler, j is a file descriptor then passed on to the printer, and only then sent back to clients for notification. 7

Type based control of the spooler j : Job [ fd � Spool → Print → Client ] ✒ ✻ to be first delivered to the spooler, j is a file descriptor then passed on to the printer, and only then sent back to clients for notification. spool : Spool [ ( Job [ fd � Print → Client ]) rw � ∆ ] ✒ ■ ✻ spool is a (r/w) channel, spool itself should be delivered controlled by the spooler as dictated by ∆ it carries file desc. which may be passed on to a client only after having been transmitted to the printer 8

Type based control of the spooler J = Job [ fd � Spool → Print → Client ] Spool [ ( Job [ fd � Print → Client ]) rw = � ∆ ] S | {z } SJ j : J , spool : S ⊢ spool ( x : SJ ) . . . . | spool � j � . . . . � �� � � �� � spooler client • x (hence j ) may only be delivered as prescribed by SJ • there is no possibility of logging/cheating: ! spool ( x : SJ ) . ack � x � and ! spool ( x : SJ ) . log � x � . print � x � Note: j must be given different types as it is delivered: Job [ fd � Spool → Print → Client ] Job [ fd � Print → Client ] Job [ fd � Client ] 9

Type Based DAC Policies Our types support powerful policies • delivery chains of bounded/unbounded depth; • multiple (branching) chains along alternative paths G [ T � G 1 → G 2 → G 3 ; G ′ 1 → ( G ′ 2 ; G ′ 3 → G ′ 4 ) ] • delivery at different (super) types depending on recipients n : G [ ( int ) rw � G 1 @ ( int ) w → G 2 @ ( int ) w ; G 3 @ ( int ) r ] Main Result (Safety) In well-typed processes all names flow according to the delivery policies specified by their types, and are received at the intended sites with the intended capabilities. 10

A typed pi calculus with groups Syntax as in [CGG00] ::= 0 | a ( x 1 : τ 1 , . . . , x n : τ n ) .P | a � b 1 , . . . , b n � .P P | ( ν n : τ ) P | ( ν G ) P | P | P | ! P Types generalize those in [CGG00] T ::= B | ( τ 1 , . . . , τ n ) ν ( τ i closed ) Structural Types τ ::= G [ T � ∆] | X | µX. G [ T � ∆ { X } ] Resource Types ∆ ::= [ G i → τ i ] i ∈ I ( G i = G j ⇒ i = j ) Delivery Policies 11

Sample Types • Channels of group G that may be received and re-transmitted at group F only as write-only channels. µX. G [ ( nat ) rw � G → X ; F → µY. G [( nat ) w � F → Y ] ] 12

Sample Types • Channels of group G that may be received and re-transmitted at group F only as write-only channels. µX. G [ ( nat ) rw � G → X ; F → µY. G [( nat ) w � F → Y ] ] • Default entries also allowed: µX. G [ ( nat ) rw � G → X ; Default → µY. G [( nat ) w � Default → Y ] ] 13

Sample Types • Channels of group G that may be received and re-transmitted at group F only as write-only channels. µX. G [ ( nat ) rw � G → X ; F → µY. G [( nat ) w � F → Y ] ] • Default entries also allowed: µX. G [ ( nat ) rw � G → X ; Default → µY. G [( nat ) w � Default → Y ] ] • Two parties, Alice and Bob, establish a private exchange. Alice sends a fresh name c AB to a trusted Server and delegates it to forward it to Bob. The Server should only act as a forwarder, and not interfere with the exchanges between Alice and Bob. c AB : Alice [ ( data ) rw � Server → Alice [( data ) � Bob → Alice [( data ) rw � ]] ] 14

Operational Semantics Different occurrences of the same name may flow along different paths: Let n 1 : G 1 [ . . . ] , n 2 : G 2 [ . . . ] , n 3 : G 3 [ . . . ] and m : G [ B � G 1 → G 2 ; G 3 ]. P � n 1 � m � | n 3 � m � | n 1 ( x ) . n 3 ( y ) . n 2 � x � Q � n 1 � m � | n 3 � m � | n 1 ( x ) . n 3 ( y ) . n 2 � y � P should be safe, Q unsafe, but P → → n 2 � m � ← ← Q . 15

Operational Semantics Different occurrences of the same name may flow along different paths: Let n 1 : G 1 [ . . . ] , n 2 : G 2 [ . . . ] , n 3 : G 3 [ . . . ] and m : G [ B � G 1 → G 2 ; G 3 ]. P � n 1 � m � | n 3 � m � | n 1 ( x ) . n 3 ( y ) . n 2 � x � Q � n 1 � m � | n 3 � m � | n 1 ( x ) . n 3 ( y ) . n 2 � y � P should be safe, Q unsafe, but P → → n 2 � m � ← ← Q . 16

Operational Semantics Use names that are tagged to record their flow history: m [ npq ] n [ ϕ ] � m 1[ ϕ 1 ] , . . . , m k [ ϕ k ] � .A | n [ ψ ] ( x 1 : τ 1 , . . . , x k : τ k ) .B − → A | B { x i := m i [ ϕ i n ] } Now the computation exhibits different flows for P and Q : P = n 1 � m � | n 3 � m � | n 1 ( x ) .n 3 ( y ) .n 2 � x � → → n 2 � m [ n 1 ] � Q = n 1 � m � | n 3 � m � | n 1 ( x ) .n 3 ( y ) .n 2 � y � → → n 2 � m [ n 3 ] � Theorem → ∗ B then | A | �→ ∗ | B | . • If A − • If | A | �→ ∗ Q , then ∃ B such that A − → ∗ B and | B | ≡ Q . 17

Type formation and Subtyping Good types G [ T � G 1 → G [ T 1 � G 2 → G [ T 1 � ∆] ] ] 18

Type formation and Subtyping Good types G [ T � G 1 → G [ T 1 � G 2 → G [ T 1 � ∆] ] ] 19

Type formation and Subtyping Good types G [ T � G 1 → G [ T 1 � G 2 → G [ T 1 � ∆] ] ] • delivery preserves the authority in control of values • T i are supertypes of T 20

Type formation and Subtyping Good types G [ T � G 1 → G [ T 1 � G 2 → G [ T 1 � ∆] ] ] • delivery preserves the authority in control of values • T i are supertypes of T Subtyping ( τ -Type) ( τ -Policy) Γ ⊢ T ≤ T ′ Γ ⊢ ∆ � ∆ ′ G [ T ′ � ∆] Γ ⊢ G [ T � ∆] ≤ Γ ⊢ G [ T � ∆] ≤ G [ T � ∆ ′ ] • ∆ � ∆ ′ implies ∆ ′ is at least as restrictive as ∆ 21

Core Typing Rules Good Messages (Delivery) Γ ⊢ n [ ϕ ] : G [ T � ∆] Γ ⊢ m : G 1 [ T 1 � ∆ 1 ] ( G 1 → τ ∈ ∆) ’or’ ( Default → τ ∈ ∆) Γ ⊢ n [ ϕm ] : τ Good Processes (Input) Γ ⊢ a : G [( τ 1 , . . . , τ k ) r ] Γ , x 1 : τ 1 , . . . , x k : τ k ⊢ P Γ ⊢ a ( x 1 : τ 1 , . . . , x k : τ k ) .P (Output) Γ ⊢ a : G [( τ 1 , . . . , τ k ) w ] Γ ⊢ P Γ ⊢ b i : G i [ T i � ∆ i ] Γ ⊢ ∆ i ( G ) � τ i Γ ⊢ a � b 1 , . . . , b k � .P 22

Type soundness Theorem: Access Control Γ ⊢ n [ ϕ ] � a 1 , . . . , a k � .A ′ | n [ ϕ ′ ] ( x 1 : ρ 1 , . . . , x l : ρ l ) .B ′ If then 23