1. 1 Operating System vs. Network Security Butler Lampson Microsoft Outline What security is about Operating systems security Network security How they fit together

2. 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. 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. 4 Dangers Vandalism or sabotage that –damages information –disrupts service Theft of money Theft of information Loss of privacy Secrecy, integrity, and availability

5. 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. 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. 7 The Access Control Model Guards control access to valued resources. Reference monitor Object Do operation Resource Principal GuardRequest Source

8. 8 Mechanisms Authenticating principals  Mainly people, but also machines, programs Authorizing access.  Usually for groups of principals Auditing Trusted computing base

9. 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. 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. 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. 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. 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. 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. 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. 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. 17 What Principals Do Principal says statement –Lampson says “read /MSR/Lampson/foo” –Microsoft-CA says “Lampson's key is #7438”

18. 18 Says things directlyC says s Has knownpossible receiverssecrecy possible sendersintegrity Examples –Within a node: operating system (pipes, etc.) –Between nodes: »Secure wiredifficult to implement »Network fantasy for most networks »Encryptionpractical Secure Channel

19. 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. 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. 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. 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 –K microsoft says K bwl  K microsoft / Lampson –These certificates are public Path names can start from anywhere –K microsoft / Lampson / friends –K lampson / friends

23. 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 K ca that “owns” P. Then K ca can authenticate channels from P: –K ca says K ws  K ca / WS –K ca says K bwl  K ca / Lampson Anyone can use these certificates

24. 24 Checking Access Givena request Q says read O an ACL P may read/write O P  read/write O Check thatQ speaks for PQ  P rights are enough read/write  read Q  P  read/write O hence Q  read/write O

25. 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. 26 Groups and Group Credentials A group is a principal; its members speak for it –Lampson  MSR –Rashid  MSR –... Proving group membership: Use certificates. –K msr says Lampson  K msr / MSR These certificates are public too

27. 27 Authenticating Systems A machine can store its own secret key A program can be authenticated by a digest: –K ca says “If I has digest X then I is program P” formally X  P A system can speak for another system: –K ca 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. 28 Auditing Checking access: –Givena request Q says read O an ACL P may read/write O –Check thatQ speaks for PQ  P rights suffice read/write  read Auditing –Each step is justified by »a signed statement (certificate), or »a rule

29. 29 Implement: Tools and Assurance Services — tools for implementation –AuthenticationWho said it? –AuthorizationWho is trusted? –Auditing What happened? Trusted computing base –Keep it small and simple. –Validate each component carefully.

30. 30 References Why “real” security is hard –www.cl.cam.ac.uk/users/rja14www.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.htmltheory.lcs.mit.edu/~cis/sdsi.html Simple Public Key Infrastructure (SPKI) –ftp://ds.internic.net/internet-drafts/draft-ietf-spki- cert-structure-02.txtftp://ds.internic.net/internet-drafts/draft-ietf-spki- cert-structure-02.txt