essential guide ifs security pdf

7/29/2019 Essential Guide IFS Security PDF

1/9

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 applicatio ns, such

as those w ritten in Java, JavaScript, a nd PH P. But to bepalatable to these uses, the IFS must eschew the strong

capa bility-ba sed 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, a nd routinely exploit. To

avoid becoming hacker chum in the Internet o cean, 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 att empts.

Along the way, youll pick up a few handy IFS man-

agement tips, and discover some of the power IFS gives

your applications which is what makes putting up with

IFS security b lemishes w orthw hile. To sta rt, compare the

IFS security archit ecture with t ha t of i5/OS.

IFS Permissions GrantedThe i5/OS file system is simple; it consists of libraries, files,

and file members. File members live inside files, w hich

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 pa rticular ob ject or gro up 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, a nd t he ability to grant rights to other users.

When employed co rrectly, na tive i5/O S security is vir-

tually bulletproof.

The IFS file system is not a simple one, although its

security model is much less sophisticated t han tha t o f

i5/O S. The file system itself con sists of directo ries and

files, with directories nested within one another to an

infinite depth. You reference files through a path name

such a s /w w w /ht do cs/ima ges/myp ic.jpg. The same f ile

can exist simultaneously in several directories through a

Unix feature called a fi l e link. Thus, the file mypic.jpg

can reside in bot h th e /w w w /htd ocs/ima ges 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 o bject ha s 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 ow ner, the group

ow ner, and the general public. The one nice thing a bout

this security architecture is that the entire security for an

object can be printed on a single line:

T

T H E E S S E N T I A L G U I D E T O

1 SUPPLEMENT TO iSeries NEWS 2006


2/9SUPPLEMENT TO iSeries NEWS 20062


3/9

T H E ES S EN T I A L G U I D E T O I F S S EC U R I T Y

SUPPLEMENT TO iSeries NEWS 20063

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

The first cha racter in the example () show s this is a

file; a d in this position means the entry is a d irectory.

The string of cryptic letters after that describes the three

sets of permissions for this object, in groups of three

chara cters. The number 1 follow ing 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 t he ow ner of the object has all three per-

missions read, w rite, and execute. The second group

of three chara cters, , means that the group owner

of this object ha s no permissions. The third

set of three characters is the most important

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 w hether the object

is a directory or a file. For directories, read

gives a user the right to examine the con tent s

of a directory; how ever, na vigating 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 fundamentalsof 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

methods depending on the task at hand.

Navigating the IFSYou can a ccess and na vigate 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 dow nload files using FTP, but

because this interface doesnt let you see or

manipulat e permissions, I don t d iscuss it,

either. In this guide, I focus on two other

methods t hat let y ou ma nipulate security

aspects of the IFS one using nat ive i5/OS

commands and the other using a conversa-

tional Unix-like comma nd line interfa ce.

The CL commands Display File (DSPF),

Edit File (EDTF), and Work with Links (WRKLNK) all

let yo u brow se and manipulate the IFS using the native

i5/OS C L synta x. DSPF and EDTF are similar, w ith the

latter letting you edit a files contents as w ell as d isplay

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 show s the D SPF/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

D SPF view offers much more information o n its basic

screen. However, WRKLNK offers the Display Attributes

option (option 8), w hich gives a more detailed view of

Figure 1B:WRKLNK with no arguments

Figure 1A:DSPF/EDTF view


4/9

CL Command Descript ion QShell Command

A DDLNK Add Link. Adds a link betw een a directory and an object . Uses default perm issions, lkw hich establish initial security.

CHGA UD Change A udit ing Value. Turns audit ing on or off for an object .

CHGA UT Chang e A ut horit y. Giv es s pec if ic aut horit y f or an obj ec t t o a li st of s pec if ic us ers .

CHGOW N Change ow nership of an object . chow n

CHGPGP Change the primary user group of an object . chgrp

CRTDIR Create a directory. Uses default perm issions, w hich establish init ial security. mkdir

DSPAUT Displays the authorit ies for a directory or file. The CL command also displays ls -ala list of authorized users.

DSPF Displays a directory and/or file contents. ls, cat

EDTF Edits the contents of a file.

W RKAUT Changes the security at t ributes of a file. The CL command lists users and chmodtheir authorities and provides options for adding, changing, or revoking userauthorization to an object.

Securit y-related IFS CL and QShell Comm ands



the file path and physical storage attributes, such as actual

and allocated space. However, neither of these views

show s you t he IFS file permissions, w hich 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 a t this screen, QShell

starts up w ith its current directory set to the IFS root.

Typing t he ls l (list directory long) comma nd reveals

this, as youll get a directory listing showing each root

objects permissions (Figure 1C). This listing shows the

IFS permissions a s they w ere described ear lier.

While you will have occasion to use

DSPF/EDTF and WR KLN K a t t imes,

youll probably find QShell the most con-

venient means of manipulating the IFS. The

CL commands are useful in ba tch pro cesses

and can do some things tha t yo u cant do

in QShell. The reverse, however, is also

true, so it makes sense to learn the capabil-

ities of both CL commands and Q Shell indetail. For a summary of IFS CL com-

mands a nd t he QShell equiva lents, see

Security-related IFS CL a nd Q Shell

Co mmands below. With that in mind, lets

focus on Q Shell manipulations of the IFS.

Ma ny of these manipulations depend on

correctly setting directory and file permissions,

so lets start by comparing the different

nota tions used b y each venue.

Working with Directories

and Permissions in QShellIf youre already familiar with Unix shell commands,youll be instantly comfortable in QShell. Even if you

know only MSDO S batch commands, you can transfer

these skills to QShell. The primary command for navi-

gating is Change Directory (cd), which you can use to

instantly change your current directory t o a nother one:

cd /www/apachedft

Note that path names use the forward slash, not the

backslash as in MSDOS. You can also use relative path

Figure 1C:QShell command entry display


5/9



character permission nota tions.

Lets try these command codes out using the chmod

(change mode) command, w hich sets permissions to any

values you specify. You supply tw o a rguments, 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 d iscussed 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 fo r the ow ner, the 0 means for

the group, a nd t he 5 means rx for the general public.

To cha nge this to give the public w rite permission to

the file, youd type

chmod 707 mypic.jpg

Displaying the changed permissions using

ls l mypic.jpg yields

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

Now, b efore you faint dead a w ay from the thought of

doing all that binary math, take heart you can change

permissions symbolically using chmodl as well. You use

a character nota tion to indicate which permission set you

w ant t o change: u for the ow ning user, g fo r group, and

o for others (the general public). You can use the code a

to represent all three. You fo llow 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 ow ners w rite 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.

Locking Down IFS PermissionsPerhaps 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 ra ther 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 rwx rw srwx is a prob lem. Setting aside for a

moment the puzzling rw s group permissions, notice that

the general public ha s w rite permission to the root

director y! This is the defa ult permissions setting o f /,

names (which prepend the current d irectory) by omitting

the leading slash. Thus, if your current directory is

/w w w /apa chectl and yo u type

cd logs

your current directo ry becomes /w w w /apachedf t/logs.

There are a lso tw o very important symbolic directory

names, . and .. (period and period period). The single

period represents the current directory, a nd the do ubleperiod 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 /w w w /apachedft/logs:

./ /www/apachedft/logs

../ /www/apachedft/

../htdocs /www/apachedft/htdocs

../../ /www

You now know tw o Q Shell commands cd and ls

that you can use to explore IFS. Manipulating permissionsin IFS is a slight ly more complex endea vor, how ever.

Youve seen how QShell represents IFS permissions in the

ls command , using the rwx nota tion. 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, bina ry, a nd

Dec Bin Directory List ing

0 000 ---

1 001 --x

2 010 -w -

3 011 -w x

4 100 r

5 101 r-x

6 110 rw -

7 111 rw x

Figure 2:File permission numeric values
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsphttp://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsphttp://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsphttp://publib.boulder.ibm.com/infocenter/iseries/v5r4/index.jsp


6/9



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 ob jects in the root directory a nd should give these

entries specific permissions appropriate for their use.

For example, the /w w w directory should be ow ned by

the HTTP server user and should not have public write

permission. But w ith the root directory itself having public

write permission, anyone can override the permissionsyou set for /w w w (or any other root -resident object). To

change this, yo u must be logged in as Q SECO FR. 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 G roup ID for users executing this object.

Under i5/OS this bit has no meaning, but certain o ther

operating systems expect yo u to set it. Its existence here

is just an artifact of QShells Unix heritage, which you

can saf ely 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 w ill 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 tra cks. 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, obviouslyup to no good. You should be on the lookout for suspicious

looking hidden files. Note also that every directory contains

tw o hidden directories, . and .., w hich were described

earlier as shortcut not atio n. You can see that these are

actually d irectory ob jects, w hich have the property o f

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 w rite-only d irectories to let remote

(e.g., FTP) users create files, but not access these files or

files other users have creat ed. At f irst glance, this seems

drw xrw sr-x 5 QSYS 0 90112 M ay 23 2002



drw xrw sr-x 2 QSYS 0 81920 M ay 23 2002 conf

drw xrw sr-x 2 QSYS 0 81920 M ar 1 12:00 htdocs

drw xrw s--x 2 QSYS 0 389120 M ar 2 00:00 logs

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

$ ls -al


drw xw sr-x 3 QSYS 0 81920 M ay 23 2002

drw xrw sr-x 3 QSYS 0 81920 M ay 23 2002 melw uzhere

drw xrw sr-x 2 QSYS 0 81920 M ay 23 2002 conf

drw xrw sr-x 2 QSYS 0 81920 M ar 1 12:00 htdocs

drw xrw s--x 2 QSYS 0 389120 M ar 2 00:00 logs

Figure 3:Viewing all the files in a directory


7/9



to w ork. 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 non-

obvious 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 butcan r ead ily get to /incoming/by pass if the permissions

on the bypass directory include r or x. The hacker simply

creates a hidden directory in the directory named incoming

w ith r a nd x permissions set. She can now upload a nd

dow nload files freely from her private lair, w hich will

remain invisible to casual ob servers. H ackers do in fa ct

widely exploit this weakness, using the hidden directory

to turn the victims server into a distributor of illicit

softw are, w hich hackers call w arez. Incidentally, if

youre wo ndering 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.

Interacting with i5/OSWhen using CL commands to interact with IFS objects,

you ma y ha ve occasion t o a lter permissions. The i5/OS

authority values of *O BJOPR, * READ, *ADD, *UPD,

*D LT, a nd * EXEC UT all ha ve corresponding IFS rw x

values (Figure 5). You can a lso use the IFS rw x no ta tionby simply excluding the dashes and prefixing the remaining

characters with an asterisk (e.g., *RW for rw -). The actual

meaning of t he native authority va lues may not be wha t

you expect, however. For example, *ADD and *UPD

have the same meaning, so that giving a user *UPD

authority t o a n IFS object w ill also let them add records

to the object.

One interesting a spect of the IFS is an extension t o t he

Unix security mode. The IFS, when accessed through CL,

supports t he i5/OS concept o f user-specific rights beyond

those of t he ow ner, gro up, and general public. You use

the WRKAUT comma nd to set these aut horit ies, w hich

beyond the *RWX values also include existence, man-

agement, and reference authorities. You can t hus grant

user and user group rights to any IFS object, just as youwould any native object. You can also use authorization

lists to assign rights. However, keep in mind that these

authorities are enforced only fo r users accessing the IFS

from the iSeries itself. They a re ignored w hen users enter

via any remote IFS access method.

The IFS directory structure can q uickly become burdened

with outda ted 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). O ption

6 computes the total disk space consumed by all files and

directories conta ined in a particular directory; optio n 9

deletes a d irectory and all its subsidiaries. Use these w ith

care to keep your IFS slim and trim.

Occasionally, you may encounter object-locking

problems when a ttempting to delete a file or directory.

These can result w hen a process hangs o r a remote user

fa ils to log off correctly. While i5/O S has no nat ive

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 iSeri esN etw ork .com).

Another clash tha t can occur betw een the IFS and i5/OS

is unexpected user profile expirations. Na tive user prof iles

can expire after a certain period of no nuse, based on thelast sign-on timestamp stored in the user profile. The

problem is that this value is not set w hen users log in

via FTP or other remote means. The result is unexpected

shutdo w n of user accounts because i5/OS considers the

user profiles unused. An easy fix for this is the Change

Previous Sign-On Date (QSYCH G PR) API, w hich when

I FS Pe r m i s s i on r w x r x - r - x r - - - w x - w - - - x

I 5 / OS A u t h o r i t y * RW X * RW * RX * R * W X * W * X

* OBJOPR

* READ

*ADD

*UPD

* DLT

* EXECUTE

Figure 5:IFS permissions and corresponding i5/OS data authorities

7
http://iseriesnetwork.com/http://iseriesnetwork.com/http://iseriesnetwork.com/http://iseriesnetwork.com/


8/9



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 a spect of i5/OS IFS management is audit ing

at tempted security viola tions. To d o t his, you use the

native i5/OS C hange 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 o ther IFS

objects as you see fit. Viewing a uthorizatio n 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. iSeri es Securi ty Guid e

(www.redbooks.com/redbooks/pdfs/sq246668.pdf)

describes the audit journal record lay outs.

IFS Safe and SoundUnderstanding IFS permissions and how they differ from

native i5/OS security is the key to ensuring your iSeries

server remains secure from IFS-prosecuted a tta cks. By

specifically assigning permissions, auditing permission

violations, and managing the interaction betw een the IFS

and your native applications, you can lock down your

IFS but still keep it very useful to your users.

8

A b o u t t h e a u t h o r

M el Beckmanis a

senior technical editor

fo r iSeries NEWS.


9/9SUPPLEMENT TO iSeries NEWS 20069

essential guide ifs security pdf

Documents