02
Sat, Nov
2 New Articles

Security Patrol: What Do You Do with Those IBM-Supplied User Profiles?

IBM i (OS/400, i5/OS)
Typography
  • Smaller Small Medium Big Bigger
  • Default Helvetica Segoe Georgia Times

 

Carol discusses what you shouldand shouldn'tdo with all of the user profiles that are provided with the IBM i operating system.

 

When IBM i is installed, numerous user profiles are created on your system. With each release, more of these profiles are added that support various new features of the operating system or other IBM products. This article discusses how these profiles should be used as well as what not to do with them.

The settings for most IBM-supplied profiles are documented in Appendix B of the IBM i Security Reference manual. This is handy for two reasons: if they're listed in the manual, you know they belong to the operating system or a licensed program product. This is helpful when you're trying to clean up a system and wish to delete profiles that are no longer in use. Because not all profiles make it into the manual, you can't assume that a profile that begins with "Q" is not an IBM profile. But if it is in the manual, it is definitely an IBM profile and shouldn't be deleted. Another place to look is in the "Created by" field in the object description. Use the Display Object Description (DSPOBJD) command on the user profile. If the profile was created by either *IBM or QLPAUTO, that's another indication that it's an IBM-supplied profile. The other reason Appendix B is helpful is because some organizations alter one or more attributes of these profilesmost often it's the addition of a special authority. The table in Appendix B documents each profile's original attribute settings so you can set the profiles back to their "factory defaults."

While there are many IBM-supplied profiles, six user profiles have been around foreverQSECOFR, QPGMR, QSYSOPR, QUSER, QSRV, and QSRVBAS. Not only are these well-documented in IBM documentation, but they're also well-documented in hacker forums. If hackers know anything about the IBM i, they know these profiles exist on all systems. That's why you should leave these profiles with their password set to *NONE. With the exception of QSECOFR, all of these profiles have shipped without a password for many releases. I highly recommend that you leave them without a password and do not use them for sign on. I can hear you asking now, "What about QSRV? My IBM rep usually signs on with that profile." That's fine. Assign the profile a password, let your rep use it, and then set it back to *NONE when the work is completed.

Use of QSECOFR

As I noted above, QSECOFR is the exception. Even if you wanted to set QSECOFR's password to *NONE, it's prevented by the operating system. Why? Because certain taskssuch as upgrading the systemrequire that you sign on with QSECOFR; however, there should be very few other occasions that require sign on to the actual QSECOFR user profile. Yes, there are some lazy vendors that have coded their install routines to require a literal sign on with QSECOFR, but thankfully, it doesn't happen often. What does happen is that administrators see install or other instructions to sign on with a profile with "security officer" authority and they immediately leap to the assumption they must sign on with QSECOFR. Most often, what the vendor is requiring is that the administrator sign on with a profile that has at least *ALLOBJ special authority. Equating that requirement to needing to sign on as QSECOFR is a false assumption and leads to overuse of QSECOFR.

I don't like to use QSECOFR for regular sign on. I like to use it on an exception base only. That way, it's more obvious when it's being abused. While you can't set its password to *NONE, one way to protect against inappropriate use is to set the status of QSECOFR to *DISABLED. Many people hesitate to do this because they fear that they won't be able to use the profile in the case of an emergency. But you can always sign on to the console (virtual or otherwise) with QSECOFR even if its status is *DISABLED. Of course, you still have to know the correct password for this to work.

For the cases when you need "security officer rights," create a profile and give it all special authorities. This should suffice for the vast majority of your security administration needs. If you feel you must use QSECOFR for tasks other than system upgrades, then create a separate profile for each administrator and make them a member of QSECOFR rather than signing on as QSECOFR. That way, QSECOFR doesn't become a shared profile, accountability is preserved (that is, the audit journal will reflect who actually performed each task), and you can more easily detect misuse of QSECOFR.

 

Here are some ways to detect the misuse of QSECOFR (and all of the other IBM profiles for that matter):

  • Turn on *JOBDTA or *JOBBAS action auditing. This auditing level logs the start, end, hold, and release of all jobs. Because this auditing value causes vast amounts of audit journal entriesespecially on busy systemsmany people don't have this value specified for the QAUDLVL system value. But because QSECOFR shouldn't be used, *JOBDTA shouldn't cause excessive audit entries if you're only turning it on at the user level. Note: the operating system and some vendor products run some jobs as QSECOFR. If this creates too much "noise" in your audit exception report, you can filter and look for certain activityinteractive sign-ons for example. Use the Change User Auditing (CHGUSRAUD) command to turn on action auditing at the user profile level.

  • Look for invalid sign-on attempts. These will be under the PW audit journal entry type.

  • Turn on *CMD auditing. This is an action auditing type that can be set only at the user profile (vs. system value) level. This causes all CL commands entered from a command line or run from a CL program to be logged. While you may not want to review all of the audit entries generated by turning on *CMD auditing, you'll have forensic data should you need it for investigation.

IBM Profiles as Application Owners

Unfortunately, application developers often choose QSECOFR as the owner of the application rather than creating their own application-specific profile to own the application. This practice bloats the QSECOFR user profile and makes it very difficult for system administrators to identify potentially dangerous programs. That is, it makes it difficult to spot programs that are inappropriately adopting QSECOFR's profile. In many cases, there are simply too many programs owned by QSECOFR to investigate. What you can do is generate a "baseline" of programs currently on the system and look for additions going forward. At least you'll know what's happening on your system from now on (which is better than not at all!)

IBM Profiles as Group Profiles

QPGMR is another IBM-supplied profile that's often assigned as a vendor product owner. This is just one reason I don't like to use QPGMR as a group profile. Making any of the IBM-supplied profiles a group profile can be dangerous. That's because IBM ships these profiles authorized to many and often owning some IBM i objects. Before you make one of these profiles a group profile, I encourage you to run the Display User Profile (DSPUSRPRF) command specifying the *OBJOWN and running it again specifying the *OBJAUT option. Look at the lists produced and make sure you want those users to also be authorized to or own the objects listed. Making these users a member of the IBM profile will make them the owners of everything the IBM profile owns and authorized to any commands and programs to which the IBM profile is authorized, including vendor products.

The one IBM profile that seems to make the most sense to use as a group profile is QSYSOPR. That's because the people in the operator role typically need authority to all of the commands to which this profile is authorized. In addition, it's very rare that vendors use this profile as a product owner, so you are usually not giving operators more authority or ownership than you intended. You'll still want to check out what QSYSOPR owns and is authorized to on your specific systems, however, before making it your operators' group profile.

Realize, too, that any special authority that the group has, the members will also have. Several releases ago, the default special authorities for each user class were re-worked. IBM decided that the programmer user class should not be defaulting to give users *SAVSYS and *JOBCTL. The role of programmer or developer typically doesn't own the task of saving or restoring all objects or managing other users' jobs. So IBM stopped assigning profiles in the *PGMR class to either *SAVSYS or *JOBCTL special authorities. However, for compatibility reasons, the IBM profile QPGMR continues to have both *SAVSYS and *JOBCTL special authorities. Therefore, when you assign QPGMR as a developer's group profile, you have now given that user *SAVSYS and *JOBCTL special authoritiesspecial authorities that most programmers do not need, especially on production.

Additional Special Authorities

I routinely see organizations where IBM-supplied profiles have been given additional special authorities beyond those assigned by IBM. I can understand in smaller organizations assigning QSYSOPR *IOSYSCFG special authority. People in smaller organizations often perform multiple roles. However, I caution you to understand the implications of making any additional special authority assignments. Specifically, adding *ALLOBJ to an IBM-supplied profile should never occur. That's because whatever task it's used for is now running with authority to every object on the system. I've seen *ALLOBJ assigned to many IBM profiles throughout the years. All cause security exposures, but here are some of the highlights:

  • *ALLOBJ assigned to the QTMHHTTP and QTMHHTP1 user profilesThese are the default profiles under which the Apache web server runs. True, you can change the profile, but the majority of Apache web instances run as these two profiles. Assigning *ALLOBJ to these profiles means that the web instance has the authority to access any directory and any database file on the system. Hopefully, the configuration file for the web server instance prevents open access, but if it's poorly coded, you could be giving web application users authority to access anything on your system!

  • *ALLOBJ assigned to QSYSOPRThis means that anyone using this profile or has it assigned as a group has *ALLOBJ. I've seen QSYSOPR used as a shared profilethat is, more than one person is signing on with this profile, typically operators on different shifts. The result is that you have given *ALLOBJ to a shared profile, so determining who performed that accidental update or intentional delete is going to be difficult. Shared profiles are never a good idea. Shared profiles having *ALLOBJ is an investigator's nightmare.

  • *ALLOBJ assigned to QPGMRThis is, in my opinion, the worst. Not only do you give all members of QPGMR *ALLOBJ special authority (that is, any programmer assigned to QPGMR now has *ALLOBJ), but you have also given vendor products owned by QPGMR more authority than the vendor intended or tested with. In other words, you may be giving users of these vendor products more authority than intended.

Summary

I hope this article has provided guidance about the appropriate use of IBM-supplied profiles. They are a necessary part of the operating system, but they need to be used appropriately so as not to be the cause of security exposures on your IBM i system.

Carol Woodbury

 

Carol Woodbury is IBM i Security SME and Senior Advisor to Kisco Systems, a firm focused on providing IBM i security solutions. Carol has over 30 years’ experience with IBM i security, starting 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 practical experience and her intimate knowledge of the system combine for a unique viewpoint and experience level that cannot be matched.

Carol is known worldwide 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, including her two current books, IBM i Security Administration and Compliance, 3rd Edition and Mastering IBM i Security, A Modern, Step-by-Step Approach. 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

Mastering IBM i Security Mastering IBM i Security
Get the must-have guide by the industry’s #1 security authority.
List Price $49.95

Now On Sale

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$

Book Reviews

Resource Center

  • SB Profound WC 5536 Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application. You can find Part 1 here. In Part 2 of our free Node.js Webinar Series, Brian May teaches you the different tooling options available for writing code, debugging, and using Git for version control. Brian will briefly discuss the different tools available, and demonstrate his preferred setup for Node development on IBM i or any platform. Attend this webinar to learn:

  • SB Profound WP 5539More 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.

  • SB HelpSystems ROBOT Generic IBM announced the E1080 servers using the latest Power10 processor in September 2021. The most powerful processor from IBM to date, Power10 is designed to handle the demands of doing business in today’s high-tech atmosphere, including running cloud applications, supporting big data, and managing AI workloads. But what does Power10 mean for your data center? In this recorded webinar, IBMers Dan Sundt and Dylan Boday join IBM Power Champion Tom Huntington for a discussion on why Power10 technology is the right strategic investment if you run IBM i, AIX, or Linux. In this action-packed hour, Tom will share trends from the IBM i and AIX user communities while Dan and Dylan dive into the tech specs for key hardware, including:

  • Magic MarkTRY 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.

  • SB HelpSystems ROBOT GenericForms 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.

  • SB HelpSystems ROBOT GenericIT security is a top priority for businesses around the world, but most IBM i pros don’t know where to begin—and most cybersecurity experts don’t know IBM i. In this session, Robin Tatam explores the business impact of lax IBM i security, the top vulnerabilities putting IBM i at risk, and the steps you can take to protect your organization. If you’re looking to avoid unexpected downtime or corrupted data, you don’t want to miss this session.

  • SB HelpSystems ROBOT GenericCan you trust all of your users all of the time? A typical end user receives 16 malicious emails each month, but only 17 percent of these phishing campaigns are reported to IT. Once an attack is underway, most organizations won’t discover the breach until six months later. A staggering amount of damage can occur in that time. Despite these risks, 93 percent of organizations are leaving their IBM i systems vulnerable to cybercrime. In this on-demand webinar, IBM i security experts Robin Tatam and Sandi Moore will reveal:

  • FORTRA 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:

  • FORTRAManaging messages on your IBM i can be more than a full-time job if you have to do it manually. Messages need a response and resources must be monitored—often over multiple systems and across platforms. How can you be sure you won’t miss important system events? Automate your message center with the Robot Message Management Solution. Key features include:

  • FORTRAThe thought of printing, distributing, and storing iSeries reports manually may reduce you to tears. Paper and labor costs associated with report generation can spiral out of control. Mountains of paper threaten to swamp your files. Robot automates report bursting, distribution, bundling, and archiving, and offers secure, selective online report viewing. Manage your reports with the Robot Report Management Solution. Key features include:

  • FORTRAFor over 30 years, Robot has been a leader in systems management for IBM i. With batch job creation and scheduling at its core, the Robot Job Scheduling Solution reduces the opportunity for human error and helps you maintain service levels, automating even the biggest, most complex runbooks. Manage your job schedule with the Robot Job Scheduling Solution. Key features include:

  • LANSA 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.

  • LANSAWhen it comes to creating your business applications, there are hundreds of coding platforms and programming languages to choose from. These options range from very complex traditional programming languages to Low-Code platforms where sometimes no traditional coding experience is needed. Download our whitepaper, The Power of Writing Code in a Low-Code Solution, and:

  • LANSASupply Chain is becoming increasingly complex and unpredictable. From raw materials for manufacturing to food supply chains, the journey from source to production to delivery to consumers is marred with inefficiencies, manual processes, shortages, recalls, counterfeits, and scandals. In this webinar, we discuss how:

  • The MC Resource Centers bring you the widest selection of white papers, trial software, and on-demand webcasts for you to choose from. >> Review the list of White Papers, Trial Software or On-Demand Webcast at the MC Press Resource Center. >> Add the items to yru Cart and complet he checkout process and submit

  • Profound Logic Have you been wondering about Node.js? Our free Node.js Webinar Series takes you from total beginner to creating a fully-functional IBM i Node.js business application.

  • SB Profound WC 5536Join us for this hour-long webcast that will explore:

  • Fortra 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: