1

Operating System vs. Network Security

Butler Lampson

Microsoft

Outline– What security is about– Operating systems security– Network security– How they fit together

2

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.

3

Real-World Security

It’s about value, locks, and police. Good enough locks that bad guys don’t break in

very often. Good enough police and courts that bad guys

that do break in get caught and punished often enough.

As little interference with daily life as possible, consistent with these two points.

4

Dangers

Vandalism or sabotage that – damages information – disrupts service

Theft of money

Theft of information

Loss of privacy

Secrecy, integrity, and availability

5

Vulnerabilities

Bad (buggy or hostile) programs

Bad (careless or hostile) people giving instructions to good programs

Bad guy tapping or interfering with communications

6

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

7

The Access Control Model

Guards control access to valued resources.

Reference monitor

ObjectDo

operation

Resource

Principal

GuardRequestSource

8

Mechanisms

Authenticating principals Mainly people, but also machines, programs

Authorizing access. Usually for groups of principals

Auditing

Trusted computing base

9

Levels of Security

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

10

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.

11

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

12

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 pairkwise secure channels– SIDs include domain ID

13

Distributed Systems Are Different

Big

Heterogeneous and autonomous parts

– In equipment

– In management

Fault tolerant

– Partly broken but still working

All these make authentication harder

14

Web Server Security Today

Simplified from single OS– (Establish secure channel with SSL)– Authenticate user by local password

» (or by local certificate)

– Usually ACL only on right to enter– Map user to her private state

15

Web Browser Security Today

Authenticate server by DNS lookup (?)– (Authenticate server by SSL + certificate)

Authenticate programs by signature– Good programs run as user– Bad programs rejected, or totally sandboxed

16

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

17

What Principals Do

Principal says statement– Lampson says “read /MSR/Lampson/foo”– Microsoft-CA says “Lampson's key is #7438”

18

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

19

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»Server-1 MSR-NFS»Key #7438 Lampson

Handoff rule: If A says B A then B A– Reasonable if A is competent and accessible.

20

Secure Channels via Encryption

The channel is defined by the key:

– If only A knows K–1, then K A.

K says s is a message which K can decrypt.

21

Authorization with ACLs

Access control lists (ACLs)

– An object O has an ACL that says: principal P may access O.

» Lampson may read and write O» MSR may append to O

ACLs must use names for principals

– so that people can read them.

22

Names and Name Spaces: 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

– Kmicrosoft says Kbwl Kmicrosoft / Lampson

– These certificates are public

Path names can start from anywhere

– Kmicrosoft / Lampson / friends

– Klampson / friends

23

Authenticating a Channel

Who can send on a channel?

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

To get this, must trust some principal Kca that “owns” P.

Then Kca can authenticate channels from P:

– Kca says Kws Kca / WS

– Kca says Kbwl Kca / Lampson

Anyone can use these certificates

24

Checking Access

Given a request Q says read O an ACL P may read/write O

P read/write O

Check that Q speaks for P Q Prights are enough read/write read

Q P read/write O

hence Q read/write O

25

What about 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 domain authentication

– Users and ACLs stay the same

(3) Assign SIDs to network principals– Do this automatically– Use network authentication as before

26

Groups and Group Credentials

A group is a principal; its members speak for it– Lampson MSR– Rashid MSR– . . .

Proving group membership: Use certificates.

– Kmsr says Lampson Kmsr / MSR

These certificates are public too

27

Authenticating Systems

A machine can store its own secret key

A program can be authenticated by a digest:– Kca says “If I has digest X then I is program P”

formally X P

A system can speak for another system:– Kca says N P

The first certificate makes N want to run I

The second certificate lets N convince others that N is authorized to run P

28

Auditing

Checking access:– Given a request Q says read O

an ACL P may read/write O

– Check that Q speaks for P Q Prights suffice read/write

read

Auditing

– Each step is justified by

» a signed statement (certificate), or

» a rule

29

Implement: Tools and Assurance

Services — tools for implementation

– Authentication Who said it?

– Authorization Who is trusted?

– Auditing What happened?

Trusted computing base

– Keep it small and simple.

– Validate each component carefully.

30

ReferencesWhy “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