Carol discusses the differences between these two methods of elevating authority on the IBM i.

Many organizations have the requirement to reduce the number of profiles to which special authorities—especially *ALLOBJ specially authority—have been assigned. In many cases, the excess capabilities can simply be removed because they aren't required for the person to perform their job functions. *SAVSYS special authority is a good example. Unless the person is performing system saves—i.e., is in the role of system operator or system administrator—the user does not need *SAVSYS assigned to their profile.

However, there may be cases when some users occasionally need a special authority to perform their tasks. In this case, you'll want to use a method that provides the user the special authority they need but not permanently assign it to their user profile. IBM i provides two methods to accomplish this: profile swap and adopted authority. I've written about adopted authority previously but haven't contrasted that method with swapping to another profile. Since many vendors provide tools to assist with privilege escalation and most provide the ability to either adopt or swap, I thought it might be helpful to explain the differences. First, let me explain how each method accomplishes the elevation of privileges.

Adopted authority is configured through a program's User profile (USRPRF) attribute. When the program is called, the adopted authority is in effect for as long as it's in the call stack. The authority the user gains while the program is in the stack is the program owner's authority, including any special authorities the program owner has. Therefore, for as long as the program is in the stack, IBM i will check the caller of the program as well as the owner of the program for sufficient authority to access objects or perform tasks.

A profile swap is performed by calling an API. When a profile swap occurs, the current user for the job is changed to be the profile you've swapped to. Now, when IBM i checks authority, it's no longer the original user's authority that's checked; it's the authority of the profile that's been swapped to. The profile's special authorities, groups, limited capability, and audit settings are all swapped in and become the new settings for the job where the profile swap API was invoked.

To sum it up, adopted authority provides you with the opportunity to use the authority of program owners to perform tasks or gain access to objects. Swapping to a profile changes the job to run as the profile being swapped to. Both allow the user who originally started the job to have more authorities than what's assigned to their profiles. Now let's see where they're different.

Current User

When calling a program that adopts, the profile that calls the program remains as the current user of the job. Not so with a profile swap. When the profile swap API is run, the current user changes to be the profile swapped to. This has implications when managing this job. It's important to understand that there are two profiles associated with a job: the job user and the current user. The job user is the profile under which the job originally started. The current user is the user under which the job is currently running. The job user will never change. Even after a profile swap, the job user will stay the original user. A good example would be the pre-started jobs used for ODBC. Those jobs start running as QUSER and, when identifying that job, QUSER will always remain as that middle component of the job name—for example, 078348/QUSER/QZDASOINIT. However, the current user of the job is always the profile that made the ODBC connection. There's nothing "wrong" or "bad" about this; it's just something to be aware of. You may remember that the User field on the Work with Active Jobs display was changed several releases ago to display the Current user rather than the Job user. This was done to help eliminate confusion over which user was running the job.

The other affected area is the audit journal. When elevating by calling a program that adopts, the User profile field in the audit journal entry will contain the user doing the work—that is, the Current user. In the case of a profile swap, there can be some confusion. In this case, the User profile field will contain the name of the swapped-to profile. This won't cause confusion except when all users swap to the same profile (which I've seen happen in many organizations.) In this case, the User profile field in all of the audit entries created after the profile swap contains the same name. If you are examining the audit journal and are trying to determine the person who actually did the work, you'll have to refer back to the job user field, which is called the User name. (The names of the audit entry profile fields are confusing, I know. The way I tell them apart is to look at the fields that surround them. You can tell the job user field because it's right after the Name of job field and right before the Job number field in the audit journal entry. The User profile field, that is, the Current user, comes several fields later.) To avoid the confusion of trying to tell which user did the work, I recommend that a separate profile be created so that individuals swap to a profile with elevated privileges that's easily identified with their profile prior to the swap. For example, CJW is the name of my profile with no privileges, and I swap to a profile called POWERCJW.

Submitted Jobs

I've said that adopted authority is in effect for as long as the program is in the call stack. That presents problems when you're submitting a job and you want the new job to run with the adopted authority. When a job is submitted, it's a brand-new job and a new call stack. Therefore, when you submit a job, the program that provided the adopted authority is out of the call stack and the adopted authority is gone. If you want the new job to elevate using adopted authority, then you'll have to re-establish the adopted authority—that is, call a program that adopts in the new (submitted) job.

When you submit a job after doing a profile swap, the new job runs as the swapped-to profile. In other words, the elevated privilege is still in effect in the new job.

Accessing Objects in the IFS

The IFS has some quirks to be sure, and one of them is that when accessing an object in the IFS, the operating system ignores adopted authority when checking a user's authority to an object. If you want to access an object in the IFS with elevated privileges, you must use the profile swap method.

Owned Objects

When calling a program that adopts, any objects that the user creates will be owned by that user. When using profile swap, anything created after swapping will be owned by the swapped-to profile. Challenges may arise if the job swaps back to the original user and that user needs to access the objects created by the swapped-to profile but doesn't have sufficient authority to access the object. Spooled files are a good example. If a spooled file is generated while the job is swapped and the job swaps back to the original user, the original user won't have authority to view the spooled file.

Final Thoughts

How do you decide whether to use adopted authority or profile swap? Sometimes it comes down to personal preference. I happen to prefer adopted authority because there's never any question in the audit entries about who performed a task. But some IBM i functions ignore adopted authority, such as accessing the IFS or creating a user profile and specifying group profiles. In this case, there's no choice but to use profile swap. My only concern with profile swap is when organizations choose to have multiple people swap to the same profile. To me, this can cause confusion when looking at audit journal entries. I'm also concerned when organizations always swap to a very powerful profile such as QSECOFR. Like all other approaches to security, you should swap to a profile with only the authorities required to perform the task. Performing a profile swap does not require that you swap to an all-powerful profile, just a profile with the authorities needed to perform the job function.

I hope this article has provided you with some insights on adopted authority and profile swap so that you can more easily determine which approach to take when elevating privileges.

 

Carol Woodbury is IBM i Security SME and Senior Advisor to Kisco Systems, a firm focused on providing IBM i security solutions. Carol has over 30 years’ experience with IBM i security, starting her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies: SkyView Partners and DXR Security. Her practical experience and her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known worldwide as an author and award-winning speaker on security technology, specializing in IBM i security topics. She has written seven books on IBM i security, including her two current books, IBM i Security Administration and Compliance, 3^rd Edition and Mastering IBM i Security, A Modern, Step-by-Step Approach. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.

---

MC Press books written by Carol Woodbury available now on the MC Press Bookstore.

		IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
		Mastering IBM i Security Get the must-have guide by the industry’s #1 security authority. List Price $49.95 Now On Sale

Also Read

IBM i Security Essentials: 4 Components for an Effective Strategy

New IBM i Security Features and a Farewell

Securing IBM i: A Dual Responsibility