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

• bject 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 TCP (A, e) = ∃ s • sˆe ∈ traces(P) ∧ (s \ A)ˆe / ∈ traces(P). NTCP (A, e) = ¬TCP (A, e) Unfortunately, this definition suffers from the refinement-paradox. P = (a → b → STOP) ⊓ b → STOP ⊑ Q = a → b → STOP NTCP ({a}, b) but TCQ({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 CP (A, e) = ∃ Q • P ⊑ Q ∧ TCQ(A, e) NCP (A, e) = ¬CP (A, e) NC is the refinement-clsoure of NTC. NCP (A, e) ≡ ∀ Q • P ⊑ Q ⇒ NTCQ(A, e)

Authority Analysis for Least Privilege Environments 11

Failures-Causation

CP (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 FCP (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 ¬CP (A, e). We generalise the test from a single event e to a set of events B, where A ∩ B = {}: we define NCP (A, B) = ∀ e ∈ B • ¬CP (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). ✛ ✲

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

✲ ✛

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

c e ping a ping s \ A sˆt right left

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, Ctrl1. Harness(P) = (left.P ||| right.P)

• {

|left,right| }

Ctrl1 Ctrl1 = left?c → (Ctrl2< I c ∈ A> I right.c → Ctrl1) Ctrl2 = left?c → (Ctrl2< I c ∈ A> I (right.c → Ctrl2 ⊓ ping → Ctrl3(c))) Ctrl3(c) = Ctrl5(c)< I c ∈ B> I Ctrl4(c) Ctrl4(c) = left?d → (Ctrl5(c)< I d ∈ B> I Ctrl4(c)) Ctrl5(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. Spec1 = left?c → (Spec2< I c ∈ A> I (right.c → Spec1 ⊓ STOP)) ⊓ STOP Spec2 = left?c → (Spec2< I c ∈ A> I (right.c → Spec2 ⊓ ping → Spec3(c) ⊓ STOP)) ⊓ STOP Spec3(c) = Spec5(c)< I c ∈ B> I Spec4(c) Spec4(c) = left?d → (Spec5(c)< I d ∈ B> I Spec4(c)) ⊓ STOP Spec5(c) = ping → right.c → STOP

Authority Analysis for Least Privilege Environments 15

The Refinement Test

Thus, Harness(P) will refine Spec1 if and only if the right-hand copy of P can never refuse the final c event, i.e., if and only if NCP (A, B) holds. Spec1 ⊑ Harness(P) ≡ NCP (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.

Authority Analysis for Least Privilege Environments 16

Analysing the Confused Deputy

We model the scenario in CSP. We show how a simple safety analysis fails to detect Alice’s excess authority. We then show a refinement check that accurately detects Alice’s excess authority.

Authority Analysis for Least Privilege Environments 17

The Model

We define a set of operations Op = {Read, Write, Append, Exec} and a set of objects Object = {Alice, Bill, Carol}. Our alphabet is then {o1.o2.op | o1, o2 ∈ Object ∧ op ∈ {Read, Write, Append}} ∪ {o1.o2.Exec.arg | o1, o2 ∈ Object ∧ arg ∈ Object}. An object o is involved in events that represent it operating on some

• ther object p, and events that represent p operating on it. Hence,

the alphabet of each o ∈ Object is defined as: α(o) = { |o.p | p ∈ Object − {o}| } ∪ { |p.o | p ∈ Object − {o}| }.

Authority Analysis for Least Privilege Environments 18

The configuration of permissions is defined by the acl function: acl(Bill, Write) = {Carol}, acl(Bill, Append) = {Carol}, acl(Carol, Exec) = {Alice}, acl(other, other) = {}. We define a set of parameterised CSP processes that represent the behaviour of different types of entities within the system. Compiler(me, logFile) = ?s : acl(me, Exec)!me!Exec?file → me.file.Write → me.logFile.Append → Compiler(me, logFile) File(me) = ?s : acl(me, Write)!me!Write → File(me) ?s : acl(me, Append)!me!Append → File(me) ?s : acl(me, Read)!me!Read → File(me).

Authority Analysis for Least Privilege Environments 19

User(me) = me?prog!Exec?arg → User(me) me?file!Read → User(me) me?file!Write → User(me) me?file!Append → User(me). The total system, System, is then the parallel composition of User(Alice), File(Bill) and Compiler(Carol, Bill), with the above alphabets.

Authority Analysis for Least Privilege Environments 20

A Simple Safety Analysis

We can perform a simple safety analysis to determine whether Alice can ever obtain permission to overwrite Bill. Were Alice able to obtain any permission to Bill, then System would be able to perform some event in { |Alice.Bill| }. We can test whether System is ever able to perform such an event by testing if it refines the most general process that performs no such event: Spec = CHAOSΣ−{

|Alice.Bill| }.

FDR indicates that Spec ⊑T System. As we expect, this simple safety analysis reveals that Alice can never gain permission to overwrite Bill.

Authority Analysis for Least Privilege Environments 21

An Authority Analysis

We now analyse whether Alice has authority to cause Bill to be

• verwritten, i.e., if she can cause some event from

B = {o.Bill.Write | o ∈ Object}. We can check that Alice has no such authority by testing the following refinement, where A = α(Alice). Spec1 ⊑ Harness(System) FDR indicates that this refinement does not hold and provides the following failure as a counter-example. (left.Alice.Carol.Exec.Bill, left.Carol.Bill.Write, ping, ping, {right.Carol.Bill.Write})

Authority Analysis for Least Privilege Environments 22

Discussion

Analysing authority in capability systems. Information flow as authority (or Non-Interference as the absence of authority).