IBM i > ADMINISTRATOR > SECURITY

iSeries EXTRA : Recognizing and Preventing User Profile Impersonating


Securing an iSeries server for your organization can be a daunting task, one that draws on resources from every corner of the enterprise. If you have a knowledgeable and experienced iSeries security administrator, count yourself among the fortunate few as these folks are scarce.

Over the years, I've been retained by many companies to perform iSeries security audits. One security risk that I find ubiquitous in organizations of all sizes is user profile impersonation.

Using Someone Else's Authority
Let's say I'm a programmer or contractor who wants to examine things or do things that are prohibited by OS/400 security, like looking at the production payroll file, or worse yet, modifying the files records. Because my user profile is prohibited from even looking at the file, I need to borrow the authorities of a more powerful profile, maybe QSECOFR. At OS/400 security level 30, this can be painfully easy; at level 40, it's a bit more difficult, but may be doable, depending on how you manage user profiles.

While I'm not going to provide an iSeries hackers guide, I will mention a few things to be aware of. Having *USE rights to someone else's user profile allows me to run jobs as that user. User profiles are created with the default public authority of AUT(*EXCLUDE), which is what you want. If the user profiles public authority is AUT(*USE) or better, you're open to having your user profile used by someone else.

If I have *USE authority to another user profile, I have the rights to use that profile to perform work on that users behalf. I can submit batch jobs for them or dynamically swap my job to run under that profile in place of mine. In so doing I temporarily pick up and use their OS/400 authorities. If I have *USE authority or better to another profile, I don't even need to know the users password to perform work on the users behalf.

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

 

Dan Riehl is the founder and technical advisor of The Power Tech Group. He can be reached at dan.riehl@powertech.com.


comments powered by Disqus
Buyers Guide

Advertisement

Programmers vs. Security - Is Peace Possible

How to establish peace in the datacenter between security officers and programmers.

Discovering IDS on IBM i

Quick and easy intrusion detection at no additional cost

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App
IBMi News Sign Up Today! Past News Letters

Advertisement