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:
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
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.
Note that path names use the forward slash, not the backslash as in MSDOS. You can also use relative path
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
chmod
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
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.
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 /,
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
389120 Mar
389120 Mar
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
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.