Preventing the use of unsupported interfaces

At security level 40 or higher, the system prevents attempts to directly call system programs that are not documented as call-level interfaces.

For example, directly calling the command processing program for the SIGNOFF command fails.

The system uses the domain attribute of an object and the state attribute of a program to enforce this protection.
  • Domain:

    Every object belongs to either the *SYSTEM domain or the *USER domain. *SYSTEM domain objects can be accessed only by *SYSTEM state programs or by *INHERIT state programs that are called by *SYSTEM state programs.

    You can display the domain of an object by using the Display Object Description (DSPOBJD) command and specifying DETAIL(*FULL). You can also use the following commands:
    • Display Program (DSPPGM) to display the domain of a program
    • Display Service Program (DSPSRVPGM) to display the domain of a service program
  • State:

    Programs are either *SYSTEM state, *INHERIT state, or *USER state. The *USER state programs can directly access only *USER domain objects. You can access objects that are *SYSTEM domain by using the appropriate command or application programming interface (API). The *SYSTEM and *INHERIT states are reserved for IBM-supplied programs.

    You can display the state of a program by using the Display Program (DSPPGM) command. You can display the state of a service program by using the Display Service Program (DSPSRVPGM) command.

Table 1 shows the domain and state access rules:

Table 1. Domain and state access
Program state Object domain
*USER *SYSTEM
*USER YES NO 1
*SYSTEM YES YES
1
A domain or state violation causes the operation to fail at security level 40 and higher. At all security levels, an AF type entry is written to the audit journal if the auditing function is active.

The supported interfaces for object access are by CL commands and IBM® i APIs. For example, accessing a DB2® file using the Open API or “read/add/update/delete record” API (which are also built into most runtime support) are examples of supported interfaces to access a *FILE object. Using SQL, DDM, DRDA, or any other IBM i provided interface is also a supported interface. Using CL commands such as CHGPF is also an example of a supported interface. The same is true for other object types, examples of supported interfaces for *PGM objects include calling a program, displaying a program using DSPPGM, and compiling a program. If the applications are developed with the supported interfaces and compiler statements and directives, your application, at ALL security levels, will run without system integrity errors. Security level 40 and 50 issues will be encountered if unsupported interfaces are used or direct object access is attempted by the application

“Direct” access to an object or IBM i control block, using the object address and then reading or modifying the bytes within the object, is NOT allowed. Using programming languages that support pointer/address access is typically how one could attempt the direct access. The C programming language is typically how one would attempt this type of access but pointer/address access is also available in other languages. Resolving (or the application runtime code finding the object within a library) and then setting a pointer to the internals of the object is NOT allowed on security level 40 and 50 but is allowed on security level 30 for most object types. Also, if a user program were to use an already “set” pointer that addresses a protected control block or object, and tries to read or write from this control block or object directly, then an exception will occur on security level 40 and 50 and the read or write would be denied. For most objects or control blocks, this access will work on security level 30. Resolved or set pointers/addresses to certain objects and control blocks exist within a users job. This is how one may obtain an already set pointer to a protected control block or object. An audit can occur on level 30 as “object domain” is applied to all objects and thus an audit record will be sent to the audit journal for violations that would occur on security level 40 and 50. See Enhanced hardware storage protection for a description of control blocks that aren’t “objects” so there is no object domain checking and no auditing available. The Object Domain setting for an object is displayed via DSPOBJD, *FULL display.

Within the Machine Interface, high-level instructions exist. Many of these instructions are available to user level programs and are generated by the compilers when programs are created. But, as a part of the MI instruction set, many of these instructions are reserved for operating system use (need extra privilege to use them). These restricted instructions are never generated by the underlying compile process of user code. They are only allowed when running an IBM i operating system program. HOWEVER, it is possible to patch or alter a program, by using the service tools or offline, to “add” one of these restricted instructions to a program’s instruction stream. This is why there is support in the system to “block” the use of these instructions from a user level program (these instructions, if used incorrectly, could cause serious issues in the system). There is also a CL command, CHKOBJITG (Check Object Integrity), that will look for these patched programs on the system and report them. The restore process will also look for patched programs during restore and will either remove the patch, audit the restore, or allow the patched program on the system (admin options using QFRCCVNRST, QVFYOBJRST and QALWOBJRST syst89iopem values).

Journal entry:

When the following conditions are met, an authority failure (AF) entry, violation type D or R, is written to the QAUDJRN journal:
  • The auditing function is active
  • The QAUDLVL system value includes *PGMFAIL.
  • An attempt is made to use an unsupported interface.