SecureMyi.com Security and Systems Management Newsletter for the IBM i February 27, 2013 - Vol 3, Issue 24
Security Related System Values - Lock Out Changes!
By Dan Riehl
The numerous System Values on the IBM i are the main controlling system settings that determine how your system operates. For example, the System Value QCRTAUT determines what the default *PUBLIC authority will be for newly created objects. The System Value QALWOBJRST determines if there are any restrictions on the programs and service programs that can be restored onto the system. The System Values QTIME and QDATE store the current system time and date respectively.
When you aren't the only one at your company who has security officer privileges or high levels of authority, one of these other powerful users can change the settings stored in these System Values. In one particular "real life" example, an unwise change to the QCRTAUT System Value caused the system to assign incorrect *PUBLIC authority settings to newly created objects, leaving them open to abuse.
In order to protect these high-impact, Security-related System Values, IBM has provided a Lock/Unlock mechanism that's available through System Service Tools (STRSST).
In order to access the Lock/Unlock setting, a user must have *SERVICE special authority and a powerful Service Tools User ID and Password. These Service Tools User IDs and Passwords aren't the same as the operating system User IDs and Passwords. These are special Service Tools User IDs, like 11111111, 22222222 and, yes, QSECOFR. But the Service Tools user QSECOFR is a different user than the operating system's QSECOFR user profile, typically with a different, and case sensitive, password.
To access the System Values Lock/Unlock function, enter the command Start System Service Tools (STRSST) and, when prompted, enter QSECOFR as the User ID and supply the QSECOFR SST Password. You are then presented with the System Service Tools menu. (Note: If you have created other powerful Service Tools User IDs, similar to QSECOFR, you can optionally log into Service Tools using one of these.)
When you Log in to SST, you are then presented with the System Service Tools menu as shown here.
System Service Tools (SST) Select one of the following: 1. Start a service tool 2. Work with active service tools 3. Work with disk units 4. Work with diskette data recovery 5. Work with system partitions 6. Work with system capacity 7. Work with system security 8. Work with service tools user IDs and Devices Selection 7 F3=Exit F10=Command entry F12=Cancel
Selected menu option 7 to Work with System Security. The following screen is then shown.
Work with System Security System: MYSYSTEM Type choices, press Enter. Allow system value security changes . . . . . 2 1=Yes, 2=No Allow new digital certificates . . . . . . . 1 1=Yes, 2=No Allow a service tools user ID with a default and expired password to change its own password . . . . . . . . . . . . . . 1 1=Yes, 2=No
To Lock the Security-related System Values from modification, enter option 2 in the option to "Allow system value security changes," and press ENTER.
Specifying option 2 will prohibit anyone, even QSECOFR, from making changes to the Security-related System Values.
What System Values are Protected from Modification?
You obviously can't restrict changes to all System Values by all users. That would prevent the date from changing at midnight and prevent the time from changing during the day. The system also adjusts memory pools all during the day, which causes changes to storage allocation System Values such as QBASPOOL.
In IBM i 6.1, the following System Values are locked by the SST Lock/Unlock function:
QALWJOBITP QCRTOBJAUD QPWDEXPWRN QALWOBJRST QDEVRCYACN QPWDLMTAJC QALWUSRDMN QDSCJOBITV QPWDLMTCHR QAUDCTL QDSPSGNINF QPWDLMTREP QAUDENACN QFRCCVNRST QPWDLVL QAUDFRCLVL QINACTMSGQ QPWDMAXLEN QAUDLVL QLMTDEVSSN QPWDMINLEN QAUDLVL2 QLMTSECOFR QPWDPOSDIF QAUTOCFG QMAXSGNACN QPWDRQDDGT QAUTORMT QMAXSIGN QPWDRQDDIF QAUTOVRT QPWDCHGBLK QPWDRULES QCRTAUT QPWDEXPITV QPWDVLDPGM QRETSVRSEC QSCANFSCTL QSSLCSLCTL QRMTSIGN QSECURITY QSSLPCL QRMTSRVATR QSHRMEMCTL QUSEADPAUT QSCANFS QSSLCSL QVFYOBJRST
If you need to restrict changes to additional System Values, you can attempt to restrict access to the CHGSYSVAL command itself. But if your technicians have high levels of authority, restricting the use of the CHGSYSVAL command isn't effective in preventing changes to the System Values that aren't listed above.
I strongly encourage you to set the Security System Value Lock in SST. If a protected System Value must be changed, it should only be done with the administrator's approval. In that case, the lock can be temporarily removed and the System Value changed. Once the System Value is changed, the lock can be reset by the administrator.
It's Just Too Much Trouble
I have heard some folks refuse to set the SST lock on System Values because it could possibly cause an extra step during a Restore operation. Since the System Value QALWOBJRST can be Locked into a secure setting of *NONE, programs that adopt authority or have other security sensitive attributes cannot be restored.
This is one of the Main Reasons to TURN ON the SST System Values Lock!!! I do not want any adopting programs, or other programs that have security sensitive attributes restored onto my system, unless I know about it. The QALWOBJRST System Value setting of *NONE helps protect your system from installing potentially rogue programs that have integrity problems, cause domain violations, and potentially adopt the authority of a powerful user like QSECOFR.
If you need to restore a program that adopts authority, which is sometimes the case, simply unlock the SST lock, Set the QALWOBJRST system value to *ALWPGMADP(Allow restore of Adopting Programs), do the Restore operation, Reset the QALWOBJRST System Value to *NONE, and then reset the SST Lock.
From an operational perspective it's not a Big Deal to set and reset the SST Lock. It takes only a few seconds. But from a security perspective, locking the security related System Values is a REALLY BIG DEAL.
About the AuthorDan Riehl is the Editor of the SecureMyi Security Newsletter and a Security Specialist for
the IT Security and Compliance Group, LLC.
Dan performs IBM i security assessments and provides security consulting, remediation, forensic evaluations, and other customized security services for his clients. He also provides training in all aspects of IBM i security and other technical areas through The 400 School, Inc.