Removing Owner's Authority
Q: I read somewhere that removing the owner's authority to an object will reduce the number of private authorities on the system, saving me time on my Save Security Data (SAVSECDTA) process as well as on the Restore Authority (RSTAUT) process. And, as a bonus, it will also save space in user profiles. Is this true?
A: In a word--no. That's true if you have given someone other than the owner a private authority, but not the owner. Here's a little bit about how authorities are stored internally in a user profile object:
Stored in a user profile (among other things) are
--An entry for every object the profile owns
--An entry for every object the profile has a private authority to
--An entry for every user who has a private authority to an object owned by this profile
Even if you remove the owner's authority to the object, his user profile entry for owning the object doesn't go away. The authority you see for the owner through Edit Object Authority (EDTOBJAUT) or Display Object Authority (DSPOBJAUT) is not a private authority entry. So removing it does not remove a user profile entry.
Now, let's look at the user profile entries created when you grant an individual or group profile a private authority to an object by using the EDTOBJAUT or Grant Object Authority (GRTOBJAUT) command. Say we grant Allison a private authority to one of Suzanne's owned objects. A "private authority" entry is added to Allison's user profile and a "someone has a private authority to one of my owned objects" entry is added to Suzanne's user profile. If you then remove Allison's private authority, two user profile entries are removed--one from each profile. Why is this important?
When you do a SAVSECDTA, all of a user's private authorities are saved. The more private authorities on the system, the longer this process takes. In a recovery situation or when you are restoring a system onto new hardware, the process is to restore the profiles, then restore the objects, then run the Restore Authority (RSTAUT) command, which puts back all of the user's private authorities. Once again, the more private authorities you have on the system, the longer the RSTAUT takes.
Now, back to object ownership. The owner's authority to an object is stored with the object itself. Therefore, it is both saved and restored with the object and is not part of either the SAVSECDTA or the RSTAUT. Hopefully, it's now obvious why removing an object's ownership does not save either space or time, but removing private authorities does both.
Reducing private authorities is another reason to use authorization lists. Rather than having entries for every object, there is an entry in the authorization list owner's profile for owning the authorization list, an entry for each user authorized to the authorization list, and a private authority entry in each profile authorized to the authorization list. If the authorization list secures 100 objects, the savings is significant. It's even more significant because files and members are actually made up of multiple internal objects, with each object requiring the appropriate user profile entries.
Debugging Access Failures from Application Administration
Q: I've recently learned about the host applications that you can control using Application Administration in Operations Navigator (now known as iSeries Navigator). I set some of the functions to restrict access, but some system functions then didn't work. How can I tell if I've set something to be too restrictive?
A: First of all, let's make sure everyone knows what we're talking about. Open up Operations Navigator, right-click on the system name you're connected to, and select Application Administration. You'll see a window with three tabs: AS/400 Operations Navigator, Client Applications, and Host Applications. The first two tabs allow you to control the Ops Nav or Client Access Express or iSeries Access functions that appear on a user's desktop. The last tab provides true security function in that it provides access control--that is, it provides another mechanism that prevents users from doing things. If you click on the Host Applications tab and expand the list, you will see that you can control use of FTP, Digital Certificate Manager (DCM), and service tool usage. It's an obscure but pretty cool function.
Now back to the question.
The best way that I know of to determine whether you've set something to be too restrictive is to look in the audit journal. If you have *SECURITY specified as one of the values for the QAUDLVL system value and someone tries to perform a function that they've been restricted from using App Admin, you will see a GR audit journal entry listing the failure. To confirm this, I configured JOE_USER to not be able to do the Change Directory subfunction of the FTP Server. I logged on to FTP as JOE_USER and tried to do a change directory. After it failed, I went to the audit journal. There, you will find a GR type entry. One of the possible values for one of the fields in this type of entry is *USAGEFAILURE. The easiest way to look for this information is through the Display Audit Journal Entry (DSPAUDJRNE) command, specifying GR for the ENTTYP (Entry type) parameter. Also, you might want to take a look at the iSeries Security Reference manual Appendix F. There, you'll find the layouts for all of the model outfiles for all audit journal entry types.
How Much Security Do Exit Programs Provide?
Q: What's the difference between the QIBM_QCA_RTV_COMMAND and the QIBM_QCA_CHG_COMMAND exits? Should these be considered security tools?
A: The QIBM_QCA_CHG_COMMAND exit point allows you to register an exit program for a particular command. That exit program will receive the command string the user entered before the command is run. If the user does not specify the library for the command (e.g., *LIBL/CHGJOB), you can actually change the command string being entered. However, if the user enters the library for the command (e.g., QSYS/CHGJOB), the exit program will receive--but not be able to change--the command string.
The QIBM_QCA_RTV_COMMAND exit sends the exit program the command string, but in no cases can you change the command string. However, your exit program could log the command string and retrieve information about the current job--such as the process user profile name (be careful; don't retrieve the job user name because it might be different from the name of the user actually running the job)--and then log it to a journal. This way, you could track who was running the Change Job (CHGJOB) command (or some other command). You can define up to 10 exits programs to be called per command.
So are these security functions? I have a hard time declaring the CHG_COMMAND exit to be security-related simply because its behavior (the ability to change the command string) is not foolproof. Once people know to library-qualify a command, they know their command string will not be changed. However, the RTV_COMMAND string is different. You can consistently send an audit journal entry every time a command is run. I consider this exit point to be a part of the "security bag of tricks" that OS/400 provides.
You can find the documentation for these two exit programs in the IBM iSeries Information Center. Go to Programming->CL and APIs->APIs->Exit programs. Look for Command Analyzer Change and Command Analyzer Retrieve.
Q: I'm trying to get a list of all the objects a particular user owns, but when I run the Display User Profile (DSPUSRPRF) *OBJOWN option and send it to an outfile, I get a message that not all objects are included in the list. What's going on, and how to I get a complete list?
A: The issue is that the user owns objects in the Integrated File System (IFS). IFS objects use pathnames and the outfile can only handle fixed-length fields. You will have to use the QSYLOBJA (List Object Authority) API. This API provides similar function to the Display User Profile (DSPUSRPRF) command. Several of its formats provide object information using pathnames.
Again, you can find the documentation for these two exit programs in the IBM iSeries Information Center. Go to Programming->CL and APIs->API by Category->Security.
That's all for this month's "Security Patrol." Happy New Year, everyone!
Carol Woodbury is co-author of the book Implementing AS/400 Security as well as co-founder of SkyView Partners, a firm specializing in security consulting and services. Carol has 13 years in the security industry, 10 of those working for IBM's Enterprise Server Group as the AS/400 Security Architect and Chief Engineering Manager of Security Technology. Carol recently authored iSeries security training videos that are now available for purchase at www.expertanytime.com. Carol can be reached at
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