One of the problems AS/400 administrators face is that of giving users different levels of authority for an object under different circumstances. Consider the following security problems:
o Sue needs to run an inquiry program to retrieve an employee's name and mailing address from the employee master file, but you don't want her to use Query against the file because she might see salary information. You don't want to restrict Sue from running Query, though, because she needs to use Query for other files. How can you let her read the employee master file through the inquiry program without letting her read it through Query? The answer is adopted authority.
o Joe needs to use a file maintenance program to change records in the vendor master file, but you don't want him to use a utility program (such as DFU) to change vendor records. How do you give him *CHANGE authority while he's running the maintenance program, yet give him *USE authority at other times? Again, the answer is adopted authority.
o How can you let help desk personnel change the password of a user who's forgotten his password without giving them access to the Change User Profile (CHGUSRPRF) command? Big surprise-adopted authority is the answer.
o How can you allow system operators to save and restore data to which they are not authorized? Adopted authority to the rescue again.
All of these problems occur because OS/400 will not permit a user to have different levels of authority to an object under different circumstances. A good way to get around this restriction is to let a user temporarily adopt the authority of a program's owner while the program is executing.
Actually, giving a program adopted authority is simple. When you create a program, you specify whether the system should consider only the authority granted to the user who runs the program or the authority of the program's owner as well. You specify this with the User Profile (USRPRF) parameter of the Create xxx Program (CRTxxxPGM) command. USRPRF(*USER), the default, tells the system to check the user's authority only. If you specify USRPRF(*OWNER), the system considers the authority of both the user who is running the program and the owner of the program. When an object uses the owner's authority, it is known as adopted authority.
When a program adopts authority, it inherits the owner's object authorities and special authorities. In general, the user running the program has the owner's authorities as long as the program remains in the invocation stack. (This creates a serious security exposure, which I'll discuss in more detail later.) The exceptions that suspend adopted authority occur when you use the System Request or Attn key, when you execute a group job request, during the execution of a break-message handling program, and during debug operations.
If you recompile a program and specify REPLACE(*YES), the USRPRF and Authority (AUT) parameters will be ignored. The new copy of the program will have the same USRPRF, Use Adopted Authority (USEADPAUT), and AUT values as the replaced program. To allow an existing program to adopt authority, you must either use the Change Program (CHGPGM) command or delete the program object before recompiling.
Let's take a look at how adopted authority can resolve the security problems I presented at the beginning of this article.
In Sue's situation (retrieving an employee's name and address), you tell the system that Sue is not to use the employee master file at all; grant her *EXCLUDE access. Change the inquiry program to adopt the authority of its owner, who should have *USE authority (or greater) to the employee master file. Sue can see the employee's name and address through the inquiry program she uses, but she can't read the file from Query, SQL, or other query tools.
As regards the problem of the vendor master file, you want Joe to be able to read the file and change vendor information only if he does it through the file maintenance program. By giving him *USE authority to the vendor master file, you allow him to read it but not make changes to it. Joe can run programs that read the vendor master, and he can use query packages to retrieve information from the vendor master.
You must also grant him *USE authority to the file maintenance program so he can run it. You give ownership of the file maintenance program to another user who has *CHANGE authority (or higher) to the vendor master file. Change the maintenance program to adopt the owner's authority. Joe runs the program and, since the owner can change the file, Joe gets to change the file. When Joe cranks up DFU to change a vendor's record, however, he is met with a surprise. The system will not let him change the file.
The last two security problems I mentioned earlier are basically solved by creating a program to run the commands the user needs to run and having that program adopt the authority of its owner.
For all its benefits, adopting authority poses some security risks. To take advantage of adopted authority, you must understand and protect against such risks. For example, it is critical that programs that adopt authority do not give users access to a command line.
If you allow a program to adopt authority, you may unintentionally permit a user to do things he shouldn't do. All the user needs is a command line or an appropriate utility to take advantage of the adopted authority. The potential risks multiply if the program adopts the authority of a user who has *JOBCTL or *ALLOBJ authority. Given *JOBCTL authority and a command line, a user can modify any job on the system. A user who inherits *ALLOBJ authority can potentially access any object on the system.
Another risk is that a program that is not meant to adopt authority-that is, it was compiled with USRPRF(*USER)- might use the authority of another program. By default, a program can use the authorities of programs higher in the invocation stack. 1 contains data from an invocation stack. PGMA calls PGMB. It would appear that a user of PGMB has no access to objects to which he is not authorized. Since PGMB inherits the adopted authority from programs higher in the invocation stack, PGMB can run under the authorities of PGMA. PGMB runs under QSECOFR's authority, and Joe has authority to all objects on the system. Again, if PGMB includes a command line or is a utility program, the danger is that Joe has access to do nearly anything.
Another risk is that a program that is not meant to adopt authority-that is, it was compiled with USRPRF(*USER)- might use the authority of another program. By default, a program can use the authorities of programs higher in the invocation stack. Figure 1 contains data from an invocation stack. PGMA calls PGMB. It would appear that a user of PGMB has no access to objects to which he is not authorized. Since PGMB inherits the adopted authority from programs higher in the invocation stack, PGMB can run under the authorities of PGMA. PGMB runs under QSECOFR's authority, and Joe has authority to all objects on the system. Again, if PGMB includes a command line or is a utility program, the danger is that Joe has access to do nearly anything.
One common cause of this type of security breach is the use of CL programs to provide menus. If a CL menu program adopts its owner's authority, everything the user does while that menu is in the stack is a potential security problem. Menu options may include commands that supply a command line, such as Work with Spooled Files (WRKSPLF), Work with Output Queues (WRKOUTQ), and Work with Submitted Jobs (WRKSBMJOB). It is good to prevent the programs called by the CL menu program from using the authority of the CL menu program.
To prevent a program from using the authority of a program higher in the invocation stack, use the CHGPGM command, specifying USEADPAUT(*NO). When you create a program, the default value for the USEADPAUT parameter is *YES. Unfortunately, the USEADPAUT parameter is not available with the CRTxxxPGM commands.
So there are really two ways a program can adopt authority. Compiling the program with the option USRPRF(*OWNER) lets that program adopt authority from the program's owner. A program can also adopt authority from previous programs in the call stack that have adopted authority, unless you change the program with the CHGPGM command, specifying USEADPAUT(*NO).
You can implement security on the AS/400 in different ways. The following recommendations are not the only ways-or necessarily the best ways-to secure your data. They are recommendations for using adopted authority. You won't be able to use all these; pick the ones that apply to your situation.
1. Separate objects into those that don't store data-such as programs, display files, and printer files-and those that do-such as database files and data areas.
Generally, the data objects should specify that *PUBLIC has *EXCLUDE authority to keep unauthorized users out of the files.
The nondata objects should specify that *PUBLIC has *USE authority so users can run these programs. (For more sensitive applications, such as payroll, you might prefer to give *EXCLUDE authority to *PUBLIC.)
By restricting *PUBLIC authority to objects, you set up a default that reduces the possibility that users will have more access to objects than you intend them to. You can give more authority to the users who need it by granting authority to their individual or group profiles.
An excellent way to separate different types of objects is to put them into separate libraries. When you create a library for data objects, specify CRTAUT(*EXCLUDE). When you create a library to hold nondata objects, specify CRTAUT(*USE). These will set the defaults for new objects created in the libraries.
Double-check the objects in your existing libraries. If you did not specify the authority granted to *PUBLIC when you created those objects, they probably have *CHANGE authority, which indirectly comes from the QCRTAUT system value.
2. Keep users menu-bound as much as possible.
If possible, give the users just the options they need. There are commercial programs that build menus dynamically from options stored in a file. You can also create your own or you can use the program described in "Creating OS/400-Style Rolling Menus" (MC, May 1990). This is not a necessity, of course, but in an environment in which programs typically adopt authority, restricting the menu options to just those a user needs is a good idea.
If your dynamic menu program uses a database file to determine what options a user can perform, be sure no one can change the library list, or someone might insert a library with his own database file ahead of yours. The best way to keep someone from changing the library list is to prevent him from using a command line.
3. Specify LMTCPB(*YES) for most user profiles.
Users with LMTCPB(*YES) are not able to enter commands from the command line, even under adopted authority. They also won't be able to press the F4 key to get the Major Command Groups menu. You can set a user profile to LMTCPB(*YES) using the Create User Profile (CRTUSRPRF) or CHGUSRPRF command.
For the commands that you want all users to have access to, specify ALWLMTUSR(*YES) on the Create Command (CRTCMD) or Change Command (CHGCMD) command.
4. Beware of initial programs that adopt authority.
If possible, let a user's initial program come to end of job. That is, don't let the initial program remain in the job stack during the interactive session if it's not necessary.
5. Use native menus rather than CL program menus.
If a user runs a command with a command line-such as the Work with Spooled Files (WRKSPLF) command-from a CL program that adopts authority, he could get into places he doesn't need to be.
6. If you use CL program menus, don't allow them to adopt authority.
After compiling the CL program, run the CHGPGM command, specifying USEADPTAUT(*NO). Add a comment to the CL source to remind you or inform someone else to change the program every time it's compiled.
7. Don't put commands that run file utilities-such as Run Query (RUNQRY) and Start DFU (STRDFU)-directly behind menu options.
Menu options that run file utilities should run them indirectly through CL programs.
Don't let these CL programs adopt authority from the owner or from programs higher in the invocation stack. The users still have access to Query or DFU, but they have to run those programs under their own authority.
8. Try to limit the amount of authority adopted.
Instead of giving ownership of your programs to QSECOFR, set up some dummy "super users" to own programs. Give these user profiles access to just the necessary objects and not to special authorities like *JOBCTL, *SPLCTL, or, heaven forbid, *SECADM and *ALLOBJ. Set the passwords for these super users to *NONE, so no one can sign on under these user IDs.
9. Use the Transfer Control (TFRCTL) command rather than CALL.
There will be circumstances in which you cannot follow this rule, but, in general, it provides a higher level of security. CALL leaves the invoking program in the stack, and programs lower in the stack may be able to adopt authority from it. TFRCTL removes the invoking program from the stack, so its authority cannot be passed along.
10. Process in batch rather than interactively.
Not only is batch processing good for performance, but it is also a good security process as batch jobs do not inherit authority from submitting jobs.
11. Run the Display Programs that Adopt (DSPPGMADP) command periodically.
The DSPPGMADP command displays the objects that adopt the authority of a specific user profile. This command provides you with a good way to check for potential security exposures due to program adoption.
12. Don't depend on a user's ignorance of OS/400 to keep him out of information.
I have been surprised on more than one occasion to learn that a user knew more than I had given him credit for. Besides, you never know who has a friend or relative who programs an AS/400. For example, a one-minute lesson from an AS/400-savvy outsider may be all a user needs to learn to run the RUNQRY command over a file from a command line.
13. Protect the library list or qualify object references with a specific library.
If a hacker knows that PGMA adopts the authority of the security officer and then calls PGMB, he can place a program with the name PGMB in the library list before the library that contains the intended PGMB. Since the adopted authority of PGMA is propagated to called programs, the hacker's version of PGMB will inherit the propagated authority. You can limit this exposure in two ways.
o Qualify all references to programs and commands with a specific library.
o Save the library list on entry to the adopting program, and set the library list as expected. On exit, restore the saved library list.
If you don't like to qualify objects, specifying LMTCPB(*YES) on user profiles will protect the library list. Users with limited command line capability cannot execute commands that change the library list.
14. On programs that adopt, specify LOG(*NO) and ALWRTVSRC(*NO).
This prevents a hacker from determining the program logic and possibly compromising the adopted authority.
Sometimes we get so busy fighting fires and whacking away at the backlog that we neglect security. Granting *PUBLIC a minimal amount of authority to objects by default and granting more authority as needed on an individual basis tightens security and reduces the amount of attention you must give to security issues.
Keep in mind that restricting authority is a way of protecting users, not an expression of a lack of trust in them. By restricting authority, you protect a user in several ways. First, if a user has no way to get to sensitive information, he is less likely to be suspected if sensitive information is leaked. Second, you protect his privacy by locking everyone out of sensitive information about him, such as payroll data. Third, you help him do his job by keeping others out of the data he is responsible for maintaining. Fourth, you prevent the user from accidentally deleting objects. If you communicate these ideas to your users, they are less likely to get perturbed when they must come to you for authorization.
You can secure the data on your system and, at the same time, give users the authority they need-no more, no less-when they need it. Adopting authority is one powerful tool that can help you do that.
Ted Holt is an associate technical editor for Midrange Computing. He can be reached by E-mail at
Reference
OS/400 Security?Reference V3R1 (SC41-3302, CD-ROM QBKALC00).
The Benefits and Dangers of Adopted Authority
Figure 1: Partial Invocation Stack in which PGMB Adopts Authority from PGMA
Program Owner USRPRF USEADPAUT PGMA QSECOFR *OWNER N/A PGMB JOE *USER *YES
Ted Holt is IT manager of Manufacturing Systems Development for Day-Brite Capri Omega, a manufacturer of lighting fixtures in Tupelo, Mississippi. He has worked in the information processing industry since 1981 and is the author or co-author of seven books.
MC Press books written by Ted Holt available now on the MC Press Bookstore.
 |
||
 |
|
Complete CL: Fifth Edition Become a CL guru and fully leverage the abilities of your system. List Price $79.95 Now On Sale
|
|
||
 |
|
Complete CL: Sixth Edition Now fully updated! Get the master guide to Control Language programming. List Price $79.95
Now On Sale
|
|
||
 |
|
IBM i5/iSeries Primer Check out the ultimate resource and “must-have” guide for every professional working with the i5/iSeries. List Price $99.95 Now On Sale
|
|
||
 |
|
Qshell for iSeries Check out this Unix-style shell and utilities command interface for OS/400. List Price $79.95
Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online