Piotr KaminskiJuly 18, 2003

SEng 480a / CSc 586a: Capability Security2

30 Minute 30 Minute RoadmapRoadmap

1. From traditional methods to capabilities

2. Problems solved by capabilities

3. Some objections addressed

SEng 480a / CSc 586a: Capability Security3

Rotate Tradition Rotate Tradition 9090°°

Firewalls, file permissions, stack introspection, …

open namespace + logic wall = a leaky sievedifficult to code, performance suffers too

Authorization policiesA

B

C

File1

File2

File3

R

R

RW

R

W

W

RW

Access Control ListsCapabilities

File1

File2

File3

Alice {r} {r} {}

Bob {r,w}

{} {w}

Carol

{r} {w} {r,w}

resources

sub

ject

s

SEng 480a / CSc 586a: Capability Security4

Mechanisms that don’t change:authenticationinformation security (encryption)security testing (?)

Advantagesenable principle of least authorityno designation without authority

pi : PersonalInfo

: Directory: Doctor

1: access(“Bob”)

piR: SecurityManager

1.1: checkLevel(PersonalInfo)

piR : PersonalInfoRead

1.2: create(pi)

2: getSIN()

2.1: getSIN()

3: setSIN(“123”)

Capability Capability DisciplineDiscipline

A capability isa reference to a resource,combined with authority to use that resource,that cannot be forged.

pi : PersonalInfo

: Directory: Doctor

1: access(“Bob”)

pi

2: getSIN()

: SecurityManager

2.1: check(SIN, read)

3: setSIN(“123”) 3.1: check(SIN, write)

SEng 480a / CSc 586a: Capability Security5

Mmm…Tight Mmm…Tight SecuritySecurity

A secure system ensures that subjects are only allowed to perform authorized actions on resources

Principle Of Least Authority(POLA)

Each subject is authorized to perform all and only the actions necessary for

its work.

SEng 480a / CSc 586a: Capability Security6

Policy in the Policy in the MatrixMatrix

POLA depends on:fine resource and subject granularitydynamic resource and subject creationfine authority granularity

Not practical with ACLssubjects per-user or per-roleauthorities are often coarse

Trivial with capabilitiessubjects per-object or per-processauthorities down to individual method level

File1

File2

File3

Alice {r} {r} {}

Bob {r,w}

{} {w}

Carol

{r} {w} {r,w}

resources

sub

ject

s

SEng 480a / CSc 586a: Capability Security7

Confused Confused DeputyDeputy

Scenario:Print spooler component is given authority to write to a billing file, “/etc/bill”.Print spooler accepts a file name from user to save status information.User asks for status to be saved to “/etc/bill”.Print spooler overwrites billing information, user gets free printing.

How to prevent this scenariousing traditional methods?

SEng 480a / CSc 586a: Capability Security8

Objection: Objection: DelegationDelegation

Claim

Capability systems cannot prevent subjects from giving away their

capabilities.

Rebuttal

If two subjects can communicate,even ACLs cannot prevent delegation.

Small print: to guarantee the *-property, the system mustpartition capabilities from data.

SEng 480a / CSc 586a: Capability Security9

: Client : Server

p : Precious

1: getPrecious()

pc2: stillTrusted()

4: fraud()

r : Revokablepc : Precious

1.1: create(p)

1.1: create(r) 3: revoke()

3.12.1: stillTrusted() 2.1.1: stillTrusted()

4.1: fraud()

Objection: Objection: RevocationRevocation

Claim

Once granted, a capability cannot be revoked.

Rebuttal

Revocation is achievablewith a simple design pattern.

: Client : Server

p : Precious

1: getPrecious()

p

2: stillTrusted()

3: fraud()

SEng 480a / CSc 586a: Capability Security10

In the BalanceIn the Balance

In Favour

Principle Of Least Authority upheld

Unseparable designation and authority

Resilient in the face of lazy programmers

Against

Whole-system method, hybridization weakens security

Requires design changes

Doesn’t seem to fit static typing

SEng 480a / CSc 586a: Capability Security11

Practice Makes Practice Makes PerfectPerfect

Past:KeyKOS

Present:EEROSWaterken

Paper:Capability Myths Demolished

Future: Earthweb?

Thank You