IBM i IFS Security Basics

Even though the IFS has been part of the system since V3R6 many administrators still find its settings confusing and don’t administer the security configuration with as much rigor as they do objects in libraries.

Unfortunately, part of the defense in fending off malware are appropriately applied security settings. Ignoring these settings can leave the system – and therefore, its data – more vulnerable. In addition, many organizations have regulated data (e.g., images containing healthcare information, credit card information, etc). If not regulated data, there’s often data considered (or should be considered) company confidential (e.g., documents, encryption keys, signatures, etc). Finally, the IFS is often used to implement processes that drive the business. All of these demand a sound security configuration to ensure that the data – and your organization – remains secure.

The principles for securing IFS objects are the same as administering objects in libraries, with a handful of differences. Let’s take a look.

Different Names, Same Purpose

One of the major confusion points are the names used for authorities. If you realize that the IFS was added to enable UNIX applications to be ported to the system, the authority settings may make more sense. That’s why IFS data authorities use the UNIX terms of *R (read), *W (write) and *X (execute.)

In addition, IFS authorities are split into two groups and must be managed this way on authority commands. The two groups are data authorities (*R, *W, and *X) and object authorities (*OBJMGT, *OBJEXIST, *OBJALT, *OBJREF). Here’s how this translates from the traditional IBM i authorities to the less familiar IFS authorities:

*ALL = DTAAUT(*RWX) OBJAUT(*ALL)

*CHANGE = DTAAUT(*RWX) OBJAUT(*NONE)

*USE = DTAAUT(*RX) OBJAUT(*NONE)

*EXCLUDE = DTAAUT(*EXCLUDE) OBJAUT(*NONE)

IFS authorities can’t just use the data authorities (*R, *W and *X) because, after all, under the covers they’re still IBM i objects and all IBM i objects have both data and object authorities. The key is to specify both sets of authorities. Unfortunately, it’s easy to set the data authorities and forget to set the object authorities. Setting the *PUBLIC authority of an IFS object to *PUBLIC DTAAUT(*EXCLUDE) and leaving OBJAUT(*ALL) doesn’t make much sense since it prevents everyone from seeing the contents, but the object itself could be deleted!

Briefly, here’s the access each of the data authorities provide (the object authorities provide the same access for IFS objects as they do objects in libraries).

*R allows you to read the contents of an object (for example a streamfile) or display the contents of a directory

*W allows you to write to or update an object or add an object to a directory

*X allows you to traverse through a directory to a subdirectory. For example, to get to an object in /home/cwoodbury/private you must have

X to the /home directory as well as each of the subdirectories (/home/cwoodbury and /home/cwoodbury/private.) You do not need *R unless you are listing the contents of /home or one of the subdirectories.

Securing an IFS Object

The approach to securing objects in the IFS is the same as objects in a library. Just like a library, if it contains confidential information or information that needs to be restricted to only a few users, the directory should be secured. That is, the *PUBLIC authority should be set to DTAAUT(*EXCLUDE and OBJAUT(*NONE). Or you can secure an individual IFS object – again, just like you would an object in a library. As part of that authority rework you’d then grant individuals or groups authority to use the object (for example, grant the group AR_ADMIN DTAAUT(*R) OBJAUT(*NONE) allowing members of the group to read the contents of a file being secured or list the contents of a directory. Or, if many objects in the same directory need to be secured, you can use an authorization list to secure the objects then grant the group *USE authority to the authorization list. Like an object in a library, we recommend that you grant authority only to the users requiring access and granting them only the authority they need. The good news is that the guesswork for determining what authority is required and who’s currently accessing the object has been removed. Authority Collection is available for IFS objects just as it is for objects in a library. Check out this article from Steve Riedmueller for tips on using the latest IFS Authority Collection views.

Note: Using adopted authority to provide access to an IFS object is not an option. The operating system ignores adopted authority when accessing IFS objects.

How are Authorities Set?

Another point of confusion is where the authority comes from when an IFS object is created.  In general, the authorities come from the directory in which the object is being created.  For example, the root directory (‘/’) ships with *PUBLIC authority set to DTAAUT(*RWX) OBJAUT(*ALL).  When a sub-directory is created under root, it inherits that *PUBLIC authority setting. That’s why most directories in the IFS 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 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 hard coded 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 original behavior caused many issues and an option has been added to these commands allowing you to specify that the authority should come from the directory the file is being created into or from the file being copied.  

Final Tips

Root *PUBLIC authority

• Should be reduced from *PUBLIC DTAAUT(*RWX) OBJAUT(*ALL) to DTAAUT(*RX) OBJAUT(*NONE). This allows everyone to traverse through ‘/’ as well as list the contents but NOT create new directories or objects directly into root.
• Prior to changing make sure that no process is creating objects into root. The process that is typically broken when reducing *PUBLIC authority is one that places a temporary file into root, processes it then deletes it. The best way to check is to examine the CO audit journal entries.

  -- Look for processes creating something into root in the last two weeks
  
  SELECT entry_timestamp,
         user_name,
         qualified_job_name,
         program_library,
         program_name,
         path_name
      FROM TABLE (
              systools.audit_journal_co(STARTING_TIMESTAMP => CURRENT TIMESTAMP - 14 DAYS)
          )
      WHERE path_name NOT LIKE '/%/%';

  -- Look for processes creating something into /QOpenSys in the last two weeks
  
  SELECT entry_timestamp,
         user_name,
         qualified_job_name,
         program_library,
         program_name,
         path_name
      FROM TABLE (
              systools.audit_journal_co(STARTING_TIMESTAMP => CURRENT TIMESTAMP - 14 DAYS)
          )
      WHERE path_name LIKE '/QOpenSys%'
            AND path_name NOT LIKE '/QOpenSys/%/%';

• Should NOT – rather CANNOT - be set to *PUBLIC DTAAUT(*EXCLUDE). OS processes use the IFS on occasion and setting root to exclude will break those internal processes. (An auditor once demanded this at a client and the resulting failures were subtle and extremely hard to trace back to the root setting. Resist the urge and set *PUBLIC to *RX!

/home

• *PUBLIC authority for /home should be set to *PUBLIC DTAAUT(*X) OBJAUT(*NONE) to allow users to traverse through /home to their own home directory but not list its contents. What’s the big deal about /home? It’s a well-known directory that all *IX platforms have. Bad actors love to park things in /home and/or list its contents. Listing the contents usually produces at least a partial list of the users on the system, giving the bad actor profiles to attempt to exploit as well as the profile naming convention that’s been implemented.
• Individual’s home directory (e.g, /home/cwoodbury) should be owned by the individual (in this case, CWOODBURY)

/QOpenSys

• Everything stated in this article should also be applied to /QOpenSys. As stated earlier, the only difference between /root and /QOpenSys is that /QOpenSys is case sensitive. Therefore, the recommendations for *PUBLIC authority as well as the /QOpenSys/home directory are the same as /root’s.
• /QOpenSys is usually where Open Source distributions reside. While you may not be using this file system directly, it’s highly likely that the operating system or an application provider is.

Summary
Hopefully this has cleared up some of the more confusing parts of the IFS. Please contact us if you’re interested in learning how Kisco Systems’ software can add a layer of security to your IFS security scheme (including detecting ransomware) and bring visibility into what’s occurring in this vital – but often ignored – part of IBM i.

Contributed by:
Carol Woodbury
IBM i Security SME
Kisco Systems