V5R2 Security System Value Lock

April 14, 2004 Hey, Wayne

Editor’s Note: Security questions for the Four Hundred Guru are now being answered by Wayne O. Evans, one of the top OS/400 security experts in the world. Wayne designed security features on the AS/400 and S/38 during his 27 years at IBM and is a well-known and highly respected consultant, author, educator, and speaker. His security tips will become a regular item in Guru newsletters.

The security reference manual for OS/400 V5R2 says, “New for V5R2, you can restrict users from changing several security-related system values. These restrictions can prevent even a user with *SECADM and *ALLOBJ authority from changing these system values with the CHGSYSVAL command.” Why are users with *SECADM and *ALLOBJ authority prevented from changing security-related system values with the CHGSYSVAL command?

What is the risk if users change any security system value with CHGSYSVAL? If I use this feature, what’s the proper way to change security system values?

–John

Some computer systems go through a major system configuration, often called sysgen (system generation), in which the system administrator determines what features should be installed in the operating system. This often involves compiling and linking programs. On large IBM mainframes, this is often a major process that takes two to four hours and has to be done each time a new release is installed. The programs are added and removed from the operating system to create the “system image,” a collection of programs that represent the features the administrator wants to use, such as which database management system or which security product. The sysgen can be a very lengthy process because the individual components often come from different vendors. In fact, the installation needs to “purchase” the individual pieces (like database, security product, communications software). There are many combinations possible, and not every combination can be tested to be sure that the software is compatible (uses the same interfaces and provides equivalent function).

Contrast this with OS/400. One vendor, IBM, provides the OS/400 operating system. (That is why OS/400 is said to be a closed system.) System administrators do not need to go through a lengthy sysgen process to add and remove programs. The programs are always there in OS/400. If the programs are the same in all OS/400 installations at the same release level, then how do system managers configure OS/400 to run for their company?

You probably guessed the answer already. System managers customize the version of OS/400 for their organization by setting system values. With this understanding you can get a better appreciation for the importance of system values. System values represent how the system is configured for the installation.

Let’s focus on just one system value: QSECURITY. Changing this system value has a dramatic impact on the way OS/400 secures a system.

SECURITY LAYERS

Multiple protection layers often describe good security. The protection layers for the change of system values are:

1. Authorized user on the system.

2. Authorized to CHGSYSVAL command.

3. *ALLOBJ and *SECADM special authority.

4. Service Lock = *YES. (new in V5R2)

5. Change system value.

The user must be able to sign on and be authorized to the CHGSYSVAL command. For the security system values, the user must also have *ALLOBJ and *SECADM special authority. With V5R2, there is the additional protection that the service lock must be *YES. Then, and only then, can the system value be changed.

There is actually another layer that I did not show. The value must be one of those allowed for the system value.

The change to the service lock would have a similar protection diagram, which I will leave as an exercise for you readers.

V5R2 ADDS PROTECTION

A user with Security Administrator (*SECADM) and All Object (*ALLOBJ) special authorities can alter security system values. Because setting the system values can have such a major impact, system administrators do not want to trust just any user with *ALLOBJ and *SECADM special authority. There are often too many of these users on the system.

In V5R2, IBM gave system administrators an option to require something extra to change security system values. This sounds like a system configuration option or system value. But IBM was not stupid, so rather than create a system value to control other system values, it made a DST option.

The answer to your final question, how to change system values, is just like before: use the CHGSYSVAL command. However I hope that after you get security set correctly, you take advantage of the new V5R2 support to lock security-related system values.

The following information from IBM’s manuals on systems management and security (in PDF format) is included here so you have a complete understanding of this support.

LOCK AND UNLOCK SECURITY-RELATED SYSTEM VALUES

System service tools (SST) and dedicated service tools (DST) provide an option that allows you to prevent changes to a variety of security related system values. When the “allow change of security related system values” service tools option is set to no, the system values can’t be changed using the Change System Value (CHGSYSVAL) command (or any other user interface). Setting this option to no is useful if, for example, you have settings for security level (QSECURITY). Selecting no for this option ensures that applications can’t change these system value settings.

HOW TO LOCK THE LOCK

You must have a service tool profile and password to lock or unlock the security-related system values. This ensures that not just every user with *ALLOBJ and *SECADM can change the lock. To lock or unlock security-related system values with the Start System Service Tools (STRSST) command, follow these steps:

1. Open a character-based interface.

2. On the command line, type STRSST.

3. Type your user name and password.

4. Select option 7 (“work with system security”).

5. Type 1 to unlock security-related system values, or 2 to lock security-related system values in “allow security system value changes.”

SYSTEM VALUES LOCKED BY V5R2 FUNCTION

The following table identifies the system values that are affected by this option.

Lockable system values:

–Wayne O. Evans

Security articles authored by Wayne O. Evans can be found on his Web site, www.woevans.com. E-mail: woevans@aol.com