OpenEdition MVS: RACF Meets UNIX, Part 2

By Mark S. Hahn

Reprinted with permission. ©1996 Candle Corp. All Rights Reserved.

The RACF implementation of OpenEdition MVS (OMVS) integrates UNIX And MVS, two operating systems that provide similar functions using very different methods. With the blurring of traditional boundaries, UNIX and RACF administrators need to understand each other's operating system.

Part one of this series introduced Portable Operating System Interface (POSIX) and OMVS, IBM's method of providing UNIX support under MVS. The article detailed OMVS and UNIX user, group and file definitions and their security. See Figure 1 for an overview.

Part two continues with the reporting of events that occur in both UNIX and OMVS, and how these events compare to those in MVS RACF. This comparison is important to security administrators and auditors who need to understand each system. Specific topics include the enhancements made to RACF in releases 2.2 and 2.2 to support OMVS; UNIX reporting services and the means of providing UNIX-like reports from RACF System Management Facility (SMF) records; and finally, audit points for event reporting.

INTRODUCTION

OMVS introduced several new concepts into the RACF realm. One of these was using File Security Packets (FSPs) for authorization checking instead of traditional data set profiles. These events are reported by OMVS in the same fashion as all RACF events: through SMF records.

Reporting OMVS events in SMF

Prior to RACF 2.1, IBM provided the RACF Report Writer (RACFRW) to format and report on SMF records. This traditional method is not an option for reporting on RACF records detailing OMVS events because RACFRW was functionally frozen at Version 1.9.2 prior to the debut of OMVS in RACF 2.1. IBM suggests three alternate methods: the Service Level Reporter (SLR), the SMF unload utility (IRRADU00), or DF/SORT or a comparable reporting utility reading the unformatted SMF records. Each of these has advantages depending on available products at your installation. UNIX has its own collection of reporting services which are discussed later.

OMVS event codes

RACF uses event-qualifier pairs to report on the results of user requests. For easy reference, RACF event-qualifier pairs relating to OMVS are listed in Figure 2, and appear throughout the article in the format (ee-qq). In all cases, any event ee followed by a 00 qualifier reports a successful request. Any nonzero qualifier indicates a result other than unqualified success: either a problem (failure) or an alert (warning) resulted. In MVS, RACF failure qualifier codes always retain their event code. For example, when an 02 event fails, the qualifier is an (02-qq) code.

This is not the case in OMVS, where failures may report under different event codes. In these situations, accurate interpretation of directory failures requires more than a quick look at the event and qualifier codes. This occurs most commonly when creating, renaming, or performing some other directory or file operation. Since directories and files are defined within directories, any attempt to affect them requires access to each directory in the path of the requested object. When requests fail because there is no directory access, the failure qualifiers (ee-01) reflect the failed directory requests to access the file or perform the function, not the actual function. For example, when remove directory (48-00) fails, there is no (48-01) event failure code. Instead, the user is denied access to the directory in the file path because they do not have OMVS x level authorization (28-01) or OMVS write access (29-01) to the directory that houses the directory to be deleted. These two codes, (28-01) and (29-01), are used extensively in audit events.

Notes:

1. There are, by definition, no failure qualifiers possible.
2. Unsuccessful dub attempts (38-01) and mount actions (44-qq and 45-qq) requested by a non-superuser are always logged.

RACF ENHANCEMENTS

The use of FSPs for authorization checking required a new means of setting RACF audit controls. To this end, RACF 2.1 added six support classes to the RACF Class Descriptor Table (CDT), grouped by type of service. RACF 2.2 added a seventh table entry.

Support classes have no defined profiles and set only relevant audit flag controls, similar to SETROPTS in RACE The LOGOPTIONS and AUDIT settings determine what level most events are logged to SMF by RACF and which event logs are ignored. Figure 3 shows which classes refer to the LOGOPTIONS and AUDIT settings. Support classes do not have to be active for LOGOPTIONS and AUDIT settings to be effective.

Directory events

Directories store definitions for files and other directories. User access to either search or update directory content can be controlled and audited. The FSP controls user access. The following RACF classes control auditing of directory events:

• DIRACC - controls the auditing of directory reads and writes using the LOGOPTIONS setting. A read or write authorization failure is indicated by a (29-01) code.
• DIRSRCH-checks the LOGOPTIONS parameter for auditing directory searches. A search authorization failure is indicated by a (28-01) code.

File system events

UNIX and OMVS have very robust file system collections, including the Hierarchical File System (HFS) and the Network File System (NFS). Since the file system maintains control over file access, file system events have new control settings within RACF auditing:

• FSOBJ - checks for access to files and directories. AUDIT level setting determines the logging level for the creation and deletion of file system objects. LOGOPTIONS defines the logging level for all access to file system objects, except directory searches (DIRSRCH). Audit flags set by the OMVS chaudit command are ignored if LOGOPTIONS is set to ALWAYS or NEVER, which indicates the auditor's interest in all or none of the files.
• FSSEC - audits changes to file system security objects at the level set by the LOGOPTIONS parameter.

Processes

Processes or programs in UNIX are controlled very differently than they are in MVS. Since every UNIX process has an owner, effective UID, and effective GID, resulting controls and event reporting are distinct:

• IPCOBJ - controls the auditing of InterProcess Communication (IPC) keys and user IDs. This was added in RACF 2.2 to support the X/Open Portability Guide Issue 4 (XPG4). The LOGOPTIONS setting controls UID, GID, and mode changes, while the AUDIT setting controls auditing of IPCOBJ object creation and deletion.
• PROACT - used for events related to a user looking at data from other processes or affecting other processes. LOGOPTIONS directs what level of events are logged.
• PROCESS - OMVS includes the UNIX function granting users temporary access based on a UID or GID other than their own. Logging changes to their effective UID (EUID) or effective GID (EGID) and thread limits are controlled by the LOGOPTIONS setting for this class. Additionally, the AUDIT setting for this class determines the level of auditing for dubbing (initiate execution), undubbing (execution completion), and server registration.

ACCESSING OMVS

As discussed in part one, before a user enters the OMVS kernel successfully (38-00) by issuing the OMVS command from TSO, RACF checks their RACF userid and password and validates their entry into the MVS system and TSO. Possible failures logged for an unsuccessful attempt to enter OMVS include:

• RACF is unable to extract the UID from the user's OMVS segment (38-02)
• There is no OMVS segment within the user profile (38-01)
• User's current group does not have an OMVS segment with a GID (38-03).

All unsuccessful dubs are logged, regardless of the setting for PROCESS class auditing. When the user finishes with OMVS and undubs, RACF writes a 39-00 record documenting the event.

File system

The HFS is an SMS-managed MVS dataset. One or more file systems are mounted at OMVS initialization under MVS by means of parameters found in the BPXPRMxx member of SYS1.PARMLIB.

UNIX and OMVS are very similar to MVS in that they maintain integrated file catalogs. Just as the MVS catalog tracks the volume serial where a dataset is stored, UNIX tracks the device on which a file is stored. Tracking the physical storage device is transparent to the user. This differs from PC-type DOS systems where the user must specify the drive on which to look for the directories and desired file.

UNIX and OMVS mount their file systems at system startup. A superuser can add devices to the file system by issuing a mount command after OMVS initialization. This is tracked by RACF as a (44-00) event when successful and (57-01) when not. A file system is removed from service via the unmount command and results are reported by RACF as either successful (55-00) or unsuccessful (57-01). If these commands are attempted by a user other than the superuser, a failure event is recorded, regardless of AUDIT parameter settings.

Directories

Directory events are a bit different in OMVS than they are in MVS. For example, MVS uses catalogs to locate datasets; UNIX and OMVS follow hierarchical directory paths (trees) to locate files. MVS dataset names are up to 44 characters; each dataset name level (1ev1.lev2.lev3.lev4.dsn) resembles part of the UNIX directory path. In UNIX, a file path is up to 1023 characters.

OMVS journals events to SMF that are related to the path followed to gain access to a file. This makes it possible to determine the location of the file and directory if needed. SMF80 records for OMVS may include one or two path-names, depending on the event journalled, of up to 1023 bytes each.

The file identifier field contains a 16-byte token functioning as the mode within the HFS. Directory searches succeed (28-00) or fail (28-01) indicating whether the user had execute access to the directory (DIRSRCH); whether the user did (29-00) or did not (29-01) have requested access to the directory (DIRACC); and whether the user is (32-00) or is not (28-01) authorized to use the chdir command to change their working directory to the requested directory.

While MVS controls the existence of only the highest level of index (HLQ or levl) for dataset names in master catalogs, UNIX controls each level based on a user 5 authorization to the specific directory. OMVS logs events showing the success of adding directories via mkdir (42-00) or removing directories via rmdir (48-00), or the failure of these requests (28-01 or 29-01).

Files

In OMVS a user either successfully accesses a file (30-00) or is not authorized (30-01) to access the file at the level requested (read, write or execute). The user can create (open) a new file (45-00) if not denied search access (28-01) or update access (29-01) to the directory.

Files are renamed using the mv command. RACF reports a successful rename (47-00) if the user is authorized, or directory failure if not authorized (28-01 or 29-01). The unlink command in OMVS functions the same as the UNIX rm (file remove) command: it removes file entries from the directory. Successful attempts to unlink are (54-00) events and unsuccessful attempts are (28-01 or 29-01) events.

With the UNIX link (ln) command, a file can have multiple names, called links. Links are not independent copies of the original file, but aliases pointing to the same tile via mode or OMVS file token. This allows each user requiring access to the same file to have their own name for the file. For example, /usr/mark/project/file.doc can be referred to as simply /admin.doc by another user. A file with multiple links has a number greater than one in the links column of the directory list (see Figure 4).

Links function like MVS module use counts. When the count of links is greater than zero, a file exists. When the last link is removed via the UNIX rm command or the OMVS unlink command, UNIX deletes the file. A user can establish a link (41-00) if they are not denied access to the file (28-01) or the directory (29-01).

A symbolic or soft link acts like a link, but without a separate directory entry to the linked file. The symbolic link is an actual, separate file containing the path for its linked file. This opens the door for links to files on other UNIX systems using the NFS. OMVS extends this definition to include external links, which are capable of being MVS dataset references. Successful symbolic (ln -s) or external (In -e) requests are reported as (53-00) events, while failures are either (28-01 or 29-01) events.

Other UNIX files include named pipes and character special files. These files are created using the mknod command. Successful requests are reported (43-00) as well as unsuccessful requests (28-01 or 29-01).

Program Execution

When executing a program, UNIX allows flagging the FSP of an executable file so that it runs under the effective UID or GID of the owner instead of the requester. Executing a program file with FUID or EGD requested in the FSP results in a potential logging of the (36-00) event: execute with SETUID, SETGID. There is no failure case for this event.

To request set UJD or set GID, the change file mode (chmod) command is issued. RACF reports the success (49-00) or failure (49-01) of set UID and the success (50-00) or failure (50-01) of set OlD requests. There is no comparable MVS facility or RACF event. Figure 4 shows file listuser with the LID flag set (-rwsrwxrwx). Figure 5 explains the authorization and audit flags listed in Figure 4.

InterProcess Communication

IPC is the OMVS service allowing two processes to communicate and share data with each other. The relevant OMVS commands are ipcs, to display message queues, semaphores, shared memory, and other relevant information, and ipcrm, to remove orphaned requesters or processes. As mentioned earlier auditing of IPC events is controlled by the IPCOBJ class.

Changing File and Directory Access Privileges

Neither UNIX or OMVS support generic file profiles. Each file carries its own FSP. Where RACF uses the PERMIT and ALTDSD commands to modify dataset profiles, UNIX and OMVS use their own commands to modify the contents of a file's FSP. Multiple OMVS commands may generate logging records. Commands include:

• chaudit -change file audit options with-in the file's FSP~ Possible outcomes are successful change of the audit flags (31-00), caller may not change owner audit flags (31-01), or caller may not change auditor flags (31-02) because of lacking RACF AUDITOR privilege. This is similar to a RACF GLOBALAUDIT parameter
• chmod - change file mode by changing file authorization flags within the FSR Change may be successful (33-00) or unsuccessful (33-01). Using chmod to modify other access flags is like using the RACF ALTDSD UACC(level) command to modify the UACC in RACF
• chown - change file owner, the UID within the FSIP, thereby "giving the file away" to another user Possible outcomes of the chown command are successful change (34-00) of the owning UID or unsuccessful request (34-01). This is like a RACF ALTDSD OWNER(user) request. Many UNIX installations have removed the chown command from users due to abuses and security concerns.

Running process

Authorized users can impact processes running under the OMVS kernel subsystem, such as user sessions and daemons. For example, the kill command cancels the execution of a specified process. This can result in a successful request (40-00) or notification that the user is not authorized to kill the specified process (40-01).

UNIX AND OMVS EVENT REPORTING SERVICES

UNIX provides several reports that can be duplicated under OMVS using one of the alternate methods of reporting SMF events mentioned at the beginning of this article. Like UNIX, SMF record layouts for RACF OMVS include four-byte UID number, four-byte GID number, and 16-byte file identifier (token). But UNIX offers a different philosophy on reporting events. There is no central data repository like SMF within UNIX. While any authorized program can write to SMF for data capture in MVS, UNIX depends on a set of daemons, parameters governing their processing, and each daemon's recording files.

A key UNIX advantage is input / output redirection or piping. Instead of writing programs to filter, rearrange, and reorder data, piping allows one line command strings to provide immediately usable and easily stored reports.

User last access

Another advantage of UNIX, depending on the version, is reporting of date of last logon. Some versions also supply date of last unsuccessful logon, which is very useful in detecting attempted system attacks.

Most UNIX systems store last logon information but do not alert security administration about unsuccessful logons. This is not an issue for OMVS, because RACF validates user passwords and reports last successful logons when logging onto TSO, and writes SMF records if a user is not allowed access to OMVS.

Password changes

UNIX and OMVS allow a user to change their passwords. As with last access, OMVS password changes are controlled by RACF OMVS uses standard RACF support for password controls. RACF password events are outside the range of OMVS events and qualifiers.

UNIX has varying levels of password controls, depending on the use of the shadow password file (/etc/passwd). There are no UNIX reports on changed passwords; reporting can be accomplished by periodically reviewing the shadow password file.

System Entry

UNIX keeps track of the last x number of users to enter the system. This log is frequently reviewed using the last command. While RACF offers no such log, it is possible to run a report against the SMF files to determine who entered the system for any recorded interval.

UNIX provides a command to change logged on user (su). Use of this command is not logged since it is the same as logging onto the system. If the user knows the password for the specified user, access is allowed and the UID is changed. RACF reports these changes in the (52-00) records.

UNIX keeps a separate log of super-user (UID=0) system entry. This can be duplicated in OMVS using the successful dub records (38-00) and checking for UID=0 within the recorded data.

AUDIT POINTS FOR EVENT REPORTING

Part of the challenge of UNIX auditing is the scarcity of audit reporting tools. By migrating UNIX applications to OMVS, far greater and more centralized reporting becomes possible.

When performing a review of OMVS event reporting, Figure 2 provides a handy reference listing OMVS RACF event and qualifier codes for successes and failures, RACF audit controlling classes, and their LOGOPTIONS (-L) or AUDIT (-A) settings, which affect all records checking the RACF class. Authorized users can review current settings for each of these classes by issuing the RACF SETROPTS LIST command, as shown in Figure 6.

To further enhance RACF support for OMVS, IBM recommends building a collection of OMVS reports for the RACF portion of your OMVS environment. These include:

• A superuser report to identify all users with OMVS (UID=(0))
• A cross-reference report for all UIDs and the GIDs to which they are connected
• A cross-reference report for all GIDs and the UIDs connected to them.

SETROPTS LIST
. . .
AUDIT CLASSES = DATASET USER FSOPB IPCOBJ
. . . 
LOGOPTIONS "ALWAYS" CLASSES = NONE
LOGOPTIONS "NEVER" CLASSES = NONE
LOGOPTIONS "SUCCESSES CLASES = PROCESS

CONCLUSION

While UNIX and MVS are very different in how they process data, there are enough similarities that knowing one system makes understanding the other relatively easy. OMVS, the first step towards marrying MVS and UNIX, provides the framework for security professionals in one environment to learn to work with the other The next step comes with IBM's announcement of OS/390 to replace MVS/ESA in 1996, which will bring the UNIX and MVS worlds even closer together.

Please take a moment to fill out the Feedback form.  Other articles of interest can be found in the library.