22
Mon, Apr
1 New Articles

Security Patrol

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

Watching QSECOFR

Question: In our shop we have several people who need to use the QSECOFR password, but I have a problem trying to figure out who makes which changes as the security officer. Is there any way to reliably track who was signed on as the security officer when a change happened?

Answer: Yes. In fact, there are many. But first, let me commend you for not giving *ALLOBJ and other special authorities to your programmers all of the time. It’s simply too dangerous to allow someone to operate on a daily basis with the OS/400 equivalent of a nuclear missile strapped to his hip. Let me also suggest that you not give the QSECOFR password to your programmers or anyone else in your shop, for that matter. It is better to create a QSECOFR clone (you can call it ZSECOFR) and give the programmers the ability to use that profile for emergency work. I like the QSECOFR clone idea because you are less likely of getting the QSECOFR profile corrupted, broken, or disabled. An alternate security officer can have all of the power of QSECOFR but still leave the QSECOFR profile available for those critical emergencies when nothing else will work. As an added precaution, you might even choose to give the alternate security officer profile slightly less authority than QSECOFR typically carries (remove *SERVICE and *AUDIT, for example) yet still allow it to function successfully as an emergency profile.

Tracking Security Officers

To answer your original question about tracking who is using the powerful QSECOFR profile, allow me to point you toward a solution that I have used successfully for some time. The solution uses the Get Profile Handle and Set Profile APIs to perform password validation and profile swapping for a user who you want to assume the authority of a security officer. To implement this solution, create user profile ZSECOFR as a clone of QSECOFR. For safety purposes, remove *AUDIT and *SERVICE special authority, because they offer the ability to change such things as disk configurations and object auditing, which you might not want changed as a matter of normal application recovery. Don’t assign a password to ZSECOFR, and set the initial program to *NONE and the initial menu to *SIGNOFF because you don’t ever want anyone to sign on directly as that profile. The create statement for ZSECOFR might look like this:


CRTUSRPRF USRPRF(ZSECOFR) PASSWORD(*NONE) +
USRCLS(*SECOFR) INLMNU(*SIGNOFF) +
TEXT(‘Alternate Security Officer’) +
SPCAUT(*ALLOBJ *IOSYSCFG *JOBCTL +
*SAVSYS *SECADM *SPLCTL)

For good measure, you can also turn on object auditing for the user ZSECOFR so that everything that is done by this user is logged to the QAUDJRN security-auditing journal as well. The command to accomplish user profile auditing might look like this:

CHGUSRAUD USRPRF(ZSECOFR) +
OBJAUD(*ALL) AUDLVL(*CMD *CREATE +
*DELETE *OBJMGT *SAVRST *SECURITY +

*SERVICE *SYSMGT)

Now you need a program that will allow your programmers to assume ZSECOFR’s identity. In this case, you’re going to use the profile swapping APIs rather than the usual method of adopting authority, because you want a clear audit trail whenever someone uses ZSECOFR authority. The program SWPUSRPRF, which is downloadable from the MC Web site at www.midrangecomputing. com, uses three of the user profile APIs to accomplish this. The first API, QSYGETPH, accepts the user profile name and the valid password for the user profile you want to become. After QSYGETPH validates authority, it returns a 12-character hexadecimal profile handle that can be passed to the second API, QWTSETP. QWTSETP actually performs the profile swap and changes the authority of the current job. And, finally, the QSYRLSPH API does the housekeeping by releasing the profile handle so that the profile handle cannot be used again.

For security purposes, the profile handle that QSYGETPH provides is limited to use in the job that it was created in. This precaution prevents someone from creating a profile handle in one job and then nefariously distributing it to other processes or saving it for clandestine use on another day.

A Security Hole?

You may notice that the second parameter passed to the QSYGETPH API is *NOPWD. In this example program, SWPUSRPRF is not actually passing a valid password to the API but rather requesting to bypass traditional password processing because the current user has *USE authority to use the profile that we are retrieving the profile handle for. This bypass is permitted because there is a feature in AS/400 user profile security that allows you to retrieve the handle of another user if you have *USE authority to that user’s profile. If you take a moment to reflect upon this, you might get really scared. And getting scared may be a good idea, because these two APIs already exist on your system and just about anyone could write a program such as the one available for download. But, before you get all worked up about holes in the operating system, you should understand that this feature is fairly useful and common in other operating systems, particularly UNIX, and the swapping feature has some great applications in OS/400. But, best of all, it’s easy to eliminate any risk that these APIs may introduce by simply making sure that none of your users have *USE authority to anyone else’s profile (more on securing user profiles later).

Now that QSYGETPH has retrieved a profile handle for you, you can pass that profile handle to QWTSETP, and it will magically change your current job to run under the authority of ZSECOFR. When you first do this, it’s really quite surprising. If you issue the DSPJOB command, you’ll see that nearly everything else about your job stays the same: job name, library list, job description, etc. It’s just that you are now running under the authority of ZSECOFR. The only clue you have that you’re running as another user is that, under option 1 of the DSPJOB command, the current user profile will be listed as ZSECOFR, even though the job name still contains the name of the original, signed-on


user. If you have OS/400 security auditing turned on, there will also be an audit entry in the QAUDJRN journal that will mark your movement to ZSECOFR.

The last piece of work to do is to clean up after yourself by releasing the profile handle so that it isn’t lying around in your job for potential retrieval by anyone else. And, just for good measure and great accountability, the program also logs a record in the QAUDJRN that records the fact that you have swapped to a security officer profile.

Program SWPUSRPRF works well in reverse, too. If you called the program after you have already swapped to ZSECOFR, it will conveniently swap you back to yourself and log that fact in the security audit journal as well.

Securing Your Security Application

Any time you build a new application, it’s important to build security in, and that is doubly true for a security application. This program is going to need an elevated authority to run because these APIs are shipped with *PUBLIC *EXCLUDE authority and because you need special authority in order to Send Journal Entries (SNDJRNE) into the QAUDJRN journal. Fortunately, the security for this application is not that complicated. For starters, change the program to be owned by ZSECOFR and specify that it will adopt the authority of its *OWNER. This allows any user who can run the program to access the sensitive objects that SWPUSRPRF uses. But, because you likely don’t want to give everyone in your organization access to ZSECOFR, you should also remove *PUBLIC authority to the program and specifically grant *USE authority to any individual programmer who needs temporary security officer authority. Figure 1 demonstrates the CL commands needed to properly secure program SWPUSRPRF. Now you’ve got a powerful and traceable emergency profile that you can safely give to your IS staffers without losing track of who did what.

AS/400 IFS Adopt

Question: In the September 2000 issue, you answered a question on an AS/400 Integrated File System (AS/400 IFS) authority problem. We have a similar problem. When the users don’t have an *ALLOBJ authority, they can’t clear the AS/400 IFS file and keep adding records to the file, even if they are the owners of that particular file. You stated that the solution was to swap the user profile to solve the problem. Could you explain in more detail how to use the QSYGETPH and QWTSETP APIs?

Answer: As I have just mentioned, program SWPUSRPRF can give users the authority to operate with heightened authority. This tool is especially useful in the AS/400 IFS because the AS/400 IFS does not support adopted authority. If you want to temporarily grant elevated authority to an AS/400 IFS user (a la program adopt), I do believe that the profile- swapping APIs are your only option.

Who Cleared the File?

Question: Is there a way to see who cleared the data from a file if the file is not under journaling? One of my test data files was cleared, and no one is owning up to doing it. Can the system tell me who it was?

Answer: If you don’t have journaling turned on for the file, and you don’t have the QAUDJRN turned on and the QAUDLVL system values set to *OBJMGT, then I can think of no completely accurate way to discern the file history. You can make some educated guesses, but you’ll never really know.

If I had to guess, I would look at the last changed date on the file (assuming you haven’t messed with the file yet). I would then look at the QHST history log for sign-on


and sign-off times (CPF1124 and CPF1164) for the time period in question to see if I could make an educated guess based on when the file was changed and who was signed on at the time. It’s not a perfect scenario, and there are lots of things that could mess with your guess, but, in the absence of journaling and QSECURITY auditing, it is your best option.

Think Like a Hacker

Question: In the August 2000 “Security Patrol” column (“Security Patrol: Limiting *ALLOBJ Users”), you wrote that it was impossible to limit a user with *ALLOBJ special authority, and that a user with *ALLOBJ could gain access to *SECADM special authority. I haven’t been able to create, change, alter, etc., user profiles with *ALLOBJ if the profile I am using doesn’t have *SECADM special authority. Am I missing something? If what you wrote is true, isn’t this a tremendous security hole that has managed to escape general knowledge? I thought I had a pretty decent knowledge of iSeries 400 security, but this one has me stumped.

Answer: The answer to your question lies in the profile swapping APIs that were explained in “Watching QSECOFR.” When you’re trying to secure your systems, sometimes it helps to think like a hacker. If you read the first question in this article carefully, you will see how an *ALLOBJ user could gain access to *SECADM or any other special authority. Remember that I wrote that the QSYGETPH API will return a profile handle if you supply a valid password, or if you have at least *USE authority to the profile in question. If a user has *ALLOBJ authority, then, by default, the user has at least *USE authority to every profile on the system, which includes QSECOFR.

And, as I demonstrated, if you have at least *USE authority to the QSECOFR profile, you will be able to use the swap profile APIs to assume QSECOFR’s identity and all of its special authorities. But, please don’t get overly concerned about the “new” potential exposure that these APIs might pose. Security experts inside and outside of IBM have been saying for years that *ALLOBJ authority was a dangerous thing to hand out. These APIs are just one more argument in a long list of arguments for restricting access to *ALLOBJ authority. The moral of this story is not that the swap profile APIs (available in OS/400 since V3R1) are dangerous, but rather that *ALLOBJ special authority is dangerous.

CHGOBJOWN OBJ(SWPUSRPRF) OBJTYPE(*PGM) NEWOWN(ZSECOFR)
CHGPGM PGM(SWPUSRPRF) USRPRF(*OWNER)
GRTOBJAUT OBJ(SWPUSRPRF) OBJTYPE(*PGM) USER(*PUBLIC) AUT(*EXCLUDE)
GRTOBJAUT OBJ(SWPUSRPRF) OBJTYPE(*PGM) USER(DAN) AUT(*USE)

Figure 1: These CL commands are needed to properly secure program SWPUSRPRF.


John Earl

John Earl is the founder and Director of Technology and Security for  The PowerTech Group.  a Seattle-area software company that specializes in System i security. He has over 25 years experience with IBM midrange systems and security, has published numerous articles and columns for industry magazines, and served as a Subject Matter Expert (SME) for Security for COMMON. A highly regarded speaker on OS/400 and i5/OS security, Mr. Earl has presented several hundred of iSeries security sessions at industry conferences and user groups all over the world. He is a three-time winner of COMMON's Speaker Excellence award and has also served on the board of directors of COMMON U.S.

 

He can be reached at 253.872.7788 or at This email address is being protected from spambots. You need JavaScript enabled to view it..

 

 

BLOG COMMENTS POWERED BY DISQUS

LATEST COMMENTS

Support MC Press Online

$0.00 Raised:
$

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: