Authority Analysis for Least Privilege Environments Toby Murray - PowerPoint PPT Presentation

Authority Analysis for Least Privilege Environments 01 Authority Analysis for Least Privilege Environments Toby Murray and Gavin Lowe Oxford University Computing Laboratory

Authority Analysis for Least Privilege Environments 02 The Rise of Least Privilege The principle of least privilege is finally being recognised within mainstream computing. Examples of least- and limited-privilege solutions include • Windows Vista’s User Account Control • Dynamic firewalls • SELinux • And many more... All of these work by limiting the permissions of running application instances.

Authority Analysis for Least Privilege Environments 03 Permissions Permissions The set of objects that the instance can access, or interact with, directly. An instance’s permissions should match its function. In order to achieve least privilege, the permissions of an instance must be dynamic. Otherwise, an instance requires the union of permissions relating to all of its possible functions, completely violating least privilege. But this raises the question: “How can we be sure an instance cannot acquire an unwanted permission?”

Authority Analysis for Least Privilege Environments 04 The Safety Problem The Safety Problem Can a particular instance ever acquire a particular permission? This problem is very well understood. When designing and analysing a limited-privilege system, it is imperative to be able to answer this question in order to demonstrate that untrusted subjects cannot obtain sensitive permissions.

Authority Analysis for Least Privilege Environments 05 Re-Enter an Old Attack Unfortunately, answering the safety question is not enough. What if an untrusted subject can use their minimal permissions to cause unwanted effects? As limited-privilege systems become more common, we are beginning to see more examples of this sort of attack. The basic idea is that one subject, s , is able to use its minimal privileges to cause another subject, t , to perform some action on behalf of s that violates the security policy. Here, s has more authority than it should have.

Authority Analysis for Least Privilege Environments 06 The Confused Deputy Problem The classic example of this vulnerability. Alice has permission to invoke a compiler, Carol . When invoking Carol , Alice supplies the name of a file that is to receive the output of the compilation process. Carol has write access to a special-purpose billing file, Bill , in which she records a log of her own usage. By supplying the name of Bill when invoking Carol , Alice can cause Bill to be overwritten – despite the fact that Alice does not have permission to write to Bill . Carol ’s permissions are being used, incorrectly, on behalf of Alice .

Authority Analysis for Least Privilege Environments 07 Authority Authority All of the indirect effects a subject can cause. Current models for the analysis of the safety problem cannot reason about the indirect effects a subject can cause but only the permissions a subject can acquire. This example highlights the importance of the principle of least authority. It is not enough to simply limit a subject’s permissions in order to enforce meaningful least privilege. We require methods to correctly analyse and detect excess authority.

Authority Analysis for Least Privilege Environments 08 Characterising Authority in CSP We model a system in CSP and use refinement checks to detect and diagnose excess authority. Each system we model comprises a set of objects. Each object has its own alphabet, that defines those events that the object partakes in. An object has excess authority if it can cause some unwanted event to occur. Causation x causes y if y would be possible if x had occurred, but y would not be possible if x had not occurred.

Authority Analysis for Least Privilege Environments 09 Traces-Causation An object with alphabet A can cause some event e to occur if e can follow some trace s , but when the events from A are removed from s , e can’t follow s . Traces-Causation TC P ( A, e ) � = ∃ s • s ˆ � e � ∈ traces ( P ) ∧ ( s \ A )ˆ � e � / ∈ traces ( P ) . NTC P ( A, e ) � = ¬ TC P ( A, e ) Unfortunately, this definition suffers from the refinement-paradox. P = ( a → b → STOP ) ⊓ b → STOP ⊑ Q = a → b → STOP NTC P ( { a } , b ) but TC Q ( { a } , b ).

Authority Analysis for Least Privilege Environments 10 General Causation The refinements of P represent all of the possible ways in which the nondeterminism in P can be resolved. Therefore, we want a general definition of causation that holds precisely when P has a refinement for which Traces-Causation holds. General Causation C P ( A, e ) � = ∃ Q • P ⊑ Q ∧ TC Q ( A, e ) NC P ( A, e ) � = ¬ C P ( A, e ) NC is the refinement-clsoure of NTC . NC P ( A, e ) ≡ ∀ Q • P ⊑ Q ⇒ NTC Q ( A, e )

Authority Analysis for Least Privilege Environments 11 Failures-Causation C P ( A, e ) looks impractical to test, because of the quantification over refinements of P . Fortunately, there is an equivalent definition. An object with alphabet A can cause event e to occur if e can follow some trace s , but that when the events from A are removed from s , it’s possible that e cannot follow, in the sense that it or an earlier event may be refused. Failures-Causation FC P ( A, e ) � = ∃ s, t • s ˆ t ˆ � e � ∈ traces ( P ) ∧ s ` | A � = �� ∧ ( s \ A, { c } ) ∈ failures ( P ) where c = first ( t \ A ˆ � e � ) FC and C are equivalent.

Authority Analysis for Least Privilege Environments 12 Testing for Authority We can construct a refinement test to check for ¬ C P ( A, e ). We generalise the test from a single event e to a set of events B , where A ∩ B = {} : we define NC P ( A, B ) � = ∀ e ∈ B • ¬ C P ( A, e ). We run two copies of P in parallel with a controller process. The left copy of P performs some trace s ˆ t ˆ � e � , where s ` | A � = �� . The right copy of P performs the trace s \ A , after which we test whether it can refuse the event c = first ( t \ A ˆ � e � ). a c e left ✛ ✲ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . s ˆ t ping ping right ✛ ✲ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . s \ A

Authority Analysis for Least Privilege Environments 13 The Test Harness We use a renaming transformation to have each copy of P perform its events on separate fresh channels, left and right . The two copies of P run in parallel with a controller process, Ctrl 1. Harness ( P ) = ( left .P ||| right .P ) � Ctrl 1 { | left , right | } Ctrl 1 = left ? c → ( Ctrl 2 < I c ∈ A> I right .c → Ctrl 1) Ctrl 2 = left ? c → ( Ctrl 2 < I c ∈ A> I ( right .c → Ctrl 2 ⊓ ping → Ctrl 3( c ))) Ctrl 3( c ) = Ctrl 5( c ) < I c ∈ B> I Ctrl 4( c ) Ctrl 4( c ) = left ? d → ( Ctrl 5( c ) < I d ∈ B> I Ctrl 4( c )) Ctrl 5( c ) = ping → right .c → STOP

Authority Analysis for Least Privilege Environments 14 The Specification The most general process that mirrors the behaviour of the harness, but never refuses the final event right .c . Spec 1 = left ? c → ( Spec 2 < I c ∈ A> I ( right .c → Spec 1 ⊓ STOP )) ⊓ STOP Spec 2 = left ? c → ( Spec 2 < I c ∈ A> I ( right .c → Spec 2 ⊓ ping → Spec 3( c ) ⊓ STOP )) ⊓ STOP Spec 3( c ) = Spec 5( c ) < I c ∈ B> I Spec 4( c ) Spec 4( c ) = left ? d → ( Spec 5( c ) < I d ∈ B> I Spec 4( c )) ⊓ STOP Spec 5( c ) = ping → right .c → STOP

Authority Analysis for Least Privilege Environments 15 The Refinement Test Thus, Harness ( P ) will refine Spec 1 if and only if the right-hand copy of P can never refuse the final c event, i.e., if and only if NC P ( A, B ) holds. Spec 1 ⊑ Harness ( P ) ≡ NC P ( A, B ) The refinement can be tested using a model checker like FDR. If the refinement fails, FDR will produce a counter-example. The ping events in the counter-example aid in its interpretation.