Workshop 7 Agenda

Homework review: 18.7, 19.11, 19.12, 20.1, 20.7Study group project milestoneLecture & discussion on distributed coordinationLecture & discussion on protectionGroup activity on protectionLecture & discussion on securityGroup activity on securityCourse review (primarily chapters 12-20)Summary and preview of next workshop

Module 18: Distributed Coordination

Event Ordering

Mutual Exclusion

Atomicity

Two phase commit

Concurrency Control

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 Pi a logical clock, LCi 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.

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:CentralizedFully distributed

DME: Centralized Approach

One of the process is appointed coordinator.

Each process uses three messages per critical-section entry: request reply release

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

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.

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.

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.

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:

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 Si and let the transaction coordinator at Si be Ci.

Phase 1: Obtaining a Decision

Coordinator adds <prepare Transaction> record to the log.

Coordinator sends <prepare Transaction> message to all sites.

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 <no transaction> record to the log and

respond to the coordinator with <abort transaction>.

If yes: add <ready transaction> record to the log. force all log records for the transaction onto stable

storage. transaction manager sends ready message to

coordinator

Phase 1 (Cont.)

Coordinator collects responsesAll 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.

Phase 2: Recording Decision in the Database

Coordinator adds a decision record <abort transaction> or <commit transaction>to its log and forces record onto disk.Once that record reaches stable storage it is irrevocableCoordinator sends a message to each participant informing it of the decision (commit or abort).Participants take appropriate action locally.

Failure Handling in 2PC – Site Failure

The log contains a <commit T> record. In this case, the site executes redo(T).The log contains an <abort T> record. In this case, the site executes undo(T).

The contains a <ready T> record; consult Ci. If Ci 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).

Failure Handling in 2PC – Coordinator Ci Failure

If an active site contains a <commit T> record in its log, the T must be committed.If an active site contains an <abort T> record in its log, then T must be aborted.If some active site does not contain the record <ready T> in its log then the failed coordinator Ci cannot have decided to commit T. Rather than wait for Ci to recover, it is preferable to abort T. All active sites have only a <ready T> record in their logs. In this case we must wait for the coordinator to recover. Can cause blocking.

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.

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.

Single-Coordinator Approach

A single lock manager resides in a single chosen site, all lock and unlock requests are made a that site.Simple implementationSimple deadlock handlingPossibility of bottleneckVulnerable to loss of concurrency controller if single site fails Multiple-coordinator approach distributes lock-manager function over several sites.

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.

Module 19: Protection

Goals of Protection

Basic Hardware Protection

Domain of Protection

Access Matrix

Implementation of Access Matrix

Language-Based Protection

Protection

Process protection provided and/or controlled in several ways:HardwareOperating SystemApplicationsUsers/Administrators

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

Hardware

CPU Protection levels: I.e. user-mode vs kernal mode

Trap illegal instructions (I/O, etc.)

Memory bounds

Etc.

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

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.

Rings

Lower privileges as go away from center

Access Matrix

Figure 1

Row = capability list; column = access list

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

Access Matrix With Domains as Objects

Figure 2

Access Matrix with Copy Rights

Access Matrix With Owner Rights

Modified Access Matrix

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

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”)

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

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

Module 20: Security

The Security Problem

Authentication

Program Threats

System Threats

Threat Monitoring

Encryption

The Security Problem

Security must consider external environment of the system, and protect it from:unauthorized access.malicious modification or destructionaccidental introduction of inconsistency.

Easier to protect against accidental than malicious misuse.

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.

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

Program Threats

Trap DoorSpecific 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

System Threats

Worms – use spawn mechanism; standalone program

Internet wormExploited UNIX networking features

(remote access) and bugs in finger and sendmail programs.

Grappling hook program uploaded main worm program.

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.

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

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

Network Security Through Domain Separation Via Firewall

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.

Security Classifications

D : lowest levelC1: Some protection owner, group, others, etc. Many Unix systems at his level

C2: Protections at user level Audit trails NT at this level

BA

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