Screening Requests Based on Simple Policies

• The application itself

• The security service module targeted to perform the service

• The CSSM

• An add-in service module that performs policy evaluation

To screen its own security service requests, an application must have a priori knowledge of the system-wide policy, runtime knowledge of the execution environment, and a willingness to follow the rules. Embedding the policy in the application makes the system-wide policy static. This approach also raises a concern about consistency of policy interpretation and enforcement when each application performs this task. It is often counter-productive for applications to screen/control their own security service request stream.

Each add-in security service module could screen the application requests it receives. This leads to the same problems and concerns encountered with applications screening their own requests. It is also a burden that CSSM should be able to remove from the module vendor community.

The remaining two options, CSSM and special add-in modules that perform policy evaluation, can be used in combination or alone to screen application requests according to a system-wide policy.

Simple Policies

• It can be evaluated in a single atomic execution of an evaluation function.

• The input required for evaluation of the policy is localized and available when the evaluation must be made.

• The screening mechanism is transparent to the application (except for rejected service requests).

CSSM Mechanisms Supporting Simple Policies

• Module installation check-the basic install time verification procedure is extended to include a comparison of the module's basic capabilities with the system-specified restrictions. This determines whether the module's capabilities are valid under current system constraints. If the module is found to be unacceptable then module installation is aborted.

• Module attach check-the basic attach time verification procedure is extended to include a comparison of the module's basic capabilities with the system-specified restrictions. This determines whether the module's capabilities can validly be attached to the CSSM framework, under current global policy constraints. If the module is found to be unacceptable then module attach is aborted. This is the same test that was performed at module installation. It is re-evaluated at module attach because the governing system-wide policy can change between the time of module install and module attach.

• Security service invocation-checking mechanisms are required to determine the validity of function calls.

CSSM enforces simple system-wide policies by screening function calls against:

• The signed system-wide policy description

• The signed capabilities description of the target security service module

This mechanism is:

• Transparent to the calling application-the application does not make additional calls to obtain pre-approval for their requests.

• Policy-neutral-it does not embed any specific policy, but can dynamically check different policies as they are installed. The permitted operations are specified by the administrator defining the system policy and the module vendor specifying the add-in module's capabilities. The CSSM mechanism is "table-driven".