Top Security Issue for the Integrated File System (IFS)

First, let me clarify what I mean by the term “IFS.” Integrated File System or IFS is really the name given to a set of file systems that are available in IBM i. (See Figure 1.) Those file systems include the QSYS.LIB file system (which is the “traditional” IBM i file system that we are all familiar with), the NFS file system, the QNTC file system that supports the Integrated xSeries Server and other Windows 2000 servers on the network. Other file systems may be available, depending on the features and products installed on the system.

One of the most challenging issues for IBM i security administrators today is managing the security associated with the various file systems—in particular, the security (or lack of security) associated with root (‘/’). The root directory is where many IBM i products (including iAccess and WebSphere) and TCP/IP applications, as well as thirdparty applications, store code, data, and configuration files. (See Figure 2.)

The security issue with root is how its default or public (*PUBLIC) access is defined. Root is shipped with public having all access. In other words, everyone on the system has the authority to perform any action against root. In IBM i terms this would be the same as the QSYS library having *PUBLIC authority *ALL.

The wide-open access of root is compounded whenever a directory is created into root. When a directory is created it usually inherits the authority of its parent directory. The same is true when stream files, text files, or other objects are created into a directory. So the wide-open definition of ‘/’ is continually propagated. This means that anyone with access to root can create a directory and store inappropriate material on the system—this is called “parking.” It also means that anyone on the system can update or delete inappropriately secured file system objects—hardly the control a security administrator needs to ensure a stable and available system and accurate production data.

File shares are what makes a file system or a directory within the file system available for viewing or manipulation via the network. IBM i ships at least three file shares. There may be more, depending on the features installed.

To create a new file share use Navigator for i. Go to My Connections > Power Systems_name > File Systems > Integrated File System. Right click on the directory or file you want to share. and choose Sharing. Shares can be defined as read-only or read/write. Obviously, the more secure setting is read-only because—as the name implies—users can only read the data which is being shared on the network and not update it. It should be noted, that while an individual file or the entire root directory may be shared on the network, users attempting access must still have the appropriate IBM i authority to the directory or file to perform the intended request. For example, the user must still have sufficient authority on IBM i to perform an update even though the share is defined as read/write.

While a convenient way to share data throughout a corporation, defining shares can create serious security exposures. For example, defining a read/write share for root provides access to the entire directory structure of IBM i via the corporate network. This means that any user that can map a drive to IBM i or has a symbolic link for root defined on their desktop can access any file on the system that has *PUBLIC authority set to at least *R (read) or *USE authority. On many systems, this means that most, if not all, files on the system are accessible. In many cases public access allows anyone with an IBM i user ID and password to download, update, replace or, in some cases, delete IBM i objects.

Most IBM i installations have inappropriate file shares defined. Many installations have defined a read/write share for root. While it is often appropriate to share a specific directory on the corporate network, it is rarely appropriate to share the entire ‘/’ file system. To see the existing shares, click on File Shares under File Systems in Navigator for i. Right click on a share and choose Properties to see whether the share is read-only or read/write. When viewing directories or files under the Integrated File System, shares are indicated by a hand underneath the directory or file name. (See Figure 3.)

"Virus scanning and IBM i…? What does virus scanning have to do with IBM i? I thought IBM i was virus-proof!" This is the reaction I typically receive after making a recommendation to run a virus scanner against the file systems in the IFS. While IBM i itself cannot be modified by PC- or UNIX-based viruses and worms, the objects stored in the various file systems in the IFS are vulnerable. Over the years, the IFS has proven, on numerous occasions, to be a very effective "carrier." That is, it very efficiently stores and propagates viruses around a network. Another way to put it is that IBM i is the perfect host. It may not get infected itself, but it is very good at infecting everything that touches it.

Many think that if they don’t use an IBM i server as their company’s mail server that they don’t have to worry about viruses. Unfortunately, it is not that simple. Viruses and worms come from infected CDs, website downloads, FTP downloads, and infected PCs attached to the network.

One recent worm made its way into numerous corporate networks through misconfigured firewalls and laptop computers that had become infected while employees were working from home or traveling.

Most companies would consider it heresy to not regularly virus scan PCs. In fact, most companies have virus scanning procedures as part of their corporate security policy. Yet the thought of scanning the IFS has never been considered. The fact is, scanning the IFS needs to be part of corporate policies and procedures as well.

Two options are available for virus scanning the IFS. One is to map a drive from a PC to the IBM i server and run a virus scanner residing on the PC against the file systems in the IFS. While an option, it is not a good one. To accomplish this method, a security administrator—that is, someone with power to do anything on the system—must establish the connection between the PC and IBM i. This means that the PC must be placed in a secure location so that no one can exploit this connection and establish other connections to run as this powerful profile. In addition, a file share must be established for all of the file systems being scanned—including ‘/’. As discussed earlier, defining shares can expose critical data files and applications to the entire corporate network. Another issue is network traffic. To accomplish the actual scan of the object, portions, if not all, of the objects must be downloaded to the PC. This presents two problems. First, any sensitive data stored in a file system is transmitted over the corporate network. In other words, it is free to be read by any network sniffing software. Second, the transmission of data can cause bandwidth issues. In addition, the scan can literally take days depending on bandwidth, other network traffic, and the amount of data being scanned. Last, but certainly not least, there’s the issue of convenience. It’s not! Mapping a drive from a PC to IBM i and running a virus scanner sounds simple enough but when put into practice it is enough of an inconvenience that I have never actually seen a company perform this vital task on a consistent basis.

The better solution is to use a commercially available virus scanner that runs natively on IBM i. While a security administrator has to run the software, there is no network connection that can be exploited. No file shares are required, therefore, vital corporate data need not be made available to the corporate network. Objects being scanned are not transmitted over the corporate network, therefore the security concern about confidential data being subject to sniffing is eliminated as are the network traffic concerns. Duration of the actual scan will obviously vary depending on the amount of data being scanned, as well as processor speeds, but natively running scans typically take a fraction of the time of a scan performed over the network.

Review the *PUBLIC authority for application and user directories

Approach the securing of directories the same way libraries are secured. A great deal of security can be gained simply by securing the library and authorizing only those users needing access. This same approach also works well for directories. That is, exclude the general public from accessing the directory and authorize only those users with a business requirement.

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. Review the file shares that have been defined in IBM i and remove the ones that are not appropriate.

Scan the IFS

Use a commercially available virus scanning product that runs natively on the IBM i server to reduce the business risk associated with viruses and worms. Consider adding the scanning of IBM i file systems to the corporate security policy.