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 30. However, level 40 or higher is recommended. 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
Access to all objects.	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

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

At security level 30 (or below), users can call system interfaces that exchange to QSECOFR user profile or allow users access to resources that they are not normally allowed to access. At security level 40, users are not allowed to directly call these interfaces. Therefore, security level 40 or higher is strongly recommended.

Security level 40 provides additional integrity protection without affecting system performance. Applications that do not run at security level 40 have a negative effect on performance at security level 30. They cause the system to respond to domain violations.

Security level 50 is intended for systems with very high security requirements. If you run your system at security level 50, you might notice some performance effect because of the additional checking that the system performs.

Even if you want to give all users access to all information, consider running your system at security level 30. You can use the public authority capability to give users access to information. Using security level 30 from the beginning gives you the flexibility of securing a few critical resources when you need to without having to test all of your applications again.