Using System Security (QSecurity) system value

You can choose how much security you want the system to enforce by setting the security level (QSECURITY) system value.

Overview

Purpose:: Specify level of security to be enforced on the system.
How To:: WRKSYSVAL *SEC (Work with System Values command) or Menu SETUP, option 1 (Change System Options)
Authority:: *ALLOBJ and *SECADM
Journal Entry:: SV
Note:: Before changing on a production system, read appropriate section on migrating from one level to another.

Levels of security

The system offers five levels of security:

10: No system-enforced security
Note: You cannot set the system value QSECURITY to security level 10.
20: Sign-on security
30: Sign-on and resource security
40: Sign-on and resource security; integrity protection
50: Sign-on and resource security; enhanced integrity protection.

Your system is shipped at level 40, which provides sign-on and resource security and provides integrity protection. For more information, see Security level 40.

If you want to change the security level, use the Work with System Values (WRKSYSVAL) command. The minimum security level you should use is 40. Security level 40 and 50 provide the system integrity protection required to run a secure server. Security levels 30 and below do not provide the integrity protection required for a secure operating environment. The change takes effect the next time you perform an initial program load (IPL). Table 1 compares the levels of security on the system:

Table 1. Security levels: function comparison
Function	Level 20	Level 30	Level 40	Level 50
User name required to sign on.	Yes	Yes	Yes	Yes
Password required to sign on.	Yes	Yes	Yes	Yes
Password security active.	Yes	Yes	Yes	Yes
Menu and initial program security active.	Yes¹	Yes¹	Yes¹	Yes¹
Limit capabilities support active.	Yes	Yes	Yes	Yes
Resource security active.	No	Yes	Yes	Yes
Direct access to all objects using object address.	Yes	No	No	No
User profile created automatically.	No	No	No	No
Security auditing capabilities available.	Yes	Yes	Yes	Yes
Programs that contain restricted instructions cannot be created or recompiled.	Yes	Yes	Yes	Yes
Programs that use unsupported interfaces fail at run time.	No	No	Yes	Yes
Enhanced hardware storage protection is enforced for all storage.	No	No	Yes	Yes
Library QTEMP is a temporary object.	No	No	No	No
USRSPC, USRIDX, and *USRQ objects can be created only in libraries specified in the QALWUSRDMN system value.	Yes	Yes	Yes	Yes
Pointers used in parameters are validated for user domain programs running in system state.	No	No	Yes	Yes
Message handling rules are enforced between system and user state programs.	No	No	No	Yes
A program’s associated space cannot be directly modified.	No	No	Yes	Yes
Internal control blocks are protected.	No	No	Yes	Yes ²
¹ When LMTCPB(*YES) is specified in the user profile. ² At level 50, more protection of internal control blocks is enforced than at level 40. See Preventing modification of internal control blocks.

Default special authorities

The system security level determines what the default special authorities are for each user class. When you create a user profile, you can select special authorities based on the user class. Special authorities are also added and removed from user profiles when you change security levels.

These special authorities can be specified for a user:

*ALLOBJ: All-object special authority gives a user authority to perform all operations on objects.
*AUDIT: Audit special authority allows a user to define the auditing characteristics of the system, objects, and system users.
*IOSYSCFG: System configuration special authority allows a user to configure input and output devices on the system.
*JOBCTL: Job control special authority allows a user to control batch jobs and printing on the system.
*SAVSYS: Save system special authority allows a user to save and restore objects.
*SECADM: Security administrator special authority allows a user to work with user profiles on the system.
*SERVICE: Service special authority allows a user to perform software service functions on the system.
*SPLCTL: Spool control special authority allows unrestricted control of batch jobs and output queues on the system.

You can also restrict users with *SECADM and *ALLOBJ authorities from changing this security related system value with the CHGSYSVAL command. You can specify this restriction in the System Service Tools (SST) with the "Work with system security" option.

Note: This restriction applies to several other system values.

For details on how to restrict changes to security system values and a complete list of the affected system values, see Security system values.

Table 2 shows the default special authorities for each user class. The entries indicate that the authority is given at security levels 10 and 20 only, at all security levels, or not at all.

Table 2. Default special authorities for user classes by security level
Special authority	User classes
Special authority	*SECOFR	*SECADM	*PGMR	*SYSOPR	*USER
*ALLOBJ	All	10 or 20	10 or 20	10 or 20	10 or 20
*AUDIT	All
*IOSYSCFG	All
*JOBCTL	All	10 or 20	10 or 20	All
*SAVSYS	All	10 or 20	10 or 20	All	10 or 20
*SECADM	All	All
*SERVICE	All
*SPLCTL	All

Note: The topics User class and Special authority provide more information about user classes and special authorities.

Considerations

At security level 30 the system does not automatically give users access to all resources. At lower security levels, all users are given *ALLOBJ special authority.

Security level 30 is not a secure level to run your production system. At security level 30 and below, users can directly call system level interfaces that are not intended to be directly called by user applications. In addition, user applications can access internal control blocks and object contents directly using an address. This is a security and integrity exposure. At security level 30, the integrity protection mechanisms are not activated to the same level as security level 40 and 50. Therefore, security level 40 or higher is strongly recommended.

Security level 40 and 50 provide significant integrity protection that is not available on security level 30 and below. To run a secure server, you must run at security level 40 or 50. Security level 40 and 50 are similar in capabilities. This was not always the case but, over time, the capabilities that were initially available in security level 50 have been moved into the security level 40 support. There are still some differences between 40 and 50. The differences are mostly internal processing of buffers and control blocks plus the restrictions on how messages can be sent within a job, see Restricting message handling. Running security level 50 provides the most secure level to run your server.