Carol discusses what you should—and shouldn't—do with all of the user profiles that are provided with the IBM i operating system.

When IBM i is installed, numerous user profiles are created on your system. With each release, more of these profiles are added that support various new features of the operating system or other IBM products. This article discusses how these profiles should be used as well as what not to do with them.

The settings for most IBM-supplied profiles are documented in Appendix B of the IBM i Security Reference manual. This is handy for two reasons: if they're listed in the manual, you know they belong to the operating system or a licensed program product. This is helpful when you're trying to clean up a system and wish to delete profiles that are no longer in use. Because not all profiles make it into the manual, you can't assume that a profile that begins with "Q" is not an IBM profile. But if it is in the manual, it is definitely an IBM profile and shouldn't be deleted. Another place to look is in the "Created by" field in the object description. Use the Display Object Description (DSPOBJD) command on the user profile. If the profile was created by either *IBM or QLPAUTO, that's another indication that it's an IBM-supplied profile. The other reason Appendix B is helpful is because some organizations alter one or more attributes of these profiles—most often it's the addition of a special authority. The table in Appendix B documents each profile's original attribute settings so you can set the profiles back to their "factory defaults."

While there are many IBM-supplied profiles, six user profiles have been around forever—QSECOFR, QPGMR, QSYSOPR, QUSER, QSRV, and QSRVBAS. Not only are these well-documented in IBM documentation, but they're also well-documented in hacker forums. If hackers know anything about the IBM i, they know these profiles exist on all systems. That's why you should leave these profiles with their password set to *NONE. With the exception of QSECOFR, all of these profiles have shipped without a password for many releases. I highly recommend that you leave them without a password and do not use them for sign on. I can hear you asking now, "What about QSRV? My IBM rep usually signs on with that profile." That's fine. Assign the profile a password, let your rep use it, and then set it back to *NONE when the work is completed.

Use of QSECOFR

As I noted above, QSECOFR is the exception. Even if you wanted to set QSECOFR's password to *NONE, it's prevented by the operating system. Why? Because certain tasks—such as upgrading the system—require that you sign on with QSECOFR; however, there should be very few other occasions that require sign on to the actual QSECOFR user profile. Yes, there are some lazy vendors that have coded their install routines to require a literal sign on with QSECOFR, but thankfully, it doesn't happen often. What does happen is that administrators see install or other instructions to sign on with a profile with "security officer" authority and they immediately leap to the assumption they must sign on with QSECOFR. Most often, what the vendor is requiring is that the administrator sign on with a profile that has at least *ALLOBJ special authority. Equating that requirement to needing to sign on as QSECOFR is a false assumption and leads to overuse of QSECOFR.

I don't like to use QSECOFR for regular sign on. I like to use it on an exception base only. That way, it's more obvious when it's being abused. While you can't set its password to *NONE, one way to protect against inappropriate use is to set the status of QSECOFR to *DISABLED. Many people hesitate to do this because they fear that they won't be able to use the profile in the case of an emergency. But you can always sign on to the console (virtual or otherwise) with QSECOFR even if its status is *DISABLED. Of course, you still have to know the correct password for this to work.

For the cases when you need "security officer rights," create a profile and give it all special authorities. This should suffice for the vast majority of your security administration needs. If you feel you must use QSECOFR for tasks other than system upgrades, then create a separate profile for each administrator and make them a member of QSECOFR rather than signing on as QSECOFR. That way, QSECOFR doesn't become a shared profile, accountability is preserved (that is, the audit journal will reflect who actually performed each task), and you can more easily detect misuse of QSECOFR.

Here are some ways to detect the misuse of QSECOFR (and all of the other IBM profiles for that matter):

• Turn on *JOBDTA or *JOBBAS action auditing. This auditing level logs the start, end, hold, and release of all jobs. Because this auditing value causes vast amounts of audit journal entries—especially on busy systems—many people don't have this value specified for the QAUDLVL system value. But because QSECOFR shouldn't be used, *JOBDTA shouldn't cause excessive audit entries if you're only turning it on at the user level. Note: the operating system and some vendor products run some jobs as QSECOFR. If this creates too much "noise" in your audit exception report, you can filter and look for certain activity—interactive sign-ons for example. Use the Change User Auditing (CHGUSRAUD) command to turn on action auditing at the user profile level.

• Look for invalid sign-on attempts. These will be under the PW audit journal entry type.

• Turn on *CMD auditing. This is an action auditing type that can be set only at the user profile (vs. system value) level. This causes all CL commands entered from a command line or run from a CL program to be logged. While you may not want to review all of the audit entries generated by turning on *CMD auditing, you'll have forensic data should you need it for investigation.

IBM Profiles as Application Owners

Unfortunately, application developers often choose QSECOFR as the owner of the application rather than creating their own application-specific profile to own the application. This practice bloats the QSECOFR user profile and makes it very difficult for system administrators to identify potentially dangerous programs. That is, it makes it difficult to spot programs that are inappropriately adopting QSECOFR's profile. In many cases, there are simply too many programs owned by QSECOFR to investigate. What you can do is generate a "baseline" of programs currently on the system and look for additions going forward. At least you'll know what's happening on your system from now on (which is better than not at all!)

IBM Profiles as Group Profiles

QPGMR is another IBM-supplied profile that's often assigned as a vendor product owner. This is just one reason I don't like to use QPGMR as a group profile. Making any of the IBM-supplied profiles a group profile can be dangerous. That's because IBM ships these profiles authorized to many and often owning some IBM i objects. Before you make one of these profiles a group profile, I encourage you to run the Display User Profile (DSPUSRPRF) command specifying the *OBJOWN and running it again specifying the *OBJAUT option. Look at the lists produced and make sure you want those users to also be authorized to or own the objects listed. Making these users a member of the IBM profile will make them the owners of everything the IBM profile owns and authorized to any commands and programs to which the IBM profile is authorized, including vendor products.

The one IBM profile that seems to make the most sense to use as a group profile is QSYSOPR. That's because the people in the operator role typically need authority to all of the commands to which this profile is authorized. In addition, it's very rare that vendors use this profile as a product owner, so you are usually not giving operators more authority or ownership than you intended. You'll still want to check out what QSYSOPR owns and is authorized to on your specific systems, however, before making it your operators' group profile.

Realize, too, that any special authority that the group has, the members will also have. Several releases ago, the default special authorities for each user class were re-worked. IBM decided that the programmer user class should not be defaulting to give users *SAVSYS and *JOBCTL. The role of programmer or developer typically doesn't own the task of saving or restoring all objects or managing other users' jobs. So IBM stopped assigning profiles in the *PGMR class to either *SAVSYS or *JOBCTL special authorities. However, for compatibility reasons, the IBM profile QPGMR continues to have both *SAVSYS and *JOBCTL special authorities. Therefore, when you assign QPGMR as a developer's group profile, you have now given that user *SAVSYS and *JOBCTL special authorities—special authorities that most programmers do not need, especially on production.

Additional Special Authorities

I routinely see organizations where IBM-supplied profiles have been given additional special authorities beyond those assigned by IBM. I can understand in smaller organizations assigning QSYSOPR *IOSYSCFG special authority. People in smaller organizations often perform multiple roles. However, I caution you to understand the implications of making any additional special authority assignments. Specifically, adding *ALLOBJ to an IBM-supplied profile should never occur. That's because whatever task it's used for is now running with authority to every object on the system. I've seen *ALLOBJ assigned to many IBM profiles throughout the years. All cause security exposures, but here are some of the highlights:

• *ALLOBJ assigned to the QTMHHTTP and QTMHHTP1 user profiles—These are the default profiles under which the Apache web server runs. True, you can change the profile, but the majority of Apache web instances run as these two profiles. Assigning *ALLOBJ to these profiles means that the web instance has the authority to access any directory and any database file on the system. Hopefully, the configuration file for the web server instance prevents open access, but if it's poorly coded, you could be giving web application users authority to access anything on your system!

• *ALLOBJ assigned to QSYSOPR—This means that anyone using this profile or has it assigned as a group has *ALLOBJ. I've seen QSYSOPR used as a shared profile—that is, more than one person is signing on with this profile, typically operators on different shifts. The result is that you have given *ALLOBJ to a shared profile, so determining who performed that accidental update or intentional delete is going to be difficult. Shared profiles are never a good idea. Shared profiles having *ALLOBJ is an investigator's nightmare.

• *ALLOBJ assigned to QPGMR—This is, in my opinion, the worst. Not only do you give all members of QPGMR *ALLOBJ special authority (that is, any programmer assigned to QPGMR now has *ALLOBJ), but you have also given vendor products owned by QPGMR more authority than the vendor intended or tested with. In other words, you may be giving users of these vendor products more authority than intended.

Summary

I hope this article has provided guidance about the appropriate use of IBM-supplied profiles. They are a necessary part of the operating system, but they need to be used appropriately so as not to be the cause of security exposures on your IBM i system.