Last month's "Security Patrol" talked about the basic concepts regarding security and the Integrated File System (IFS). But there is more to the IFS than permissions and copying files. This "Security Patrol" covers numerous IFS topics--from file attributes and file shares to tips for the application writer to guidelines for securing various parts of the IFS. Hang on! Several diverse topics are going to be covered as we dive deeper into the depths of OS/400's IFS.

File Attributes

File attributes are PC attributes. They are properties of the file that are in addition to--but not a replacement for--OS/400 authority settings for the file; the enforcement of these attributes primarily occurs on the PC. These are the file attributes:

• Read-only--This file or folder can only be read. It cannot be updated, changed, or deleted.
• Hidden--This file or folder is hidden and cannot be worked with unless you specifically know its name.
• System--This indicates that the file is a system file. A folder cannot have this attribute set.
• Archive--This indicates whether this file or folder should be archived. Some programs use this attribute to determine what is backed up.
• Archive OS/400--This has the same meaning as the Archive attribute. It cannot be specified (it's grayed-out) and is always checked.

To set file attributes, navigate through the IFS to the desired file or folder. Right-click on the object and select Properties.

You can set file attributes on an object that resides on an iSeries but only from PC interfaces. There is no system-shipped way to set them via an OS/400 green-screen interface. However, one of the free (but unsupported) tools mentioned last month can help you manage these attributes. ATTRIB allows IFS file attributes to be updated from OS/400 without requiring a network drive or PC connection. This provides a way to remove or change the read-only or hidden file attributes for a particular file or files in a specific directory from an OS/400 green-screen. See Figure 1.

 

Figure 1: To set the file attributes for a file in the IFS, navigate to the file, right-click, and select Properties. (Click images to enlarge.)
 

Perhaps you've noticed the file attributes when you are working with a Windows application such as Word. To see these, open a document residing on your PC, then click on File->Properties. You'll notice that not all file attributes are available through this interface, as shown in Figure 2.

Figure 2: Here are the file attributes associated with a Microsoft Word document.

File Shares

File shares are what make the IFS or a specific file system, such as root (/) available for viewing or manipulation via the network. When the IFS was first introduced, once you mapped a drive to the system, the entire IFS was available to you. File sharing was re-worked a few releases ago, and now it follows the Windows technique of file sharing, which is, believe it or not, more secure! Now, only those parts with file shares defined are available. OS/400 ships at least three file shares. There may be more, depending on the features installed.

Right-click on the file share name and choose Properties to see the type of share. Qca400 is read-only. The other two are read/write shares. That means, if you map a drive to the iSeries, these two shares allow users to write to these directories (assuming the user has sufficient OS/400 authority to write to the directory). Qca400 allows you only to read from the directory. Even if the user has *W (write) authority that allows the user to write to the directory through OS/400 interfaces, defining the share as a read share will allow the user only to read from the directory, not write to it. You can choose to remove those shares or create some of your own. You would use file shares when you want all users on the network to have access to something. For example, you may want to leave the Qca400 file share so that users can easily find and download the latest version of iSeries Access (aka Client Access)--or perhaps that's the last thing you want them to do! In that case, you probably want to remove that share.

To see the existing file shares or create a new file share, use iSeries Navigator. Go to My Connections->iSeries_name->File Systems->Integrated File System. Right-click on the directory or file you want to share. Choose Sharing. Figure 3 shows the share for the root (/) directory.

Figure 3: These are the properties of a share as defined for the root (/) directory.

You can choose to have the share be read-only or read/write. Obviously, the more secure setting is read-only because users can then only read the data, not update it. You can also choose how many users can use this share at one time. It is doubtful that you ever want a read/write share for root (although I've seen numerous systems with just such a share.) To do so exposes the directory structure of your entire iSeries onto your network. If you don't have your object-level authority set properly, any user that can map a drive can access any file on the system that has *PUBLIC authority set to either *R (read authority) or *USE authority. On many systems, this would mean that most, if not all, files are accessible. There is one appropriate reason to define a share for root, and that is to create a read-only share, map a drive to the system, and run a virus scanner against root. In this case, you will want to specify Maximum number of users as 1 so that the job running the virus scanner is the only one with network access to root. Unlike Windows 2000, OS/400 will not allow you to define particular shares for particular users. Once you've created the share, it is available for all users on the network with an OS/400 user profile and password.

To see the existing shares, click on File Shares under File Systems. Right-click on a share and choose Properties to see whether the share is read-only or read/write. When you are viewing directories or files under the IFS, shares are indicated by a hand underneath the directory or file name. See Figure 4 below.

Figure 4: The hand under the QIBM directory in the left nav pane indicates that a share has been defined for it (as shown in the right pane.)


While an individual file or the entire root directory may be shared on the network, users attempting access must still have the appropriate authority to the directory or file to perform the intended request. Just because a file is shared does not mean that everyone can read it. That is still determined by the authority settings on the object (including the rest of the path).

Application Authorization Schemes That Work with IFS Objects

When accessing objects in one of the file systems (such as stream files or HTML), adopted authority will not work. No file system except QSYS.LIB honors adopted authority. If you have written an application that runs with adopted authority, you know that as long as the owner of the program that is running either owns or has authority to the object (such as a file) being accessed, the person running the program can access the file. Well, this scheme does not work when accessing objects in file systems such as root or QOpenSys. The user running the program must have the authority to the object in the file system. So your option is to authorize the end user to the objects or change the process or thread so it runs as a different user when accessing these objects. To run as a different user, you have several choices--profile swap, profile token, or the UID and GID family of APIs.

Profile Swap APIs

Profile swap APIs have been around for quite awhile. These are the APIs that the servers (like FTP and Telnet) use to get the job to run as the requesting user rather than the user the server started under. When a process' profile is swapped, all security attributes are swapped in, including the new user's special authorities, limited capability attributes, and group profile(s). The use of the profile handle that has to be generated before the profile is actually swapped is limited to the process that generated it. For more information, see the documentation online in the IBM InfoCenter. Look for the QSYGETPH and QWTSETP APIs.

Profile Token APIs

Profile token APIs were introduced in V4R5. They have the same effect as the profile swap APIs except that the token can be passed between jobs and can be generated as one-time use, multi-use, or multi-use regenerable. These tokens time-out after a specified time and become ineligible for use. For more information, see the documentation online in the IBM InfoCenter. Look for the QSYGENPT and QSYSETPT APIs.

UID and GID APIs

The UID and GID family of APIs are also new in V4R5. The setuid(), setgid(), and associated APIs were added to aide in the porting of UNIX applications to run in PASE, but the native OS/400 versions--qsy_setuid(), qsy_setgid(), and associated APIs--give OS/400 application developers a new option for an application's authorization model. Unlike the profile swap or profile token APIs, the UID and GID APIs only swap in either the user, as in the case of the UID APIs, or the group, as in the case of the GID APIs.

How does this help? Now, when a user accesses an application, part of the application start-up can be to set the GID to the application owner. The application owning profile is now the user's first group. The beauty of this solution is that the application owner is that user's group for that thread only. Prior to V4R5, the only way you could implement a similar model was to change a user's group profile and then use the swap APIs to swap to the same user (to get the new group take effect). The problem with this technique is that, if a user can start another process, the application profile is now the user's group profile, and therefore, the user can access all of the application objects with the rights of the owner. The risks are similar to directly defining the user as a member of the application owner's profile. These risks are eliminated when you use the GID APIs.

Guidelines for Authority Settings

Here are some handy guidelines to help you determine how to set your users' authorities.

*PUBLIC Authority for Application and User Directories

The approach to setting authorities on directories should be no different from the approach taken with libraries and applications whose objects are in libraries. I often recommend that *PUBLIC authority to an application library be set to *EXCLUDE, and only those users with the business requirement to run the application be given authority to the library. This same scheme can be followed for directories.
For user and application directories, that translates into setting *PUBLIC authority OBJAUT(*NONE) DTAAUT(*EXCLUDE) and granting authority to only those users with a specific need to access objects within the directories.

*PUBLIC Authority for IBM-Supplied Directories

Setting authorities on IBM-supplied application directories is much like setting authorities on system-supplied libraries. In the same way that many operations would fail if you were to set *PUBLIC(*EXCLUDE) on QSYS, many applications--especially Web and Lotus Domino applications--will fail if you exclude public from root (/).

IBM's (and SkyView Partners') recommended *PUBLIC authority setting for root is OBJAUT(*NONE) DTAAUT(*RX). It is possible to get by with DTAAUT(*X), but some applications need to read the contents of root (/) and therefore will need *R authority. Setting DTAAUT to *RX will prevent users and applications from creating sub-directories into root (/).

Most IBM application directories have their *PUBLIC authorities set appropriately--that is, *PUBLIC OBJAUT(*NONE) DTAAUT(*RX). However, you will want to review them to make sure. None of them should default to *PUBLIC OBJAUT(*ALL) DTAAUT(*RWX). In addition, most IBM application directories have given the necessary private authorities to the appropriate system-supplied user profiles. For example, QTMHHTTP has been given private authority to the directories and objects it needs to run the APACHE Web server. You probably do not want to remove or otherwise alter these private authorities unless you have thoroughly researched the ramifications of doing so.

Determining Appropriate Authority

To determine the appropriate setting for each directory, you have to first determine the purpose of each directory. If the directory is associated with an application, set *PUBLIC authority as noted above. Users needing to access the application need the following:

• OBJAUT(*NONE) and DTAAUT(*X) to all directories in the path to the application objects
• OBJAUT(*NONE) and DTAAUT(*X) for the directories containing the application objects (Note: They may need DTAAUT(*RX) if the application needs to read the contents of the directory.)
• OBJAUT(*NONE) and DTAAUT(*RWX) for the directory if they are creating objects into it
• OBJAUT(*NONE) and DTAAUT(*WX) for the directory if they are renaming or deleting objects
• OBJAUT (*OBJMGT) at the object level for objects being copied or renamed
• OBJAUT(*OBJEXIST) at the object level for objects being deleted

Home Directory

You may want to create a home directory for each developer (e.g., /home/cjw ) and let them use this directory as their "playground." This is analogous to giving the developers their own library to use. Do you allow developers to create whatever library they want to create? Most likely not--especially not on a production machine. Therefore, you will probably want to set up the following structure:

• Provide *PUBLIC authority to /home to OBJAUT(*NONE) and DTAAUT(*X).
• Provide *PUBLIC authority to /home/developer_name to OBJAUT(*NONE) and DTAAUT(*EXCLUDE). If other users need to be able to access objects in the user's directory, they (or their group) can be given DTAAUT(*RX) to /home/developer_name.
• Have the developer either own or have OBJAUT(*ALL) DTAAUT(*RWX) to /home/developer_name.

Web Applications

The QTMHHTTP profile needs authority to the directories containing the configuration files. The profile under which the application runs needs authority--at least DTAAUT(*X) if not (*RX)--to the directories containing HTML, graphics, etc. This is typically QTMHHTTP; however, an application profile can be specified, or the application can run under the OS/400 user profile. This is specified as part of the protection directives in the Web server config file. Note: QTMHHTTP has already been given the appropriate private authorities.

QPWFSERVER Authorization List

Set the *PUBLIC authority to the QPWFSERVER authorization list to *EXCLUDE, and authorize only users with a business need to have *USE authority to the authorization list.

Review (and Remove) File Shares

Most systems that I have seen have an over-abundance of file shares. Most of the shares have been added without thought to what is being made available to the entire network. You will want to review the file shares that have been defined on your systems and remove the ones that are not appropriate.

You will also want to add a section to your security policy regarding shares:

• Determine policy for who can create shares.
• Determine policy for what should be shared across the network.
• Communicate these policies to developers, network administration, tech support, and security officers.
• Set appropriate authorities on all directories and their objects--especially those that are shared across the network.

Final Words

Don't propagate the problem! As stated last month, the IFS is the most ignored part of OS/400--especially when it comes to security. Just because you may be unsure of how to clean up what's already been placed into the file systems such as root, don't let it get worse. Modify the settings on the directories, set the standards, and communicate those standards to the appropriate groups--such as development, tech support, the security team, etc.--within your organization. As you communicate and enforce the new standards, some of the "fall out" will help you determine what is already in IFS and how it needs to be cleaned up. At this point, the worst action is no action.


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 over 12 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 can be reached at This email address is being protected from spambots. You need JavaScript enabled to view it..