Securing a system for your organization can be a daunting task, drawing on resources from every corner of the enterprise. If you happen to have a knowledgeable and experienced System i security administrator, count yourself among the very fortunate few. These folks are quite scarce, and with the graying of our technical ranks, they are getting scarcer day by day.

Over the years, I have been retained by many large and small organizations to perform System i security assessments -- my job was to tell them what's wrong and how to fix it. There is one particular security risk that I find to be ubiquitous in both large and small organizations. In this article, I'll spell out this risk and tell you how to fix it.

The Risk Defined

Let's say I'm a programmer or contractor at your place. I want to look at or do things that I'm prohibited from doing by i/OS security, such as look at the production payroll file or worse yet, modify the records in that file. So, since my user profile is prohibited from even looking at the file, I need to borrow/steal the authorities of some powerful profile, maybe QSECOFR. At security level 30, this can be painfully easy, at level 40, maybe a bit more difficult, but probably doable.

So, how does one borrow or steal a user profile? Without providing a hacker's guide to the i/OS, let me just mention a few things to be aware of. If I have even *USE authority to someone else's user profile, I can run jobs as that user. Under the i/OS, user profiles are created with the default public authority of AUT(*EXCLUDE), and this is what you want. If you have carried user profiles from far in the past, it is probable that you have many user profiles that are not secured with AUT(*EXCLUDE). If the public authority on a user profile is AUT(*USE) or better, you are at risk for user profile borrowing.

You see, if I have *USE authority to another user profile, that means I have the rights to use that profile to perform work on their behalf. I can submit batch jobs for them or dynamically swap my job to run under their profile in place of mine. In doing so, I temporarily pick up and use their authorities. If I have *USE authority or higher to another profile, I do not even need to know their password to perform work on their behalf.

To find these offending profiles, you can use the PRTPUBAUT(Print Publically Authorized Objects) command. You can also use the DSPOBJAUT(Display Object Authority) command to see detailed authorizations.

To fix this problem, check your user profiles to make sure that user profiles are secured by AUT(*EXCLUDE), and that no unneeded private authorities exist to the profile. If they are not secured correctly, then change the authority to AUT(*EXCLUDE), and remove any unneeded private authorities.

Under system security level 30, another easy user profile borrowing method is available, which is widely known and has been published by System i trade magazines. It is also documented in the iSeries Security Reference. This method of borrowing a profile is one of the many reasons to run your system at security level 40 or 50.

This exposure is found when running a job using a job description that specifies the name of a user profile in the USER parameter. When a user runs a job with one of these job descriptions, the job can run under the authority of the named user, not under the authority of the submitting user. For example, I submit a job using a job description that specifies QPGMR as the USER parameter. When the job runs, it runs under the authority of QPGMR, and not my submitting user profile.

The problem at security level 30 is that I do not need any authority to the user profile named in the job description -- all I need is *USE authority to the job description itself. This hole is fixed under security level 40 and 50, in which I need authority to both the job description and the named user profile.

Other Considerations

There are a few IBM profiles for spooling and other internal functions that should not be messed with. Other IBM profiles like QSECOFR, QSYSOPR, QSRV, QSRVBAS, QPGMR, and QUSER should be *PUBLIC AUT(*EXCLUDE).

In some i/OS configurations, the applications have been implemented in such a way that *USE authority to certain profiles is required to make certain jobs run. If you have these implementation issues, test before you implement any changes to profile authorities, with a view to removing any requirement to use another profile.