Transcript Lesson 3 - Operating Systems Security

Introduction to z/OS Security
Lesson 3: Operating Systems Security
© 2006 IBM Corporation
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.
© 2006 IBM Corporation
Key Terms
 APF-authorized
 Application Security
 Supervisor state
 LNKLST Libraries
 Dynamic format
 Started Task Security
 System integrity
 User Attribute Dataset
 Execute-controlled programs
 Operator command security
 Tape Volume Security
© 2006 IBM Corporation
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.
© 2006 IBM Corporation
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.
© 2006 IBM Corporation
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.
© 2006 IBM Corporation
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.
© 2006 IBM Corporation
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).
© 2006 IBM Corporation
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.
© 2006 IBM Corporation
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.
© 2006 IBM Corporation
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..
© 2006 IBM Corporation
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
© 2006 IBM Corporation
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.
© 2006 IBM Corporation
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.
© 2006 IBM Corporation
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.
© 2006 IBM Corporation
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
© 2006 IBM Corporation
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
© 2006 IBM Corporation
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
© 2006 IBM Corporation
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.
© 2006 IBM Corporation