|
The SPEEDOS Project was initiated by Prof. Keedy and his research group in 1998 at the University of Ulm, Germany. As a successor of the MONADS Project, it extends the earlier Monads research in the areas of computer security and software engineering design. Key ideas from the Monads Project and the SPEEDOS Project are described in separate documents which are referenced at appropriate points in the following text, and are listed individually at the end of the document. Aims of the Project As with its predecessor, Monads, the primary aims of the project are as follows: - To develop practical software engineering techniques for improving the specification, design, implementation and maintenance of large software systems, i.e. systems involving tens, hundreds and even thousands of man years of effort.
- To develop practical techniques for guaranteeing the security (i.e. the confidentiality, integrity and availability) of information held in large computer systems.
Similarities to the Monads Project Most of the more significant ideas of Monads have been carried over into the SPEEDOS Project. These are indicated below. The pointers take you back to the original description produced for the MONADS system. In principle there are no significant differences between Monads and SPEEDOS with respect to these ideas. Differences from the Monads Project (a) No Special Processor Hardware The first major break with the Monads Project is in the approach to the basic hardware to be used by the system. In the case of Monads several special hardware systems were developed at a time when it was still possible to influence hardware manufacturers. But as we enter the new millenium processor design and implementation are dictated by a very few manufacturers, and it is futile for a small uiversity project to attempt to compete. The only realistic possibility is to build a software system using current processor technology. In the SPEEDOS Project we have decided initially to implement a system on the basis of the Pentium design, as this is the most widely used hardware. This has led to two fundamental restrictions in comparison with Monads: - Orthogonal Segmentation and Paging In the original Monads design the orthogonal segmentation and paging scheme was used to good effect, as this almost eliminates internal fragmentation, and in the Monads systems it was also used to support protected segments (e.g. containing module capabilities) within the address spaces of user modules.
In fact the Pentium uses a segmentation and paging scheme which can be viewed as a variant of the orthogonal scheme, but we have decided not to use the segmentation hardware, because (a) it is not so easy to use for our purposes as the Monads hardware, and (b) it appears that future Pentium systems will not support segmentation. Furthermore, by avoiding the use of segmentation, the porting of the SPEEDOS system to other hardware platforms which do not support segmentation is made easier. Nevertheless, we consider this a very unfortunate step backwards. As is described in more detail under the heading Protected Segments in a Paged Virtual Memory, abandoning the orthogonal scheme leads both to a substantial increase in internal fragmentation of the memory, and a serious loss of flexibility in the organisation of system segments. - Efficient Capabilities Using Virtual Addresses The Monads systems used very large virtual addresses (60 bits in the Monads-PC, 128 bits in the MONADS-MM) to allow an entire distributed persistent virtual memory (potentially world-wide) to be addressed directly from any module executing in any process. Using conventional hardware even allowing for 64 bit addresses this approach cannot be successfully maintained.
However, if the uniform module structure is rigorously maintained, a module active in a process has only a few well-defined addressing possibilities. This fact can be used to good effect: when the Kernel executes an inter-module call it can set up the addressing hardware in such a way that the necessary addressing environment is realised. This implies that module capabilities used for inter-module calls should still contain long unique (protected) module identifiers, but these need not be carried over into the internal addressing within a module active in a process (see Implementing SPEEDOS in a System with Short Virtual Addresses). In comparison with the loss of segmented addressing, this restriction is not so serious. (b) More Powerful Access Controls Monads is a pure capability based system and suffers from some of the disadvantages of such a system. For example, it is difficult to revoke a capability once this has been handed to another user. Similarly the advantages of an access control list (ACL), e.g. to modify the access rights of a user in a straightforward manner, are lost. The important new features of SPEEDOS include a potentially endless range of facilities for controlling access to the persistent information of modules. SPEEDOS brings this added quality to the Monads ideas by introducing a new linking mechanism in the Kernel based on an object-oriented language programming language idea which we developed in the L1 Project that allows an object (in this case a protected module) to be qualified by an attribute module which can include bracket routines in its implementation. Such routines are automatically invoked by the Kernel when an attributed module is called. These routines have access to their own private persistent data (e.g. an ACL) and the code of a routine can determine whether (e.g. on the basis of these data) the routine called by the user is actually invoked or not (using the keyword body as a statement). This technique allows arbitrary security checks to be carried out by the bracket routine. It can also be used to log security information (e.g. when and by whom calls to a module are made). More details can be found under the headings Protection based on Bracket Routines and Access Control Based on Bracket Routines: Some Examples. A further development of this idea allows bracket routines to be used in association with an inter-module call from a module. Such call brackets (using the keyword call to indicate the point at which a call takes place) can be used for example to implement a very precise form of confinement. A variety of confinement problems can be solved using another technique implemented in SPEEDOS. For each module active in a process there is a Process Security Word, which consists of a bit list containing permissions (if the corresponding bit = 1) which can be turned off (the corresponding bit = 0) individually. These bits determine whether a called module (primary permissions) or the modules which it calls and which they in turn call (secondary permissions) can - access the persistent data of the module in read/write or read only mode,
- access the parameters passed into the module in read/write or read only mode,
- have peristent data at all, and/or
- make calls to other modules (either as a whole or only to modules passed to them as parameters).
Such permissions can be turned off either on the basis of information held in capabilities used to make calls or from bracket routines associated with a module. This technique allows many confinement problems (including for example the Bell-LaPadula security model) to be solved in a flexible manner. For a more detailed description see Confinement of Objects, Examples of Confinement of Objects and Rule Based Confinement. Some specialised confinement problems which arise in the SPEEDOS are also described in separate notes. In particular SPEEDOS provides information about the environment in which a module is executing. Such information is especially helpful in programming bracket routines designed to enhance protection. However, it can be misused (e.g. in Trojan horses in collaboration with hackers) and so an additional mechanism is provided to switch off the permission to call the Kernel instructions which pürovide this information (see Environmental Instructions and their Confinement). Another kind of confinement problem arises in association with the SPEEDOS Project: How can the distribution of capabilities themselves be confined? There are some limited solutions for this problem which were already included in Monads (and similar projects), but for example the problem of ensuring that a directory module to which capabilities are entrusted was not solved. SPEEDOS provides a solution to this and related problems (see Confinement of Capabilities). Thus SPEEDOS combines the advantages of a capability-based system and persistent processes with attribute-based protection and provides a solution for many confinement problems, in a flexible, user-programmable way. Key Monads Concepts used in the SPEEDOS Project.
|
