Question: In the mainframe environment, there is a ZAP utility that allows whoever has access to it to overwrite all controls. Is there an equivalent utility for the AS/400, or are these powers granted exclusively to supervisor/administrator-type users?
Answer: In your question, I assume that when you say “overwrite all controls,” you mean bypass the security controls that limit which users can access an object. There is no ZAP utility on the AS/400, but OS/400 includes a utility called the System Service Tools (SST) that has a display/alter function that can display or modify any object. Access to objects in SST is not limited by object authority, so this utility is the equivalent of the ZAP utility. The users must have *SERVICE special authority in their user profile to use SST.
A similar utility, called the Dedicated Service Tool (DST), includes the display/alter function. DST requires access to the system console, the system to be in manual mode (requires system key), and the entry of the DST password.
Both the SST and DST functions can be used to circumvent system security and should be carefully controlled. These utilities could change critical system control blocks and cause the system to be unusable.
Discourage Unauthorized Prying with QUSEADPAUT
Question: What is the purpose of the system value QUSEADPAUT, and what security exposure is it attempting to prevent?
Answer: Explaining the QUSEADPAUT system value and the exposure it is attempting to prevent is somewhat complex. By way of explanation, I must first provide some background material about two program attributes related to the program adoption of authority because this information is essential to understanding the security exposure. I will then explain the exposure and how the system value can be used to prevent the exposure.
To create a program that adopts authority, specify the USRPRF (*OWNER) parameter on the CRTxxxPGM command to indicate that the program uses the authority of
the owner of the program in addition to using the authority of the user running the program. When a program that adopts authority calls another program, the adopted authority is propagated to the called program unless the called program has an attribute USE-ADPAUT (*NO). The USEADPAUT(*NO) attribute specifies that the called program should not run using the adopted authority of other programs higher in the invocation stack. As shown in Figure 1, PGM1 was created to adopt the authority of the program owner A. PGM1 calls PGM2, and the adopted authority is propagated to the called program PGM2. PGM2 can access objects using the authority of the owner of PGM1 because the adopted authority is propagated. PGM3 has the USE-ADPAUT (*NO) attribute, so the adopted auth-ority is not propagated when PGM3 is called.
With this background about program adoption, I can now explain the security exposure. Many applications use adopted authority and call subprograms. If the application that adopts authority uses the library list to find called programs, this introduces a potential exposure. A hacker intent on breaking security could create a program with the same name as the called subprogram in the application into another library. The hacker’s program would be called by the application if the library containing the hacker’s program appears before the application library on the library list.
Three conditions must exist to create this potential exposure:
1. Applications that adopt often call subprograms to perform applicaton functions. If the CALL locates the subprograms using the library list, this allows the potential for an alternate program to be invoked.
2. The hacker library must be inserted in the library list before the application library. If the application library appears on the user portion of the library list, it is easy to insert a hacker library in the library list using the CHGLIBL or CHGCURLIB command.
3. The hacker must create a program that both inherits adopted authority and is named the same as the application program.
The applications that adopt authority can prevent the potential security exposure by either using a fully qualified name when calling the program or by controlling the library list within the program stack. Usually, modifying the application to eliminate the exposure is difficult because, often, you do not have the source for purchased applications. Also, preventing users, such as programmers, from modifying the library list for their job or from creating programs is not practical. The QUSEADPAUT system value prevents the exposure by restricting the users who can create or change programs with the USEADPAUT (*NO) attribute.
The QUSEADPAUT system value can contain the name of an authorization list. The user’s authority is checked against this authorization list. If the user has at least *USE authority to the named authorization list, the user can create, change, or update programs or service programs with the USEADPAUT (*YES) attribute.
Most AS/400 installations leave the QUSEADPAUT system value at *NONE. The value *NONE does not restrict which users can create programs that inherit adopted authority. (This would be an obvious security hole.) Naming an authorization list is a good way to protect a production system from this kind of security exposure.
Question: Why does a program that adopts *ALLOBJ authority get authority failure messages when accessing objects in the Integrated File System (IFS)?
Answer: Adopted authority is not used when accessing objects in the IFS. The retrieval of information from the IFS is not performed in your job. Access to IFS is performed by a server job so no adopted authority is used.
Adopt Owner PGM2
Figure 1: This is an example of adopted authority.