THE ESSENTIAL GUIDE TO

BY MEL BECKMAN MAY 2006

HE IFS IS CRITICAL TO THE iSERIES ability to operate in a heterogeneous network. IFS lets the iSeries serve as an archival store for ASCII files, which PC users can retrieve and manipulate using the traditional Windows file system. It also serves as a repository for Web-hosted files and applications, such as those written in Java, JavaScript, and PHP. But to be palatable to these uses, the IFS must eschew the strong capability-based security architecture of i5/OS and descend to the lowest common denominator file system one based on the much weaker, but simpler, Unix security model. And therein lurks a monster. Since the IFS exists on every iSeries, it makes a perfect chink in the armor for hackers to gain a foothold into your system. Thanks to its Unix heritage, IFS inherits many of the Unix security vulnerabilities that hackers already know, love, and routinely exploit. To avoid becoming hacker chum in the Internet ocean, you must understand the IFS security architecture, learn how to manipulate its security features, and establish some basic auditing functions to help you catch intrusion attempts. Along the way, youll pick up a few handy IFS management tips, and discover some of the power IFS gives your applications which is what makes putting up with IFS security blemishes worthwhile. To start, compare the IFS security architecture with that of i5/OS.

IFS Permissions Granted

The i5/OS file system is simple; it consists of libraries, files, and file members. File members live inside files, which live inside libraries. All of these things are collectively

called objects. i5/OS gives you very fine-grained control over access to these objects through a mechanism called object capabilities, a collection of rights owned by a particular user to a particular object or group of objects. Thus a programmer has one set of rights to an object, an application user has another, and a system administrator has yet another. Each set of rights controls very detailed actions, such as creation, deletion, modification, management, save/restore, and the ability to grant rights to other users. When employed correctly, native i5/OS security is virtually bulletproof. The IFS file system is not a simple one, although its security model is much less sophisticated than that of i5/OS. The file system itself consists of directories and files, with directories nested within one another to an infinite depth. You reference files through a path name such as /www/htdocs/images/mypic.jpg. The same file can exist simultaneously in several directories through a Unix feature called a file link. Thus, the file mypic.jpg can reside in both the /www/htdocs/images and /dev/library/pictures directories. Access via either path leads you to the same physical file on disk. Instead of a fine-grained security model, IFS employs a very coarse one. Every object has three permissions associated with it read, write, and execute represented by the letters R, W, and X, respectively. Three sets of these permissions exist; one each for the object owner, the group owner, and the general public. The one nice thing about this security architecture is that the entire security for an object can be printed on a single line:

SUPPLEMENT TO iSeries NEWS 2006

SUPPLEMENT TO iSeries NEWS 2006

THE ESSENTIAL GUIDE TO IFS SECURITY

-rwx r x 1 QSYS 0 960 Feb 1 1:44 mypic.jpg

The first character in the example () shows this is a file; a d in this position means the entry is a directory. The string of cryptic letters after that describes the three sets of permissions for this object, in groups of three characters. The number 1 following this indicates the file has one hard link, which means it is referenced in only one place in the IFS. QSYS is the owner of the object, and the number 0 following this means the file has no group ownership (usually the case in IFS). Following this is the size of the file in bytes, the last-changed timestamp, and the file name. Where a permission isnt assigned, a dash () appears in its place. The first group of three characters, rwx, indicates that the owner of the object has all three permissions read, write, and execute. The second group of three characters, , means that the group owner of this object has no permissions. The third set of three characters is the most important Figure from a security standpoint because it identifies the permissions granted to the general public in this case, only read and execute. The three permissions have slightly different meanings, depending on whether the object is a directory or a file. For directories, read gives a user the right to examine the contents of a directory; however, navigating into that directory (e.g., by making it the users current directory) requires the execute permission. For files, read lets a user retrieve the contents of a file, and write lets the user change the contents; deleting or moving a file requires the execute permission. Now that you understand the fundamentals of IFS permissions, youre ready to see how theyre used in practice. But first, youll need to know how to get around in the IFS. There are several ways, and youll use different Figure methods depending on the task at hand.

Edit File (EDTF), and Work with Links (WRKLNK) all let you browse and manipulate the IFS using the native i5/OS CL syntax. DSPF and EDTF are similar, with the latter letting you edit a files contents as well as display it. Both commands take a single argument the path of the directory to view. To view the IFS root directory, use
DSPF STMF('/)

Figure 1A shows the DSPF/EDTF view. The WRKLNK command is so named because IFS files actually dont physically reside within a directory but are linked to directories (and may be linked to more than one directory). You can invoke WRKLNK with no arguments to get a view of the IFS root (Figure 1B). As you can see, the DSPF view offers much more information on its basic screen. However, WRKLNK offers the Display Attributes option (option 8), which gives a more detailed view of

1A: DSPF/EDTF view

1B:WRKLNK with no arguments

Navigating the IFS

You can access and navigate the IFS through several means. Its accessible in iSeries Navigator, although your ability to manipulate objects through that interface is somewhat limited, so I dont detail it in this article. You can also browse, manipulate, upload, and download files using FTP, but because this interface doesnt let you see or manipulate permissions, I dont discuss it, either. In this guide, I focus on two other methods that let you manipulate security aspects of the IFS one using native i5/OS commands and the other using a conversational Unix-like command line interface. The CL commands Display File (DSPF),

SUPPLEMENT TO iSeries NEWS 2006

THE ESSENTIAL GUIDE TO IFS SECURITY

Figure 1C: QShell command entry display
While you will have occasion to use DSPF/EDTF and WRKLNK at times, youll probably find QShell the most convenient means of manipulating the IFS. The CL commands are useful in batch processes and can do some things that you cant do in QShell. The reverse, however, is also true, so it makes sense to learn the capabilities of both CL commands and QShell in detail. For a summary of IFS CL commands and the QShell equivalents, see Security-related IFS CL and QShell Commands below. With that in mind, lets focus on QShell manipulations of the IFS. Many of these manipulations depend on correctly setting directory and file permissions, so lets start by comparing the different notations used by each venue.

the file path and physical storage attributes, such as actual and allocated space. However, neither of these views shows you the IFS file permissions, which means you must use the QShell interface. You invoke QShell by running the CL command STRQSH. Youll then see a blank command screen. Although you cant tell from looking at this screen, QShell starts up with its current directory set to the IFS root. Typing the ls l (list directory long) command reveals this, as youll get a directory listing showing each root objects permissions (Figure 1C). This listing shows the IFS permissions as they were described earlier.

Working with Directories and Permissions in QShell

If youre already familiar with Unix shell commands, youll be instantly comfortable in QShell. Even if you know only MSDOS batch commands, you can transfer these skills to QShell. The primary command for navigating is Change Directory (cd), which you can use to instantly change your current directory to another one:
cd /www/apachedft

Note that path names use the forward slash, not the backslash as in MSDOS. You can also use relative path

Security-related IFS CL and QShell Commands CL Command

ADDLNK CHGAUD CHGAUT CHGOWN CHGPGP CRTDIR DSPAUT DSPF EDTF WRKAUT

Description
Add Link. Adds a link between a directory and an object. Uses default permissions, which establish initial security. Change Auditing Value. Turns auditing on or off for an object. Change Authority. Gives specific authority for an object to a list of specific users. Change ownership of an object. Change the primary user group of an object. Create a directory. Uses default permissions, which establish initial security. Displays the authorities for a directory or file. The CL command also displays a list of authorized users. Displays a directory and/or file contents. Edits the contents of a file. Changes the security attributes of a file. The CL command lists users and their authorities and provides options for adding, changing, or revoking user authorization to an object.

QShell Command
lk

chown chgrp mkdir ls -al ls, cat

chmod

SUPPLEMENT TO iSeries NEWS 2006

THE ESSENTIAL GUIDE TO IFS SECURITY

names (which prepend the current directory) by omitting the leading slash. Thus, if your current directory is /www/apachectl and you type
cd logs

your current directory becomes /www/apachedft/logs. There are also two very important symbolic directory names, . and .. (period and period period). The single period represents the current directory, and the double period represents the parent directory of the current directory. This saves you from having to type the full path name when navigating upwards in the directory hierarchy. Here are some example shortcut notations and their corresponding expansions, assuming a current directory of /www/apachedft/logs:
./ /www/apachedft/logs ../ /www/apachedft/ ../htdocs /www/apachedft/htdocs ../../ /www

character permission notations. Lets try these command codes out using the chmod (change mode) command, which sets permissions to any values you specify. You supply two arguments, a new set of permissions and the name of a file (or list of files) to be changed. The permission sets are three-decimal digits, representing the owner, group, and public permissions, respectively. Consider the permissions for the mypic.jpg file discussed earlier:
-rwx---r-x 1 QSYS 0 960 Feb 1 1:44 mypic.jpg

In numeric notation, the current permissions are 705. The 7 means rwx for the owner, the 0 means for the group, and the 5 means rx for the general public. To change this to give the public write permission to the file, youd type
chmod 707 mypic.jpg

You now know two QShell commands cd and ls that you can use to explore IFS. Manipulating permissions in IFS is a slightly more complex endeavor, however. Youve seen how QShell represents IFS permissions in the ls command, using the rwx notation. You can use these same permission codes (i.e., r, w, x) in some circumstances for modifying permissions, but in others you must use a corresponding numeric code. The code is simple: Each permission flag represents a bit in a three-bit binary number; r has the binary value 100, w has 010, and x 001. Add them all up, and you get the numeric code for the permission set. Thus rw- would be 100 + 010, or 110; rx is 100 + 001, or 101. In QShell commands, you specify these numbers in decimal form, from 0 through 7. Figure 2 shows a list of the corresponding decimal, binary, and

Displaying the changed permissions using ls l mypic.jpg yields

-rwx---rwx 1 QSYS 0 960 Feb 1 1:44 mypic.jpg

Now, before you faint dead away from the thought of doing all that binary math, take heart you can change permissions symbolically using chmodl as well. You use a character notation to indicate which permission set you want to change: u for the owning user, g for group, and o for others (the general public). You can use the code a to represent all three. You follow this with a plus (+) or a minus () to indicate whether the permission is being added or removed, and then the permission to be changed r, w, or x. Some examples clarify this: chmod o+w add public write permission chmod u-w remove owners write permission chmod go+r add group and public read permission There are other features to this notation that we wont go into now, but you can read about them in IBMs QShell documentation in the iSeries Information Center (publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp). Knowing how to interpret and change permissions is essential to hardening the security of IFS. Lets now look at how permissions can make or break IFS security.

Figure 2: File permission numeric values

Dec 0 1 2 3 4 5 6 7 Bin 000 001 010 011 100 101 110 111 Directory Listing ----x

Locking Down IFS Permissions

-w-wx r r-x rwrwx Perhaps the most important directory in IFS is the root directory, named /. Lets look at its permissions using the ls ld / command (the d option means to display the permissions of the directory itself rather than to list the contents of the directory):
drwxrwsrwx 26 QSYS 0 180224 Nov 2 02:36 /

The d means this is a directory, which you already knew. But the rwxrwsrwx is a problem. Setting aside for a moment the puzzling rws group permissions, notice that the general public has write permission to the root directory! This is the default permissions setting of /,

SUPPLEMENT TO iSeries NEWS 2006

THE ESSENTIAL GUIDE TO IFS SECURITY

and the first thing you should change. You dont want just anybody creating files and subdirectories in the IFS. Instead, a single administrator should be responsible for all objects in the root directory and should give these entries specific permissions appropriate for their use. For example, the /www directory should be owned by the HTTP server user and should not have public write permission. But with the root directory itself having public write permission, anyone can override the permissions you set for /www (or any other root-resident object). To change this, you must be logged in as QSECOFR. From within QShell, execute the following chmod command:
chmod o-w /

Now lets consider the s in the group permission value of rws. This is a special value that in the group permission set means Set Group ID for users executing this object. Under i5/OS this bit has no meaning, but certain other operating systems expect you to set it. Its existence here is just an artifact of QShells Unix heritage, which you can safely ignore. Another aspect of the IFSs Unix ancestry is not so innocuous the hidden file. In Unix and the IFS, any file

name beginning with a period will not display in an ordinary directory listing. The original intent was to use such names for configuration files that users shouldnt be bothered with using or viewing. But hackers just love this ability to hide things in plain sight, and they make liberal use of so-called dot files to cover their tracks. To view all the files in a directory, use the a option on the ls command (Figure 3). Aha! Some nefarious hacker has planted a hidden directory, named .melwuzhere, obviously up to no good. You should be on the lookout for suspicious looking hidden files. Note also that every directory contains two hidden directories, . and .., which were described earlier as shortcut notation. You can see that these are actually directory objects, which have the property of pointing to the current and parent directory, respectively. And, since their names start with a period, theyre normally hidden from view. A common hacker trick is to create a directory or file named . . . (three periods). In an ls al listing, its easy to miss this (Figure 4). A frequent practice among novice IFS users is to create write-only directories to let remote (e.g., FTP) users create files, but not access these files or files other users have created. At first glance, this seems

Figure 3:Viewing all the files in a directory

$ ls -al drwxrwsr-x drwxwsr-x drwxrwsr-x drwxrwsr-x drwxrwsr-x drwxrws--x 5 3 3 2 2 2 QSYS QSYS QSYS QSYS QSYS QSYS 0 0 0 0 0 0 90112 81920 81920 81920 81920 May May May May Mar 23 23 23 23 1 2 2002 2002 2002 2002 12:00 00:00 melwuzhere conf htdocs logs

389120 Mar

Figure 4: Hacker-placed directory or file . . .

drwxrwsr-x drwxrwsr-x drwxrwsr-x drwxrwsr-x drwxrwsr-x drwxrws--x 5 3 3 2 2 2 QSYS QSYS QSYS QSYS QSYS QSYS 0 0 0 0 0 0 90112 81920 81920 81920 81920 May May May May Mar 23 23 23 23 1 2 2002 2002 2002 2002 12:00 00:00 conf htdocs logs

389120 Mar

SUPPLEMENT TO iSeries NEWS 2006

THE ESSENTIAL GUIDE TO IFS SECURITY

to work. If you create a directory named incoming with public permissions of w, remote users can indeed deposit files there, but they can not view the files deposited by others. Hackers cleverly exploit this using a nonobvious feature of the Unix file system: You dont apply permissions recursively to subsidiary directories. A directorys permissions apply only to the directory itself, not to directories it contains. Thus, a user might not be able to access /incoming but can readily get to /incoming/bypass if the permissions on the bypass directory include r or x. The hacker simply creates a hidden directory in the directory named incoming with r and x permissions set. She can now upload and download files freely from her private lair, which will remain invisible to casual observers. Hackers do in fact widely exploit this weakness, using the hidden directory to turn the victims server into a distributor of illicit software, which hackers call warez. Incidentally, if youre wondering how to safely implement a private drop-off directory, there is no way to do it in the current IFS implementation. You must write an FTP exit program to handle private one-way uploads. Incidentally, the default public permissions for any object created in the IFS are rwx, so be sure that your applications make appropriate adjustments to newly created IFS objects. Some IFS-based applications (e.g., Apache Web server) have a configurable default permissions value. to the object. One interesting aspect of the IFS is an extension to the Unix security mode. The IFS, when accessed through CL, supports the i5/OS concept of user-specific rights beyond those of the owner, group, and general public. You use the WRKAUT command to set these authorities, which beyond the *RWX values also include existence, management, and reference authorities. You can thus grant user and user group rights to any IFS object, just as you would any native object. You can also use authorization lists to assign rights. However, keep in mind that these authorities are enforced only for users accessing the IFS from the iSeries itself. They are ignored when users enter via any remote IFS access method. The IFS directory structure can quickly become burdened with outdated files that do nothing but take up space. Two of the useful options of the CL DSPF command are path sizing (option 6) and recursive delete (option 9). Option 6 computes the total disk space consumed by all files and directories contained in a particular directory; option 9 deletes a directory and all its subsidiaries. Use these with care to keep your IFS slim and trim. Occasionally, you may encounter object-locking problems when attempting to delete a file or directory. These can result when a process hangs or a remote user fails to log off correctly. While i5/OS has no native command to display such locks, the Retrieve Object References (QP0LROR) API can do the trick. A simple interface to this API is Carsten Flensburgs DSPIFSLCK (Display IFS Object Locks) program (article ID 18313 at iSeriesNetwork.com). Another clash that can occur between the IFS and i5/OS is unexpected user profile expirations. Native user profiles can expire after a certain period of nonuse, based on the last sign-on timestamp stored in the user profile. The problem is that this value is not set when users log in via FTP or other remote means. The result is unexpected shutdown of user accounts because i5/OS considers the user profiles unused. An easy fix for this is the Change Previous Sign-On Date (QSYCHGPR) API, which when

Interacting with i5/OS

When using CL commands to interact with IFS objects, you may have occasion to alter permissions. The i5/OS authority values of *OBJOPR, *READ, *ADD, *UPD, *DLT, and *EXECUT all have corresponding IFS rwx values (Figure 5). You can also use the IFS rwx notation by simply excluding the dashes and prefixing the remaining characters with an asterisk (e.g., *RW for rw-). The actual meaning of the native authority values may not be what you expect, however. For example, *ADD and *UPD have the same meaning, so that giving a user *UPD authority to an IFS object will also let them add records

Figure 5: IFS permissions and corresponding i5/OS data authorities IFS Permission I5/OS Authority *OBJOPR *READ *ADD *UPD *DLT *EXECUTE rwx *RWX rx*RW SUPPLEMENT TO iSeries NEWS 2006 r-x *RX r-*R -wx *WX -w*W --x *X

THE ESSENTIAL GUIDE TO IFS SECURITY

invoked automatically updates the sign-on timestamp for the current user. The API has no input and requires only a return code parameter so it can be readily invoked from CL:
PGM DCL VAR(&EC) TYPE(*CHAR) LEN(016) CALL PGM(QSYCHGPR) PARM(&EC) ENDPGM

You can call this program from an FTP exit program, or via an inline FTP command, to update the sign-on timestamp. One final aspect of i5/OS IFS management is auditing attempted security violations. To do this, you use the native i5/OS Change Auditing Value (CHGAUD) command to enable auditing on selected sensitive directories and files. One you should most certainly audit is the IFS root directory; you can enable auditing on other IFS objects as you see fit. Viewing authorization violations can be a challenge. You can use the Display Audit Journal Entry (DSPAUDJRNE) command to view violations, but this command wont show you the path name in question. Use Display Journal (DSPJRN) to dump the raw journal file to an outfile and then programmatically scan that file for the path name value. iSeries Security Guide (www.redbooks.com/redbooks/pdfs/sq246668.pdf) describes the audit journal record layouts.

IFS Safe and Sound

Understanding IFS permissions and how they differ from native i5/OS security is the key to ensuring your iSeries server remains secure from IFS-prosecuted attacks. By specifically assigning permissions, auditing permission violations, and managing the interaction between the IFS and your native applications, you can lock down your IFS but still keep it very useful to your users.

About the author

Mel Beckman is a senior technical editor for iSeries NEWS.

SUPPLEMENT TO iSeries NEWS 2006

SUPPLEMENT TO iSeries NEWS 2006