Concerns associated with the IFS include wide-open access, file shares, and virus scanning.

Written by Bytware

Editor's note: This article introduces the white paper "Security Issues for the Integrated File System (IFS)" available for download free from the MC White Paper Center.

What are the top five issues facing IBM i security administrators today?

Somewhere near the top of that list are the concerns I have about the IFS. Most people don't realize they need to be concerned. They make the in­correct assumption that if they're not using their system as a web server or a network file server, they have no reason to concern themselves with the IFS. This assumption couldn't be further from the truth.

The IFS is one of the most ignored parts of the system, yet it enables many of the most powerful and most-used features on IBM i today. Many people are unaware that iAccess for Windows and iAccess for the Web, Java, and WebSphere code is stored in the IFS. In addition, many configuration files, including most of the configuration files for the TCP/IP servers, reside in the IFS. Plus, mail is processed through or stored in the IFS by the POP and SMTP servers. These are just some of the IBM i functions that use the IFS.

What are the security concerns associated with the IFS? Three areas concern me the most when considering the IFS:

• Wide-open access

• File shares

• Virus scanning

Let's look at these issues.

Wide-Open Access

The IFS is a set of file systems available in IBM i, including the QSYS.LIB file system (the "traditional" IBM i file system we're all familiar with), the NFS file system, and 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 is managing the security associated with the various file systems—in particular, the security associated with the root directory ('/'), where many IBM i products (including iAccess and WebSphere) and TCP/IP applications, as well as third-party applications, store code, data, and configuration files.

The security issue with root is how its default or public (*PUBLIC) access is defined. Root is shipped with public hav­ing all access; everyone on the system has the authority to perform any action against root. 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. This means that anyone with access to root can create a directory and store inappropriate material on the system. 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

File shares make 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.

Shares can be defined as read-only or read/write. Obviously, the more secure setting is read-only. Note that, while an individual file or the entire root directory may be shared on the network, us­ers attempting access must still have the appropriate authority to the directory or file to perform the intended re­quest. For example, the user must still have sufficient author­ity on IBM i to perform an update even though the share is defined as read/write.

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, so any user who 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 au­thority. 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, de­lete objects.

Most IBM i installations have inappropriate file shares de­fined. 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.

Want to Know More?

Download the free white paper "Security Issues for the Integrated File System (IFS)" from the MC White Paper Center.