Resource identification is another area that can be subject to
integrity exposures. Exposures can result if the control program
does not maintain and use sufficient data to uniquely distinguish
one resource from other similar resources. For example, a program
must be identified by both name and library to distinguish it from
other programs. The consequences of inadequate resource identification
are problems such as the ability of an unauthorized problem program
to create counterfeit control program code or data, or to cause varying
types of integrity problems by intermixing incompatible pieces of
control program code or data, or both.
The general solution can only be stated as the reverse of the problem;
that is, the control program must maintain and use sufficient (protected)
data on any control program resource to distinguish between that resource
and other control program or user resources. The following are examples
of the controls that the system employs to comply with the requirement:
- In general, authorized program requests to load other authorized
programs are satisfied only from authorized system libraries (see “Control
Program Extensions” described in this information.)
- The operating system takes explicit steps to ensure that routines
loaded from authorized system libraries are used only for their intended
purpose. This includes expanded validity checking to remove any potential
for the unauthorized program to specify explicitly which of the authorized
library routines are to gain control in any given situation.
- Sensitive system control blocks are validated as being the “correct”
blocks to be used in any given control program operation. (See “User-Supplied
Addresses of Protected Control Blocks” described earlier in this
information.)