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





How are you sending and recieving confidential Information?

12 12 2009

Fax, couriers and FTP appear to be common ways to send sensitive information. This 2009 benchmark study shows that you have plenty of opportunities to improve service levels, reduce costs and improve your company’s impact on the environment. Time to stop faxing and delaying business due to long cycle times for expedited mail or courier services. For the cost of 1 overnight package you can improve your business agility and security with just a few clicks.





Don’t get all legal on me and stuff

18 09 2009

So Gartner’s Frank Kenney’s intro to his latest blog post is spot on!

Every CIO must ask Chief Counsel and all of the workers reporting to Legal (including internal and external attorneys, paralegals and administrative executives) how the information that flows in and out their department is governed and controlled.

The challenge for many law firms is they don’t have the IT staff or technical solution in pace to adaquetly support secure communications and data exchange, so email is the next best best.  The recent launch of Scribbos, the latest data exchange and secure communications solution for easily exchanging confidential messages securely is about filling that gap for eDiscovery as one of the commenters on the post cited:

E-discovery is something that has been on the minds and the lips of the email guys for a long time. Unfortunately, not enough people listen to the email guys, and it’s important that, with the convergence of all the MFT interaction patterns—from email to system-to-system to B2B and all the different permutations—you’re able to lay a level of governance (i.e., “Who sent what to whom?”), the auditability aspect (i.e., the reporting of “Did they actually get it?”) and the compliance aspect (i.e., “Can you prove it?”).

So quickly the question of “where’s my file?” is morphing for legal staff, users and business in general to be more about Who sent what file and to whom.   So how are you communicating with your personal and corporate lawyers?

Any chance you have a big disclaimer at the bottom of the email or you had to sign something to authorize the use of email to communicate with your attorney?  I gues if email was secure or not error prone there wouldn’t be disclaimers like the following on the bottom of your real estate agents, CPA or attorney’s email.

LEGAL DISCLAIMER
The information transmitted is intended solely for the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you have received this email in error please contact the sender and delete the material from any computer.

So who has your file? Your legal agreement? Your mortgage application or other confidential document again?