Special Authorities – What are they on IBM i?
If you come from the world of IBM I you will have heard of *ALLOBJ authority.
This is the ultimate level of object access authority on an IBM I system. *ALLOBJ literally means you are authorized to read, change, or delete any/all objects on the system! It’s a super user, admin level of ability, and it’s very obvious how dangerous this could be when granted to the wrong person.
What’s not so obvious it’s just how often *ALLOBJ is used throughout the industry.
I’m constantly shocked, logging onto a customer’s machine, to see many user profiles for regular users, IT staff and even ‘service profiles’ (those used to connect to the machine for web services) that are set up with* all object authority.
This is so dangerous it’s unbelievable. If you have the user and password for a service account with *ALLOBJ you can connect and do untold damage.
Don’t give *ALLOBJ to users. Full Stop. Repeat that.
While we are talking about dangerous rights – what about this *SECADM level?
*SECADM allows the user to create other user profiles, or modify them. As you might imagine, *SECADM in conjunction with *ALLOBJ puts you in God Mode!
If you have *SPLCTL, you can do anything with any of the reports on the system. Think about how dangerous this could be if a regular user has access to read HR salary?
So the first step in securing your IBM-i system is to understand what the special authorities mean and do so let’s have a look at some of them:
A quick look at IBM i special authority
*AUDIT
Any users with audit authority means they can change the system values and other auditing functions built into the operating system. These background jobs are constantly auditing what’s happening at a system level. Maybe recording things like user profile changes, any system authority changes or even granular things when files are written to the IFS.
With that in mind, you can quicly see that anybody with *AUDIT ability could maliciously hide some of those activities from your system admins, security or audit teams.
You should only ever grant audit authority to people running in security or as an administrator role
*JOBCTL
Job control allows users to control what is running on the system.
Jobs? If you’re new to IBM I any process that’s running a program is called a job. So when I sign on to the machine, that process is called ‘my job’ and everything that I do while I’m signed on is all part of that one job. If I submit something to run in the background, that’s that’s its own job.
Job Control gives you the the ability to hold and change any of the jobs running on the system. This is commonly an authority that’s granted to lots of people and that’s a bad thing.
Why?
If you give someone job control they have the ability to change other users jobs. They can lower the run priority, increase the time slice, change auditing values or do all kinds of things on the jobs to make them eat the machines memory resources.
If the user has job control, they can look at other users spooled files in their outputout queues. This is obviously an invasion of privacy.
job control should only be granted to users that need to change job details when they’re running.
*IOSYSCFG
This special authority does exactly what it says on the tin – it lets you change the input and output system configuration this means changing communications TCP settings network settings file share information.
Be careful who you grant this to, because anyone that can change communication settings could be calamitous for your business if they accidentally brought down your network. Or deliberately bring down your communications?
Only ever allow system administrators or system operators to have *IOSYSCFG
*SAVSYS
Another special authority that does so it says on the tin – SAVE SYSTEM lets you save the system.
This should only ever be granted to operators, system administrators or the team that is responsible for backing up the IBM system itself.
*SAVSYS is often assigned to developers, but unless they’re going to perform these functions they just don’t need it. Something to consider here is that the default IBM profile QPGMR has *SAVSYS and people often look at QPGMR, and think “OH I must grant my programmers the same rights because that will let them back up to save files or restore their own work”.
But that’s just not true!
*SAVSYS is a systemwide saving level. Users without can save their objects, as long as you have the rights to an object’s existence you can save that object.
Granting a user *SAVSYS lets them save anything on the system even if they’re not authorized to it you can quickly see the size of this exposure?
*SERVICE
Service is a special authority that should only be granted to your System Administrators. It grants some powerful functions like the ability to work with disk units and run communications traces and other system debug level functions
Of course this is just dipping your toe in the waters of special authorities so here’s the most recent IBM manual I could find it’s at version 7.5 but this should apply to anything from 7.3 open brackets which is just being going out of service close brackets upwards grab a coffee and read on my friend: