Persistent Protected Processes

The Monads persistent virtual memory not only allows files to be viewed as directly addressable objects, but also allows processes to be implemented as persistent entities, with some remarkable advantages for system security. Many of the basic ideas are described in more detail in:

Keedy, J.L. "A Model for Security and Protection in Persistent Systems", Microprocessors and Microsystems, 17, 3, 1993, pp.139-146

Keedy, J.L. and Vosseberg, K. "Persistent Protected Modules and Persistent Processes as the Basis for a More Secure Operating System", Proc. 25th Hawaii International Conference on System Sciences, 1992.

Keedy, J.L. and Vosseberg, K. "Security in a Persistent Distributed Operating System", Proc. 12th GI/ITG-Conference: "Architektur von Rechensystemen", 1992, Christian-Albrechts-Universität, Kiel.

A persistent process is a process which continues to exist between system shutdowns. Since the Monads virtual memory is a persistent virtual memory any process can be persistent, because it is represented in the virtual memory by a process stack held in a separate address space.

The Monads systems have adopted a rigorous in-process (sometimes called procedure-oriented) approach, which means that an application process invokes the services of all other modules (for example library routines and operating system services, and in the Monads case also file modules) as protected procedure calls, called in Monads inter module calls. In order to make such a call the caller must present a module capability.

A process stack can thus be viewed as a stack of module frames, in which the topmost frame holds the temporary data of the currently active module and the bottommost frame the module in which the process was first activated. This is illustrated in the diagram, where the first module frame is for the User Manager. This has then invoked a routine of the Command Language Interpreter (CLI), which has in turn (following a user command) invoked an Editor. At the top of the stack is a frame for the file being edited, for which a semantic operation has been invoked.

In contrast with conventional systems a stack is created in Monads systems for a user when he is introduced to the system and it continues to exist until he is dergistered from the system. Hence the bottommost module on the stack is the User Manager in this example. (This is not predefined by the Monads architecture.) When this has initialized the stack it would, in a timesharing system, typically call a CLI which can execute commands for the user. A command is simply a routine of a module, which may be a user written module. For more about command invocation see:

Keedy, J.L. and Thomson, J.V. "Command Interpretation and Invocation in an Information Hiding System", IFIP TC-2 Conference on The Future of Command Languages: Foundations for Human-Computer Communication (ed. K.Hopper and I.A.Newman), Rome, Italy, 1985, pp.278-292.

When a user logs out of the system his stack continues to persist in the virtual memory. This is achieved by invoking a logout command. Instead of this causing the process stack to be deleted (as would happen in a conventional system), it invokes the kernel long_suspend interface, which causes the process to be removed from the list of active processes and allows the stack pages to be removed from the main memory. The process then persists until the user logs in again. At this point the kernel exits back to the logout module, which exits back to its caller. If this was the CLI then it can continue executing new commands form the user.

The first advantage of this technique is that the system overheads involved in creating and deleting processes for each login session are eliminated. The second advantage is that the user can return to his process in the state in which he left it when he logged out, for example in the same current directory and with the same further environment, which is both quicker and more convenient for the user. In fact he need not log out from the CLI. Any other software which he uses can provide him with a logout command which calls his logout module. Consequently he might for example log out from within the editor, and thus be able to continue editing where he left off when he logs in again.

A particularly important advantage of this technique is that it allows a more powerful form of authentication of users to be introduced into the system in a straightforward manner. Conventionally a user authentication scheme involves the operating system in requesting the user's identity (i.e. his login name) and then authenticating that he is who he claims to be (e.g. by checking a password). This conventional approach has many weaknesses, but especially (a) that there is a central repository of authentication information which is vulnerable to hackers, and (b) that a hacker knows what he has to do in order to get himself authenticated.

Both of these problems are solved if, as in Monads, the two stages of identification and authentication are separated in such a way that (a) the security kernel handles the initial identification, which serves to identify an inactive persistent process, but (b) the authentication is left to the logout module of the user. Remember that the process was suspended in the middle of the logout command, which is then resumed as the kernel routine exits. At this point it does not need to return to its caller. Instead it can carry out any checks which it chooses to authenticate the user. In fact it is more modular to have a separate authentication module for this purpose, which has a routine callable from the logout module that simply returns a boolean value true if the authentication was successful or false if the user could not authenticate himself. In this way users can link different authentication modules to their processes, and can progrma these as they wish.

In the simplest case a "public" process has an authentication routine which always returns true. Alternatively it may check a simple password. (In this case the authentication module can be programmed as a file with semantic routines for setting and changing a password, etc. Even this is more secure than a conventional password system, first because the hacker does not know what rules govern the structure of a password, and second, the password is not held in a central file which he can attack.) But a concerned user can program authentication checks to any level of sophistication which he thinks suitable.

In a mandatory security system, the user can be constrained from linking his own authentication module to his process in that he is not provided with a capability enabling him to carry out this operation. Instead the system administrator can install his standardauthentication module and thus retain control of the system. It is also possible to develop a system where a user undergoes two sets of checks: for example the logout routine calls the standard authentication module, which then allows a user to link a further authentication module of his own.

There is another important security advantage of Monads persistent processes. Since a stack is held in an address space which not only persists but also has a unique identifier over time (as discussed in connection with capabilities), this unqiue identifier can always be used to identify the user, and as all his activities are carried out from his persistent process, this identifier can be obtained from the security kernel by any software which is invoked in the process.

Finally, in practice it is too restrictive for users to have only a single persistent process. Given that a user has a capability needed to create a new process, he may set up several persistent processes (either using the same or different authentication modules). In this case his first process serves as heis unique identifier, and this can be obtained via the security kernel by any module invoked in any of his processes.