• Disable Qxxxxx User Profiles?


• Using Swap Profile API QWTSETP


• Silent STRCPYSCN?


• Command Access

Disable Qxxxxx User Profiles?
Q: We have noticed that we have a bunch of "Q" user profiles on our systems. We would like to know which would be the ones that it might be OK to disable.

A: I would not disable any of the IBM profiles that come shipped with OS/400, but not every "Q" profile is guaranteed to be an IBM profile. Here is a method of determining which are legitimate.

First, look in OS/400 Security Reference Manual?V4R4 (SC41-5302-03, QB3ALC03). Appendix B has a list of all the user profiles that IBM ships with OS/400. Not every profile that is listed in the manual may be on your system?it depends on which Licensed Program Products (LPPs) you have installed?but this is a good starting point.

Second, view all of the Q* user profiles on your system using the Work with User Profiles (WRKUSRPRF Q*) command. Review this list and compare it to the user profiles that are listed in Appendix B. On my V5R1 system, I have 44 IBM profiles that were loaded when I installed the operating system (See Figure 1.)

Figure 1: Numerous IBM Profiles are shipped with V5R1.

Third, just to verify the results the earlier steps, you can do a Display Object Description (DSPOBJD) on each of these profiles to see when and where it was created. If the profile object was created on system "00000000" by user *IBM, it's a pretty good bet that it is a legitimate IBM user profile. On my V5R1 system, only three user profiles didn't fit this description: QNETWARE, QTMPLPD, and QTMTWSG. However, all three of these profiles were created on my system by the user QLPINSTALL and their creation times matched the date and time that my V5R1 operating system was installed.

I wouldn't recommend that you disable any IBM profiles. A better idea would be to simply set their passwords to *NONE so that these profiles do not have the ability to sign on. When you attempt to change the passwords, you will find that only 11 of the 44 profiles listed in Figure 1 will actually allow you to change them. Those profiles are listed below:

• QBRMS
• QEJB
• QNETWARE
• QPGMR
• QRJE
• QSECOFR
• QSRV
• QSRVBAS
• QSYSOPR
• QTMHHTTP
• QTMPLPD
• QTMTWSG
• QUSER

Of the profiles listed, only QSECOFR is shipped with an active password (QSECOFR). All other profiles are shipped from the factory with a password of *NONE. The truly paranoid among us might change all of these profiles to password of *NONE (except QSECOFR?you'll need that one), but this would only be necessary if you were concerned that some of these profiles had been tampered with.

Using Swap Profile API QWTSETP

Q: On my system there are many instances of the prestart job named QZDASOINIT. My understanding of this job is that it sits and waits for an incoming ODBC request, and then it swaps the authority of the job from the current user (QUSER) to the user who is requesting data. Only then is the query executed and the data request served. After the data request completes, the QZDASOINIT job waits for another data request, which could come from the same user or some other user of the system. Therefore, one QZDASOINIT job could service numerous users throughout the course of the day.

I am using the QSYGETPH and QWTSETP APIs to retrieve a profile handle and swap active users. I understand that the profile handle is temporary and can be used only in the job that created it. But when I create a user profile handle to swap to, how will I know which user I have created a handle for? Also, will the profile handle expire when the servicing user xxxxxxx job is ended, or will the profile handle stay active until the QZDASOINIT job is ended?

I plan to use Release Profile Handle API (QSYRLSPH) at the end of the routine, but I am concerned about what may happen if a job ends abnormally or if the user turns the PC off.

A: When you call the QSYGETPH API, you must supply the name of a user profile that you want to swap to. So the answer to the question of which user the profile handle will be generated for depends on which user profile name you feed into the API. You have a couple of choices as to which user profile you request. When your program prepares to swap, it will probably want to look at the current job to determine who to swap to. You should look at the parameter for current user rather than the traditional user parameter. The current user parameter was added to the job information structure specifically so that you can distinguish between the user profile that the job started under (the traditional user parameter) and the user profile who the job is currently active for (current user). After swapping profiles with the QWTSETP profile, the profile that you have swapped to becomes the current user.

You'll notice that the IBM portion of the QZDASOINIT jobs does some swapping of its own. When this job starts, it is running under the profile QUSER. If you were to watch the audit journal for these ODBC jobs, you would notice that, as soon as they start, the QZDASOINIT job swaps from user QUSER (the default IBM user for QZDASOINIT jobs) to the user who made the ODBC request. After this swap is done, the exit program is called and you have the opportunity to swap yet again to a profile of your own choosing.

But I have a couple of words of caution. First, the QSYRLSPH API does not undo the swapping. It just releases the profile handle and invalidates it for future use (which is a good thing), but the user profile that was set by the QWTSETP API is still the active user. In order to clean up after yourself and not leave inappropriate levels of authority lying around, you'll have to use the QSYGETPH and QWTSETP APIs to swap back to the original user at some point.

This brings me to the second concern. Your exit program will only be called on the way into the ODBC request, not on the way back out. Unless specifically noted to the contrary, an exit program is called at the beginning of a process only. When the exit program completes, control is returned to the IBM process and your exit program is completely out of the picture. This means that once you have swapped to an alternate user, you will not be given an opportunity to swap back until the next time the exit program is called. In this example, your exit program would not get called again until the next ODBC request was routed through this particular occurrence of the QZDASOINIT job. To prevent subsequent users from running under the authority of the previous user, instruct your exit program to always save and swap back to its original user when the program is first activated. This will clean up any old authorities that may have been lying around and gives you a clean start with each call.

Silent STRCPYSCN?
Q: I'm trying to conduct a subtle investigation into what a certain high-powered profile is being used for. A lot of the functions performed under this profile involve high-level functions that are hard to distill from the job log. Instead, I would like to perform a Start Copy Screen (STRCPYSCN) on this user's profile. I don't want the user to know this is happening. The problem is that STRCPYSCN sends a break message to the workstation message queue asking for permission to begin the copy screen.

A: Have you considered using user profile auditing to track this user's actions? User profile auditing is easy to set up and will track this user's access to files and programs as you dictate. It has the added benefit of being asynchronous so that you don't have to "catch" anyone in the act; you can just review the logs at a later date. This makes it more comprehensive than STRCPYSCN because it is on duty 24 hours a day.

User profile auditing will also write its details to the IBM Security Auditing Journal (QAUDJRN), so if there is a dispute about what was (or was not) done, the journal can be referenced to get an accurate version of history. The great thing about journals on the iSeries is that they don't lie. They're a write-only object whose contents cannot be modified by users or security officers. If you saw illicit activity during a STRCPYSCN session, it could be your word against theirs. If you've got journal entries that demonstrate that activity, then you have some pretty solid evidence. Just a word of caution though: If you suspect someone of criminal fraud, you should consult a security forensics expert to capture data that may be needed later as evidence.

Command Access
Q: I'd like to know what commands users can execute if their profile parameter for Limited Capability (LMTCPB) is set to *YES. Is their any way to get a list of all of these commands on my system?

A: Limited Capability *YES is designed to restrict a user's ability to execute most commands at an OS/400 command line. By default, most IBM commands are restricted from access by a limited capability user. This limitation is recorded in the command object itself and not through the traditional object authorities that appear on every OS/400 object. If you execute a Display Command (DSPCMD) command for the Work with Active Job (WRKACTJOB) command, you'll see that the parameter for Allow Limited Users (ALWLMTUSR) is set to *NO. This means that a limited capability user is not allowed to execute this command. Contrast that with the Sign Off (SIGNOFF) command, and you'll see that the ALWLMTUSR parameter is set to *YES. (This makes sense; you always want a user to be able to sign off.)

Below I've listed the eight IBM commands that come shipped with the Allow Limited Capability parameter set to *YES:

• DSPJOBLOG
• DSPMSG
• SIGNOFF
• SNDMSG
• STRPCO
• WRKENVVAR
• WRKMSG
• DSPJOB

This may be the complete list of commands allowed to these users because you (or your third-party application vendors) may have created additional commands that allow limited capability users to execute them.

A word of caution on the LMTCPB parameter, however: As I wrote in the Midrange Computing December 2000 "Security Patrol" column, the LMTCPB parameter is not honored by DDM and Client Access remote commands and therefore cannot be solely relied on to prevent users from entering commands on your system. Refer to the December issue for more information.

John Earl is chief technology officer for the PowerTech Group in Kent, Washington. If you've got a security question or problem, email it to John at This email address is being protected from spambots. You need JavaScript enabled to view it..

References and Related Materials
OS/400 Security Reference Manual?V4R4 (SC41-5302-03, QB3ALC03)

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

IBM i Security Essentials: 4 Components for an Effective Strategy

New IBM i Security Features and a Farewell

Securing IBM i: A Dual Responsibility