Excessive *ALLOBJ special authority assigned beyond IT administrators
What Happened
Authority reviews on IBM i systems routinely find *ALLOBJ special authority sitting on application and business-user profiles that have no need for it. The count is usually a surprise: shops that expect to find three or four holders find dozens, and frequently nobody currently employed can explain half of them.
Nobody decides to do this. It arrives one reasonable decision at a time, through four routes that account for most of what you will find. Authority granted to a group profile flows to every member, including members added years later for unrelated reasons, and supplemental groups mean a profile can inherit from several at once. Creating a new profile by copying an existing one is fast and copies the special authorities along with everything else, so a single over-privileged template quietly reproduces itself across a department. Somebody elevates a profile at three in the morning to clear a production problem and never removes it, because removing it has no deadline and no owner. And vendor installers and integration projects ask for *ALLOBJ because it is easier than working out what the software actually needs, after which that profile runs unattended for years.
The reason it survives is that nothing breaks. An over-authorized profile works perfectly. There is no error message, no failed job, no user complaint, and no alert. Excess authority is invisible from the outside, which means the only way you will ever find it is by deliberately going to look.
Why It Matters
*ALLOBJ bypasses object-level authority checking entirely. Every profile holding it is a superuser for data access purposes whether or not anyone intended that, and no amount of careful object-level work constrains it.
That is what makes it more serious than it first sounds: it quietly cancels the controls you believe you have. Your *PUBLIC settings, your library authority, and the object-level grants somebody spent a month getting right are all decorative for those profiles. Combine that with the open network routes most systems still have, and the data can leave through ODBC or FTP without ever passing through an application that might have logged it.
It also fails segregation of duties on its face. An application profile holding *ALLOBJ can read payroll and change the general ledger. Whether anyone did is beside the point for an auditor, and it should be beside the point for you: the control either constrains access or it does not.
The encouraging part is that the correct alternative is native and free. Adopted authority lets a program run under the authority of its owner, giving users exactly the access that program needs without granting anything to their own profile. Most standing *ALLOBJ grants exist because nobody had time to scope one program properly.
Recommended Actions
- Inventory every profile holding *ALLOBJ with PRTUSRPRF or an authority report, and resolve group and supplemental group inheritance rather than reading direct grants only
- Run Authority Collection (STRAUTCOL, available from IBM i 7.3) to record the authority profiles actually use, so you can revoke a grant against evidence instead of hoping
- Reconcile the list against real administrative roles and treat every surviving grant as an exception with a named owner and a written reason
- Replace ad hoc grants with adopted authority scoped to specific programs, which is the native answer and costs nothing
- Check profiles that were created by copying a template, since special authorities travel with the copy and multiply quietly
- Review vendor, service, and integration accounts specifically, because they hold the same authority with the least scrutiny and the longest uptime
- Include *SECURITY in QAUDLVL so future authority and profile changes are recorded from now on
- Put the review on a recurring schedule with an owner's name against it, because authority creeps back within a year or two of any one-time cleanup
Sources
This is a recurring vulnerability class, not a single-incident CVE. It shows up repeatedly across live IBM i systems in industry security assessments, which is exactly why it is worth checking on yours rather than assuming it was handled.
Other Vulnerability Classes
- Default and weak passwords on powerful profiles (QSECOFR and equivalents) Critical severity
- Unsecured FTP, ODBC, and remote command exit points High severity
- *PUBLIC *CHANGE authority left on production libraries and files Medium severity
- IFS exposure to network-share-originated ransomware encryption High severity