SirSafe

SirSafe integrates the file security and access control mechanisms employed by Model 204 with the native facilities of MVS (OS/390 and z/OS). SirSafe addresses several potential security exposures, while providing significant improvements in usability for large scale environments. SirSafe allows Model 204 to continue to use its proprietary security mechanisms to manage access to the information contained in database files, preserving its rich set of security controls. In addition to improving security, the tight integration of SirSafe with modern MVS facilities enables support of read-only files, and it simplifies file sharing among members of a sysplex.

Overview

SirSafe functions as a layer on top of Model 204, using the System Authorization Facility (SAF) to control access to individual Model 204 file and group passwords. SAF provides a standardized interface for accessing the services of a system security manager such as RACF, ACF2, or Top Secret. The Model 204 System Manager is still responsible for maintaining file and group entries in a Model 204 password table (CCASTAT). However, each user's access to particular file and group entries in the password table is controlled by a system security manager, using rules entered by a system security officer. Thus, even if a password is known to a user, that user may be prevented from gaining the access rights conferred by the password.

SirSafe can significantly improve the behavior of Model 204 in multi-system or sysplex environments. In addition, SirSafe extends the functionality of Model 204 database file security in four important ways:

• The security of data contained in Model 204 databases no longer depends upon maintaining the secrecy of file and group passwords.
• SirSafe can be configured to support read-only access to database files, preventing unintended updates while reducing the number of users requiring update access to Model 204 file data sets.
• A given file or group password can confer different privileges, depending upon the identity of the current user and the current Online, without the confusion of multiple password tables.
• Enhancements to the Model 204 SECURE command make it easier to manage security in complex, multiple online environments, while also eliminating certain security exposures.

By providing control over who can use Model 204 file and group passwords, SirSafe allows the passwords to be freely shared, without the need for periodic changes. Straightforward file and group passwords that are easy to remember, such as read, update, or sysprog, can be freely distributed and embedded in batch job streams. Security is not compromised, because SirSafe will verify access to the passwords for each user and for the submittor of batch jobs.

This is especially useful for large programming teams, where members may come and go. Without SirSafe, an ever-expanding circle of programmers become aware of key Model 204 file and group passwords, or the passwords need to be changed frequently and redistributed to those users still authorized. With SirSafe, the system security administrator would simply change the access rules for the affected user in order to grant or revoke access to the required Model 204 file and group passwords.

Model 204 database security

Model 204 enforces a sophisticated array of controls to enforce security and integrity policies for its database files. The access to each individual file is determined by fourteen independent capability bits, four separate access levels for field-level security, and a procedure class designation. The "file group" feature of Model 204 adds an additional two capability bits for each database file that is accessed as a group member. All of these controls are documented in Security.

Subsystem access rights

Most end users access applications that are formally defined to Model 204 as application subsystems, using the SUBSYSMGMT administrative tool described in Overview of the SUBSYSMGMT interface. Application subsystems are invoked from the Model 204 command level with a simple command, and then the so-called "APSY" runtime uses information saved in the CCASYS file to determine the set of files and groups that need to be opened for the application along with their appropriate access rights. Users of application subsystems are not prompted for file or group passwords: the subsystem definition identifies the access granted for each user, with some users getting potentially different privileges based upon their user ID.

SirSafe does not affect how APSY assigns file or group privileges. SirSafe does, however, offer the use of Model 204 subsystem maintenance commands that simplify the stopping, starting, testing, and debugging of subsystems.

Model 204 password table

Programmers and DataBase Administrators frequently use the Model 204 OPEN command to access files and groups while they are developing applications and maintaining files. The file or group access privileges granted as a result of an OPEN command depend upon the type of the file and upon the user-provided password, as follows:

Public	The end-user is not prompted for a password, and the privileges are those that were specified as the default when the file or group was created.
Semipublic	The end-user is prompted for a password. The Model 204 password table is searched for a corresponding password (for the file or group being opened), and if a match is found, the user is given the privileges from the matching entry. If a matching password is not found, the user is given the default privileges for the file, as specified when the file or group was created.
Private	The end-user is prompted for a password. The Model 204 password table is searched for a corresponding password (for the file or group being opened), and if a match is found, the user is given the privileges from the matching entry. Otherwise the OPEN is rejected.

The Model 204 password table provides the ability to store multiple passwords for each file or group. A distinct set of access rights is associated with each password, so in effect the passwords become substitutes for named roles. It is the development and the file maintenance roles that present the greatest challenges, since they confer the strongest (update) privileges, and they are frequently embedded in maintenance job streams.

Model 204 password table (CCASTAT)

The Model 204 password table (maintained in the sequential file CCASTAT) is divided into three physical sections. The user ID section contains one entry for each ten-character login ID that is directly managed by Model 204 (as opposed to the IDs managed by a "security manager" like RACF or ACF2). Each user ID entry holds a one-way encrypted password and a set of login privileges. Most users of SirSafe do not use CCASTAT to manage login security; instead they typically use a formal security manager like RACF or ACF2. For more information, refer to the Model 204 security interfaces wiki pages.

The file and group sections of CCASTAT contain the various one-way encrypted passwords and the privileges they confer for Model 204 database files and groups. The two sections are physically distinct so that a file and group of the same name can have separately managed passwords. A particular file or group may have multiple entries in CCASTAT, each conferring a set of (possibly different) access rights and privileges.

The LOGCTL command is used to maintain entries in the Model 204 password table. Variants of the LOGCTL command are used to Add, Delete or Change entries in CCASTAT. The basic form of the command is:

LOGCTL {A | D | C} key

The first argument indicates the type of operation being performed. key indicates both the type of entry as well as the specific entry:

• For a file entry, key must begin with a colon (:), immediately followed by a one- to eight-character file or group name, then one or more optional blanks and a single index character. If no index character is present, a blank is assumed.
• For group entries, the format is the same as for a file entry, except the colon character is replaced by a comma (,).
• For a login entry, a key contains from one to ten alphanumeric characters.

The following example deletes the password table entry for group GARY with an index character of C, and then it adds an entry for file ALEX with index character 2:

LOGCTL D ,GARY C LOGCTL A :ALEX 2

After the second command completes, the end user is prompted to enter a password, privileges, and other access information, and a terminal mask, if any.

The three sections of the password table are maintained in the order of their ten-byte key strings. Thus all of the entries for a particular file follow each other, sorted in the order of their index character (with blank coming first, of course). The LOGFILE command is used to display the file entries in a CCASTAT, producing output like:

:ALANPROC X'0201' 0, 0, 0, 0, 0, ALL :ALANPROC A X'BFFF' 0, 0, 0, 0, 0, ALL :ALANPROC 1 X'0CCC' 0, 0, 0, 0, 0, ALL :ASDF X'BFFF' 0, 0, 0, 0, 0, ALL :BACKUP X'8761' 0, 0, 0, 0, 0, ALL

When a Semipublic or Private file or group is OPENed, the end user is prompted for a password, which is immediately one-way encrypted. Then the file or group section of CCASTAT is searched for a match on the "middle" eight characters of the key. For each file or group name match, the one-way encrypted password in the entry is compared to the one-way encrypted value of the password provided by the end-user. If they match, the privileges contained in the entry are granted to the OPEN request. Otherwise, the scan continues until all entries for the file/group have been checked.

You can see that if two or more CCASTAT entries for a file or group contain the same password, the one with the lowest index character value will be the only one ever used. The possibility of duplicate passwords, coupled with the fact that LOGFILE and LOGGRP don't display password values, can cause a great deal of confusion.

SirSafe offers LOGCTL, LOGFILE, and LOGGRP enhancements to make password table maintenance simpler. See LOGCTL enhancements for visible file/group entries and LOGFILE and LOGGRP enhancements.

SECURE and DESECURE commands

Each password table contains an encrypted eight-character key value. The LOGKEY command changes the key value from its default. The SECURE command copies the current CCASTAT key value into the current default file. Once this has been done, that file can only be opened by a copy of Model 204 using a CCASTAT with the same key value. This feature can be used to prevent a malicious user from counterfeiting a password table and using it to obtain inappropriate access to a private or semipublic Model 204 database file. Once a file has been successfully opened, the DESECURE command can be used to clear the key value from the current default file so that it can once again be opened by an Online with any CCASTAT.

Physical OPEN of Model 204 files

Under MVS, Model 204 does a physical (operating system) OPEN of its database files with the INOUT option, using the access profile of the current job. Because INOUT implies WRITE access to the file, the job's profile must allow WRITE access, or the Open will be rejected with an IEC150I message.

The INOUT option is used because a subsequent OPEN for the same file uses the already opened DCB, so the initial OPEN must allow for READ or WRITE access. While this is not typically a problem for Online jobs, it means that users running batch jobs require WRITE access to the data sets of the Model 204 database files, even if the files are opened with access privileges that do not allow updating. This can raise concerns with Sarbanes/Oxley reporting requirements.

Shared DASD enqueueing

A shared DASD configuration allows a particular DASD device to be accessed by more than one computer system or operating system instance. Shared DASD has become far more common with the advent of Logical PARtition (LPAR) support, fiber-optic (ESCON) channels with EMIF sharing between LPARs, and Sysplex clusters.

Model 204 utilizes a variety of mechanisms to serialize the access and update of database files among the various users in an online instance and between various instances of Model 204. The primary mechanism serializing database file accesses between various instances of Model 204 is the operating system ENQ and DEQ facility.

When a database file is opened, Model 204 enqueues upon a resource name comprising the database file name, the volume serial for the first (or only) data set of the file, and the data set name for the first data set:

filename.volser.fully_qualified_dataset_name

The strength of enqueue (share or exclusive) depends upon the access intent for the file. In order to support deadlock-free reduction in access strength, Model 204 uses three different "queue names": IFAMQA, IFAMQB, and IFAMQC.

This mechanism works well for cataloged and uncataloged data sets referenced only from one operating system instance. However, it breaks down when two instances of Model 204 running on separate systems access the same file via shared DASD. By default, the two operating system instances will not share information about the enqueues used by Model 204. Thus, two separate instances of Model 204, each running on different systems, can simultaneously hold exclusive enqueues for the same resource.

The shared DASD support in Model 204 is based upon the concept of a "Shared DASD Enqueue List." This enqueue list is a structure contained in the first page of the first (or only) data set of each database file, the File Parameter List (FPL) page. An entry is placed in a file's enqueue list for every Model 204 instance that opens the file. The entry is deleted when the file is physically closed by the instance, and the entry is updated if the instance changes its access intent for the file.

The shared DASD enqueue list is used during the Model 204 database file open process to identify conflicts with Model 204 instances running under other operating system instances. Each entry in the enqueue list contains the following information:

System name	A four-character name that identifies the system that is hosting the Model 204 instance, identified as the first field in message M204.0061. For instances running under MVS, this ID will be the SMF system ID, set by the parameter SID in a SMFPRMxx parmlib member. For instances running under CMS, this ID will be CMS.
Access intent	This is EXCL when a file is opened for update; otherwise, it is SHR.
Job name	For most operating systems, this is the job name of the Model 204 instance. For instances of Model 204 running under CMS, it is the ID of the Model 204 virtual machine.
Step name	For most operating systems, this is the step name of the Model 204 instance. For instances of Model 204 running under CMS, it is the six-character CPU serial number padded on the right with two blanks.
Date/Time	The date and time when the entry was added or last updated.

The open logic also removes obsolete enqueue entries that were established, but no longer needed, by Model 204 instances executing under the current operating system instance. Obsolete entries can result from system crashes, x22 ABENDs, and other infrequent (but ordinary) events. The following logic is used:

1. Standard operating system ENQ/DEQ logic is used to enqueue upon the specific database file. If the enqueue fails, the open is rejected with file is in use.
2. A hardware RESERVE is placed upon the volume containing the FPL page. This prevents other systems from accessing the device and potentially changing the enqueue list.
3. The FPL is read and the shared DASD enqueue list is scanned for a conflict with the access being requested by the current open.
   1. If an entry is found that conflicts with our access, but the entry was established by a Model 204 instance under our system, delete the entry because it is obsolete. We know the entry is obsolete because the standard ENQ/DEQ mechanism under our operating system gave us the requested access.
   2. If a conflicting entry was established under a different operating system instance, reject the open with M204.0582 access prevented by and M204.0584 file is in use messages.
   3. If all entries are processed with no current conflict, then add an entry for our requested access, and write the FPL back out to disk.
4. Release the hardware RESERVE on the volume containing the FPL page.

If an Open request is prevented by an obsolete entry from a different operating system instance, the Model 204 ENQCTL command can be used to clear out the offending entry. If ENQCTL is used to delete a non-obsolete entry, then an M204.0585 list overlaid message results when the file is closed on the system whose entry was deleted.

SirSafe topics

The SirSafe documentation consists of the pages listed below. This list is also available as a "See also" link from each of the pages.

For information about product changes and Model 204 feature support per SirSafe version, see the RKTools release notes.

For information about product error messages, see MSIR. messages.

• SirSafe
• SirSafe control of access to passwords
• SirSafe support for read-only files under MVS
• SirSafe enhanced shared DASD enqueueing
• SirSafe command and function reference
• SirSafe SIRENQ utility