1. Workshop 7 Agenda Homework review: 18.7, 19.11, 19.12, 20.1, 20.7 Study group project milestone Lecture & discussion on distributed coordination Lecture & discussion on protection Group activity on protection Lecture & discussion on security Group activity on security Course review (primarily chapters 12-20) Summary and preview of next workshop

2. Module 18: Distributed Coordination Event Ordering Mutual Exclusion Atomicity Two phase commit Concurrency Control

3. Implementation of Event Ordering No common clock. Therefore need some other method to coordinate events. Associate a timestamp with each system event. Within each process P i a logical clock, LC i is associated. Implemented as a simple counter. A process advances its logical clock when it receives a message whose timestamp is greater than the current value of its logical clock. If the timestamps of two events A and B are the same, then use the process identity numbers to break ties and to create a total ordering.

4. Distributed Mutual Exclusion (DME) Requirement If a process is executing in its critical section, then no other process is executing in its critical section. We present two algorithms: Centralized Fully distributed

5. DME: Centralized Approach One of the process is appointed coordinator. Each process uses three messages per critical-section entry: request reply release

6. DME: Fully Distributed Approach When a process wants to enter its critical section, it generates a new timestamp and sends a request message to all other processes. When a process receives a request message, it may reply immediately or it may defer sending a reply back. When process P i receives a reply message from all other processes in the system, it can enter its critical section. After exiting its critical section, the process sends reply messages to all its deferred requests.

7. DME: Fully Distributed Approach (Cont.) The decision whether process a process replies immediately to a request message or defers its reply is based on three factors: If it is in its critical section, then it defers its reply If it does not want to enter its critical section, then it sends a reply immediately If the process wants to enter its critical section but has not yet entered it, then it compares its own request timestamp with the timestamp of the request.

8. Desirable Behavior of Fully Distributed Approach Freedom from Deadlock is ensured. Freedom from starvation is ensured, since entry to the critical section is scheduled according to the timestamp ordering.

9. Three Undesirable Consequences The processes need to know the identity of all other processes, which makes dynamic addition and removal of processes more complex. If one of the processes fails, then the entire scheme collapses. This protocol is therefore suited for small, stable sets of cooperating processes due to high overhead.

10. Atomicity Transaction is a single “unit of work”. Either all the operations associated with a program unit are executed to completion, or none are performed. Ensuring atomicity in a distributed system requires a transaction coordinator, which is responsible for the following:

11. Two-Phase Commit Protocol (2PC) Use to commit a distributed transaction (ex: distributed database). Execution of the protocol is initiated by the coordinator after the last step of the transaction has been reached. When the protocol is initiated, the transaction may still be executing at some of the local sites. The protocol involves all the local sites at which the transaction executed. Example: Let T be a transaction initiated at site S i and let the transaction coordinator at S i be C i.

12. Phase 1: Obtaining a Decision Coordinator adds record to the log. Coordinator sends message to all sites.

13. Phase 1: Obtaining a Decision When a site receives a prepare message, the transaction manager at that site determines if it can commit the transaction. If no: add record to the log and respond to the coordinator with. If yes: add record to the log. force all log records for the transaction onto stable storage. transaction manager sends ready message to coordinator

14. Phase 1 (Cont.) Coordinator collects responses All respond “ready”, decision is commit. At least one response is “abort”, decision is abort. At least one participant fails to respond within time out period, decision is abort.

15. Phase 2: Recording Decision in the Database Coordinator adds a decision record or to its log and forces record onto disk. Once that record reaches stable storage it is irrevocable Coordinator sends a message to each participant informing it of the decision (commit or abort). Participants take appropriate action locally.

16. Failure Handling in 2PC – Site Failure The log contains a record. In this case, the site executes redo(T). The log contains an record. In this case, the site executes undo(T). The contains a record; consult C i. If C i is down, site sends query-status T message to the other sites. The log contains no control records concerning T. In this case, the site executes undo(T).

17. Failure Handling in 2PC – Coordinator C i Failure If an active site contains a record in its log, the T must be committed. If an active site contains an record in its log, then T must be aborted. If some active site does not contain the record in its log then the failed coordinator C i cannot have decided to commit T. Rather than wait for C i to recover, it is preferable to abort T. All active sites have only a record in their logs. In this case we must wait for the coordinator to recover. Can cause blocking.

18. Concurrency Control Modify the centralized concurrency schemes to accommodate the distribution of transactions. Transaction manager coordinates execution of transactions (or subtransactions) that access data at local sites. Local transaction only executes at that site. Global transaction executes at several sites.

19. Locking Protocols Can use the two-phase locking protocol in a distributed environment by changing how the lock manager is implemented. Nonreplicated scheme – each site maintains a local lock manager which administers lock and unlock requests for those data items that are stored in that site. Simple implementation involves two message transfers for handling lock requests, and one message transfer for handling unlock requests. Deadlock handling is more complex.

20. Single-Coordinator Approach A single lock manager resides in a single chosen site, all lock and unlock requests are made a that site. Simple implementation Simple deadlock handling Possibility of bottleneck Vulnerable to loss of concurrency controller if single site fails Multiple-coordinator approach distributes lock-manager function over several sites.

21. Primary Copy One of the sites at which a replica resides is designated as the primary site. Request to lock a data item is made at the primary site of that data item. Concurrency control for replicated data handled in a manner similar to that of unreplicated data. Simple implementation, but if primary site fails, the data item is unavailable, even though other sites may have a replica.

22. Module 19: Protection Goals of Protection Basic Hardware Protection Domain of Protection Access Matrix Implementation of Access Matrix Language-Based Protection

23. Protection Process protection provided and/or controlled in several ways: Hardware Operating System Applications Users/Administrators

24. Protection Operating system consists of a collection of objects such as hardware devices, programs, files, etc. Each object has a unique name and can be accessed through a well-defined set of operations. (ex: file MyFile can be accessed through read, write). Protection problem - ensure that each object is accessed correctly and only by those processes that are allowed to do so.

25. Hardware CPU Protection levels: I.e. user-mode vs kernal mode Trap illegal instructions (I/O, etc.) Memory bounds Etc.

26. Domain Structure Access-right = Rights-set is a subset of all valid operations that can be performed on the object. Domain = set of access-rights

27. Domain Implementation System consists of 2 domains: User Supervisor 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.

28. Rings Lower privileges as go away from center

29. Access Matrix Figure 1 Row = capability list; column = access list

30. 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 s access rights transfer – switch from domain D i to D j

31. Access Matrix With Domains as Objects Figure 2

32. Access Matrix with Copy Rights

33. Access Matrix With Owner Rights

34. Modified Access Matrix

35. Access Rights Access matrix usually implemented via access lists or access control lists (ACL’s). (VAX/VMS uses these) Access List – Add/delete/modify access rights from access list. Simple Immediate

36. NT Example NT Retrieves user access rights Rights are encapsulated in a “token” which “travels” with the user’s processes Essentially, creates the access “domain” (not the network “domain”)

37. 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. Ex: C program opens file for read only

38. Group Activity – Protection Select protection method: Hardware Operating system User Application Language Administrator Identify key characteristics Try to relate your learning team O/S to the “rights” matrix Choose representative to give 5 minute whiteboard presentation

39. Module 20: Security The Security Problem Authentication Program Threats System Threats Threat Monitoring Encryption

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.

41. 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.

42. Program Threats Trojan Horse Code segment that misuses its environment. Exploits mechanisms for allowing programs written by users to be executed by other users. Ex: put a program in the Unix path of a user that looks like normal program but can do special things Trap Door Specific user identifier or password that circumvents normal security procedures. Could be included in a compiler. Ex: if logged in as ddurso then allow special operations

43. Program Threats Trap Door Specific user identifier or password that circumvents normal security procedures. Could be included in a compiler. Ex: if logged in as ddurso then allow special operations

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.

45. System Threats 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. Macro type viruses now found (ex: Melissa virus). Typically in Microsoft environments.

46. 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 Scan the system periodically for security holes

47. 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

48. Network Security Through Domain Separation Via Firewall

49. Encryption 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.

50. Security Classifications D : lowest level C1: Some protection owner, group, others, etc. Many Unix systems at his level C2: Protections at user level Audit trails NT at this level B A

51. Group Activity – Security Select area: Passwords Program threats System threats Encryption Security classifications NT Unix Linux Identify key characteristics Choose representative to give 5 minute whiteboard presentation