Security
Security
Introduction
Security on the AS/400 is similar to that on any machine in that it allows limitation of the ability of particular users to carry out operations on the system.
Where the AS/400 differs from other machines is in the fact that a security system has been integrated into the machines architecture and is implemented within the machine's licensed internal code (LIC) (even the operating system has to pass security checks before the machine will allow it to perform its own functions). This means that even knowledgable systems programmers cannot bypass the security checking of the system.
Objectives and facilities
1 sec36
Users
The most fundamental component of security is the user identification (user id) which is used to sign on to the system. Anybody who intends to use the AS/400 must be defined to the system by setting up a user profile.
The user profile provides security-related information about an individual job, and is required by the machine at the LIC level - this extends even to the operating system (OS/400), which itself must "sign on" to the machine at IPL time, using its special user profile QSYS.
User profiles are required for all jobs, batch as well as interactive. Batch jobs normally, but not always, run under the profiles of the submitter of the job.
Controlling normal user access
2 sec43
Functional security
This is almost invariably implemented using some sort of menu structure, which has the obvious side-effect of easing application selection for the user.
OS/400 allows the creation of native menu objects for this purpose; each menu option drives a CL command. Command line control is handled by the limited capability option on a user profile, which limits commands that may be entered on AS/400 native menu command lines and OS/400 display command lines (but not on the Command Entry Display).
Third party and in-house functional security systems usually get round the command line problem by not putting one on their menus.
Resource security
The fundamental concept here is Rules of Access.
These rules govern which user profiles can perform particular actions on the object as a whole and also which can perform particular actions on any data contained in the object, for example, physical file records.
It is not necessary to specify explicitly the access required by every user profile to every object; the public authority, group profile, authorisation list and authority holder facilities exist to simplify matters, and are described later.
Avoiding human error
3 sec44
Password control
The AS/400 has a comprehensive system of password control (see later for details).
You can for example force users to change their passwords frequently, limit the length and contents, or prevent a password being the same as any of the last 32.
Display station authority
Powerful user profiles (for example, those with *ALLOBJ special authority, discussed later) can be prevented from signing on to screens other than those to which they are explicitly authorised.
Inactive job timeout
Interactive jobs that remain inactive (waiting for input from the user) for lengthy periods can be ended or disconnected automatically.
Disconnect Job
The disconnect job facility (DSCJOB) enables interactive jobs to be suspended; the sign-on display appears. When the same user signs on to the same display station the system reconnects the job and continues as if there had been no interruption. This is particularly useful at lunch-time, for example, when an unattended display could provide a security risk.
DSCJOB suspends all group and secondary jobs where these are present.
Avoiding malicious access
There are several potential areas of security violation, and areas that should be considered, together with possible detection and control techniques, are summarised here:
4 sec45
Networks
If your AS/400 is in a network (even if communications facilities are limited to PCs dialling in, for example) you should be alert to the danger of network links being misused and unauthorised access gained thereby.
Service functions
These fall into two categories:
•System service tools (SST), usable during normal running from a normal interactive job, and
•Dedicated service tools (DST), accessible only from the attended IPL facility
DST has the greater security implications, as it can under certain circumstances be used to suspend AS/400 security completely.
Save/restore
Objects and their authorities saved on one machine can be restored on another, and the security implications of this may require consideration.
Job descriptions
User profiles may be specified explicitly on job descriptions, and this facility could be used to run batch jobs under powerful user profiles for inappropriate purposes.
Adopting authority
Programs may be compiled with a special parameter allowing the authority of the owner of the program to be added to that of the user while the program is running. Again this facility can be used for inappropriate purposes.
Detection
All attempted resource security violations and incorrect passwords are noted in the system history log.
An audit journal (QAUDJRN) can be created for the automatic logging of security-related events. Some examples of possible log entries are:
•incorrect passwords
•resource security violations
•object deletions
•changes to authorities
Management and audit information
It is frequently essential to be able to identify the user responsible for a particular action - updating a record, creating a file, etc.
For this reason it is to be recommended that each user has his or her own user profile, so that suitable audit information may be stored by applications and by the system.
This method is also often convenient both operationally and to the user, in that it is easy, for example:
•to identify who is responsible for a particular active job
•to identify a user's spooled output
•for users to communicate amongst themselves (individual user profiles are essential if using OfficeVision/400)
AS/400 security implementation
5 sec01
Security Levels
A lot of users will initially migrate to the AS/400 from the System/36 upon which security is optional. To facilitate this, the AS/400 uses two levels of security (10 and 20) to mimic that found on System/36. There is also a level (30) that corresponds to System/38, and a higher level (40) recently introduced for sites that require total confidence in operating system and application integrity.
6 sec23
Level 10
Also known as Physical Security. IBM ships the machine with this value. The system prompts a user for a user identification (but not a password) in order for him to sign on. If there is a user profile with that name, the system signs him on with that name. If there is no such user profile, AS/400 will create one with all object authority (see later), thereby both satisfying the machine's requirement for a user profile, and the user's requirement for no authorisation impediments.
There are very few situations where level 10 security is appropriate.
Level 20
Also known as Password Security. AS/400 requires a valid user profile name and its associated password. All such profiles must have been previously created, but OS/400 gives all object authority to them all. Such a user can however, be restricted to a system of menus, a specific program, or both.
This security level is theoretically adequate where IBM-supplied menus are used to provide functional security. However, it is recommended that resource security (level 30 or 40) be implemented in such a case, if only in a very basic way, as, once functional security is broken (for example, by the acquisition somehow of a Command Entry Display), the system is otherwise wide open to interference.
It would almost certainly be inappropriate to use level 20 where programming development work was done on the system.
Level 30
Also known as Resource Security. As with level 20, user profiles must already exist and users must enter the associated password. However, the profiles will not generally have all object authority (although certain selected profiles might) and would be restricted to accessing certain objects only. Resource security is described in detail later.
Level 40
Although the compiler is not normally accessible, it is possible to write your own Machine Interface programs (like assembler on traditional systems) and bypass OS/400 altogether. You can even modify control blocks and MI data structures (such as user profiles) with this type of program.
Some third party software utilises this type of programming for speed of execution and to get at machine facilities not visible through OS/400.
Another method of getting round OS/400 is to call its programs directly. For example, to call a command processing program and not use the command.
All of this use of what IBM calls 'unsupported interfaces' is usually for entirely virtuous purposes. However, there is a potential security risk.
AS/400 resource security works by requiring all access to machine objects (from which OS/400 objects are constructed) to use resolved system pointers. These can be obtained only using a special MI instruction which automatically places authorisation information, relevant to this user profile and this object, in the pointer.
Resolved system pointers are accessible only by the job that created them, thus providing secure access to machine objects. There is, however, one exception to this accessibility rule. OS/400, for performance reasons, stores resolved system pointers to its most-used objects in a special table called the system entry point table. Access can be gained to these pointers by MI programs, and there is then a possibility of the relevant OS/400 objects being used in inappropriate ways, because the authorisation stored in these system pointers is that of the QSYS user profile, which is all-powerful.
Level 40 security prevents the use of unsupported interfaces entirely; any program that uses one will simply fail.
It also checks all programs restored onto the system to make sure that they have not been 'patched' since they were compiled; if such a change is identified, the restore fails.
Level 40 security is not unreservedly recommended, because it prevents the use of much useful and perfectly safe software.
The audit journal (see earlier), if used in conjunction with level 30 security, can log all events that would have caused failures under level 40; IBM recommend that this option is used for some time before level 40 is set, and a sensibly frequent and detailed review of the audit journal is usually adequate in practice anyhow.
7 sec24
The QSECURITY system value can be changed at any time by an authorised person; an IPL is needed to implement the change.
From now on we will assume level 30 or 40 security.
User Profiles
8 sec25
User profiles hold the following:
•security-specific information items, for example, the password (security control attributes)
•information to drive the IBM-supplied functional security setup, for example, the menu to be displayed initially (functional security attributes)
•non security related information for this user, for example, his default print device (environmental attributes)
•object ownership and authorisation information used for resource security (see later for details)
When a user signs on ("logs on" in other systems' parlance) his user id and password are used to locate a user profile.
This profile will then be used to control a user's access to the system until he signs off ("logs off").
Using attributes stored in the user profile, the system can determine the initial procedures to be followed in allowing the user on to the system.
The user profile then, provides a source of authority for the user in terms of both resource and (IBM-supplied) functional security.
Security control attributes
9 sec26
Password
Passwords are encrypted and cannot be seen even by service personnel. If you forget your password, the Security Officer cannot retrieve it for you; all he can do is change your profile to take a new password. Password control, in terms of content and expiry, is discussed later.
Special authority
•All Object A user profile with this special authority has unrestricted access to the system. Used only for Security Officer functions. This is a serious security risk
•Save System special authority enables a user to save and restore any object even though he might have no other authority to that object. Typically used for users with a system operator responsibility
•Job Control special authority lets a user manipulate jobs and subsystems. Typically used for those users having a system operator function
•Security Administrator special authority enables a user to perform all the activities associated with AS/400 Office administration, which may include creating and changing user profiles. You must have this special authority to use the CRTUSRPRF, DLTUSRPRF or CHGUSRPRF command, to maintain the system directory or the SNADS configuration tables
•Spool Control authority enables a user to manipulate spool queues. Typically for system operator functions
•Service special authority enables a user to perform IBM-related software servicing (application of program modifications, identification of hardware and software faults, etc.). This is typically required for IBM engineers and technical service personnel.
User class
The user class allows for a slightly easier definition of special authorities. Instead of specifying the individual special authorities, it is possible simply to specify that a user is of class *SYSOPR (system operator). The system will then generate the necessary special authorities. The following classes are available:
•Security Officer (*SECOFR)
•Security Administrator (*SECADM)
•Programmer (*PGMR)
•System Operator (*SYSOPR)
•User (*USER)
Group profile details
Users can be grouped together by specifying a group profile. This allows easier management of users by giving the group leader specific authorisations and then allocating users into that group. Grouping is specified on the user profile. See later for detailed information.
Signon Information
There is a system value QDSPSGNINF which can be set to show users the sign-on information display whenever they sign on. This display includes the date of the last sign-on, any invalid sign-on attempts and, if their password expiry date is imminent, the number of days to run.
Functional security attributes
10 sec31
Initial Program
You can specify a program to be invoked when the user signs on. Typically this is an installation-written program, but any program could be specified.
Initial Menu
You can specify a user-written (N.B. AS/400 native) menu or an IBM-supplied menu. When the initial program has completed (or if one has not been specified) this menu will be presented. INLMNU(*SIGNOFF) disables the display of such a menu altogether, and would frequently be appropriate where an initial program is given.
Limited Capability
Instead of referring to the user's mental prowess, this specifies how far into the system the user is allowed to progress. There are three levels of capability:
•Unlimited capability. The user has no restrictions placed upon him. He can modify both the initial program and menu to be invoked as part of the sign on prompt - overriding what has been specified in his user profile. He can also change his user profile (with the CHGPRF command) such that he can modify the values set for the initial program and menu, and also the attention key handling program (see later). Unlimited capability is usually appropriate only where resource security has a full implementation
•Partial capability. The initial program cannot be overridden at sign on, but the initial menu can. The user can change the initial menu specified by his user profile (with the CHGPRF command) but the initial program value cannot be changed. Bear in mind that system supplied menus give access to a command entry line, which may give the user access to commands to which he has not been deliberately denied access
•Limited Capability. The user cannot override his initial program or menu at sign on time, nor may he modify his user profile (except to change his password). If presented with a system-supplied menu, the only commands he can execute are to sign off (SIGNOFF), send a message (SNDMSG), display job (DSPJOB), and display job log (DSPJOBLOG), and the like. This list can be modified, using the ALWLMTUSR parameter on the relevant commands
Attention key handlers
Attention key handling programs receive control when the user presses the ATTN key on the keyboard. This special key interrupts the processing in the application program and makes the system check to see if a program has been specified in the user profile that should now gain control. If it has, this program is given control.
Generally, this facility is exploited by programmers to enable the user to interrupt the processing of an application to perform some other, temporary, function (such as sending a message or making an enquiry upon some other, unrelated part of the system).