|
AS/400 Security
12/5/99
J. Yates
OSAll Staff Writer
There are three types of security on an AS/400 system. Each type of security builds upon the preceding type. The first type is physical security that allows you to protect the system. Next there is sign-on security which limits who can sign on and what said user can do when they are signed on. And last is resource security, AKA object security that provides protection for system objects like programs, files, and libraries, and the data within these objects.
Physical security
Physical security is just what you think it is -- where you're going to put IBM's big black box. You wouldn't want to place it in the lobby of your office where anybody could walk by it and bump it. I prefer to keep mine beside my desk -- it makes a great coffee table. Not only that, but it's always in my sight. Some places keep their systems underground or inside brick rooms where a person has to have the proper clearance to access the actual AS/400 system.
Sign-on security
Sign-on security deals with the good ol' user profile. Within the user profile you will find specific user information such as password, special authority, user class, and initial menu/program. In addition to these the user profile contains a list of all objects the profile owns and a list of all objects the profile has specifically been authorized to use or banned from using. While ownership of an object can be changed usually whoever created it owns it. If one could get to a command line of an AS/400 system they could access a list of user profiles using the work user profile command (WRKUSRPRF).
Displaying a list of objects the user owns is done by entering the variable *OBJOWN. In addition to that you can use *OBJAUT to see what they´re authorized to use and for a complete description of the user you´d use the variable *BASIC.
One of the parameters that can be specified in the user profile is the user class. There are five types of user classes on the AS/400, the first and highest being the security officer or *SECOFR. The logon name on for most security officers is QSECOFR. The QSECOFR has complete control over the system. He can grant authority or take it away, take control over all objects, services, and stop any process running on the machine.
The *SECADM class takes care of the shit work the QSECOFR can't be bothered with. *SECADM sets up user profiles, can grant limited authority to some objects and job controls and perform system saves. In addition QSECOFR can grant further authorities to *SECADM.
The next class of user is the programmer or *PGMR. The login name for the programmer will be just an ordinary user ID. Naturally the main function of the programmer is to develop applications that will run on the black box. Most programmers have limited access to *allobj, *Jobctl, *savsys. These accesses are granted at a security access of 10,20 (Qsecurity levels will be explained latter). These authorities are the least that the programmers need to do their jobs.
The last user class on the AS/400 is the *USER. The logon for the user will be an ordinary user ID. The user has limited access to *allobj and *savsys as default. The user class determines what options the users will see on the operations menus and on the systems menus. Another parameter that can be set in the user profile is special authority. The special authorities give a user the ability to perform certain functions on the system. Unless over-ridden, a user has special authorities based on user class and security level.
The following is a brief explanation pf special authorities
*ALLOBJ user can access any object.
*AUDIT user can perform auditing functions
*IOSYSCFG user can change input/output Configurations.
*JOBCTL user can stop, display, hold, release, cancel, and clear all jobs running on the system. The user can also start or stop all devices and subsystems.
*NONE user cant do shit.
*SAVSYS user can save and restore and free up space on the system
*SECADM user can create user profiles
*SERVICE user can has service authority
*SPLCTL user has spool control authority
Value
Now let's take a look at the security systems value controls on the AS/400, called Qsecurity values. There are five system value levels 10 – 50. The 10 value provides the least system security while 50 provides the most. A system set at level 10 security HAS NO SECURITY -- all a user has to do is enter a user id to access the system, not even a password. When a system is set to level 10 security there is no way of telling what users are doing and you can not tell what users are signed on. A system set to level 20 security forces users to use both user ids and passwords to sign on, but once they are on they can do what ever they wont. So at level 20 the system really still is not secure.
At level 30 life gets a little harder, a user has to sign on with an id and a password and once on the users have to have authority to objects before they can use them. At level 40 id's and passwords are required and system integrity risks from unauthorized interfaces are prevented. Try running a script on one of these babies and see where it gets you.
With level 40 security each user is assigned their own specific workstation and there is no roaming profiles, as it will also prevent the use of restricted instructions. This level also provides advanced hardware storage protection, protects a programs' running space and will not allow anyone to restore invalidated programs. At level 50 you will be lucky if the thing will let you pick your own nose. Level 50 security on the AS/400 was designed to meet the very strict requirements of the department of defense for C2 security. It provides all the security of level 40 plus restricts user domain objects. Users have to have validated parameters and it also will not allow messages between users or system state programs, it prevents modification of internal controls, and makes all temporary libraries truly temporary.
Other security related items
QMAXSIGN maximum sign on attempts.
QMAXSGNACN maximum sign on attempts action.
QINACTITV job time out.
QINACTNSGQ message queue time out.
QPWDEXPITV password expiration.
The following is a list of object authority values that can be manually set by QSECOFR.
*OBJMGT user has full control over the object the user can set the security over the object or move and rename the object. But the user cannot delete the object.
*OBJEXIST the user can control the object existence on the system and ownership.
*OBJALTER the user can change attributes of the object.
*OBJREF the user can specify the object as the first in referential constraint.
A user can have public or private authorities to an object. The difference being is that the authority that the public has to an object is set when the object is created and is kept within the object. Where as private authority is both stored within the object and in the user profiles of the users who have been given special authority to the object.
Working with this type of object based security can get very confusing so an easier way of managing objects is to create authorization lists. The authorization list would reference both user profiles and objects. It would contain a list of user profiles, which would have different authority to the object. All one would have to do when using the list would be to specify the name of the authorization list when the object is created. Authorization list can be used to secure almost any object.
Wrapping it up
The AS/400 is a very unique server/midrange system that uses its own operating system, appropriately called OS/400. It´s unique for a number of reasons, but largely because of its many eccentricities -- such as the fact that cards inside the system can run various operating systems such as UNIX or Windows NT. The machine and OS are very reliable -- I know of one AS/400 that´s been up and running continuosly for the last seven years.
Unknown to most Web users, these systems are starting to show up all over. IBM's pushing it as a "total E-Commerce solution." The next time you're on a site that you think looks like UNIX, NT or even Lotus (yes, IBM has a version of this system with the Lotus Web server) it could very easily be an AS/400 in disguise. |
