An important feature of the security mechanisms available in SPEEDOS is that a module active in a process can request information about its environment, in the form of unprivileged Kernel instructions. When the Kernel returns such information it is guaranteed to be correct.

The currently planned environmental instructions are as follows:

In all cases except if_routine the information returned is a systemwide unique identifier, which is in practice an address space number for a file address space, a code address space or a process stack address space.

All modules in the SPEEDOS system have the same uniform module structure, which includes a code address space and a file address space.

File address space numbers:

Not all modules have a file address space for persistent data. If there is no persistent data associated with a module, the identifier returned is 0. Otherwise this instruction always returns the unique identifier which appears in the capability used to call the module.

Code address space numbers:

There is always at least one address space associated with a module. In the cases where the code of a module spans more than more than one address space (e.g. where inherited code held in several address spaces is used), one of these is the "primary" code address space. This is the address space holding the initial entry point list of the module (which is located by the Kernel when an interface routine is called). It is identical with either

• the unique module identifier which appears in the capability used to call a (code) module, or
• the code address space number which appears in the file address space located from the unique module number in the capability used to call a (file) module.

At present it is planned to return only this code identifier for the currently active module (current_code) or for the module which called the current module (calling_code). However, a further instruction may later be added to return the identifier of the actually executing code.

When these instructions are called in bracket routines the returned value refers to the code address space of the attributed module, not the bracket code itself. If a further instruction is added (see previous paragraph) this will return the identifier of the currently active bracket code if appropriate.

These instructions can for example be used for dynamic type checking at the module level or to identify the type of a calling module for security purposes.

Called module numbers:

The called file and called code numbers are only relevant in call brackets, and are the unique identifiers of the file or code of the module about to be called. If a call is not in progress the value -1 is returned.

Process address space numbers:

Associated with each persistent user process is a process stack, on which all the modules invoked directly or indirectly from that process are executed. A persistent process is identified by the unique address space number of the stack.

Owner numbers:

A user may own many file modules, code modules and/or persistent processes. Each address space has an owner. Whenever a new address space is created the identifier of the owner of the process which creates the address space is noted in the owner field of its red tape information. Consequently the owner of a process, a file or a code module can always be uniquely identified. The address space number of the first process created for a new user becomes his/her unique identifier, which appears in the owner field of that process address space and of all address spaces created by any of his processes thereafter.

The Kernel instruction process_owner is particularly useful for carrying out security checks, for example in bracket routines, as it uniquely identifies the user carrying out a particular activity. (This is one advantage of persistent processes in conjunction with a rigorous strategy of executing processes in an in-process or procedure oriented way [1].) An example of its use can be found in the module Bell-LaPadula_subjects.

Interface routine numbers:

The instruction if_routine returns a (non-unique) integer value indicating the entry point number of the interface routine which was called to activate the current module. This is particularly useful to allow bracket routines to establish which interface routine is currently being bracketed. Examples of the use of this instruction appear in the bracket implementations of the attributes untrusted and Bell-LaPadula.

Confinement of Environmental Information.

Environmental information can be used not only to enhance but also potentially to endagnger the security of a system. For example, suppose that an employee of a banking system has the task of programming a module which implements transactions at automatic teller machines (ATM). If he has access to the Kernel instruction process_owner he can include a check in his code which establishes whether a transaction is being carried out by himself (or his wife, etc.) as unique process identifiers cannot - and should not - be kept secret. Then he could introduce a Trojan horse which increases the amount of cash paid out from the ATM.

For such reasons it is desirable to be able to switch off the facilty for calling the Kernel's environmental instructions. This is achieved in basically the same way as other access rights ad confinement permissions can be reduced. The individual rights are included as further bits in the Process Security Word (PSecW) and in capabilities. There are also Kernel instructions for switching off these bits in the PSecW, which can be used for example from bracket routines. Once turned off in a capability or PSecW they cannot be turned on again.

When an environmental instruction is used which has been switched off it returns the value -1.

References

[1] H. C. Lauer and R. M. Needham "On the Duality of Operating System Structures", ACM Operating Systems Review, 13, 2, pp. 3-19, 1979.