1. 14.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition The Security Requirements Triad Data confidentiality Privacy Data Integrity System Integrity

2. 14.2 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Assets

3. Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 14: Protection

4. 14.4 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Chapter 14: Protection Goals of Protection Principles of Protection Domain of Protection Access Matrix Implementation of Access Matrix Access Control Revocation of Access Rights Capability-Based Systems Language-Based Protection

5. 14.5 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Goals of Protection Prevent accidental or intentional misuse of a system Accidental  Malicious abuse  Protection problem - ensure that each object is accessed correctly and only by those processes that are allowed to do so.

6. 14.6 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Goals of Protection 3 aspects to a protection mechanism: l Authentication: User identification  Make sure we know who is doing what l Authorization Determination  Figure out what the user is and is not allowed to do l Access enforcement  Make sure there are no loopholes in the system.

7. 14.7 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Improving Protection Guiding principle – principle of least privilege Programs, users and systems should be given just enough privileges to perform their tasks Capabilities are an implementation of this idea Hard to provide foolproof information containment:  A Trojan horse could take page faults and signal to another process Logging Record all important actions and uses of privilege in an indelible file. Correctness proofs Encryption

8. 14.8 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition User Authentication Crucial to identify user correctly, as protection systems depend on user ID User identity most often established through passwords, can be considered a special case of either keys or capabilities Also can include something user has and /or a user attribute Passwords must be kept secret Frequent change of passwords Use of “non-guessable” passwords Log all invalid access attempts Passwords may also either be encrypted or allowed to be used only once

9. 14.9 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Authentication: Identifying Users How to identify users to the system? Passwords  Very common technique  Weak form of prtoection Smart Cards  Electronics embedded in card capable of providing long passwords or satisfying challenge  response queries Biometrics  Who a person IS – Thumbprint – Retina scan

10. 14.10 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Passwords: Secrecy System must keep copy of secret to check against passwords Need to obscure information somehow  Not stored in readable form  Mechanism: one-way transformation should be used Example: UNIX /etc/passwd file passwd  one way transform(hash)  encrypted passwd System stores only encrypted version, so OK even if someone reads the file! When you type in your password, system compares encrypted version Problem: Can you trust encryption algorithm? Example: one algorithm thought safe had back door  Governments want back door so they can snoop Also, security through obscurity doesn’t work “eagle”

11. 14.11 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Passwords: How easy to guess? Ways of Compromising Passwords Password Guessing:  Often people use obvious information like birthday, favorite color, girlfriend’s name, etc… Dictionary Attack:  Work way through dictionary and compare encrypted version of dictionary words with entries in /etc/passwd Dumpster Diving:  Find pieces of paper with passwords written on them  (Also used to get social-security numbers, etc) Phishing

12. 14.12 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Passwords: How easy to guess? Paradox: Short passwords are easy to crack Long ones, people write down! Technology means we have to use longer passwords UNIX initially required lowercase, 5-letter passwords: total of 26 5 =10million passwords  In 1975, 10ms to check a password  1 day to crack  In 2005,.01μs to check a password  0.1 seconds to crack  Even faster today (use multiple processors) Takes less time to check for all words in the dictionary! Password checker https://www.microsoft.com/security/pc-security/password-checker.aspx

13. 14.13 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Passwords: Making harder to crack How can we make passwords harder to crack? Can’t make it impossible, but can help

14. 14.14 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Passwords: Making harder to crack Technique 1: Extend everyone’s password with a unique number (stored in password file) Called “salt”. UNIX uses 12-bit “salt”, making dictionary attacks 4096 times harder Without salt, would be possible to pre-compute all the words in the dictionary hashed with the UNIX algorithm: would make comparing with /etc/passwd easy!

15. 14.15 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Passwords: Making harder to crack Technique 2: Require more complex passwords Make people use at least 8-character passwords with upper-case, lower-case, punctuation, and numbers  70 8 =6x10 14 =6million seconds=69 days@0.01μs/check Unfortunately, people still pick common patterns  e.g. Capitalize first letter of common word, add one digit

16. 14.16 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Passwords: Making harder to crack Technique 3: Delay checking of passwords If attacker doesn’t have access to /etc/passwd, delay every remote login attempt by 1 second Makes it infeasible for rapid-fire dictionary attack Technique 4: Assign very long passwords Long passwords or pass-phrases can have more entropy  (randomness  harder to crack) Give everyone a smart card (or ATM card) to carry around to remember password  Requires physical theft to steal password  Can require PIN from user before authenticates self Better: have smartcard generate pseudorandom number  Client and server share initial seed  Each second/login attempt advances to next random number

17. 14.17 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Passwords: Making harder to crack Technique 5: “Zero-Knowledge Proof” Require a series of challenge-response questions  Distribute secret algorithm to user  Server presents a number, say “5”; user computes something from the number and returns answer to server  Server never asks same “question” twice Often performed by smartcard plugged into system

18. 14.18 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Goals of Protection 3 aspects to a protection mechanism: l Authentication: User identification  Make sure we know who is doing what l Authorization Determination  Figure out what the user is and is not allowed to do l Access enforcement  Make sure there are no loopholes in the system.

19. 14.19 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Authorization Determination Must indicate who is allowed do to what with what ACCESS MATRIX Two general ways of storing the information Access Lists  Indicates which users are allowed to perform which operations Capabilities list  Indicates which files may be accessed in what ways

20. 14.20 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Domain Structure Access list : usually a list of pairs Access-right = where rights-set is a subset of all valid operations that can be performed on the object. Domain = set of access-rights Process operates within a protection domain

21. 14.21 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Domain Structure Association between process and domain can be either STATIC  Fixed  Must provide MOST broad permissions that the process can possible use  May violate the need-to-know principle DYNAMIC  Modify domain protection rights to time of requirement  Allows domain switching

22. 14.22 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Domain Structure A domain can be realized in a variety of ways: Each user can be a domain Each process can be a domain Each procedure can be a domain

23. 14.23 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Domain Implementation UNIX Domain = user-id Domain switch accomplished via file system.  Each file has associated with it a domain bit (setuid bit).  When file is executed and setuid = on, then user-id is set to owner of the file being executed. When execution completes user-id is reset. More protective system Does not allow change of user ID Uses: daemon process

24. 14.24 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Access Control Assume: system knows who the user is Access request pass through some gatekeeper USER Process Resource

25. 14.25 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Access Matrix View protection as a matrix (access matrix) Rows represent domains (unix -> users) Rows represent user Users hold ‘ticket’ for each resource Columns represent objects Column represents resource Access(i, j) is the set of operations that a process executing in Domain i can invoke on Object j

26. 14.26 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Access Matrix

27. 14.27 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Implementation of Access Matrix Each column = Access-control list for one object Defines who can perform what operation. Domain 1 = Read, Write Domain 2 = Read Domain 3 = Read  Each Row = Capability List (like a key) Fore each domain, what operations allowed on what objects. Object 1 – Read Object 4 – Read, Write, Execute Object 5 – Read, Write, Delete, Copy

28. 14.28 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Use of Access Matrix If a process in Domain D i tries to do “op” on object O j, then “op” must be in the access matrix. Can be expanded to dynamic protection. Operations to add, delete access rights. Special access rights:  owner of O i  copy op from O i to O j  control – D i can modify D j access rights  transfer – switch from domain D i to D j

29. 14.29 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Use of Access Matrix (Cont.) Access matrix design separates mechanism from policy. Mechanism  Operating system provides access-matrix + rules.  It ensures that the matrix is only manipulated by authorized agents and that rules are strictly enforced. Policy  User dictates policy.  Who can access what object and in what mode.

30. 14.30 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Access Matrix of Figure A With Domains as Objects

31. 14.31 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Access Matrix with Copy Rights

32. 14.32 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Access Matrix With Owner Rights

33. 14.33 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Control Rights: Applicable to Domains Control Rights

34. 14.34 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Control Rights: Applicable to Domains

35. 14.35 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Access Enforcement Security kernel Some part of the system must be responsible for enforcing access control and protecting the authorization and identification information This portion must be run unprotected. Thus it should be as small and simple as possible Most systems, like Unix, do not have a security kernel. As a consequence, the systems are not very secure.

36. 14.36 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Implementation of Access Matrix Global table Ordered triples Access lists for Objects  Capabilities list for Domains  List of all objects together with the rights for each object.

37. 14.37 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Implementation of Access Matrix Lock-Key Mechanism Compromise Each object has a list of unique bit patterns ->keys. A process executing in a domain can access on object only if that domain has a key that matches the object

38. 14.38 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Access Control Protection can be applied to non-file resources Solaris 10 provides role-based access control to implement least privilege Privilege is right to execute system call or use an option within a system call Can be assigned to processes Users assigned roles granting access to privileges and programs

39. 14.39 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Role-based Access Control in Solaris 10

40. 14.40 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Revocation of Access Rights Access List – Delete access rights from access list. Simple Immediate Capability List – Scheme required to locate capability in the system before capability can be revoked. Reacquisition Back-pointers (link of all capabilities to that object) Indirection (global table of capabilities) Keys

41. 14.41 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Language-Based Protection Specification of protection in a programming language allows the high-level description of policies for the allocation and use of resources. Language implementation can provide software for protection enforcement when automatic hardware-supported checking is unavailable. Interpret protection specifications to generate calls on whatever protection system is provided by the hardware and the operating system. The incorporation of protection concepts into programming languages, as a matter of practical design, is in it’s infancy

42. 14.42 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Protection in Java 2 Protection is handled by the Java Virtual Machine (JVM) A class is assigned a protection domain when it is loaded by the JVM. The protection domain indicates what operations the class can (and cannot) perform. If a library method is invoked that performs a privileged operation, the stack is inspected to ensure the operation can be performed by the library.

43. 14.43 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Stack Inspection

44. 14.44 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition Improving Protection Guiding principle – principle of least privilege Programs, users and systems should be given just enough privileges to perform their tasks Capabilities are an implementation of this idea Hard to provide foolproof information containment:  A Trojan horse could take page faults and signal to another process Logging Record all important actions and uses of privilege in an indelible file. Correctness proofs Encryption

45. Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, End of Chapter 14