The Modern Alternative to Authority Adoption

A Quick Recap

I recently presented a high-level overview of a programmatic technique for temporarily elevating user privileges. This technique—known as authority adoption—works by combining the authority of the program’s owner with the authority of the program’s caller, enabling them to perform tasks that they would not normally be able to perform. Simply stated, the program object allows the user to utilize the owner’s privileges in addition to their own.

Feedback on the posting told me that many of you are actively using this great technique in your own shops, and many more are now considering it as a way to mitigate the challenge of overly privileged users.

As I mentioned during last week’s article, there are several considerations with authority adoption. These include:

1. Don’t perform any tasks that might give the user access to a command line.
2. Adoption will not carry through to the IFS.
3. An object’s public authority is never used.

Each of these considerations is important but can usually be accommodated.

But what is the effect if the program owner has the same or less privileges than the user that called the program? Effectively nothing. The program still runs with the combined authority of the user and owner and if that is determined to be insufficient to perform the programmed task then an authority failure will occur.

Today’s topic is an additional technique called “swapping.”

Introducing “The Swap”

Let’s start with a quick (yes, I promise!) history lesson. When IBM added TCP/IP functions to OS/400 in the mid-1990s, they introduced a concept whereby the profile that a job was running under could be altered on-the-fly. This was necessary so that the “listener” jobs that process the user requests could run with the authority of the user and not the system profile (usually QTCP) that the job was started under. For example, when the FTP server is started, the listener jobs are immediately started under the QTCP profile. When a user logs into the FTP server we want the job to “swap” so that the authority comes from the user and not the QTCP profile.

Unlike adoption, which combines authority from the user and program’s owner, a swap relinquishes the user’s current authority and attains only the authority of the swapped-to profile. This allows us to perform a new trick: temporarily lowering a user’s authority.

Lowering users’ privileges may not be as common as elevating them but can still be useful. Consider this scenario: a user carries All Object (*ALLOBJ) special authority but lacks command line privileges as a compensating control (while not really recommended, I have seen many examples of users configured this way). The user submits a request to access Query, a common IBM i database utility. Query is considered by many to be a read-only tool but in the hands of a user with sufficient authority (such as *ALLOBJ), there is a possibility of clearing and replacing data. Using a profile swap, the interactive job could be transferred to a profile that carries less authority before the Query interface is accessed.

How Does it Work?

Unfortunately, this is not a good forum to provide deep technical details or coded examples, so I will focus on the general approach, and the similarities and differences between swapping and adoption.

As with adoption, swapping is implemented via a program. Using IBM-supplied application programming interfaces (APIs), the programmer can instruct the OS that the profile that the job is currently executing under should be altered to run under a different profile. By performing this task via API calls, we are able to swap back and forth—potentially to different profiles&mdashduring the execution of a single program.

The process of swapping is fairly simple and involves calling the aforementioned APIs:

QSYGETPH - Get Profile Handle validates the profile and password if required
QWTSETP - Set Profile Handle alters the job to run under the swap-to profile

As with most APIs there are a few nuances. Some pertain to the requirement to supply the password to the swap-to profile; a requirement that can be eliminated by having *USE authority to the swap-to profile. Also, don’t forget to obtain a profile handle for the original profile so that the program can swap back when necessary.

Figure 1 shows how the job attributes might look during an active swap. The (job) user will always indicate the name of the original user that started the job. This is critical for auditing, especially when multiple users swap to a shared profile (yes, it is safe to do that!). As its name suggests, the current user profile shows the name of the profile that the job is currently running under.

Use the Retrieve Job Attributes (RTVJOBA) command to programmatically determine both pieces of information. Under normal circumstances, I prefer to retrieve the current user profile (CURUSER) value as it will return the active profile even if the job is not currently swapped.

Image

Things to Consider

Swapping eliminates a couple of the key restrictions associated with adoption:

1. Swapped authority works in both native and IFS environments.
2. An object’s public authority is used if private authority does not exist.

But there are considerations with this approach as well:

1. Don’t perform any tasks that might give the user access to a command line while swapped.
2. You can only swap to one profile at a time. (In contrast, adoption allows you to adopt the authority from multiple program owners concurrently).
3. While swapped, the authority associated with the swapped-from profile is temporarily relinquished.

The Best of Both Worlds

For most shops, it shouldn’t necessarily be a decision of which technique to use. There is a place for each, as well as occasions when combining them together provides the perfect backdrop. If you are concerned—as you should be—about having to publicize passwords or grant *USE authority to another profile, then you can alleviate this by embedding the swap functions inside a program that adopts sufficient authority to the target profile.

It might appear redundant to deploy both techniques at once; however, this introduces flexibility regarding IFS compatibility and downgrading a user’s authority.

Powertech Authority Broker for IBM i is a great example of how blending the two techniques can be beneficial. Using adoption, this popular privilege management solution is able swap a user without ever having to disclose passwords or grant authority to the swap-to profile—something that could easily be abused. Of course, this privilege alteration is executed in a way that maintains the integrity of your security via permissions, activity auditing (including screen capture), and notification.

No Excuses

Little excuse remains why so many users have administrator privileges under IBM i. As an auditor, I work to uncover profiles carrying capabilities in excess of their requirements; a task that is often pretty easy. These simply need to be “fixed.” Other profiles may have justifiable requirements to gain elevated privileges on occasion and this is where the adoption and swap techniques prove invaluable. So, stop reading (for now) and go take advantage of what IBM i has to offer!