Operating System vs. Network Security

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. Do Reference Object Principal operation monitor Request Guard Source Resource

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 insteadSecure 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. Secure Channel • Says things directly Csayss • 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

19. 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 Þ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. • Ksayss 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 • KmicrosoftsaysKbwlÞ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: • KcasaysKwsÞKca / WS • KcasaysKbwlÞKca / Lampson • Anyone can use these certificates

24. Checking Access • Given a request Qsaysread O an ACL P may read/write O PÞread/writeO • Check that Q speaks for PQÞP rights are enough read/writereadQÞP Þread/writeO • henceQÞread/writeO

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. • KmsrsaysLampson Þ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: • Kcasays “If I has digest X then I is program P”formallyXÞP • A system can speak for another system: • KcasaysNÞ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 Qsaysread O an ACL P may read/write O • Check that Q speaks for PQÞP rights 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. References • Why “real” security is hard • www.cl.cam.ac.uk/users/rja14 • Distributed system security • Lampson et al. TOCS10, 4 (Nov. 1992) • Wobber et al. TOCS12, 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