| Previous | Table of Contents | Next |
A larger issue was involved here: the issue of AS/400 openness. For years, many ISVs had been not only using internal objects but also insisting that IBM make the operating system internals public, because this was holding back software development. IBM argued that there was a danger of software failure caused by mishandling of MI instructions for which IBM could be held responsible. IBM’s compromise (the managed openness exhibited in the APIs) came, in part, out of a series of meetings at COMMON, which were initiated by ISVs and other users. Ron Fess, one of our lead software developers with a long history of accomplishments in both CPF and OS/400, took the lead to work with ISVs and to define the new APIs. Ron’s work led to additional openness for the AS/400 with the incorporation of the Single UNIX Specification and other industry-standard APIs in later years.
With V1R3 of OS/400, we introduced level 40 security. To tighten up security in all new AS/400 installations, OS/400 is now being shipped with level 40 security (it used to be shipped at level 10). This change affects only new systems; upgrades from an earlier version of OS/400 retain the previous level set by the customer. The security officer’s password also is now set to expire at the first sign-on. Before this, many AS/400 installations never bothered to change the password that was shipped originally with the system, which created a clear security exposure for those installations. Later, when we look at the user classes, we will see that the security officer is the highest level of user in the system.
Again, at level 40, the AS/400 user must be enrolled and must enter a valid password to gain access to the system. A limited-capability user also is still supported at this level. As with level 30, the user must have the authority to access the system resources. New for level 40 is that access to nonstandard interfaces is blocked.
With level 40 security, all the MI instructions are no longer available to the user. Many of these instructions are blocked, meaning the system will not execute them in a user program. A user program can use only the approved set of MI instructions, including the hundreds of APIs we created for the ISVs.
The set of blocked MI instructions are, however, still available to OS/400 with level 40 security. To distinguish between an OS/400 program and a user program, we created the notion of a system state and a user state. Each process in the AS/400 runs in one of these states. The use of blocked instructions and, therefore, access to certain objects in the system are allowed only in the system state. Not all of OS/400 needs to have access to everything, so parts of the operating system can run in user state.
To support the higher level of security at V1R3, we also eliminated capability-based addressing by taking the authority out of the system pointers for everyone and everything except the operating system.
Level 40 provides a very secure system for most businesses. Some businesses, however, require that their systems have a level of security that is certified by a government body. There are several levels of government-certifiable security, including the so-called Class C2 level.
The U.S. government specifies computer security guidelines for government applications. Achieving a government-approved security rating allows a computer system to participate in government bids. The government security guidelines specify certain required capabilities, such as protecting one user’s resource from another and preventing one user from taking all the system resources, such as memory. Many businesses now are requiring these same guidelines.
We recognized that with a couple of additions, our level 40 security on the AS/400 could meet the government C2 level. An extensive government audit of a computer system’s security must be conducted before the system is certified to meet the C2 standard, and we decided to go for the certification.
We announced level 50 security for V2R3 of OS/400. Level 50 security on the AS/400 has now been certified by a government audit to meet the federal government’s C2 certification standard. All the level 40 security attributes are included at level 50, although some of the interfaces were modified to meet the C2 standards. We also added the security auditing capability to meet this standard.
The U.S. Department of Defense defines the Class C2 level of security as providing “discretionary (need-to-know) protection and, through the inclusion of audit capabilities, for accountability of subjects and the actions they initiate.”1 This requires that the owner of a computer system resource has the right to decide who can access the resource, and that the system can detect when the resource is accessed and by whom. The auditing capabilities specified by the QAUDJRL system value allow the security auditor to analyze the information the system detected.
1Department of Defense Trusted Computer System Evaluation Criteria, DoD 5200.28-STD, December 1985.
The U.S. government defines security levels that range from A through D, where A is the highest level of security and D is the lowest. Classes B and C have several sub-levels. The C2 security level is the highest level commonly specified for business computing. In the future, we could include even higher levels of security in the AS/400 should the need arise.
The user profile is an OS/400 object and an MI system object. This is the object that identifies the user to the system. Every user in the system must have a user profile; although, as we will shortly see, user profiles can be shared — they do not have to be unique for each user. Even in a system with no security (level 10), if a user profile was not available for some user, the system would create one. User profiles contain the information related to security. Both the OS/400 security component and the SLIC object-authority component use user profiles.
| Previous | Table of Contents | Next |