SecureMyi.com Security and Systems Management Newsletter for the IBM i                 February 27, 2013 - Vol 3, Issue 24
Live Online Training from The 400 School
Powertech - Control of your Powerful Users



Is Your JD EDWARDS Database Secure? See how SKYVIEW PARTNERS can help!



Cilasoft Security Solutions - Intelligently Engineered Security Solutions















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 Author

Dan 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.

Dan Riehl on LinkedIn





 
Training from The 400 School