One of the most important system values is the security level, which is controlled with the security system value QSECURITY. The System i family is shipped with the system security level set to 40.
Security level 40
We recommend that you have a security level of 40 or higher on your system.
The following requirements are inherited from security levels 20 and 30:
Both the user ID and password are required to sign on.
Only someone with *SECADM special authority can create user profiles.
The limit capabilities value specified in the user profile is enforced.
Important: If you are going to change your system security level, you must follow the guidelines provided in the iSeries Security Reference, SC41-5302.
User Resource
System Values
Authorization Lists Library/Directory
Individual Objects User
Profiles Job Descriptions
Group Profiles
Users must be given specific authority to use resources on the system.
Only user profiles created with the *SECOFR user class are given *ALLOBJ special authority automatically.
Security level 40 adds:
Prevention of the use of unsupported interfaces
The system prevents attempts to directly call system programs that are not documented as call-level interfaces. The system uses the domain attribute of an object and the state attribute of a program to enforce this protection.
– Domain: Every object belongs to a domain, either a *SYSTEM or *USER domain. *SYSTEM domain objects can be accessed only by *SYSTEM state programs or by *INHERIT state programs that are called by
*SYSTEM state programs.
– State: Three different program states exist: *SYSTEM, *INHERIT, and
*USER state. *USER programs can only directly access *USER domain objects. *SYSTEM domain objects can be accessed by *USER state programs by using appropriate command or application programming interface (API). The *SYSTEM and *INHERIT states are reserved for IBM-supplied programs.
Job description protection
The user that submits a job must have *USE authority to both the job description and the user profile that are specified in the job description.
Otherwise, the job fails.
No default sign-on
The i5/OS stops any attempt to sign on without a user ID and password that can be done on lower security levels.
Enhanced hardware storage protection (HSP)
Enhanced hardware storage protection allows blocks of system information to be defined as read-write, read only, or no access. The system controls how
*USER state programs access these protected blocks. Some critical system control blocks have additional hardware storage protection that makes storage read-only from any program state. Even i5/OS cannot write to this critical system control blocks without taking special steps. This is not supported on earlier B, C, and D models.
System protection of a program’s associated space
A user state program cannot directly change the associated space of a program object.
System protection of a job’s address space
A user state program cannot obtain the address for another job on the system.
System validation of parameters
The system specifically checks every parameter passed between a user state program and a system state program that is in a user domain.
Validation of program restored
When a program is created, the system calculates a validation value which is stored with the program. When the program is restored, the validation value is calculated again and compared to the validation value that is stored with the program. If the validation values does not match, the actions taken by the system are controlled by the QFRCCVNRST and QALWOBJRST system values.
Security level 50
Security level 50 was initially designed to meet the requirements defined by the U.S. Department of Defense for C2 security. In 1998, the United States and other national governments adopted a new security evaluation scheme called the Common Criteria (CC). For additional information about Common Criteria, refer to 4.1.2, “Common Criteria” on page 50.
Security level 50 provides enhanced integrity protection in addition to what is provided by security level 40. These additional security functions include:
Restricted user domain objects
The user domain object types that are restricted are:
– User space (*USRSPC) – User index (*USRIDX) – User queue (*USRQ)
The object types in a user domain can be manipulated directly without using system-provided APIs and commands. This allows a user to access an object without creating an audit record.
Note: Objects of type *PGM, *SRVPGM, and *SQLPKG can also be in the user domain. Their contents cannot be manipulated directly, and they are not affected by the restrictions.
A user must not be permitted to pass security-relevant information to another user without the ability to send an audit record. To enforce this:
– No job can get addressability to the QTEMP library for another job.
Therefore, if user domain objects are stored in the QTEMP library, they cannot be used to pass information to another user.
– To provide compatibility with existing applications that use user domain objects, you can specify additional libraries in the QALWUSRDMN system value. If your system has a high security requirement, you should allow user domain objects only in the QTEMP library.
Restricted message handling
The following rules apply to message handling at security level 50:
– Any user state program can send a message of any type to any other user state program.
– Any system state program can send a message of any type to any user or system state program.
– A user state program can send a non-exception message to any system state program.
– A user state program can send an exception type message (status, notify, or escape) to a system state program if one of the following statements is true:
• The system state program is a request processor.
• The system state program called a user state program.
– When a user state program receives a message from an external source (*EXT), any pointers in the message replacement text are removed.
Prevention of modification of internal control blocks
At security level 50, no system internal control blocks can be modified. This includes the open data path (ODP), the spaces for CL commands and programs, and the S/36 environment job control block.
4.1.2 Common Criteria
In 1998, the United States and other national governments adopted a new security evaluation scheme called the Common Criteria. Common Criteria was adopted by the International Organization for Standards (ISO) and International Electrotechnical Commission (IEC) as an international standard, ISO/IEC 15408, in 1999.
The Common Criteria (CC) Control Access Protection Profile (CAPP) defines an implementation-independent set of IT security requirements for the evaluated product. The CAPP was derived from the C2 class of the U.S. Department of
Defence (DoD) Trusted Computer System Evaluation Criteria (TCSEC). The CAPP provides security functions and assurances that are equivalent to those provided by the TCSEC. It also replaces the requirements used for C2 trusted product evaluations.
The Common Criteria evaluation has two parts:
The Protection Profile (PP) that defines the requirements specification There exists over sixty different PPs, and CAPP is one of them. You can find the Control Access Protection Profile specification on the Web at:
http://www.commoncriteriaportal.org/public/files/ppfiles/capp.pdf
The evaluation rating, Evaluation Assurance Level (EAL), which can be between 1 and 7
The rating expresses the grade of confidence that you can place on the system. The higher value is, the better the ranking is.
A system that has a certification with CAPP/EAL3 is about equivalent with the U.S. TCSEC C2 rating.
i5/OS V5R3M0 has been evaluated by the Common Criteria Evaluation and Validation Scheme (CCEVS) for EAL 4 Augmented ALC_FLR.2, CAPP. i5/OS received its certification on 10 August 2005. You can find the evaluation report for i5/OS V5R3M0 at the official Web site for the Common Criteria project at:
http://www.commoncriteriaportal.org/public/files/epfiles/ST_VID4035-VR.pdf If you want to configure your i5/OS to meet the Common Criteria security requirements, refer to Configure Your System For Common Criteria Security, SC41-5336.
For more information regarding the Common Criteria, go to:
http://www.commoncriteriaportal.org
4.1.3 Locking system values
Since V5R2, you can control whether a user can change security-related system values. You control it with the Allow system value parameter in the System Service Tool (SST) or Dedicated Service Tool (DST) settings.
You can also use the Display Security Attributes (DSPSECA) CL command to see if the security-related system values are locked.