For security reasons, OS/400 programs have a setting that, when
compiled, controls the user profile that will be used when that program
runs. You may think your security configuration is all set and that
you've made a final determination as to which users are allowed to
access what objects on your system, but if a program on
your system is compiled with the USRPRF attribute set to *OWNER, then
all your preparation work may be out the window.
The USRPRF parameters for most program compilation commands is set to a default value of *USER on most systems. This is the way it comes from the factory. When programs are compiled with this setting, then you can count on your object security setup to provide the proper control over access to objects on your system. When this gets changed, however, then the access controls are based on the owner of the compiled *PGM object and not on the user profile of the person that is running the *PGM object. (Note: This also applies to *SQLPKG and *SRVPGM objects, but for the purposes of this article, I'm just referring to all of these generically as "programs".)
This situation is called adopted authority. There are lots of good reasons why you would want to do this. For example, you may have a CL program that creates backups of your system that is run by your night operator. You may not want your night operator's user profile to have all object authority, so you compile the CL program under a user profile that does have all object authority with the USRPRF parameter set to *OWNER. Then, when the night operator runs the backup, it goes off without a hitch. While the backup is running, it has access to the objects needed to complete the backup but the night operator profile is still restricted. A lot of third-party software developers use this technique to make sure that their programs can run without authority problems.
To make sure that your security is not being compromised by adopted authority issues, you should do a periodic review of programs that use this technique.
The first step is to identify the user profiles in your system that have all object authority. This step alone might produce some interesting results that will surprise you. One quick way you can do this is by running the following command:
DSPUSRPRF USRPRF(*ALL) OUTPUT(*OUTFILE) OUTFILE(QTEMP/USRPRF)
This creates a temporary physical file named USRPRF in your QTEMP library. Once created, you can scan this file for the value *ALLOBJ in the first seven positions of the field designated as UPSPAU. Query/400 should give you a quick report on what you're looking for. Check each profile listed to make sure there are no surprises.
Then, to see if there are any programs that adopt any of the profiles on your list, use the DSPPGMADP command for each profile. This command supports on-screen display, print and *OUTFILE output. Use the form that best suits your needs. At a minimum, you should check for programs that adopt the QSECOFR user profile. The command to review this looks like:
DSPPGMADP USRPRF(QSECOFR)
Once you have identified programs that run under a user profile that has all object authority, you should then determine if the requirement for adopted authority is absolutely necessary. In some shops where I've worked, I have identified programs adopting the QSECOFR profile because it corrected a problem during testing and was just left that way in production. One obvious problem would be if the program in question has an option to present the user with an OS/400 command line. In this situation, the user then has full access to your system that goes right around your careful security setup plans.
For third-party software, contact your software provider and ask about the adoption situation. A good software provider should have a ready answer for this question.
When you've identified a program that needs to be changed, you don't need to recompile to make the change. A simple Change Program command will work in most instances. Use the following command to change from adopted authority to user authority:
CHGPGM PGM(MYLIB/MYPGM) USRPRF(*USER)
If you have any questions concerning this tip, feel free to contact me directly. My e-mail address is rich@kisco.com.
Rich Loeber is president of Kisco Information Systems Inc., in Saranac Lake, NY. The company is a provider of various security products for the AS/400 market.
==================================
MORE INFORMATION ON THIS TOPIC
==================================
The adopted authority problem
Objects on your iSeries, such as programs, can adopt authority from
owners, users, other programs or even other systems. Is
that a problem? It can be.
Implications of giving a user *SAVSYS special authority
Systems management expert Ken Graap explains the possible
implications of giving a user *SAVSYS special authority to backup
other user's files.
How does adopted authority work?
One user writes, "We don't want to give the *SECADM to any user
profiles, but still we need some user ID's other than QSECOFR to
enable the user ID's. How does adopted authority work in this
matter?" Search400.com security expert Carol Woodbury explains.
Tightening iSeries security
As your company grows, so do the security risks -- from inside and
outside threats. Be aware of what's lurking around the corner. Our
resources can help you to protect your shop.
