Trusted software design
The process of creating trusted software is similar to that for any critical software component. The creation of trusted software should follow a carefully understood and documented specification, design, implementation, testing, and configuration control cycle.
The most important aspects of trusted software design are the identification of the subjects and objects and the definition of precise security actions at the proper level of abstraction. Most security policies are restrictions on subjects, objects, and actions. When subjects request permission to read, alter, or create objects, security policies monitor those requests and approve or deny these requests.
Subjects
A subject is normally represented by a user ID and group IDs. Normally the process's effective user and/or group ID is used for this purpose, although it may be appropriate in some cases to use the real user and/or group ID.
Objects
An object is any collection of data to which access should be controlled. In most cases, objects are files. Although it is common for trusted programs to control access to logically distinct objects within the same file, it is generally better practice to map objects one-to-one onto files.
In some cases, a subject can also be considered an object. For example, a process is normally considered a subject. However, when one process attempts to affect a second process, the second process is normally considered an object with respect to this operation.
Requests
Requests are sets of actions that a trusted module performs on behalf of a subject. Each request must be clearly identified in terms of the request's inputs, possible outputs, and results, including all side effects. The precise identification of all requests is an important prelude to the definition of security policies.
Security policies
Security policies include simple statements indicating when requests involving specified objects will be performed on behalf of specified subjects. Subjects, objects, and requests should be carefully defined and security policies should be concise and straightforward. It is important to specify the identity of the requesting subject and the objects involved for the purposes of auditing.