A Secure Distributed Operating System

Published Date: 02 Nov 2017

This paper discusses some security issues and problems for working a distributed operating system, in concern of the design of a secure distributed operating system. The objective of this project is to investigate multilevel security issues as they are related to distributed operating system designs. The design is targeted for provides best solution of security issues and few new methods in formal verification methods are reported.In the Distributed system security problems is odd with single-hosts and network security, and describe in the concern of the Problems unique to distributed operating system security issues are discribed. A argument is make for devlopeing security features in higher layers, corresponding to the session through application layers of the 0SI model. A new security based policy and it is based on message-passing rather than implement and summarized the SDOS design.

Keywords: - Secure distributed operating system (SDOS), Message passing, Networks hosts, Research base example of SDOS, AMOEBA.

Introduction

A distributed operating system is an operating system that runs on a large number of interconnected machines, but presents to the user an image of a single very powerful machine. Today, distributed operating systems only exist in research environments, although there are one or two exceptions (The Apollo Domain system is commercially available; systems such as V and Chorus are distributed in academic circles). Distributed systems, having replicated hardware, provide a potential for fault tolerance and the exploitation of parallelism. To realize fault tolerance, files are replicated on several servers so that crashes do not affect the availability of files; processing is structured so that after a crash the interrupted work can be redone without causing inconsistencies. Parallelism is achieved by splitting up jobs in a number of parallel processes that communicate and synchronize by exchanging messages.

A distributed operating system is software over a collection independent, networked, communicating . The first is a ubiquitous minimal kernel or microkernel that directly controls that node’s hardware. The second is a higher-level collection of system management components that coordinate the node's individual and collaborative activities. These components abstract microkernel functions and support user applications.

Characteristics of Distributed Operating Systems (SDOS) [1]

Allows a multiprocessor or multicomputer network resources to be integrated as a single system image

Hide and manage hardware and software resources

Provides transparency support

Provide heterogeneity support

Control network in most effective way

Consists of low level commands + local operating systems + distributed features

Inter-process communication (IPC)

Remote file and device access

Global is addressing and naming

Trading and naming services

Synchronization and deadlock avoidance

Resource allocation and protection

Global resource sharing

Deadlock avoidance

Communication security

Types of distributed operating system:-

AMOEBA

SDOS

TMACH

AMOEBA [2] –

The network consists of a collection of workstations and a pool of processors connected by a local area network. The system is object- oriented and uses a client/server model. Sparse capabilities are used as the basic naming and protection mechanism. Capabilities consist of a server name, object identifier and access rights. Access to an object is controlled at the server through the use of a capability. The server protects the access rights in the capability by adding an authentication field to the capability using a unique key for each object. Restricted capabilities may be created either at the server or by the client, and may be passed to other processes. The re - vocation of authenticated capabilities is easy since changing the authentication key on the server makes all previous capabilities invalid. That this mechanism can be used for mutual authentication of clients and servers, and may be used to prevent imposter server at- tacks. He proposes an implementation of sparse capabilities using a public key encryption method.

As the price of CPU chips continues to fall rapidly, it will soon be economically feasible to build computer systems containing a large number of processors. The question of how this computing power should be organized, and what kind of operating system is appropriate then arises. Our research during the past decade has focused on these issues and led to the design of a distributed operating system, called Amoeba that is intended for systems with large numbers of computers. In this paper we describe Amoeba, its philosophy, its design, its applications, and some experience with it.

Introduction

The cost of CPU chips is expected to continue declining during the coming decade, leading to systems containing a large number of processors. Connecting all these processors using standard technology (e.g., a LAN) is easy. The hard part is designing and implementing software to manage and use all of this computing power in a convenient way. In this paper we describe a distributed operating system that we have written, called Amoeba that we believe is appropriate for the distributed systems of the 1990s. One basic idea underlies Amoeba: to the user, the complete system should look like a single computer. By this we mean that the current model in which networked computers can only share resources with considerable difficulty will have to be replaced by a model in which the complete collection of hardware appears to the user to be a traditional uniprocessor timesharing system. Users should not be aware of which machines they are using, or how many machines they are using, or where these machines are located. Nor should they be aware of where their files are stored or how many copies are being maintained or what replication algorithms are being used. To the users, there should be a single integrated system which they deal with. It is the job of the operating system and compilers to provide the user with the illusion of a single system, while at the same time efficiently managing the resources necessary to support this illusion.

Structure of AMOEBA-:

When the command completes, the processors are released and go back into the pool, waiting for the next command, very likely from a different user. If there is a shortage of pool processors, individual processors are timeshares, with new jobs being assigned to the most lightly loaded CPUs. The important point to note here is that this model is quite different from current systems in which each user has exactly one personal workstation for all his computing activities. The pool processor model is more flexible, and provides for a better sharing of resources.

The second element in our architecture is the workstation. It is through the workstation

That the user accesses the system. Although Amoeba does not forbid running user programs on the workstation, normally the only program that runs there is the window manager. For this reason, X-terminals can also be used as workstations. Another important component of the Amoeba configuration consists of specialized servers, such as file servers, which for hardware or software reasons need to run on a separate processor. Finally, we have the gateway, which interfaces to wide-area networks and isolates Amoeba from the protocols and the idiosyncrasies of the wide-area networks

In a transparent way.

Application of AMOEBA -:

Amoeba as a Program Development Environment

Parallel Programming

Amoeba in an Industrial Environment

SDOS [3] -

Cronus distributed operating system as a baseline. Cronus is a software layer which runs on top of a Constituent Operating System (COS), and is designed to permit a collection of heterogeneous systems, with possibly different operating systems, to operate cooperatively as a single system. Cronus provides location transparency, a message passing kernel, object managers, name service, and object replication. The Phase I SDOS work was aimed at providing a TCSEC A1 level of security while preserving the Cronus basic functionality. This effort included the design of a security policy, formal security model, formal top level specification, and architectural design. Also formal proofs showing that the specification was consistent with the model were performed. Phase I1 of the SDOS work is currently ongoing and its goal is to demonstrate a B3 secure distributed operating system capability. The mandatory access control policy is based on a non-interference model which is restricted. The SDOS architecture is based on an object-oriented client server model. The trusted message switch provides interposes communications between single level clients and trusted and untrusted managers. Discretionary access control is implemented in type managers. Proxy identities are supported as a means of providing the invoker’s identity during nesting invocation of managers. The discretionary access control mechanism permits the definition of roles. A role is a tuple defining which operations can be performed on which objects when a user is in that role. The SDOS design assumes an open internet environment. COMSEC encryption is necessary at the packet level to protect multilevel messages between SDOS hosts.

TMACH [4] –

Mach and Accent are a communication oriented operating system which uses the abstraction of communication between processes as its basic organizing principle. The kernel provides basic inter-process communications, and process and memory management; all other services are provided outside the kernel. The basic communications abstraction is the port which is a protected kernel object. Ports cannot be directly manipulated by a process, but messages may be sent or received from a port using a capability. The Mach distributed operating system based on the Accent kernel, but is de- signed to run effectively on multiprocessors. To exploit the available parallelism a task is a collection of lightweight pro- cesses or threads of control. Mach also permits the sharing of memory between tasks, and ports may be associated with a task or a specific thread. A study has been performed Mach 861 on the feasibility of developing a trusted version of the Mach operating system. The goal of this study was to determine whether Mach can be modified to meet TCSEC requirements for mandatory access control. Two approaches to mediation were developed. The first, kernel mediation, placed labels on ports used for communications between processes. The second, server mediation, would require that servers perform both mandatory and discretionary access controls with no kernel modifications.

Comparison distributed operating system with other operating system [5]-:

Item

Distributed OS

Network OS

Multiprocessor

Multicomputer.

Degree of transparency

Very High

High

Low

Same OS on all nodes

Yes

Yes

No

Number of copies of OS

1

N

N

Basis for communication

Shared memory

Messages

Files

Resource management

Globally, central

Global, distributed

Per node

Scalability

No

Moderately

Yes

Openness

Closed

Closed

Open

Design Issues with Distributed Systems [6]

Design issues that arise specifically from the distributed nature of the application:

• Transparency

• Communication

• Performance & scalability

• Heterogeneity

• Openness

• Reliability & fault tolerance

• Security

Objects models and identification [7]

Distributed Coordination.

Interprocess Communication

Distributed Resources.

Fault Tolerance and Security.

Object models and identification-: Resource identification -The resources in a distributed system are spread across different computers and a naming scheme has to be devised so that users can discover and refer to the resources that they need.

An example of such a naming scheme is the URL (Uniform Resource Locator) that is used to identify WWW pages. If a meaningful and universally understood identification scheme is not used then many of these resources will be inaccessible to system users.

Objects:

Processes, files, memory, devices, processors, and networks.

Object access:

Each object associated with a defined access operation.

Accesses via object servers

Identification of a server by:

Name

Physical or Logical address

A service that the servers provide.

Identification Issue:

Multiple server addresses may exist requiring a server to move requiring the name to be changed.

Distributed Coordination-:

Processes Coordination required to achieve synchronization:

Synchronization Types:

Barrier synchronization:

Condition Coordination:

Mutual exclusion:

Barrier Synchronization-: Process must reach a common synchronization point before they can continue.

Condition Coordination-: A process must wait for a condition that will be sent asynchronously by other interacting processes to maintain some ordering of execution.

Mutual Exclusion-: Concurrent processes must have mutual exclusion when accessing a critical shared resource.

Synchronization Issues

State information sent with messages:

- Typically only partial state information is known about other processes making synchronization difficult.

- Information not current due to transfer time delay.

If the decision process may continue must rely on a message resolution protocol.

- Centralized Coordinator:

- Central point of failure

Deadlocks

- Circular Waiting for the other process

- Deadlock detection and recovery strategies.

Interprocess Communication-: interprocess communication is dived as two levels

Lower level: that level is related to some simple operation of communication

Example- message passing between devices

Higher level -: higher level logical communication provides transparency

Client/server model communication.

All system communication is seen as a pair of message exchanges between the client and server.

Remote Procedure Call, (RPC), communication.

-RPC built on top of the client / server model.

-Request/reply message passing as used in programming procedure-call concept.

Interproccess communication issues- Susceptible to failures in the system due to having to communicate through several protocol layers.

Distributed Resources-: distributed recourses are data (storage), processing capacity (sum of all processors). Transparency of data distribution contain two major parts of the system

Distributed file system: - single file system view in distributed environment.

Distributed shared memory: - single shared memory view of physically distributed memories.

Issues - Sharing and replication of data/Memory, Minimize communication overhead with efficient scheduling, Process migration strategy & mechanism.

Fault Tolerance and Security-:

Failures & Security Threats: Openness inherent in Distributed Environments

System Failures: Faults due to unintentional intrusions

Security Violations: Faults due to intentional intrusions.

Issue: Fault Tolerance

- Faults Transparent to user: System Redundancy (Inherent property in Distributed Systems)

- System's Ability to Recover. (Rolling back failed processes)

Security Issue: Authentication & Authorization

Control over access across a network with different administrative units & varying security models.

Issues that affect various system services [9]-:

Issues Affect Services

Communication, Synchronization: Interaction and control

Distributed algorithms,

Process scheduling, deadlock : Performance

Handling, load balancing,

Resource scheduling, file sharing: Resource

Concurrency control

Failure handling, configuration: System Failures

Redundancy

Design issues solution and protection [10]-:

Network security-

Open and close system

A closed network is one whose nodes and inter-node communications media are under the physical control of the using organization, such that their security can be assured, making it practical to implement multilevel security in the nodes. An open network, on the other hand, uses public communications media (such a phone line or radio signals) and public nodes, such see those in commercial packet switched networks or in the ARPANET. Physical security of the nodes and media of a public network can obviously not be assured, so multilevel security is impractical. It is a design objective of SDOS that the system is able to maintain its own security even when it is operating over an open network. The reason for this requirement is a practical one: open networks are prevalent and becoming more so every day. Closed networks are relatively rare, usually unavailable, and costly and time-consuming to construct and maintain.

Encryption

Encryption is the usual solution to the problem of maintaining security of communications across an open network. Two classes of encryption are of interest here: link encryption and end-to-end encryption. Link encryption protects data on an insecure medium that is being used for communication between two secure network nodes. Messages being relayed through several nodes to an ultimate destination are decrypted and re-encrypted at each intermediate node. End-to-end encryption is used by higher layer entities to protect data from untrusted lower layers or from entrusted nodes in an open network. Messages are encrypted by the sending higher layer entity, decrypted by the receiving higher layer entity, and remain encrypted while moving through lower layers and intermediate network nodes. End-to-end encryption has the advantages that the encryption and decryption are only done once for each message, and that layers below the encrypting layer, and intermediate network nodes, do not have to be trusted.

It has the disadvantage that message headers for the layers below the encrypting layer travel the network in the clear. The information in these headers is subject to traffic flow analysis. Further, as suggested earlier, there is a potential covert channel if untrusted software above the TCB is able to exercise control over the lower layer operation in ways that would modulate the lower layer header information. Link encryption has the advantage that all information carried on the insecure medium is protected. It has the disadvantage that all layers down to the physical layer, and all intermediate network nodes, must be secure. In other words, link encryption implies a closed network.

Conclusion

A secure distributed operating system is a single system with a uniform computational model, uniform set of abstractions and uniform protection model. In this way, the design of a secure distributed operating system is very similar to the design of secure uni processor operating systems. However, distribution introduces both benefits, like replication and reliability, and problems, like synchronization and concurrency that forces us to consider new approaches to solve the security problems and design issues.

References –

[1] Randy Chow & Theodore Johnson, 1997,"Distributed Operating Systems &

Algorithms", (Addison-Wesley), p. 45 to 50

[2-Amoeba ] S.J. Mullender and A.S. Tanenbaum, Protection and Resource Control in distributed

Operating Systems. Computer Networks 8, Nov. 1984, pp. 421-432.

[3-SDOS] S.T. Vinter, et. al. The Secure Distributed Operating System Project. BBN, Report

No.61244.jan

[4-TMach ] M.A. Branstad, et. al., Trust Issues of Mach-I. Proceedings of the 9th National

Computer Security Conference, Sept. 15-18 1986, pp. 209-212.

[5] Ian Sommerville, 2000, "Software Engineering, 6th edition", Chapter 11.

[6] Pierre Boulet, 2006, "Distributed Systems: Fundemental Concepts

[7] R. Schantz ET. Al, The Architecture of the Cmnus Distributed Operating System

. Proceedings of the IEEE 6th International Conference on Distributed Computing Systems,

May 1986, pp. 250-25

[8] D.R. Cheriton, The V Distributed System. CACM, Vol. 31, No. 3, March 1988, pp.315-

333.

[9] McCullough, D. "Specifications for Multi-Level Security and a Hook-Up Property",

Proceedings of the 1987 IEEE Symposium on Security and Privacy, May

[10] B. C. Neuman, and T. Ts’o, "Kerberos: An Authentication Service for

Computer Networks", IEEE Communications, 32, #9, September 1994