Introduction to z/OS Security Lesson 3: Operating Systems Security

1. Introduction to z/OS SecurityLesson 3: Operating Systems Security

2. Objectives • The integrity of a z/OS system is more than protecting data sets, it also provides the ability to restrict which programs can enter states to exercise hardware instructions • After this chapter you will be able to: • Explain the importance of maintaining system integrity • Explain the importance of protection of operating system components • Explain the importance of protecting application libraries. • Discuss the User Access Dataset used by TSO/e • Discuss different types of resources that are secured on z/OS • Discuss what makes a program authorized • Discuss the security events that z/OS logs, and the mechanics of retrieving the log records.

3. APF-authorized Supervisor state Dynamic format System integrity Execute-controlled programs Operator command security Application Security LNKLST Libraries Started Task Security User Attribute Dataset Tape Volume Security Key Terms

4. z/OS System Integrity • System integrity is the ability of an operating system to prevent the circumvention or bypassing of its security, auditing, or accounting controls by any program, or person not authorized to do so. • Therein lies the issue, allowing authorized persons and programs to bypass these controls while simultaneously restricting that ability to those unauthorized. • An operating system has system integrity when: • it is designed, implemented and maintained to ensure that unauthorized users and unauthorized programs cannot bypass the functions that protect other users or programs, • applications cannot obtain control in an authorized execution state, and cannot bypass the system-level security functions.

5. z/OS Resource Security • Your company’s critical data needs to be securely managed and controlled. It would be catastrophic for a competitor to obtain your company’s confidential files. You must take precautions to protect your information assets. • Security policies and standards are concerned with the safeguarding of various types of resources. • Any entity on the z/OS system is considered a “resource”. These resources are protected through several mechanisms.

6. Data Set Security • A dataset is a collection of logically related data records stored on a volume. There is a profile associated with a dataset that contains information regarding the owner of the dataset, the dataset name, list of users and groups that have access to the dataset and auditing capabilities to the dataset. • When you try to access a dataset z/OS will check both the level of dataset authorization allowed as well as the access list for the dataset to determine if you are authorized to the perform the function that you are requesting.

7. Data Set Security • Making data secure on z/OS platforms involves not only protection of data from unauthorized access, but equally important, it protects from inadvertent destruction of datasets or files. • Datasets can be protected by controlling who has access to them and what access the individuals or groups have.

8. User Attribute Data Set • One of the important system datasets that must be considered when you are planning or reviewing the protection and integrity of your z/OS system is the User Attribute Data Set (SYS1.UADS). SYS1.UADS is now an optional dataset for user authentication, but it is still required by TSO/E. • z/OS must maintain a user entry with information for the system default user (for RACF, this is always called IBMUSER).

9. User Attribute Data Set • It also is recommended to have an entry in the SYS1.UADS dataset for the system programmers. This ensures that in case the security database becomes corrupted and unavailable, certain eligible users will still be able to logon to TSO. • When the External Security Manager is not active, the system checks SYS1.UADS to determine who is authorized to logon to the system. This dataset will ensure that if there was a catastrophe where the security database at the bank’s z/OS environment was corrupted, we would still be able to have our system programmer log on to the system.

10. Program Control • The protection of the load libraries and the programs in those libraries. As you may recall, a load library is a library that contains programs that are ready to be executed. • Program Control will allow the execution of a given program only if that program resides is specific load libraries. • Program protection operates differently than dataset or general resource protection. • Programs in interpreted languages such as CLIST or JAVA cannot be protected with program protection.

11. Program Control Program Control • Controlling who can execute programs is as important as protecting the data itself. • Program Control Functions: • Simple Controls to restrict the ability to execute specified programs • Complex controls that can prevent users from copying sensitive programs or viewing the contents of such programs • Improved resistance to attacks by requiring that the program execution environments for UNIX daemons and servers remain clean. Execution will be denied if the environment had ever executed an unauthorized program. • Program access to data sets (PADS) to allow users to have more access to data sets than they would otherwise have • Program access to SERVAUTH resources to allow access to IP addresses only when executing certain programs..

12. Operator command security • Protection of the operator consoles is often performed by isolating the consoles in the locked datacenter area. This provides limited access to the consoles. In addition to this physical protection of the consoles, it is also necessary to protect the commands that are entered at the consoles. • In a sysplex environment, commands entered from one console can affect processing on another system. To protect commands issued at a console, the operator must be logged on to the console. Command protection can be controlled using the LOGON parameter in the CONSOLxx member of parmlib. • Users can issue operator commands through SDSF, so direct physical access to the console is not strictly required. • Some commands may be used by anyone: display • Some commands may be strictly controlled: quiesce

13. Tape volume security • Tapes are usually considered for backup and archiving of data since tapes are typically less expensive than Direct Access Storage Devices (DASD) and are easier to store • In today’s z/OS computing environment, the main storage media for data is DASD. There are some differences with tape volume security. • Datasets on tapes can not be protected individually. Protection is provided by entire tape volume security. For example, if one dataset on the tape is classified as confidential, the entire tape volume will be classified as confidential. • Special consideration is necessary when processing foreign tapes. A foreign tape is a tape that has been received from an outside source. An example of a foreign tape would be a product installation tape from a vendor.

14. Started Task Security • Started tasks are system jobs that are brought up at system initialization time or kicked off at any time by an operator or by anyone who has the authority to issue the START command. • Daemons such as LDAP, FTPD, and the HTTP Server are started tasks on z/OS. When a job is submitted on the system, it requires a user ID and password to validate that the user is authorized to submit jobs. • Normally, jobs submitted to z/OS inherit the security context of the submitting user. That is to say that the user ID that asked that the program be executed must have all the rights and privileges that the programs requires. • Started tasks are different in that they are initiated by an operator command. Since all address spaces require a security context, and a started task doesn’t inherit one, one must be derived from system configuration settings.

15. Application Security • Applications may use system-supplied security services that are available with your ESM or they may supply their own to protect access. Application security can be used as an enhancement to the ESM security. • In addition to application program security, you can also use your ESM for authorization checking. It is also recommended that you protect access to applications. The level of protection would need to be determined by the application personnel and policies would need to be in place. • Your ESM can be used to allow a user to access a specific application. When a user logs on to an application, the application can specify that your ESM should check if the user is authorized to use the application.

16. The Authorized Program Facility • APF Privileges • System libraries • There are certain libraries in z/OS that are considered authorized libraries. SYS1.LINKLIB, the library that contains many of the basic execution modules of the system, is always APF authorized. Your installation can specify the remaining entries in the APF list. • The APF List denotes those program libraries (datasets) where programs intending to issue privileged instructions must reside. This list is managed in the PARMLIB concatenation in the PROGxx member. • The LNKLST concatenation • Analogous to a PATH • Where z/OS looks for applications

17. The Authorized Program Facility • Programs from APF authorized libraries, if linked with authorization code 1, will not fail if they attempt to execute privileged instructions. • Since any user can link AC(1), it is essential to protect the libraries. • An APF authorized program can • put itself into supervisor state or a system key. • modify system control blocks. • execute privileged instructions (after becoming supervisor state). • turn off logging to cover its tracks

18. Event Logging • System Management facility • System management facilities (SMF) collects and records system and job-related information that your installation can use in: • Billing users • Reporting reliability • Analyzing the configuration • Scheduling jobs • Summarizing direct access volume activity • Evaluating data set activity • Profiling system resource use • Maintaining system security

19. Summary • An operating system is said to have system integrity when it is designed, implemented and maintained to protect itself against unauthorized access, and does so to ensure that security controls specified for that system cannot be compromised. • Specifically for z/OS, this means that there should be no way for an unauthorized program to do the following: • Obtain control in an authorized state • Bypass password, or External Security Manager security checking • It is up to the installation to determine what security is required for the system. • SAF provides a central control point. • ESM maintains the classes, profiles, and access control lists.