Everyone's aware of the dangers of *ALLOBJ, *SECADM, and *SPLCTL special authorities. But what about the rest? This article discusses the issues you should be aware of when assigning the other special authorities.
When discussing the concept of "least privilege access" that is, giving users only the authorities necessary to do their jobs it's obvious that only trusted users should be granted *ALLOBJ special authority. It's also obvious that *SECADM, which allows users to create user profiles and modify them when they have *USE authority to the profile, should be given only to the people who need to maintain user profiles. Since *SPLCTL is the *ALLOBJ of spooled files, obviously you only grant that special authority to users who are allowed to see all spooled files on the system. But who should be assigned the rest of the special authorities, and what vulnerabilities might you be causing when assigning these special authorities? Let's take a look.
*AUDIT Special Authority
Users assigned *AUDIT special authority allows them to change the auditing system values and enable or disable auditing on individuals and objects. Profiles assigned *AUDIT special authority can also run most of the options when using the integrated security tools, accessed by typing GO SECTOOLS. *AUDIT should be assigned only to those people performing the security administrator role.
*JOBCTL Special Authority
*JOBCTL allows users to manage (hold, release, end, modify) not just their own jobs but any job on the system. Clearly this is a special authority that's required for operators and system administrators. But after *SPLCTL, *JOBCTL is probably the most over-assigned special authority, and most people don't pay much attention to it. So why should you care? First, many auditors don't like the idea that any user can manipulate other users' jobs. You likely assert that this isn't an issue by showing that most of your users have limited capabilities so they can't enter commands from a command line. And while that's true for most users, it's usually not true for programmers, and they'd be the ones to know what batch jobs to stop or hold to disrupt processing. Second, when creating outqs, the default configuration allows users with *JOBCTL to display, copy, and send spooled files created by other users. You can configure the outq to ignore the user's *JOBCTL, but that's not the default setting. Finally, while a user can change most attributes of their own jobs, a handful of attributes require that the user have *JOBCTL - even when changing their own jobs. These are RUNPTY, TIMESLICE, PURGE, DFTWAIT, and TSEPOOL. That's why, I believe, many vendors ship the profile that owns their applications with *JOBCTL and have programs that adopt the owner's authority. Bottom line: You'll want to pay more attention to users who have *JOBCTL.
*IOSYSCFG Special Authority
*IOSYSCFG allows users to create and change objects used for communications, modify TCP/IP settings, and something I just became aware of this past year: create file shares. Our team discovered this when we were doing a penetration-testing engagement. We discovered a profile with a default password, and it had *IOSYSCFG special authority. With that authority, we were able to create a read/write file share to root (/). While modifying your communication settings could be highly disruptive to your organization, having a read/write share to root leaves your entire IBM i system vulnerable to malware if a user mapped to the share happens to click on the wrong link or download an infected attachment. *IOSYSCFG special authority should be assigned to system administrators and, perhaps, operators in smaller shops. Users assigned this special authority should be taught about the dangers of defining a share to root so they don't open up the system to this risk simply for the sake of their own convenience.
*SAVRST Special Authority
*SAVRST special authority allows the person to save or restore any object on the system. This special authority is to be granted to those users in the operator and system administrator roles. *SAVRST is not appropriate for developers, although I often see it assigned to that role. I'm guessing that's because, back in the early days of AS/400 (yes, that long ago), *SAVSYS was assigned when creating a user into the *PGMR user class. That's no longer the case and hasn't been for quite some time. But between that and the fact that QPGMR continues to have *SAVSYS, programmers continue to be assigned *SAVSYS. What's the big deal with programmers having this authority? First, many think that one needs *SAVSYS to save anything. That's not the case. If you have *OBJEXIST authority, you can save an object. Granting users *SAVSYS allows them to save any object - even if they have no authority to it. Do you really want your developers to be able to save any object? Typically not. Second, *SAVSYS is especially dangerous when assigned to developers on the development system. You do not want to provide them with the ability to save a program object from their own development library and restore it into the production-level library, bypassing the change management process.
*SERVICE Special Authority
Since the Start System Service Tools (STRSST) command began requiring sign on by a separate service tool ID, assigning *SERVICE special authority isn't as dangerous as it once was. It's still plenty powerful, however, allowing the users to run traces, work with disk units, and, if the user has *USE to a program, debug it. *SERVICE special authority should be assigned to the system administrator role.
Discovering the Details
To discover - or at least get a feel for - the types of tasks each special authority enables, scan through Appendix D in the IBM i Security Reference manual. (Be sure to use the manual that corresponds to the operating system version you're running as requirements occasionally change from release to release.) Search through Appendix D for each of the special authorities, and you'll find footnotes indicating when the special authority is required for running a particular command.
End-of-Year Thoughts
As we close out 2017, I have much to be thankful for. Thinking back through the year, I've realized that due to natural disasters, senseless killings, terrorism, accidents, and disease, many people around the world are going through their first Christmas season after losing a family member or dear friend. If you know someone in that situation, I encourage you to reach out and let them know you're thinking about them. I'm certain that even a simple card would be appreciated. I also encourage you to tell the people close to you how much they're appreciated. As we've seen, lives can be taken from us without notice.
To that end, I would like to say thank you to Victoria Mack, executive editor here at MC Press Online. Victoria has been editing my articles for more years than either of us will admit to. She's the one who takes my words and works her magic so they make sense! Thank you, girlfriend, for sharing your talent, for being patient when I'm late submitting an article, and for your sense of humor. Cheers to you!
Carol Woodbury is President and CTO of DXR Security and has over 30 years’ experience with IBM i Security. She started her career as Security Team Leader and Chief Engineering Manager for iSeries Security at IBM in Rochester, MN. Since leaving IBM, she has co-founded two companies – SkyView Partners and DXR Security. Her current company - DXR Security - specializes in penetration testing for IBM i. Her practical experience together with her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.
Carol is known world-wide as an author and award-winning speaker on security technology, specializing in IBM i Security topics. She has written seven books on IBM i Security. Carol has been named an IBM Champion since 2018 and holds her CISSP and CRISC security certifications.
MC Press books written by Carol Woodbury available now on the MC Press Bookstore.
 |
||
 |
|
IBM i Security Administration and Compliance: Third Edition Don't miss the newest edition by the industry’s #1 IBM i security expert. List Price $71.95 Now On Sale
|
 |
|
IBM i Security Administration and Compliance: Second Edition Get the must-have guide by the industry’s #1 security authority. List Price $71.95 Now On Sale
|
|
||
 |
|
IBM i Security Administration and Compliance For beginners to veterans, this is the definitive security resource. List Price $69.95
Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online