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.
- 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)
- *ALLOBJ and *SECADM
- Journal Entry:
- Before changing on a production system, read appropriate section on migrating from one level to another.
Levels of security
- No system-enforced security Note: You cannot set the system value QSECURITY to security level 10.
- Sign-on security
- Sign-on and resource security
- Sign-on and resource security; integrity protection
- 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:
|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.||Yes1||Yes1||Yes1||Yes1|
|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 2|
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.
- All-object special authority gives a user authority to perform all operations on objects.
- Audit special authority allows a user to define the auditing characteristics of the system, objects, and system users.
- System configuration special authority allows a user to configure input and output devices on the system.
- Job control special authority allows a user to control batch jobs and printing on the system.
- Save system special authority allows a user to save and restore objects.
- Security administrator special authority allows a user to work with user profiles on the system.
- Service special authority allows a user to perform software service functions on the system.
- Spool control special authority allows unrestricted control of batch jobs and output queues on the system.
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.
|*ALLOBJ||All||10 or 20||10 or 20||10 or 20||10 or 20|
|*JOBCTL||All||10 or 20||10 or 20||All|
|*SAVSYS||All||10 or 20||10 or 20||All||10 or 20|
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.