Special authorities give users the access they need quickly and easily, but they're hard to take away once granted. You need to understand what you're assigning someone. Special authorities are more serious than you might have thought.

With great power comes great responsibility.

My company is about to go on a major ERP overhaul. That's right. We've got forty plus years of a mostly home-grown solution with pieces and parts bolted on over time. Do we have people who have too much authority given their job role? Yes. Are certain objects less secure than they could be? Yes. Like any shop, we have a couple of critical applications that "might break" if the authority is changed. We also have a couple of users who "might" not be able to do their jobs if their authority is restricted. With a new solution on the horizon, it's a good time to look at what we have from a security point of view so that when we go live, we can be sure that the IBM i environment is as watertight as possible. That means ensuring any special authorities are granted on a must-have basis.

Let's go over the basics of special authorities.

System Configuration (*IOSYSCFG)

*IOSYSCFG allows you to manage communications such as line/controller/device descriptions and TCP/IP servers (HTTP, Telnet, etc.). While not as glamorous as *ALLOBJ special authority, I put it at the top of my list because I think its power is often overlooked. Most users simply do not need this authority, especially if they're not experts in system communications.

Security Administrator (*SECADM)

*SECADM gives you the ability to manipulate user profiles. Enough said. Audit any profiles with *SECADM so that user profile changes are logged.

All Object  (*ALLOBJ)

With the exception of user profiles, *ALLOBJ authority gives you control of all IBM i objects. Think about that. This means that any file on a partition can be altered or deleted. Delete IBM Domino mail files in the Integrated File System (IFS)? Easy. Browse the payroll libraries? Go for it. This is dangerous territory.

Someone who's just a little crafty could easily compile a program that adopts authority of a user with *SECADM special authority and attempt to wreak havoc with user profiles. Or they could adopt authority of a profile with *IOSYSCFG and alter TCP/IP configurations and line descriptions. Much fun to be had if one intends to do so. Make no mistake; if you have *ALLOBJ, then you own the system. Programmers don't need it. Operators don't need it. Help desk personnel don't need it. In fact, if you take the stance that nobody needs it, then you'll do OK. That way, someone will have to do some serious justification in order to gain it.

I've had vendors who wanted a copy of QSECOFR with all special authorities because their application "needed it." Some just might, but most don't. And if they want it, then they need to prove it first. And if they do prove it, maybe I'll make them sign a waiver first.

Job Control (*JOBCTL)

Another somewhat overlooked special authority is Job Control. While operators may need to control jobs, this special authority allows them the ability to control subsystems and output queues (ones that have the Operator Control attribute set to *YES). They can even IPL the IBM i partition.

Output queues would need to have their OPRCTL attribute set to *NO in order to properly protect sensitive spooled files from any potentially unauthorized personnel with *JOBCTL.

Audit (*AUDIT)

*AUDIT doesn't sound too bad, does it? Nah. Only if a person who doesn't understand what auditing does to disk and performance decides to turn on every form of auditing the system allows. If your system isn't prepared to handle the auditing overhead or doesn't have a lot of disk space, then doing just that may cause big trouble relatively quickly. Reserve *AUDIT to select personnel who understand performance and can actually read the contents of a journal receiver without a manual.

Save System (*SAVSYS)

*SAVSYS sounds harmless. You're saving objects on your system, right? Well, *SAVSYS allows you to save objects, but you can also cause some big problems with it.

These risks are taken from the IBM Knowledge Center:

• Save an object and take it to another system to be restored.
• Save an object and display the tape to view the data.
• Save an object and free storage, thus deleting the data portion of the object.
• Save a document and delete it.

Service (*SERVICE)

*SERVICE allows you access to System Service Tools (SST) and the ability to do real fun stuff like communications tracing. With regard to SST, if you have a combination of *SERVICE and *ALLOBJ, then you can do some serious damage to a system.

With regard to communications, if you have unencrypted Telnet or HTTP traffic going over your LAN adapter, then you can see pretty fast how you can collect TCP/IP packets with STRCMNTRC, dump them to an IFS file, and then scan the contents with a tool like Wireshark. Collecting user profiles, passwords, and sensitive data...it's easy peasy.

I was able to detect an insecure internal FTP process by using this method. I found some great stuff, including the profile and password that initiates the FTP connection. The data itself didn't matter. Why would I care about the little FTP transaction's data? Well, because the profile and password sent in plain text had *ALLOBJ special authority. Ouch. There is absolutely no need for that kind of carelessness. *SERVICE can be used as a powerful security mechanism, but it can also be used to snoop on data. Assign wisely...and audit afterward.

More About Special Authorities

Please review special authorities in the IBM i Knowledge Center for additional information.

Steve Pitcher works with iTech Solutions, an IBM Premier Business Partner. He is a specialist in IBM i and IBM Power Systems solutions since 2001. Feel free to contact him directly This email address is being protected from spambots. You need JavaScript enabled to view it..

Also Read

Sharing Securely: How to Cope, Part 1

Artificial Intelligence and Cybersecurity

AIX Security Basics eCourse