Is the IBM i secure or irrelevant? IBM i object security vs. Win and UNIX file security

1 04 2010

A critical security consideration for any operating system is how it secures ‘files’. Although the contexts may deffer, both Windows and UNIX encapsulate all types of information in fies of various types. IBM i, on the other hand, encapsulates information in various types of objects. Different objects require different types of access.

If I know the name and path of a file under Windows or UNIX, I know its location and can access it by knowing how to read and navigate the file structures. Under IBM i, objects in the native, library file system are located and constructed via sets of pointers. Knowing how to read and navigate the file structures only leads you to bits and pieces of an object’s definition. As a result, hacking an IBM i system requires an order of magnitude greater knowledge and sophistication than hacking either Windows or UNIX.

UNIX secures files at owner, group and public levels for read, write and execute access. Older versions of Windows only secured files via read-only, hidden and archive permissions attributes. Newer versions of Windows and many UNIX systems also provide Access Control Lists (ACLs) to secure ‘objects’ against access via user’s without proper permissions or authority. From it’s earliest days, starting with System/38, the IBM i series provided true object access control at multiple levels of an object’s definition. At the higher object definition level, the system provides Operational, Management, Existence, Alter and Reference control. For objects containing data, the system additionally provides Read, Add, Update, Delete and Execute control. What is more, file definitions can extend access controls to the field level. For the UNIX and Windows like file systems which are part of the Integrated File System, native object access controls are used to emulate UNIX access controls.

At a higher level, authority lists provide the ability to control object access for multiple objects using a single, easy to manage object. And, IBM i supports ACLs in limited environments.

Therefore, IBM i provides very mature and sophisticated access control mechanisms with a great deal of granularity. This is part of the reason IBM i systms are compromized far less often than are Windows and UNIX systems.


FTP and SFTP vs. MFT for OS/400, IBM i, platforms

8 03 2010

Over the past few weeks, I have seen a lot of news group chatter regarding FTP, FTPS and SFTP relating to the IBM System i, i/OS. Although FTP(S) and SFTP provide workable options when limited file transfers are need, they lack the functionality and usability of a mature Managed File Transfer (MFT) solution. Let’s look at some of the advantages provided by a good MFT product verses FTP.

For the purpose of this post, the term OS/400 also refers to i5/OS, i/OS and IBM i.

Under OS/400, SFTP is provided via the PASE and its use is described in this IBM Systems magazine article.

FTP(S)/SFTP vs. MFT functionality

Transferring nested directories is time consuming without a good GUI interface. MFT solutions provide simple and easy-to-use methods for transferring nested directories.
FTP(S)/SFTP only provides two party transfers. MFT allows three party transfers. In a two party transfer, files are transferred between the server and the client. In a three party transfer, the client sets up transfers between two servers so that an intermediate transfer is not necessary.
With FTP(S)/SFTP, controlling end-of-line can be tricky at best. MFT provides straight forward means by which to specify the character or character sequence wanted for end-of-line.
Using OS/400 FTP(S)/SFTP, you may have to create files before doing the transfer to get the correct file settings. An advanced MFT product allows the user to set file appropriate attributes before the transfer or detect those attributes in an OS/400 to OS/400 file transfer. Also, a good product provides one or more methods for automated file creation for save files and database files requiring DDS.
FTP only provides basic scripting. Advanced MFT products provide a full fledged scripting language allowing automation of even the most sophisticated transfer processes.
FTP on OS/400 allows execution of simple commands. Modern, full function MFT products provide the ability, possibly via add-on technology, to not only execute OS/400 commands, but also commands on other systems. A really advanced product also provides logging and control options for the remote system.
OS/400 FTP allows setting a CCSID when opening the FTP session. MFT products go beyond initial CCSID settings by detecting and automatically setting the CCSID for each file transferred during a multiple file transfer whether transferring from the QSYS or IFS file system. A really great MFT product will also adjust end-of-line settings based on ASCII vs. EBCDIC file type.
SFTP only provides binary transfers. FTP supports Single Byte Character Set, SBCS, code pages and some FTP products support UTF-8 code pages. Cutting edge MFT products may support all of the Unicode variants as well as Double Byte Character Set code pages. Although the author knows of none, MFT products that fully supports Mixed Byte Character Sets may exist.
FTP(S) and SFTP provide limited, if any, fault tolerance. MFT products provide network fault tolerance allowing transfer completion following network connection failure and recovery. They may also provide manager fault tolerance for remote command execution whereby remote commands may complete during network outages. Following network recovery, output from reconnected processes is transferred back to the initiating system.

The above information primarily addresses MFT functionality; however, all of the functionality potentially included in an MFT product is not covered. Look for such things as the ability to move files as opposed to only copying files and the ability to list files to name only a couple of items. Security options are referred to but not discussed in detail since they are limited in regard to FTP. The issue of data integrity was not discussed and should be carefully considered before purchasing an MFT product.

Is the IBM i secure or irrelevant? Intrusion detection and prevention

18 02 2010

Platform insecurity renders Managed File Transfer security meaningless. No matter how good your internal architecture your administrator requires protection policies and tools to detect, identify, isolate and mitigate or stop attacks.

Rather than cover what IBM Systems Magazine has well documented, I refer to the following two articles. The first is titled “Intrusion Detection on System i” with the introduction: “Hackers, crackers, intruders, oh my! And each with their pride at stake, But rest assured with a System i, You’ll have a host that they can’t break.” This August 2007 article by Jim Coon and Yessong Johng points our potential methods of intrusion and what to do about them.

The second article, “Intrusion Detection and Prevention on IBM i” written in March of 2009 by Jim Coon and Lindsay Avers, addresses how to set up detection and deal with intrusion, even on a real time basis.

As attackers become more inventive and pervasive, IBM i provides the ability to push back and defend your valuable resources.

Is the IBM i secure or irrelevant? Vulnerabilities

4 02 2010

In the past ten years, IBM dedicated a lot of resources to updating IBM i. With large increases in functionality, including Web enablement, comes additional opportunities for profit as well as venerability. Many traditional business users are not interested in improvements in areas such as Web enablement and, therefore, will not be exposed to many of the vulnerabilities. However, to ignore potential problem areas can result in exposure to regulatory violations and legal actions.

This post from Jon R. Kibler, Chief Technical Officer at Advanced Systems Engineering Technology, Inc. provides some insight into the IBM i vulnerabilities. Although the list is quite small and I expect that a number of them have been addressed, the point is that all system platforms, including IBM i, have vulnerabilities. If there is no one in-house that can establish audit requirements, set up user guidelines, provide substantive policy and tailor your system, or systems, to implement those requirements, guidelines and policies, then thought should be given to bringing in an outside security consultant.

Other ways of limiting your exposure include the use of third party functionality such as Yahoo! Merchant Solutions which can provide a secure customer front end with the ability to transfer orders to your business system for processing, the use of virtual cloud technology such as the Rackspace Virtual Private Cloud and the use of highly secure, cross platform managed file transfer technologies from companies such as Stonebranch. Of course, these are only three options out of thousands that exist.

Is the IBM i secure or irrelevant? 16 bit pointers

31 12 2009

In my previous post, I pointed out that the internet is the most complex system in existence. I also promised insight regarding security issues relating systems attached to the internet. Although the first and most important way to prevent security breaches is to keep your system patches, PTFs, fixes, etc. up to date, the subject of this post is IBM i (i/OS).

I see a lot of articles and discussions about whether IBM i is really secure or just so old that it’s really irrelevant. In point of fact, it’s very difficult to find any hard information explaining the how or why of IBM i security or lack thereof. To treat the subject fairly requires a book, so I will only address one small aspect of IBM i security today – 16 bit pointers.

First, 16 bit pointers have what’s called tags associated with them. That makes the pointers actually 18 bits with two bits that only the kernel (System Licensed Internal Code) can access. If these pointers are changed outside of a kernel operation, one or both of the tag bits get reset which invalidates the pointer. Although it’s not apparent to high level languages, the system is designed so that all information, on disk or in main storage, is accessed via these pointers. As a result, all information is addressed as though residing in main storage; hence, the term single level storage.

The system also organizes storage and uses the pointers in such a way that a program cannot go outside of the bounds of its assigned storage without causing a system exception. In addition, no program, procedure or data object – files, data spaces, queues, etc. – gets accessed without full kernel validation using these pointers. This validation includes access, operation and management rights verification against the user profile whose authority rights are being used to access the object. To protect the system against outside manipulation, certain system critical objects, including user profiles, cannot exist outside of the system Auxiliary Storage Pool.

Due to the design of these pointers and their use by the kernel, a worm or virus cannot take control of a program and trash or corrupt the kernel or access unauthorized information so long as the system runs at security level 40 or above. More about security levels at another time.

This only touches on one aspect of IBM i security. However, the security of the most security capable system in the world depends on
1. The competency of the system administrators
2. Limiting user authorities to only those needed to perform the required jobs and
3. Properly securing assets including passwords.

To dig deeper into aspects of pointers and IBM i internals, read the following. Some of the articles are outdated but still contain important information. Also, some of the articles contain specific information that enhances understanding of IBM i in addition to repeated information from other articles.

Notes for Storage Research by David McKenzie

AS/400 Memory Management from Inside the AS/400 by Frank G. Soltis

Architecture of the IBM AS/400 by Vincent LeVeque at James Madison University, document CS511 dated March 2001

An Object-based Systems Architecture from Smalltalk Musings by Richard Demers

Use the MI to Work with Pointers in ILE RPG by Junlei Li in MC Press Online

The AS/400’s Architecture Goes Beyond Technology by Frank G. Soltis via SystemiNetwork

OS/400 Storage Management from the IBM Information Center

Materialize Pointer (MATPTR) from the IBM Information Center

Resolve System Pointer (RSLVSP) from the IBM Information Center

Most Integrated System in the World?

11 12 2009

Basically, the IBM i (OS/400 i5) is the most integrated, some say psychotic, computer system ever built. With it you can set up LPARs from which to independently serve and/or process different types of information and/or address different domain spaces using AIX, Linux and/or native OS/400 images. It allows direct access of centralized data in the native database file system, PC file system, UNIX file system, optical file system, and other file systems from the native OS/400, PASE (AIX bind) or Windows Server interfaces. It provides system access via green screen, graphical interface, web centric interface and others. It allows running legacy and new COBOL and RPG applications along side of JAVA and PHP applications.

What system could be more integrated? The internet! IBM i systems, along with other systems, provide users with unbelievable power, flexibility and interconnectivity and they all integrate via the internet. How can you provide services to and receive services from customers, venders, government agencies, web portals, etc. without compromising your systems integrity? As demonstrated in the news this past week, not even the US Government is immune to compromise.

There is hope and in the coming weeks I plan to provide some helpful insight. Being an IBM i bigot, you can bet that IBM i will be included in the discussions.

Where’s my File?

19 09 2009

When most IT folks ask the question, “Where’s my file?”, they mean text files, executable files, DLL files, INI files, and many other types of files. However, that question is just a “little” more complicated on the IBM i platform. “How so?” To IBM i, everything’s an object. There are program objects, class objects, job description objects, subsystem objects and many more object types. And, file objects are actually made up of multiple system objects. “What does that have to do with file transfer?” IBM i file transfer programs normally only handle database files, save files and physical source files which are actually a type of database file.

“As long as I get my data, why should I care?” IBM i objects, as with modern languages, have attributes associated with them. These attributes establish record length, maximum number of file members, access path characteristics, sorting sequence, authority inheritance, data definition specification source file name and many other things. “Why do so few managed file transfer programs handle IBM i attributes?” To do so the file transfer program must be aware of file object attributes and their associated fields. Handling file object attributes requires that file transfer programs carry attribute information as part of the file transfer process. Providing this level of sophistication requires a level of technical expertise unavailable to most companies and a high commitment to customer satisfaction.

“So what?” To make up for the file transfer program’s inability to properly handle file attributes and fields, users have to spend a lot of ‘wasted’ time setting up files prior to the actual transfer. They must then transfer the files in binary which does not allow text field translations. Without a sophisticated IBM i file transfer program, transferring thousands, or even hundreds, of files a day can quickly become prohibitive or require a lot of special automation.

Is “Where’s my file?” the only question to ask? What about where’s the meta-data, audit trails and process visibility? There’s also how do I cost effectively handle multiple-platform and multiple-system configurations. These are critical questions for companies with thousands, hundreds or even tens of of systems that may be spread around the globe.