Adopted Authority Defined
Q: I am new to the iSeries 400 and have just been given the job of security officer. The programmers will sometimes throw the term "adopted authority" into the conversation, but I can't find a definition of the term. Help!
A: Adopted authority is a way to temporarily give users authority to objects. Adopted authority is configured through a program attribute. When the program is called, the adopted authority is in effect for as long as it's in the call stack. The authority you gain while the program is in the stack is the program owner's authority. Therefore, for as long as the program is in the stack, OS/400 will check both the caller of the program as well as the owner of the program for sufficient authority to access objects.
Adopted authority is often used by application developers to implement Wayne Evans' "Application Only Access" authorization model. In this authorization model, objects, such as database files, can be accessed only when a user performs an authorized function. These authorized functions are typically enabled via application menu options. Any attempt by a user to access a file directly, using an interface such as FTP, will fail with a "Not authorized" message. These attempts fail because public access is typically set at *EXCLUDE and users are not given a private or explicit authority to the application objects. However, users will be able to perform necessary functions when going through the application, because the profile that owns the programs that actually run the menu options adopts the owner's authority. The program owner then either owns the database files or, in more secure implementations, has just enough authority to the application objects to perform the application's functions.
Another popular implementation of adopted authority is used on system administrators' and operators' menus. Admins and operators are often given menus from which they perform their tasks. You can build a menu in which one or more options is a function that requires more authority than the system administrator or operator has been given. For example, to reset a user's password, you need authority to the user profile and *SECADM special authority. Rather than give the system administrators *SECADM, you can create a menu option that calls a program that does the Change User Profile (CHGUSRPRF) command. This program adopts and is owned by a profile that has *SECADM special authority, as well as *USE and *OBJMGT authority to all profiles on the system.
Adopted Authority Program Attributes
Q: In last month's Security Patrol, you said that to configure a program to adopt authority you change the User profile parameter from *USER to *OWNER. I am truly confused. I always thought it was the Use adopted authority parameter that controlled whether a program adopts. If it's not used to control whether a program adopts, what's it used for?
A: Don't feel bad. It is a widespread misperception that it is the Use adopted authority (USEADPAUT) parameter that controls whether a program adopts. You read correctly; it is the User profile (USRPRF) program parameter that controls whether a program adopts. The default value for the User profile parameter is *User, which means that the program will not adopt authority. Changing it to *OWNER configures the program to adopt authority. In Figure 1, the program PGM_A is owned by QSECOFR and adopts its owner's (that is, QSECOFR's) authority when it runs because the User profile parameter has been changed to *OWNER.
Figure 1: The program attributes important to adopted authority are User profile and Use adopted authority.
The Use adopted authority parameter determines whether the program will use adopted authority being passed to it from a program higher in the call stack. You see, when a program adopts, the program will automatically pass that adopted authority along to subsequent programs. There's no option not to pass along the adopted authority--it happens automatically and whether you want it to or not. The Use adopted authority parameter gives you the option of whether you want OS/400 to use or include this adopted authority when it checks to see if the process has enough authority to access an object. Let's look at the example in Figure 2.
Figure 2: This figure shows how adopted authority is passed from one program to another.
Step 1: Someone or some menu option calls FIRST_PGM. It adopts the authority of the application profile (you know this because the User profile parameter is *OWNER). When OS/400 checks to see if objects can be accessed, it first checks the authorities of the caller of the program. If not sufficient, then APP_PROF's authorities are checked.
Step 2: FIRST_PGM calls SECOND_PGM. Because the Use adopted authority parameter has been left at the default *YES, it means that when OS/400 checks authorities, it will check the authorities of the caller of the program, APP_PROF (because SECOND_PGM is using the adopted authority being passed to it from FIRST_PGM) as well as QUSER (because SECOND_PGM itself adopts and is owned by QUSER.)
Step 3: SECOND_PGM calls LAST_PGM. Because LAST_PGM does not adopt (the User profile parameter is set to *USER) and does not use the adopted authority from either FIRST_PGM or SECOND_PGM (the Use adopted authority parameter has been set to *NO), OS/400 will only check the authorities of the caller of the program while LAST_PGM is running.
Obvious observations:
Because adopted authority flows from one program to the next, you'll want to be careful to not put up command lines, etc. that will give a user access to the adopted authority. The worst scenario is that a program is owned by QSECOFR and adopts and then puts up a command line or the command entry screen!
- Be careful when adopting a powerful profile such as QSECOFR. You'll want to limit these programs to perform only the function requiring this type of power.
- Make library-qualified calls with adopted authority. OK, I realize this is a controversial recommendation--especially for application writers. But if a program is adopting and it makes a *LIBL call and an engineering user can get her own program inserted in a library higher in the library list, her program will be called instead of the intended program. Guaranteed her program will exploit the adopted authority being passed to it.
Exploiting Non-Library Qualified (*LIBL) Calls
Q: It's pretty easy to determine what calls are made out of a program and which ones of those are library qualified (or not). Some third-party applications adopt a profile like QSECOFR and then make *LIBL calls. This has created a huge exposure for my system. What can I do to eliminate this risk?
A: There are a couple of ways to fight this problem. First, make sure there are no libraries in the library list (especially the system portion of the library list) that allow someone to add a program into them. In other words, eliminate the libraries to which users have *CHANGE authority. You may not be able to eliminate them all because users often have a legitimate need to create objects into libraries. In that case, move the library with *CHANGE authority as far down in the library list as possible. The idea is to remove the opportunity to have a "rogue" program called instead of the one that's supposed to be called.
In addition, a system value, QUSEADPAUT, was created to try to fight this problem. This system value takes the name of an authorization list. If a user has authority to this authorization list, the user will be able to create programs that use adopted authority, i.e., the Use adopted authority parameter is set to *YES. If the user doesn't have authority to the authorization list, then any program that user creates is automatically set to Use adopted authority *NO. If you are going to use this authorization list, make sure to update the authorization list with the profiles that need to create programs that use adopted authority, such as the profile your change management software runs under, etc.
What Is Included in Adopted Authority?
Q: Exactly what authorities get checked when adopted authority is in effect?
A: The program owner's authorities are checked. These include any private authorities to individual objects or authorization lists, ownership to other objects, and any special authorities (such as *ALLOBJ or *SECADM) the owner has.
Is Group Authority Included in Adopted Authority?
Q: When a program adopts its owner's authority, does that include the owner's groups?
A: No. When OS/400 checks authority, it only checks the program owner's authorities, not any groups the owner may have.
How Adopted Authority Works with the IFS
Q: I'm setting up an application and trying to serve Web pages out of the Integrated File System (IFS). The directories are set as *PUBLIC(*EXCLUDE), and I've changed the user profile parameter of the programs to *OWNER. But when I call the program that's adopting, I get a "not authorized" message. I've implemented adopted authority before, and I know that I've got everything configured correctly. What's going on?
A: Unfortunately, the title of this section would be better listed as "How Adopted Authority Doesn't Work with the IFS." When accessing objects in the IFS, OS/400 totally ignores any adopted authority that may be in effect.
Adopted Authority and System Performance
Q: Does adopted authority have an effect on system performance?
A: It depends. If the program owner also owns the object being accessed (like the database file being opened), this an extremely fast check, thanks to an enhancement added by the folks in Rochester. If the program owner has a private authority to the object, the check is slightly slower, but it's quite doubtful you'd ever notice a performance hit using that method.
Tracking Adopted Authority
Q: Several user profiles have appeared on the system, and they were not created based on the normal request process from HR. I suspect that a couple of my programmers are abusing the fact that one of our third-party applications adopts authority and doesn't make library-qualified calls. Is there any way I can find out for sure?
A: One of the auditing options OS/400 provides is *PGMADP. If you add this value to the QAUDLVL system value, anytime adopted authority is used, an audit entry will be cut. Note that you will get an audit entry only if the adopted authority is used to access the object, not just because a program that adopts authority is called. The user calling the program has his authority checked first. If his authority is sufficient, OS/400 never looks at the adopted authority. I mention this because this cuts down on the number of audit journal entries you're going to generate by turning on this value. Also, if you know or have a strong suspicion who the culprits are, you can turn on this value in their specific profile(s) by using the Change User Audit (CHGUSRAUD) command.
In addition, the Display Programs that Adopt (DSPPGMADP) and Print Adopting Objects (PRTADPOBJ) commands will help you find the programs, service programs, and SQL packages that adopt.
If you would like to submit a question for possible inclusion in a future Security Patrol, please send it to
Carol Woodbury is co-author of the book Implementing AS/400 Security as well as co-founder of SkyView Partners, a firm specializing in security consulting and services. Carol has over 12 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology.
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