Securing the IFS remains a mystery to most, but with more confidential data being stored in the IFS, it’s time to figure it out.
Even though the IFS has been part of the system since V3R6, most administrators have never understood how or why it should be secured. However confusing it might seem, it should not be ignored. Most organizations have at least one directory that contains confidential information that should be secured. Let me see if I can clear up some confusion so that you can take steps to secure your confidential data residing in the IFS.
Clearing Up the Confusion
I think one of the reasons securing the IFS is such a mystery is that the authorities are named differently than what we use when securing libraries and objects in libraries. Instead of *ALL, *CHANGE, *USE, and *EXCLUDE, the authorities are denoted using UNIX terminology. (It’s based on UNIX terminology because, after all, that’s how the IFS came into being; there was an effort by IBM to get UNIX applications running on the iSeries.)
In the IFS, authorities are split into two groups: data authorities (*OBJOPR, *READ, *ADD, *UPD, *DLT) and object authorities (*OBJMGT, *OBJEXIST, *OBJALT, *OBJREF). Here’s how these translate from the familiar to the unfamiliar:
*ALL = DTAAUT(*RWX) OBJAUT(*ALL)
*CHANGE = DTAAUT(*RWX) OBJAUT(*NONE)
*USE = DTAAUT(*RX) OBJAUT(*NONE)
*EXCLUDE = DTAAUT(*EXCLUDE OBJAUT(*NONE)
The key is to make sure you specify both sets of authorities, especially the object authorities. It doesn’t make much sense to set the data authorities to *EXCLUDE and leave the object authorities at *ALL, for example. With those permissions, I can’t read the contents of the object, but I can delete it!
Another point of confusion is how authority is set when an object is created. In general, the authorities come from the directory in which the object is being created. For example, the root directory (/) ships as *PUBLIC authority set to DTAAUT(*RWX) OBJAUT(*ALL). When a subdirectory is created under root, it inherits that *PUBLIC authority setting. That’s why most directories in the IFS that I review are wide open—because they’ve inherited the wide-open setting of root. *PUBLIC authority is not the only authority inherited. If the directory is secured with an authorization list, has private authorities, or has a primary group assigned, these authorities are also inherited. The exception to this is when a Copy to Stream File (CPYTOSTMF) or Copy to Import File (CPYTOIMPF) is performed. When these commands were first introduced, the authorities on the resulting stream file were hardcoded such that the owner only had DTAAUT(*RWX) OBJAUT(*NONE)—that is, *CHANGE vs. *ALL, *PUBLIC authority was set to DTAAUT(*EXCLUDE) OBJAUT(*NONE), and no private authorities or authorization list were inherited. This behavior wreaked havoc when users other than the creator needed to read the file or when the owner needed to delete and re-create the file. Fortunately, in V6R1, an option was added to these commands that provides you with the ability to specify that the authority should come from the directory the file is being created into or from the file being copied. Unfortunately, the default behavior didn’t change, so people have to know about these options to take advantage of them.
Changing Authorities
It’s likely that not everything in your IFS needs to be secured. You may have created directories to hold image catalogues before applying PTFs or as a staging area for a product upgrade. These directories can be skipped or even deleted if you’re done with the task. But usually one or more directories contain at least one file with confidential information. Once you find those directories, you must first determine what profiles need access before you secure it. A variety of ways exist to find out the profiles needing access— for example, if there are multiple objects in the directory, look at the owner of the objects. If all are owned by the same profile, it’s likely that that’s the only profile needing access. But the definitive way to know is to look in the audit journal and examine the Creation of Objects (CO), Deletion of Objects (DO), and Object Move (OM) entries. Better yet, if you are running V7R4, you can take advantage of the Authority Collection feature. You can turn on the collection at the object level—in this case, the directory you’re trying to secure. The collection will list all profiles accessing the directory along with the authority required.
Once you do your research and determine the profiles needing access, directories containing confidential information are typically set to DTAAUT(*EXCLUDE) OBJAUT(*NONE). The root directory also needs to be secured. But a word of warning: DO NOT set the *PUBLIC authorities of the root directory to *EXCLUDE! Even if your own processes don’t break, internal operating system functions will, and the outcome will not be pleasant. Prior to securing root, you must first determine if objects are being created directly into it. Once again, look at the CO, DO, and OM entries in the audit journal. If you discover activity, the process should be reworked such that the object is being created/deleted/moved into a subdirectory rather than directly into root. Only after verifying there’s no activity should you change the *PUBLIC authority of root to the recommended setting of DTAAUT(*RX) OBJAUT(*NONE).
Final Thoughts
Note that my recommendations for root also apply to QOpenSys. QOpenSys behaves the same way root behaves. The difference between the two is that QOpenSys is case-sensitive and root is not.
I’m hoping that this discussion has helped you feel more comfortable about IFS security and that you are able to take steps to identify directories containing confidential information and secure them appropriately.
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 Get the must-have guide by the industry’s #1 security authority. List Price $49.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