Operating System vs.
Network Security
Butler Lampson
Microsoft
Outline
What security is about
Operating systems security
Network security
How they fit together
1
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.
2
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.
3
Dangers
Vandalism or sabotage that
– damages information
– disrupts service
Theft of money
Theft of information
Loss of privacy
Secrecy, integrity, and availability
4
Vulnerabilities
Bad (buggy or hostile) programs
Bad (careless or hostile) people giving
instructions to good programs
Bad guy tapping or interfering with
communications
5
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
6
The Access Control Model
Guards control access to valued resources.
Principal
Do
operation
Reference
monitor
Object
Source
Request
Guard
Resource
7
Mechanisms
Authenticating principals
 Mainly people, but also machines, programs
Authorizing access.
 Usually for groups of principals
Auditing
Trusted computing base
8
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
9
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.
10
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
11
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
12
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
13
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
14
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
15
Principals
Authentication: Who sent a message?
Authorization: Who is trusted?
Principal — abstraction of "who":
– People
– Machines
– Services
Exchange
– Groups
Lampson, Gray
SN12672948, Jumbo
microsoft.com,
UW-CS, MS-Employees
16
What Principals Do
Principal says statement
– Lampson says “read /MSR/Lampson/foo”
– Microsoft-CA says “Lampson's key is #7438”
17
Secure Channel
Says things directly
Has known possible receivers
possible senders
C says s
secrecy
integrity
Examples
– Within a node: operating system (pipes, etc.)
– Between nodes:
» Secure wire
» Network
» Encryption
difficult to implement
fantasy for most networks
practical
18
Speaks For
Principal A speaks for B: A B
– Meaning: if A says something, B says it too.
» Thus A is stronger than B.
– Examples
» Lampson
» Server-1
» Key #7438
 MSR
 MSR-NFS
 Lampson
Handoff rule: If A says B  A then B  A
– Reasonable if A is competent and accessible.
19
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.
20
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.
21
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
22
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
23
Checking Access
Given
a request
an ACL
read/write O
Q says read O
P may
P read/write O
Check that Q speaks for P
QP
rights are enough read/write 
read
O
Q  P read/write
24
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
25
Groups and Group Credentials
A group is a principal; its members speak for it
– Lampson
– Rashid
–. . .
 MSR
 MSR
Proving group membership: Use certificates.
– Kmsr says Lampson  Kmsr / MSR
These certificates are public too
26
Authenticating Systems
A machine can store its own secret key
A program can be authenticated by a digest:
– Kca says
formally
“If I has digest X then I is program P”
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
27
Auditing
Checking access:
– Given
a request
an ACL
read/write O
Q says read O
P may
– Check that Q speaks for P Q  P
rights suffice read/write 
read
Auditing
– Each step is justified by
» a signed statement (certificate), or
28
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.
29
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-spkicert-structure-02.txt
30