The Four Hundred

You may have heard there's a security problem with the Integrated File System, or IFS. That's true. It's just not 100 percent accurate. To get to the core of this potentially damaging problem, you have to understand that this is essentially a self-inflicted wound. It stems from a common security misconfiguration that allows users to inadvertently share files with anyone else who has access to the IFS. The fix is relatively simple.

Before I get started, I will briefly explain what the Integrated File System is. With the release of OS/400 V5R2, there were 11 file systems on the iSeries. Most of us are familiar with the classic library file system known as QSYS.LIB. This is where we have traditionally stored database files and programs. However, as the iSeries has matured QSYS.LIB has become one of the 11 file systems now available. These 11 file systems are collectively known as the Integrated File System.

Why so many, you ask? Different types of applications use different types of file systems. The various file systems allow the iSeries to support new applications like Domino, WebSphere, MQSeries, Java, Unix programming, iSeries Access, and more.

Three of these file systems are the root, QOpenSys, and user-defined file systems. They provide a blending of iSeries server, Unix, and PC capabilities. If your users are storing files and shared documents on the iSeries, they are typically accessing the root file system.

Before you start working on securing the IFS, be aware that users with *ALLOBJ authority will overrule any changes you make. They will always have access to all objects on the system, no matter what you do with object-level security. Your first task should be to review your user profiles (using the WRKUSRPRF command); look for those with *ALLOBJ authority and those with group profiles that, in turn, have *ALLOBJ authority. If you need to secure files and folders from these types of users, you will need to remove *ALLOBJ authority from their profile. Of course, for critical application users you'll need to research and consider whether this will break any existing applications.

I'm assuming you've used your iSeries for a while, and that users share documents stored on the iSeries, using their PC applications. Eventually you will notice that everyone can see everything. How is this possible? And how do you fix it?

When your system was shipped, the root file system had the equivalent of public authority set to *ALL. That allowed users to start creating files and folders right away, just like you would on your own PC. Normally this would not present a problem, except that OS/400 set the authority of these new files and folders to inherit, or to have the same settings as, its parent folder (the root). In other words, every folder that was created probably has the same authority as root, which, again, is the equivalent of *ALL. This allows everyone full access to everyone else's folders, which is probably not what you wanted.

Fortunately, OS/400 provides commands for printing a report of publicly accessible files and folders, so you can see the objects that every user on the system is authorized to access. The command is PRTPUBAUT, and here's how it works. Assume the following tree:

To print the folders that are publicly accessible in the /home/mike folder, use this command:

Of course, you need to replace /home/mike with the name of a folder you're interested in. To see the names of the folders you have at the root level, run the command WRKLNK '/'. Then use option 5 to navigate through the subfolders.

The IFS uses *R, *W, and *X authorities to grant read, write, and execute rights respectively. They can be combined, so *RWX gives the equivalent of *ALL authority. These authorities can be derived from private authorities, group profile authorities, authorization lists, and public authorities, much like we're familiar with in the QSYS.LIB file system. To access a file in the IFS, you need at a minimum *X authority to every folder in the path. For example, to access /home/mike/fileA, you need *X authority to both the home and the mike folders. Finally, you need access to file A.

That works to our advantage in this scenario. To stop everyone from accessing Mike's files and folders, you can simply remove public's authority at the /home/mike level. You don't have to be concerned with the authority on each file and subfolder, because without *X authority to /home/mike, the public cannot access files in /home/mike or in any subfolders, even though the public still has authority to the individual files.

In some cases, you may find that after running the above command the user is no longer able to access his own files! That's probably because the folder was originally created by someone else (like maybe you?), and the user was getting his authority from the public rights that you just removed. To fix this, Mike needs private authorities, which can be granted through ownership or by using this command:

When users "own" a folder, they have all authority to it and its contents, much like you would expect on their PC's local drive. I believe in making users owners of their own files and folders, so they can manage them themselves (and so I won't have to!). To change the ownership of a folder to another user, use this command:

If you run the Print Public Authorities (PRTPUBAUT) command again, you will notice the report still shows that the public has authority to all the same files. This is technically correct, because all of the files still have the same authority as when they were created. But the public cannot access them, because you closed the door at the folder level. I wish the PRTPUBAUT command had the option of taking this into consideration when producing its report. When you look at the report and see files that appear to be publicly accessible, look back at each of the folders in the path and see if access has been cut off at a higher level.

Now that no one except Mike can access the mike folder, let's see how you would go about sharing files in the /home/mike/shared folder. Remember that by removing public access to /home/mike, no one can access /home/mike/shared, either. How do we allow access to be shared, but not any of Mike's private files? The solution is to revoke public authority from all of Mike's files and then give back access to /home/mike/shared. In addition, you'll need to change the default authorities on the /home/mike/shared folder, so when Mike creates new shared files they are automatically shared.

First, return public access to /home/mike, so they can access files in /home/mike/shared. Remember, to access files in a folder, each user needs at least *X authority to each folder in the path. We removed that capability when we closed the door earlier.

Now the public can access all the files in /home/mike again. Because we only gave *X authority, the public cannot see the files in that folder, but they could open them if the name was known. This can be an effective way of hiding files, since the file name is essentially the password. In our scenario, we don't want anyone accessing Mike's files, so we remove public authority from all of Mike's files and folders, using this command:

The slash (/) and asterisk (*) at the end of the OBJ parameter indicate that you want your change to apply to all files in that folder.

Finally, to allow the public full access to /home/mike/shared run the following command:

For additional security, I recommend removing the public's ability to create folders at the root level. By doing this, you're forcing users to create their files in an existing folder, which you have previously created with the desired security settings appropriate for your environment. If you continue to allow users to create folders in the root with the default authority settings, it becomes difficult to manage the constant propagation of public access. Be aware that some applications expect to create files in the root folder, so this may take additional tweaking. To prevent users from creating folders at the root level, use this command:

Consider using group profiles, authorization lists, or even private authorities, instead of public. This requires a little more setup and planning but can be easier in the long run. Keep in mind that everyone is a member of public, so as you create new user profiles they will automatically have access to Mike's shared folder. But in different scenarios, such as sharing confidential data among a select group, a better choice than public is group profiles, authorization lists, or private authorities.

Michael Grant is the founder and CEO of Bytware, an iSeries vendor specializing in systems monitoring, security, virus-detection, and notification solutions. E-mail: mg0803@bytware.com

Sponsored By

PATRICK TOWNSEND & ASSOCIATES

Alliance AS2 Integrator from Patrick Townsend & Associates

AS2 Integrator from Patrick Townsend & Associates provides the automation and integration components you need to make EDI-INT AS2 data transfer easy to use on the IBM AS/400. With AS2 Integrator you can automatically transmit files to your trading partners such as Wal-Mart. Transmission files are processed into the AS2 Integrator execution environment, transmitted to your trading partner, archived and logged to permanent history files. Received files are automatically converted to AS/400 data format and processed into your business applications. AS2 Integrator provides an easy to follow road map for AS/400 customers to get up and running fast with a certified AS2 solution.

A closer look at AS2 standards
AS2 Integrator provides a solution for AS2 (Applicability Statement 2) secure Internet transfer. AS2 provides a means of securely transporting any file over the internet with the assurance that both the sender and receiver are fully authenticated. In addition to authentication AS2 Integrator provides session encryption so that data contents remain private. Because AS2 is an open standard you can be sure that your investment in IT technology will be secure in the future.

A closer look at Alliance AS2 Integrator
Working in conjunction with the iSoft Corporation, Patrick Townsend & Associates developed a native AS2 EDI-INT Integration solution for the AS/400. It includes all of the functions associated with iSoft's Commerce Suite on other platforms with the addition of a number of features which make using Alliance AS2 Integrator easy to use and manageable. AS2 Integrator lets you quickly deploy an AS2 solution for secure Internet eCommerce that easily integrates with your existing AS/400 applications and EDI translators.

UCC and Drummond certified
AS2 Integrator is fully UCC and Drummond certified and will meet the requirements of any vendor or supplier who deploys a certified AS2 solution. These companies include:

· IBM Global Network
· Wal-Mart
· GE Information Services (GE eXchange Services or GXS)
· IBM
· Meijer
· Kmart
· Target
· Lowes
· Amerisource Begen
· And many others

Automatically transmit/receive any file
You can create a file in a library and AS2 integrator will automatically pick it up and queue it for transmission to your trading partner. The file can be created by your business application, your EDI translator, by third party query products, or by report management software. AS2 Integrator will record the history of the transaction and save a copy of the file on the AS/400 for re-transmission if needed.

Once the AS2 Integrator receives files from your trading partner they are placed in an IFS directory. You can tell AS2 Integrator to automatically copy these files to a library, translate them to an EBCDIC character set if needed, and call your business application to process the files. AS2 Integrator will back up the file in the IFS directory and in the library for re-processing if needed.

If you are receiving ANSI X12 EDI files you can easily process the files into applications such as Inovis TrustedLink, Extol, Gentrans, and others. All EDI translators on the AS/400 support file interfaces for receiving and sending files.

If you do not have an EDI translator you can use the Alliance EDI Workbench/400 product for EDI translation. EDI Workbench/400 is a separately licensed program product from Townsend that supports ANSI X12 translation. If you need to translate XML documents you can use the separately licensed Alliance XML/400 program.

AS/400 application integration
Your AS/400 business applications can directly integrate AS2 Integrator commands. You can transmit files from your RPG, Cobol and CL programs. AS2 Integrator commands make it easy to immediately queue files for transmission to trading partners. Return codes and monitored messages tell you if the commands and APIs are successful.

Third party EDI translator support
AS2 Integrator is easy to integrate with existing EDI translators such as Inovis TrustedLink, Sterling Gentrans and Extol. All of these translators support sending an EDI document to a file in a library. AS2 Integrator can automatically pick up the file and deliver it via the AS2 interface. For inbound EDI documents you can use IFS directory scan to copy the file to a library and translate the file using your EDI translator. Sample programs in the AS2 Integrator library will help you get started with your EDI translator.

Alliance EDI Workbench/400 translation
For AS/400 customers without an EDI translator you can use the Alliance EDI Workbench/400 product from Patrick Townsend & Associates. EDI Workbench/400 integrates with AS2 Integrator for a complete EDI and AS2 solution to handle both inbound and outbound documents.

Alliance XML/400 document translation
If you need to exchange XML documents with your trading partners you can use Alliance XML/400 translator from Patrick Townsend & Associates, Inc. Alliance XML/400 can create XML documents from your AS/400 DB2 files, and can translate XML documents into your database files using advanced mapper and DB2 interfaces. Alliance XML/400 can process all standard XML document types include cXML, ebXML, SOAP, and others. Alliance XML/400 is a separately licensed program product available from iSoft and Patrick Townsend & Associates.

History and audit logs
AS2 Integrator maintains a complete history database and audit trail. You can easily query the database for information about inbound and outbound activity. AS2 Integrator also provides an easy method of retransmitting a file to a trading partner if needed, or re-processing a received file from a trading partner.

Full system management
AS2 Integrator includes a license for the Alliance Application Monitor from Patrick Townsend & Associates. Application Monitor can keep track of your system and application jobs and issue warning messages if any important component of your application fails. Application Monitor supports error notifications via email, SNMP trap message, pagers, system operator messages, and other channels.

SMTP email notification support
AS2 Integrator incorporates a complete SMTP email client application for email notification. You can also use the SMTP email interfaces to send notification messages to your trading partners. You can send confirmation of delivery, translator error, and other types of messages.

For more information on Alliance AS2 Integrator please visit:
http://www.patownsend.com/CommerceSuite.htm
Or visit the Patrick Townsend & Associates home page:
http://www.patownsend.com