By Rich Loeber
On your IBM i, every object is owned by a user profile, even if it is just a system default owner profile. As objects are created, the ownership is established by the person who creates the object. When new objects are added to your system that were created on a different system, such as third party software or objects restored to your system from another IBM i, the ownership that was in effect on the other system is carried over onto your system.
Program objects have a unique aspect of ownership that many programmers and users of IBM’s i/OS may not be aware of. There is a setting in each *PGM object on your system that controls authority checking whenever that *PGM object is executed. This is controlled by the USRPRF parameter when the program is compiled. For existing programs, it can be changed by the CHGPGM command.
The default setting for the various compilation commands in i/OS, as shipped from the factory, sets the USRPRF parameter to the value “*USER”. This means that when that program runs, the security settings are checked according to the user profile in effect for the user who actually runs the program. This is the intuitive setting that you would normally want to have in effect. When a user runs a program, you only want them to have access to objects on your system that they are authorized to work with. If they run a program that they are not supposed to be using; one that accesses objects they are not authorized for, then you want the OS security to kick in an prevent the object access. As long as your programs are set to *USER for the USRPRF parameter, then this is exactly what will happen.
The alternate setting for the USRPRF parameter in programs is *OWNER. When this is specified, then the program is said to “adopt” the security settings for the user profile that owns the *PGM object (regardless of who is running the program). So, using this method, someone with fairly limited security authorization can run a program and access objects that they are not normally cleared for. A good example of when this is desirable would be with a payroll application where a clerk is cleared for file maintenance under program control but you don’t want them to have access to the payroll files for any other purposes. By having the maintenance program adopt the authority of the program owner, you can accomplish this with ease.
So, what’s the problem then with adopted authority?
The problem is that it can be misused and, under certain circumstances, open your system to abuse. Because of this, you need to know which programs on your system use adopted authority and then check those programs to make sure that they are well behaved and don’t break any of the generally accepted rules for programs of this type.
As an example, having a program that uses adopted authority which is owned by a user profile with *ALLOBJ authority could lead to a security exposure. If that program contained an option to display an open command line, then the user could gain access to your entire system. When reviewing this situation, it is important to remember that not only can security authority be adopted, it can also be inherited. This happens when a program with adopted authority is run and then calls another program deeper in the program stack. That called program will inherit the adopted authority of the program that called it from higher up in the program call stack. This inheriting feature is only in effect for a single call level. If your called program then, in turn, calls a third program, then the inherit feature is no longer in effect.
IBM’s i/OS contains a reporting feature that will allow you to review programs that adopt authority so you can see where your possible exposures may lie. The Print Adopting Objects (PRTADPOBJ) command will let you review this on-line or via a printed report. It is run by user profile and, at a minimum, you should take a look at all of your user profiles that have *ALLOBJ authority.
This just scratches the surface of the issues associated with programs that adopt their owner’s authority. For additional research, take a long look at the IBM i Security Manual. It will show you ways to limit the use of adopted authority and provide additional insights into the issues presented.