Protection and Security in Operating Systems

1. Outline • Announcements • Protection and security

2. Announcements • Lab 3 is due tomorrow at your demonstration time • You have three minutes for preparation and three minutes to give a demonstration which needs to convince others and myself that: • You have implemented the APIs correctly • Note the penalty for missing an API is 15 points • Because of the time limit, you better use a script file of some kind to do your demonstration COP4610

3. Announcements – cont. • Final exam will be on 5:30 - 7:30 pm, Dec. 11, 2003 • Here in LOV 101 • I will have office hours on Sunday, Dec. 7, 2003 • From 10:00am – 5:30 pm except a lunch break • Unfortunately, I need to attend a conference from Dec. 8 to Dec. 11 in Canada • I will be back on Dec. 11 late that night • I will have another professor to proctor the final exam COP4610

4. Protection and Security • Operating system consists of a collection of objects, hardware or software • Each object has a unique name and can be accessed through a well-defined set of operations • Protection and security problem - ensure that each object is accessed correctly and only by those processes of authorized users that are allowed to do so COP4610

5. Allowing Only Authorized Access Authorized Access Authentication Authorization Subject Unauthorized Access Secure Entity Subject COP4610

6. Protection and Security – cont. • Authentication • Internal • External • Authorization • Network security • Secure entity is not • copied or accessed • during its transit • Cryptography COP4610

7. Policy vs. Mechanism • An organization’s security policy defines the rules for authorizing access to its computers and information resources • A particular strategy that dictates the way a mechanism is used to achieve specific goals • Protection mechanisms are tools for implementing the organization’s security policy COP4610

8. Internal Access Authorization • Internal authorization is part of the task of managing resource sharing • The goal is to protect one process’s resources from the actions of other processes COP4610

9. Hardware protection mechanisms • Processor modes and privileged instructions only valid in system mode • Memory protection • Devices, and in particular disks, are protected with processor modes and/or memory protection COP4610

10. Software protection mechanisms • Hardware resources are protected by hardware protection mechanisms • Logical resources are only accessed through system calls • All system calls must be authorized by a protection monitor • The protection monitor accesses the protection database to make decisions COP4610

11. Protection monitors for file access COP4610

12. Protection monitors in an OS COP4610

13. A Protection System COP4610

14. A Protection System Subjects Objects a S X • S desires a access to X COP4610

15. A Protection System Subjects Objects Protection State S X • S desires a access to X • Protection state reflects current ability to access X COP4610

16. A Protection System Subjects Objects Protection State S X State Transition • S desires a access to X • Protection state reflects current ability to access X • Authorities can change COP4610

17. A Protection System Subjects Objects Protection State S X State Transition • S desires a access to X • Protection state reflects current ability to access X • Authorities can change • What are rules for changing authority? Rules COP4610

18. A Protection System Subjects Objects Protection State S X State Transition • S desires a access to X • Protection state reflects current ability to access X • Authorities can change • What are rules for changing authority? • How are the rules chosen? Rules Policy COP4610

19. Protection System Example a S X • S desires a access to X COP4610

20. Protection System Example S X X • S desires a access to X • Captures the protection state S a Access matrix COP4610

21. Protection System Example (S, a, X) Access authentication S X X • S desires a access to X • Captures the protection state • Generates an unforgeable ID S a Access matrix COP4610

22. Protection System Example (S, a, x) Access authentication Monitor S X X • S desires a access to X • Captures the protection state • Generates an unforgeable ID • Checks the access against the protection state S a COP4610

23. Access Matrix • The protection state can be represented using an access matrix • An access matrix A has one row for each subject and one column for each object • Each entry A[S, X] is a set that describes the access rights held by subject S to object X • Access authentication • If subject S initiates type a access to X then if aA[S,X], the access is valid. If a  A[S, X], the access is invalid. COP4610

24. An Access Matrix Example COP4610

25. Use of Access Matrix • If a process in Domain Di tries to do “op” on object Oj, 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 Oi • copy op from Oi to Oj • control – Di can modify Djs access rights • transfer – switch from domain Di to Dj COP4610

26. Use of Access Matrix - cont. • Access matrix design separates mechanism from policy • Mechanism • Operating system provides Access-matrix + rules • If 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 COP4610

27. Domain Structure • Access-right = <object-name, rights-set>Rights-set is a subset of all valid operations that can be performed on the object. • Domain = set of access-rights that a subject has at any given time COP4610

28. Changing Protection State COP4610

29. Protection domains • A capability is a unique, global name for an access right to an object in the system • A protection domain is a set of capabilities to perform certain actions on certain objects • A process can move from protection domain to protection domain so, at any point, it has exactly the capabilities it needs for the current job (the principle of least privilege) • This is more flexible than associating capabilities directly with a process COP4610

30. Ring Architecture for Protection Domains COP4610

31. 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. COP4610

32. Implementing the Access Matrix • Usually a sparse matrix • Too expensive to implement as a table • Implement as a list of table entries • Column oriented list is called an access control list (ACL) • List kept at the object • UNIX file protection bits are one example • Row oriented list is a called a capability list • List kept with the subject (i.e., process) • Kerberos ticket is a capability • Mach mailboxes protected with capabilities COP4610

33. Store the Access Matrix by columns Each ACL is kept at the object UNIX file protection bits are one example Windows resource managers also use ACLs for protection X X X a a a Access Control Lists Derived from an Access Matrix X X X S a a a Resource Descriptor Resource Descriptor Resource Descriptor COP4610

34. Access Control Example S1 S2 S3 F1 F2 D1 D2 S1 control block wakeup owner control owner read* write* seek owner S2 control stop owner update owner seek* S3 control delete execute owner Access List of F2 {S2, {update}} {S3,{execute, owner}} COP4610

35. Store the Access Matrix by rows List kept with the subject (i.e., process) Examples Ticket to a concert Kerberos ticket Mach mailboxes S a a S Capability Lists Derived from an Access Matrix X a S S a a S a S Process Descriptor Process Descriptor Process Descriptor COP4610

36. Capability List Example S1 S2 S3 F1 F2 D1 D2 S1 control block wakeup owner control owner read* write* seek owner S2 control stop owner update owner seek* S3 control delete execute owner Capability list of S2 {S2, {control}} {S3, {stop}} {F1, {owner}} {F2, {update}} {D1, {owner}} {D2, seek*}} COP4610

37. More on Capabilities • Provides an address to object from a very large address space • Possession of a capability represents authorization for access • Implied properties: • Capabilities must be very difficult to guess • Capabilities must be unique and not reused • Capabilities must be distinguishable from randomly generated bit patterns COP4610

38. 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 • Indirection • Keys COP4610

39. Unix Protection Scheme • Mode of access: read, write, execute • Three classes of users RWX a) owner access 7  1 1 1 RWX b) groups access 6  1 1 0 RWX c) public access 1  0 0 1 COP4610

40. The Security Problem • Security must consider external environment of the system, and protect it from • unauthorized access. • malicious modification or destruction • accidental introduction of inconsistency. • Easier to protect against accidental than malicious misuse COP4610

41. User authentication • Three types of authentication: • Something a user knows • e.g. a password, a combination, answers to personal questions • Something a user has • e.g. a badge, a smart card, a key • Something a user is • e.g. fingerprint, signature, voice print, hand geometry, retinal blood vessel pattern COP4610

42. Authentication • User identity most often established through passwords, can be considered a special case of either keys or capabilities. • Passwords must be kept secret. • Frequent change of passwords. • Use of “non-guessable” passwords. • Log all invalid access attempts. • Encryption COP4610

43. Program Threats • Trojan Horse • Code segment that misuses its environment. • Exploits mechanisms for allowing programs written by users to be executed by other users. • Trap Door • Specific user identifier or password that circumvents normal security procedures. • Could be included in a compiler. COP4610

44. System Threats • Worms – use spawn mechanism; standalone program • Internet worm • Exploited UNIX networking features (remote access) and bugs in finger and sendmail programs. • Grappling hook program uploaded main worm program. • Viruses – fragment of code embedded in a legitimate program. • Mainly effect microcomputer systems. • Downloading viral programs from public bulletin boards or exchanging floppy disks containing an infection. COP4610

45. The confinement problem • How do we prevent a program from leaking information to others? • It is not as simple as preventing IPC and I/O • A covert channel is a hidden means of communication information • e.g. sending bits by manipulating the CPU load COP4610

46. The Morris Internet Worm COP4610

47. Threat Monitoring • Check for suspicious patterns of activity – i.e., several incorrect password attempts may signal password guessing. • Audit log – records the time, user, and type of all accesses to an object; useful for recovery from a violation and developing better security measures. • Scan the system periodically for security holes; done when the computer is relatively unused. COP4610

48. Threat Monitoring – cont. • Check for: • Short or easy-to-guess passwords • Unauthorized set-uid programs • Unauthorized programs in system directories • Unexpected long-running processes • Improper directory protections • Improper protections on system data files • Dangerous entries in the program search path (Trojan horse) • Changes to system programs: monitor checksum values COP4610

49. Encryption COP4610

50. Encryption – cont. • Encrypt clear text into cipher text. • Properties of good encryption technique: • Relatively simple for authorized users to encrypt and decrypt data. • Encryption scheme depends not on the secrecy of the algorithm but on a parameter of the algorithm called the encryption key • Extremely difficult for an intruder to determine the encryption key COP4610