Watching QSECOFR

Question: In our shop we have several people who need to use the QSECOFR password, but I have a problem trying to figure out who makes which changes as the security officer. Is there any way to reliably track who was signed on as the security officer when a change happened?

Answer: Yes. In fact, there are many. But first, let me commend you for not giving *ALLOBJ and other special authorities to your programmers all of the time. It’s simply too dangerous to allow someone to operate on a daily basis with the OS/400 equivalent of a nuclear missile strapped to his hip. Let me also suggest that you not give the QSECOFR password to your programmers or anyone else in your shop, for that matter. It is better to create a QSECOFR clone (you can call it ZSECOFR) and give the programmers the ability to use that profile for emergency work. I like the QSECOFR clone idea because you are less likely of getting the QSECOFR profile corrupted, broken, or disabled. An alternate security officer can have all of the power of QSECOFR but still leave the QSECOFR profile available for those critical emergencies when nothing else will work. As an added precaution, you might even choose to give the alternate security officer profile slightly less authority than QSECOFR typically carries (remove *SERVICE and *AUDIT, for example) yet still allow it to function successfully as an emergency profile.

Tracking Security Officers

To answer your original question about tracking who is using the powerful QSECOFR profile, allow me to point you toward a solution that I have used successfully for some time. The solution uses the Get Profile Handle and Set Profile APIs to perform password validation and profile swapping for a user who you want to assume the authority of a security officer. To implement this solution, create user profile ZSECOFR as a clone of QSECOFR. For safety purposes, remove *AUDIT and *SERVICE special authority, because they offer the ability to change such things as disk configurations and object auditing, which you might not want changed as a matter of normal application recovery. Don’t assign a password to ZSECOFR, and set the initial program to *NONE and the initial menu to *SIGNOFF because you don’t ever want anyone to sign on directly as that profile. The create statement for ZSECOFR might look like this:

CRTUSRPRF USRPRF(ZSECOFR) PASSWORD(*NONE) +
USRCLS(*SECOFR) INLMNU(*SIGNOFF) +
TEXT(‘Alternate Security Officer’) +
SPCAUT(*ALLOBJ *IOSYSCFG *JOBCTL +
*SAVSYS *SECADM *SPLCTL)

For good measure, you can also turn on object auditing for the user ZSECOFR so that everything that is done by this user is logged to the QAUDJRN security-auditing journal as well. The command to accomplish user profile auditing might look like this:

CHGUSRAUD USRPRF(ZSECOFR) +
OBJAUD(*ALL) AUDLVL(*CMD *CREATE +
*DELETE *OBJMGT *SAVRST *SECURITY +

*SERVICE *SYSMGT)

Now you need a program that will allow your programmers to assume ZSECOFR’s identity. In this case, you’re going to use the profile swapping APIs rather than the usual method of adopting authority, because you want a clear audit trail whenever someone uses ZSECOFR authority. The program SWPUSRPRF, which is downloadable from the MC Web site at www.midrangecomputing. com, uses three of the user profile APIs to accomplish this. The first API, QSYGETPH, accepts the user profile name and the valid password for the user profile you want to become. After QSYGETPH validates authority, it returns a 12-character hexadecimal profile handle that can be passed to the second API, QWTSETP. QWTSETP actually performs the profile swap and changes the authority of the current job. And, finally, the QSYRLSPH API does the housekeeping by releasing the profile handle so that the profile handle cannot be used again.

For security purposes, the profile handle that QSYGETPH provides is limited to use in the job that it was created in. This precaution prevents someone from creating a profile handle in one job and then nefariously distributing it to other processes or saving it for clandestine use on another day.

A Security Hole?

You may notice that the second parameter passed to the QSYGETPH API is *NOPWD. In this example program, SWPUSRPRF is not actually passing a valid password to the API but rather requesting to bypass traditional password processing because the current user has *USE authority to use the profile that we are retrieving the profile handle for. This bypass is permitted because there is a feature in AS/400 user profile security that allows you to retrieve the handle of another user if you have *USE authority to that user’s profile. If you take a moment to reflect upon this, you might get really scared. And getting scared may be a good idea, because these two APIs already exist on your system and just about anyone could write a program such as the one available for download. But, before you get all worked up about holes in the operating system, you should understand that this feature is fairly useful and common in other operating systems, particularly UNIX, and the swapping feature has some great applications in OS/400. But, best of all, it’s easy to eliminate any risk that these APIs may introduce by simply making sure that none of your users have *USE authority to anyone else’s profile (more on securing user profiles later).

Now that QSYGETPH has retrieved a profile handle for you, you can pass that profile handle to QWTSETP, and it will magically change your current job to run under the authority of ZSECOFR. When you first do this, it’s really quite surprising. If you issue the DSPJOB command, you’ll see that nearly everything else about your job stays the same: job name, library list, job description, etc. It’s just that you are now running under the authority of ZSECOFR. The only clue you have that you’re running as another user is that, under option 1 of the DSPJOB command, the current user profile will be listed as ZSECOFR, even though the job name still contains the name of the original, signed-on

user. If you have OS/400 security auditing turned on, there will also be an audit entry in the QAUDJRN journal that will mark your movement to ZSECOFR.

The last piece of work to do is to clean up after yourself by releasing the profile handle so that it isn’t lying around in your job for potential retrieval by anyone else. And, just for good measure and great accountability, the program also logs a record in the QAUDJRN that records the fact that you have swapped to a security officer profile.

Program SWPUSRPRF works well in reverse, too. If you called the program after you have already swapped to ZSECOFR, it will conveniently swap you back to yourself and log that fact in the security audit journal as well.

Securing Your Security Application

Any time you build a new application, it’s important to build security in, and that is doubly true for a security application. This program is going to need an elevated authority to run because these APIs are shipped with *PUBLIC *EXCLUDE authority and because you need special authority in order to Send Journal Entries (SNDJRNE) into the QAUDJRN journal. Fortunately, the security for this application is not that complicated. For starters, change the program to be owned by ZSECOFR and specify that it will adopt the authority of its *OWNER. This allows any user who can run the program to access the sensitive objects that SWPUSRPRF uses. But, because you likely don’t want to give everyone in your organization access to ZSECOFR, you should also remove *PUBLIC authority to the program and specifically grant *USE authority to any individual programmer who needs temporary security officer authority. Figure 1 demonstrates the CL commands needed to properly secure program SWPUSRPRF. Now you’ve got a powerful and traceable emergency profile that you can safely give to your IS staffers without losing track of who did what.

AS/400 IFS Adopt

Question: In the September 2000 issue, you answered a question on an AS/400 Integrated File System (AS/400 IFS) authority problem. We have a similar problem. When the users don’t have an *ALLOBJ authority, they can’t clear the AS/400 IFS file and keep adding records to the file, even if they are the owners of that particular file. You stated that the solution was to swap the user profile to solve the problem. Could you explain in more detail how to use the QSYGETPH and QWTSETP APIs?

Answer: As I have just mentioned, program SWPUSRPRF can give users the authority to operate with heightened authority. This tool is especially useful in the AS/400 IFS because the AS/400 IFS does not support adopted authority. If you want to temporarily grant elevated authority to an AS/400 IFS user (a la program adopt), I do believe that the profile- swapping APIs are your only option.

Who Cleared the File?

Question: Is there a way to see who cleared the data from a file if the file is not under journaling? One of my test data files was cleared, and no one is owning up to doing it. Can the system tell me who it was?

Answer: If you don’t have journaling turned on for the file, and you don’t have the QAUDJRN turned on and the QAUDLVL system values set to *OBJMGT, then I can think of no completely accurate way to discern the file history. You can make some educated guesses, but you’ll never really know.

If I had to guess, I would look at the last changed date on the file (assuming you haven’t messed with the file yet). I would then look at the QHST history log for sign-on

and sign-off times (CPF1124 and CPF1164) for the time period in question to see if I could make an educated guess based on when the file was changed and who was signed on at the time. It’s not a perfect scenario, and there are lots of things that could mess with your guess, but, in the absence of journaling and QSECURITY auditing, it is your best option.

Think Like a Hacker

Question: In the August 2000 “Security Patrol” column (“Security Patrol: Limiting *ALLOBJ Users”), you wrote that it was impossible to limit a user with *ALLOBJ special authority, and that a user with *ALLOBJ could gain access to *SECADM special authority. I haven’t been able to create, change, alter, etc., user profiles with *ALLOBJ if the profile I am using doesn’t have *SECADM special authority. Am I missing something? If what you wrote is true, isn’t this a tremendous security hole that has managed to escape general knowledge? I thought I had a pretty decent knowledge of iSeries 400 security, but this one has me stumped.

Answer: The answer to your question lies in the profile swapping APIs that were explained in “Watching QSECOFR.” When you’re trying to secure your systems, sometimes it helps to think like a hacker. If you read the first question in this article carefully, you will see how an *ALLOBJ user could gain access to *SECADM or any other special authority. Remember that I wrote that the QSYGETPH API will return a profile handle if you supply a valid password, or if you have at least *USE authority to the profile in question. If a user has *ALLOBJ authority, then, by default, the user has at least *USE authority to every profile on the system, which includes QSECOFR.

And, as I demonstrated, if you have at least *USE authority to the QSECOFR profile, you will be able to use the swap profile APIs to assume QSECOFR’s identity and all of its special authorities. But, please don’t get overly concerned about the “new” potential exposure that these APIs might pose. Security experts inside and outside of IBM have been saying for years that *ALLOBJ authority was a dangerous thing to hand out. These APIs are just one more argument in a long list of arguments for restricting access to *ALLOBJ authority. The moral of this story is not that the swap profile APIs (available in OS/400 since V3R1) are dangerous, but rather that *ALLOBJ special authority is dangerous.

CHGOBJOWN OBJ(SWPUSRPRF) OBJTYPE(*PGM) NEWOWN(ZSECOFR)
CHGPGM PGM(SWPUSRPRF) USRPRF(*OWNER)
GRTOBJAUT OBJ(SWPUSRPRF) OBJTYPE(*PGM) USER(*PUBLIC) AUT(*EXCLUDE)
GRTOBJAUT OBJ(SWPUSRPRF) OBJTYPE(*PGM) USER(DAN) AUT(*USE)

Figure 1: These CL commands are needed to properly secure program SWPUSRPRF.

John Earl is the founder and Director of Technology and Security for  The PowerTech Group.  a Seattle-area software company that specializes in System i security. He has over 25 years experience with IBM midrange systems and security, has published numerous articles and columns for industry magazines, and served as a Subject Matter Expert (SME) for Security for COMMON. A highly regarded speaker on OS/400 and i5/OS security, Mr. Earl has presented several hundred of iSeries security sessions at industry conferences and user groups all over the world. He is a three-time winner of COMMON's Speaker Excellence award and has also served on the board of directors of COMMON U.S.

 

He can be reached at 253.872.7788 or at This email address is being protected from spambots. You need JavaScript enabled to view it..

 

 

Also Read

Securing IBM i: A Dual Responsibility

Top IBM i Security Issues of 2024

Why Cleaning Up Is an Important Part of Your IBM i Security Practice