7/30/2019 Security Considerations for the IFS

http://slidepdf.com/reader/full/security-considerations-for-the-ifs 1/3TORONTO USERS GROUP for Midrange Systems – September 2005 11

When I talk to administratorsabout the top issues in Isecurity, one topic thatseems to make them squirm

is the Integrated File System (IFS). By now most people have heard o the IFS but ew understand the security considerationsone must make to ensure this part o theirsystem is secure.

First, let me clariy what I mean by theterm “IFS.” Integrated File System or IFSis really the title given to a set o le systemsthat are available on OS/400. (See Figure

1.) Tose le systems include the QSYS.LIB le system (which is the “traditional”OS/400 le system that we know and love),the NFS le system, the QNC le systemthat supports the Integrated xSeries Serveror iSeries and other Windows 2000 serverson the network. Other le systems may beavailable, depending on the eatures and

 products installed on the system. Each o these le systems use a diferent security scheme. However, the le systems that I amreerring to when I use the term “IFS” are

those le systems that ollow a UNIX-basedsecurity scheme. Tese include root (‘/’),QOpenSys and user-dened le systems.

 Why should you care about the security implications o the IFS? Because it enablesmany o the most powerul and most used

eatures on OS/400 and i5/OS. iSeriesAccess or the Web, Java, and WebSphereapplications are all implemented in theIFS, not to mention the vast number o conguration les, including most o theconguration les or the CP/IP serversthat reside in the IFS as well as the mail thatis processed through or stored in the IFSby the POP and SMP servers and the listgoes on.

Let’s look at the areas that concern me themost:

Unfamiliar and Therefore aChallenge to AdministerBecause the security schemes o the variousle systems are diferent than they areused to, most OS/400 and i5/OS Security Administrators nd it a challenge toadminister them. Administrators needto learn the UNIX authority schemeto administer the IFS. UNIX uses theollowing authorities:

*R (Read) – required to read thecontents o an object, including listing 

the contents o a directory *W (Write) – required to add anobject to a directory or update anobject

*X (Execute) – required to traverse adirectory. In other words, to display astream le in the ollowing directory 

•

•

•

 path, one would need to add *X to allthe directories and subdirectories inthe path: /Directory/Subdirectory_1/ Subdirectory_2/ Subdirectory_3/File_name.stm 

Combine *RX and you get the equivalento OS/400’s *USE authority. Combine

*RWX and you get the equivalent o *CHANGE. Tese are the data authorities.Unortunately, when dealing with the IFS, you have two sets o authorities to manage.Despite the act the you are dealing withthese objects as i they were UNIX objects,

 you can’t ignore the act that underneath thecovers, they’re still implemented as OS/400objects, so you must also deal with the

“object authorities” – object management,object existence, object alter and objectreerence. In practice, the data authoritiesmay get granular but the object authoritiesare usually *ALL or *NONE. You canmanage these authorities through “greenscreen” commands (Change Authority (CHGAU) and Work with Authority (WRKAU)), by taking option 9 of o 

the Work with Object Links (WRKLNK)command once you’ve navigated to theobject or through iSeries Navigator by right-clicking on the object and choosing Permissions. I you’re using eitherCHGAU or WRKAU, you’ll have to be prepared to type in the entire pathname orthe object name. See Figure 2.

Note: When you administer authorities onIFS objects, make sure you administer boththe data authorities (DAAU) and theobject authorities (OBJAU). I have seeninstances where the administrator adjustedthe data authorities but didn’t realize he alsoneeded to manage the object authorities.

Default Values and HowThey Should Be SetUnortunately, as root ships, it leavesa rather wide hole in the security confguration o the system. Root ships

 with the equivalent o public authority *ALL. Tat is, data authorities o *RWX

Security Considerations for theIntegrated File System (IFS)

© SkyView Partners, Inc, 2005. All Rights Reserved.

 Figure 1. File systems in the Integrated File System (IFS)

 By Carol Woodbury

7/30/2019 Security Considerations for the IFS

http://slidepdf.com/reader/full/security-considerations-for-the-ifs 2/3

TORONTO USERS GROUP for Midrange Systems – September 200512

and object authorities o *ALL. Tissetting allows anyone to create a directory directly under root and store whateverthey want in this directory – and they do!

I have seen directories with PC back-ups, pornography, other images and graphicsdownloaded rom the Internet andillegal copies o movies stored in thesedirectories. As an administrator, you will

 want to take control o who can createdirectories, just like you take controlo who can create a library. Tereore,

 you will want to restrict access to theCreate Directory (CRDIR) and MakeDirectory (MKDIR) commands.

Te wide-open access o root is compound-ed whenever a directory is created into root. When a directory is created it usually in-herits the authority o its parent directory.(Te exception is when you create IFS ob- jects through APIs such as mkdir(), open(),or creat(). With those APIs, you can speciy the data authorities or the owner, primary group, and public authorities.) Te same istrue when stream les, text les or other ob- jects are created into a directory.

So the wide-open denition o ‘/’ iscontinually propagated. It also means thatanyone on the system can update or deleteinappropriately secured le system objects

– hardly the control a security administratorneeds to ensure a stable and available systemand accurate production data.

Managing AuthoritiesLet’s take a look at some o the toolsthat are available to make managing IFSauthorities easier:

Te Print Private Authority (PR-PVAU) and Print Public Author-ity (PRPUBAU) commands wereenhanced to include directory and stream

le objects. Tese commands are the easi-est way to get the total picture o your IFSauthority structure. Beware however, i youspeciy to include all sub-directories under‘/’, the resulting report can be quite largeand overwhelming.

Te QPWFSERVER authorization list hasbeen shipping with OS/400 or quite sometime, but ew people utilize it. It ships with public authority set to *USE. I you changethat value to *EXCLUDE or specically 

exclude a user or group, then access to theQSYS.LIB le system will not be allowedthrough directory interaces such as

 Windows Explorer.

In other words, even i the user hasmapped a drive and the fle shareincludes the QSYS.LIB fle system, theuser will be prevented rom accessing theQSYS.LIB fle system through WindowsExplorer unless the user has at least

*USE authority to the QPWFSERVER authorization list.

Some challenges remain, however. While itis quite easy to change the owner (using theChange Owner (CHGOWN) command)or change the public authority o all o theobjects in a directory (using the ChangeAuthority (CHGAU) command), theonly way to propagate either o theseoperations through to any subdirectories isto write a program or perorm the operationmanually or each sub-directory.

File SharesFile shares are what makes a le system or adirectory within the le system available or

 viewing or manipulation via the network.File shares allow users to map a drive to thedirectory, making the directory appear as parto the PC directory structure when viewedrom an interace such as Windows Explorer.AS/400 ships several le shares. Te exactnumber depends on the eatures installed.

o create a new le share use iSeriesNavigator. Go to My Connections →iSeries_name → File Systems → IntegratedFile System. Right click on the directory orle you want to share. Choose Sharing.

Shares can be dened 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.However, whether the share is dened asread-only or read/write, OS/400 security has the ultimate say over whether the actionis taken. I a read-only share is dened ora directory and John maps a drive to thedirectory, i John is excluded rom thedirectory, he will not be able to see thecontents o the directory. Likewise, i theshare has been dened as read/write, John

 would have to have *W (*write) authority to the directory to add additional objects to

the directory.

 While a convenient way to share datathroughout a corporation, dening sharescan create serious security exposures. Forexample, dening a read/write share orroot provides access to the entire directory structure o OS/400 via the corporatenetwork. Tis means that any user that canmap a drive to OS/400 or has a symboliclink or root dened on their desktopcan access any le on the system that has

*PUBLIC authority set to at least *R (readauthority) or *USE authority. On many systems, this means that most, i not allles on the system are accessible. In many cases public access allows anyone with anOS/400 user id and password to download,update, replace or, in some cases deleteOS/400 objects.

o see the existing shares, click on FileShares under File Systems in iSeriesNavigator. Right click on a share and

Figure 2 – Changing the authority on an IFS object using CHGAU 

7/30/2019 Security Considerations for the IFS

http://slidepdf.com/reader/full/security-considerations-for-the-ifs 3/3

TORONTO USERS GROUP for Midrange Systems – September 2005 13

Carol Woodbury is co-founder of SkyView Partners,Inc, a rm specializing in policy management and assessment software as well as security consultingand services. Carol is the former Chief Security 

 Architect for AS/400 for IBM in Rochester, MN, USA

and has specialized in security architecture, designand consulting for over 15 years. Carol speaksaround the world on a variety of security topics and is co-author of the book, Experts’ Guide to OS/400and i5/OS Security.

 Figure 3: Te hand under the Root directory in the le hand nav pane indicates that a share has been defned. Te share is 

 shown on the right.

choose Properties to see whether the share is read-only or read/ write. When viewing directories or les under Integrated FileSystem, shares are indicated by a hand underneath the directory or le name. See Figure 3.

Summary and Recommendations1) Review the *PUBLIC authority for application and user directories. Approach the securing o directories the same way libraries are secured. A great deal o security can be gained simply by securing the library and authorizing only those users needing access. Tis same approach also works well or directories. Tatis, exclude the general public rom accessing the directory andauthorize only those users with a business requirement.

2) Review (and Remove) File Shares. Most systems that I haveseen have an over-abundance o fle shares. In act, most systemshave a fle share defned or root ‘/’ which makes the entire IFSavailable to the network. Many o these shares have been addedby programmers to check out some o the latest and greatest

 programming tools. Some have been added to allow sharing o data but in almost every case, the shares have been added without

thought to what is being made available to the entire network andusually, without the knowledge o the security administrator. Ihighly recommend that you review the fle shares that have beendefned, understand the security implications and remove theones that are not appropriate. TG