Security.PDF

Computer Security in the Real World

Butler Lampson

What people want from computer security is to be as secure with computers as they are in the real

world. Real-world security is about value, locks, and police. When it works, you get good enough

locks (not too many break-ins), good enough police (so break-ins aren't a paying business), and

minimum interference with daily life. Computer security is hard because people don’t trust new

things (especially when they don’t understand them), and computers are fast and complicated. The

kind of computer break-ins most people care about are vandalism or sabotage that damages

information or disrupts service, theft of money or information, and loss of privacy. Some people

think that because computers are precise, perfect computer security should be possible. I'll explain

why this is wrong, and talk about what kind of security is practical and how to get it.

Computer Security in the Real World

Butler Lampson

Microsoft

Outline

What security is about

Operating systems security

Network security

How they fit together

Security: The Goal

People believe that computers are

as secure as real world systems,

and it’s true.

This is hard because:

– People don’t trust new things.

– Computers can do a lot of damage fast.

– There are many places for things to go wrong.

– Anonymous attacks are easy across a network.

Real-World Security

It’s about value, locks, and police.

− Locks good enough that bad guys don’t break in

very often.

− Police and courts good enough that bad guys that do

break in get caught and punished often enough.

− Interferes with daily life less than value of loss.

Dangers

Vandalism or sabotage that

– damages information

– disrupts service

Theft of money

Theft of information

Loss of privacy

integrity

availability

integrity

secrecy

Vulnerabilities

Bad (buggy or hostile) programs

Bad (careless or hostile) people giving

instructions to good programs

Bad guy tapping or interfering with

communications

Defensive strategies

Keep everybody out

– Isolation

Keep the bad guy out

– Code signing, firewalls

Let him in, but keep him from doing damage

– Sandboxing, access control

Catch him and prosecute him

– Auditing, police

The Access Control Model

Guards control access to valued resources.

Reference

monitor

Object

operation

Resource

Principal

GuardRequest

Source

Mechanisms—The Gold Standard

Authenticating principals

− Mainly people, but also machines, programs

Authorizing access.

− Usually for groups of principals

Auditing

Trusted computing base

Levels of Security—Defense in Depth

Network, with a firewall

Operating system, with sandboxing

– Basic OS (such as NT)

– Higher-level OS (such as Java)

Application that checks authorization directly

All need authentication

Why We Don’t Have “Real” Security

People don’t buy it

– Danger is small, so people buy features instead

Secure systems do less because they’re older

− Security is a pain

» It has to be configured correctly

» Users have to authenticate themselves

Systems are complicated, so they have bugs.

KISS – Keep It Simple, Stupid

Operating System Security

Assume secure channel from user

Authenticate user by local password

Map user to her SID + group SIDs

– Local database for group memberships

Access control by ACL on each resource

– OS kernel is usually the reference monitor

– Any RPC target can read SIDs of its caller

ACLs are lists of SIDs

– A program has SIDs of its logged in user

NT Domain Security

Just like OS except for authentication

OS does RPC to domain for authentication

– Secure channel to domain

– Just do RPC(user, password) to get user’s SIDs

Domain may do RPC to foreign domain

– Pairwise trust and pairwise secure channels

– SIDs include domain ID

Distributed Systems Are Different

Autonomous parts

– In equipment

– In management

Fault tolerant

– Partly broken but still working

Web Security Today

Server: Simplified from single OS

– Establish secure channel with SSL

– Authenticate user by local password (or certificate)

– ACL on right to enter, or on user’s private state

Browser: Basic authentication

– Of server by DNS lookup, or by SSL + certificate

– Of programs by supplier’s signature

» Good programs run as user

» Bad ones rejected or totally sandboxed

Principals

Authentication: Who sent a message?

Authorization: Who is trusted?

Principal — abstraction of “who”:

– People Lampson, Gray

– Machines SN12672948, Jumbo

– Services microsoft.com, Exchange

– Groups UW-CS, MS-Employees

What Principals Do

Principal says statement

– Lampson says “read /MSR/Lampson/foo”

– Microsoft-CA says “Lampson's key is #7438”

Says things directly C says s

Has known possible receivers secrecy

possible senders integrity

Examples

– Within a node: operating system (pipes, etc.)

– Between nodes:

» Secure wire difficult to implement

» Network fantasy for most networks

» Encryption practical

Secure Channel

Speaks For

Principal A speaks for B: A ⇒ Β

– Meaning: if A says something, B says it too.

» Thus A is stronger than B.

– Examples

»Lampson ⇒ MSR group of people

»Server-1 ⇒ MSR-NFS group of servers

»Key #7438 ⇒ Lampson key for Lampson

Handoff rule: If A says “B ⇒ A” then B ⇒ A

– Reasonable if A is competent.

Secure Channels via Encryption

The channel is defined by the key:

– Decrypt with K, encrypt with K

–1

– K says s is a message which K can decrypt.

If only A knows K

–1

, then K ⇒ A.

Access control lists (ACLs)

– An object O has an ACL that says:

“Principal P may access O.”

»Lampson may read and write doc

»MSR may append to log

ACLs must use names for principals

– so that people can read them.

For manageability

– ACLs should be length 1—use groups of principals

– ACLs should protect big groups of resources

Authorization with ACLs

P ⇒

r/w

Lampson ⇒

r/w

doc

MSR ⇒

r/w

log

Names: SDSI/SPKI

A name is local to some name space

A name space is defined by a key

The key can bind names in its name space

– K

microsoft

⇒ K

microsoft

/ Lampson

– K

microsoft

says “K

lampson

⇒ K

microsoft

/ Lampson”

Path names can start from anywhere

– K

lampson

/ friends = K

microsoft

/Lampson/friends

lampson

/DNS/MIT/Rivest

= K

MIT

/Rivest

= K

lampson

/Ron

Names

Lampson

Rivest

Microsoft

DNS

MIT

Microsoft

DNS

Rivest

DNS

Microsoft MIT

MIT

Lampson

DNS DNS

Ron

Authenticating a Channel

Who can send on a channel?

– C ⇒ P; C is the channel, P the sender.

Just binding a name. In Microsoft’s name space

– K

microsoft

says “K

⇒ K

microsoft

/ WS”

– K

microsoft

says “K

lampson

⇒ K

microsoft

/ Lampson”

This is transitive, so

– K

lampson

says “K

DES

⇒ K

lampson

” plus implies

– K

DES

⇒ K

microsoft

/ Lampson

Checking Access

Given a request Q says “read O”

an ACL P may r/w O

= P ⇒

r/w

Check Q speaks for P Q ⇒ P

rights are enough r/w ≥ read

Q ⇒ P ⇒

r/w

hence Q ⇒

r/w

Compatibility with Local OS?

(1) Put network principals on OS ACLs

(2) Let network principal speak for local one

– Rivest@lcs.mit.edu ⇒ Redmond\rivest

– Use network authentication

» replacing local or domain authentication

– Users and ACLs stay the same

(3) Assign SIDs to network principals

– Do this automatically

– Use network authentication as before

Groups and Group Credentials

A group is a principal; its members speak for it

–Lampson ⇒ MSR

–Rashid ⇒ MSR

–. . .

Proving group membership: Use certificates.

– K

microsoft

says “Lampson ⇒ K

microsoft

/ MSR”

which is just like

– K

microsoft

says “K

lampson

⇒ K

microsoft

/ Lampson”

Must have groups of principals for manageability

– ACLs should be of length 1

Compound Principals

(A and B) says s = A says s and B says s

(A or B) says s = A says s or B says s

(A as B) says s = A says “B says s”

– Quoting or multiplexing

(A for B) says s ⇐ (B and (A as B)) says s

– Delegation. Examples:

»Workstation-21 for Lampson

»Payroll for Lampson

Authenticating Programs

A program can be authenticated by a digest:

– K

microsoft

says “If image I has digest X then I is Word”

formally “X ⇒ K

microsoft

/ Word”

This certificate makes node N willing to run I

if Word is on the ACL for running on N.

It also makes N assert that the running I is Word.

– K

says “K

as port15 ⇒ K

microsoft

/ Word”

Applications

– Virus control

– Least privilege

Authenticating Systems

A machine N can store its own secret key

A system can speak for another system:

– K

microsoft

says “ N ⇒ K

microsoft

/ Word ”

This certificate lets N convince others that

N is authorized to run Word

– K

says “ K

as port15 ⇒ K

microsoft

/ Word ”

Auditing

Checking access:

– Given a request Q says “read O”

an ACL P may r/w O

– Check Q speaks for P Q ⇒ P

rights suffice r/w ≥ read

Auditing—Each step is justified by

– a signed statement (certificate), or

– a handoff rule

Summary

Gold standard

– Authentication Who said it?

– Authorization Who is trusted?

– Auditing What happened?

Theory

– Principals: keys, names, compound

– Speaks for: handoff, groups

Trusted computing base

– Keep it small and simple.

– Validate each component carefully.

References

Why “real” security is hard

– www.cl.cam.ac.uk/users/rja14

Distributed system security

– Lampson et al. TOCS 10, 4 (Nov. 1992)

– Wobber et al. TOCS 12, 1 (Feb. 1994)

Simple Distributed Security Infrastructure (SDSI)

– theory.lcs.mit.edu/~cis/sdsi.html

Simple Public Key Infrastructure (SPKI)

– ftp://ds.internic.net/internet-drafts/draft-ietf-spki-

cert-structure-02.txt