System integrity

An operating system is said to have system integrity when it is designed, implemented and maintained to protect itself against unauthorized access, and does so to the extent that security controls specified for that system cannot be compromised. A multilevel-secure trusted computing base ensures system integrity. The trusted computing base has the ability to protect itself against unauthorized user access. An unauthorized program cannot bypass store or fetch protection, bypass password checking, bypass RACF® checking, or obtain control in an authorized state.

A change to the trusted computing base could compromise the integrity of the system. The installation must ensure that any authorized programs added to the trusted computing base maintain the same controls or equivalent measures to protect the trusted computing base from unauthorized access. Any installation-written authorized code also must perform the same or equivalent type checking that the trusted computing base uses.

An authorized program is any program that executes in PSW key 0-7, in supervisor state, or is authorized by the authorized program facility (APF). See z/OS MVS Programming: Authorized Assembler Services Guide for some of the potential system integrity problems for an authorized program, including:
  • User-supplied addresses for user storage areas.

    Routines with keys 0-7 must verify that the storage area that they are storing into or fetching from is in fact accessible to the user.

  • User-supplied addresses for protected control blocks.

    Routines with keys 0-7 must verify that a control block address is valid and that the control block itself is not fraudulent.

  • Resource identification.

    Authorized programs must do validity-checking to ensure that they are using the intended resource.

  • SVC routines calling SVC routines.

    Problem programs might have the opportunity to alter data passed to authorized SVC routines.

  • Control program and user data accessibility.

    Sensitive system data must be stored in and fetched from protected storage.

  • Resource serialization.

    Routines should use locking mechanisms to prevent unauthorized altering of data.

Additionally, you should take care when adding any program that will run under a user ID that has UID(0), or with authority to the FACILITY class resources BPX.DAEMON, BPX.SERVER, or BPX.SUPERUSER, or to resources in the UNIXPRIV class. While such programs do not fit the traditional z/OS® definition of an authorized program, they have broad authority to access data in the system or to assume other identities. If they have design or programming flaws then use or misuse of such programs could seriously compromise system security or integrity.