Many of the most important system values fall in the category of security system values. These system values are important because they control the workings of the system-supplied security, such as authorizations, auditing, and password management. A system value can have five different values.
Of all security system values, the most important is that which controls the level of system security provided by i5/OS. It can have five different values:
10: The system has no security whatsoever. Anyone can sign on without being set up first. The system asks for a user profile name at the sign-on display, but you can enter anything. No password is required or allowed. Once someone is in the system, that person can do everything.
20: The system requires entry of a valid user profile name and a password when the user signs on. The user profile must have been created beforehand. Once someone is in the system, however, the user can do everything.
30: User profile name and password are required to sign on. After signing on, the system checks authorities every time the user attempts to start a task.
40: Similar to level 30, but the system doesn't allow access to system objects except through "proper channels." Level 40 gives the system administrator tighter security, which protects the system from enterprising MI programmers and computer hackers. New i5 systems ship with level 40.
50: Similar to level 40, but users must have authorization to access objects and system resources. System objects are protected not only by invalidating unsupported interfaces, but by enforcing proper parameter values in those interfaces that are supported.
Security level 10 is no longer supported. A system can no longer be set to run at this level.
To change from one security level to another, you must have *ALLOBJ and *SECADM special authority. The new security level doesn't become effective until after the IPL.
The i5 operating system (i5/OS) lets you customize the public authority given by default when an object is created in a library. All create (CRTXXX) commands have an AUT parameter, which supports special value *LIBCRTAUT. This special value points to the CRTAUT parameter of the library in which you are creating the object.
For example, suppose you want to create a data area in library MYLIB. When you created MYLIB, you specified CRTAUT(*USE). If you now specify AUT (*LIBCRTAUT) when you create the data area in MYLIB, the data area will have a public authority of *USE:
CRTLIB LIB(MYLIB) CRTAUT(*USE) CRTDTAARA DTAARA(MYLIB/MYDTAARA) ... AUT(*LIBCRTAUT)
Library MYLIB also could have been created using CRTAUT(*SYSVAL). In this case, the CRTLIB command references system value QCRTAUT:
CHGSYSVAL SYSVAL(QCRTAUT) VALUE('*USE') CRTLIB LIB(MYLIB) CRTAUT(*SYSVAL) CRTDTAARA DTAARA(MYLIB/MYDTAARA) ... AUT(*LIBCRTAUT)
The Create Data Area (CRTDTAARA) command looks up the library's CRTAUT parameter, which is *SYSVAL. This makes the system look up system value QCRTAUT, where it finds *USE. The net result is that the public authority for the data area is *USE.
Initially, QCRTAUT has the value *CHANGE. This default value is good in most cases, so you really should think twice before you change it.
When a user signs on to a display station and walks away without signing off, the display station is ready for use by anyone who happens to walk by. This situation poses a security risk. The severity of this risk depends on the security classification and authorities of the user who signed on.
Consider what would happen if QSECOFR, who can do everything, left a display station unattended. Anyone would be able to do anything from that display station! If you want to keep security tight on your system, you must control these unattended display stations.
System value QINACTITV determines how long a display station is allowed to remain inactive (no function keys or Enter pressed). When the specified time interval (in minutes) passes, the system takes an action that is controlled by system value QINACTMSGO.
The QINACTITV system value will not affect workstations that are signed on to remote systems via pass-through or TELNET. If a local workstation is signed on to a remote system using either of these options, it will be ignored and the session will remain intact as long as the workstation is signed onto the remote system.
QINACTMSGQ can contain the qualified name of a message queue. In this case, the system sends a message to that message queue. QINACTMSGQ can also have two special values: *ENDJOB and *DSCJOB. If you choose *ENDJOB, the system ends the interactive job of the inactive display station (i.e., the system signs it off automatically). If you choose *DSCJOB, the system disconnects the display station. Here is an example:
CHGSYSVAL SYSVAL(QINACTITV) VALUE('30') CHGSYSVAL SYSVAL(QINATCMSGQ) VALUE('*DSCJOB')
Using these settings, the system waits 30 minutes for the user to press a function key or Enter. If the user doesn't do so, the system disconnects the display station and shows the sign-on display. A message appears at the bottom, saying that user QSYS disconnected the job. When the user returns, he will have to enter the user profile name and password again, but the system will take the user back to where he left off, with everything intact.
You should consider activating this feature using the *DSCJOB option. All things considered, the message queue alone does not give you much security (the display station remains signed on, although there are complicated ways in which you can improve on this). On the other hand, the *ENDJOB option seems too harsh and can result in lost data if the user was in the middle of a complicated transaction when he went on a coffee break.
An additional system value, QDSCJOBITV, controls how long a job can remain disconnected before the system ends it. You can use this system value in conjunction with the *DSCJOB option to follow-up on jobs the system disconnected for being inactive. For example, you can set QDSCJOBITV to 60 minutes:
CHGSYSVAL SYSVAL(QDSCJOBITV) VALUE('60')
Several system values control passwords. These system values are:
QPWDEXPITV controls how long (in days) the user can keep his password without being forced to change it. It defaults to *NOMAX, which means that the system doesn't care how long the duration is. You should consider setting this system value to a value no greater than 90, although 30 might be safer.
QPWDMINLEN and QPWDMAXLEN control the minimum and maximum lengths allowed for a password. When the system is shipped to you, these system values are set to 1 and 10, respectively. Passwords that consist of a single character are not very difficult to guess. Consider changing QPWDMINLEN to at least four or five.
QPWDLMTAJC can be set to ‘1’ if you don't want your users to have passwords with more than one digit in a row.
QPWDLMTCHR can contain a string of characters. None of the characters in the string will be allowed in passwords. For example, if you set QPWDLMTCHR to ‘DOG,’ passwords will not be allowed to contain the letters D, O, or G.
QPWDLMTREP won't allow repeated characters in a password if you set it to ‘1.’ This prevents users from using easily guessed passwords such as xxxx.
QPWDPOSDIF can be set to ‘1’ if you do not want users to change to a new password with characters in the same position as the old one. Each character in the new password must differ from the same positional character in the old one. For example, if the user has a password of BUTTERFLY, it cannot be changed to HATCHET because both passwords have a ‘T’ in the third position.
QPWDRQDDGT forces the user to use at least one digit (0 to 9) in the password. Passwords containing digits are less likely to be guessed using a dictionary attack.
QPWDRQDDIF forbids the user to reuse passwords. The system keeps track of the last 32 passwords each user has had. Users can begin recycling passwords after the 32nd password.
QPWDVLDPGM can contain the qualified name of a program that you can create to perform additional validation checking on new passwords, if the password is being changed using the Change Password (CHGPWD) command.
The system also has a few system values that control signing on. These system values provide an additional layer of security, and you should consider implementing them.
QDSPSGNINF, when set to ‘1,’ displays a panel each time a user signs on. This panel informs the user the last time he signed on, and whether there have been any invalid sign-on attempts using his user profile name. This panel is useful when you suspect someone is signing on using your name. You can activate this feature at the user profile level, so some users get the information panel and others do not. Change the user profile with DSPSGNINF(*YES). If you choose *SYSVAL, the system uses this system value to determine whether or not to display the panel.
QLMTDEVSSN can be set to ‘1’ if you don't want your users to be able to sign on to more than one display station. This can discourage users from leaving their own terminals signed on, but it can also prevent a user from signing on to another display station when there is a legitimate need for it.
QLMTSECOFR can be set to ‘1’ if you want to restrict qsecofr and other privileged users to only sign on to the system console and other predefined devices. It's a good idea to leave this system value with its default value of ‘0’ so that qsecofr can sign on anywhere, unless you have a compelling need to limit which devices privileged users may access.
QMAXSIGN indicates how many times a user is allowed to make mistakes during sign-on. This system value is originally set to 15, which is exceedingly high. This value offers ample chance for someone to try to sign on by guessing someone else's password. You should consider reducing this value to five attempts (at most). A value of three is even better.
QMAXSGNACN controls what happens when the maximum number of invalid sign-ons (indicated by QMAXSIGN) is reached. A value of ‘1’ varies off the display station. A value of ‘2’ disables the user profile. A value of ‘3’ does both. In environments where most users access the system through virtual devices such as client access, option ‘2’ is recommended.
A value of ‘1’ is dangerous when your i5 is in a restricted state (dedicated) and only the system console is varied on. If you make mistakes when signing on, you may lose the system console and be forced to IPL the system to regain it. Using a value of ‘2’ is safer.