Reprinted with permission. ©1995 Candle Corp. All Rights Reserved.
| Author's note: A rough draft of this article was published on the World Wide Web in early August, 1995. This is a greatly enhanced version and appeared in CANDLE Corporation's Candle Computer Report Nov./Dec. 1995 issue. This is not the same article previously released. |
MVS/ESA 5.1 and the OpenEdition MVS(OMVS) segment of user and group profiles in RACF 2.1 introduced major support for UNIX on MVS. To administrators familiar with RACF, this two part series serves as an introduction to UNIX analogue controls. To those already familiar with UNIX, the series shows how RACF and OMVS deal with UNIX controls. What are the similarities between OMVS and UNIX? How is the OMVS segment of a RACF user profile like the password file in UNIX? How does OMVS use RACF to validate users and their access to files?
OMVS and UNIX are two different computer systems supporting different hardware and operating system environments. Their analogues are not identical, but are "best fitted " to their respective environments. Part one compares RACF and its support of OMVS to UNIX and its methodology of defining and controlling users and data files. Part two explores the interpretation of OMVS audit events into more familiar RACF-like descriptions, including use of the new OMVS classes in RACF.
This series assumes basic knowledge of RACF controls and UNIX command services. Operands and specific command syntax are found in each product's command reference manual and documentation. Users familiar with the DOS operating system used on IBM and compatible PCs will recognize many UNIX commands and concepts.
To understand how OMVS integrates UNIX and MVS user sign-on, group structure, and data access requires a basic understanding of UNIX and MVS at the system level. MVS performs UNIX functions via OMVS support of Portable Operating System Interface (POSIX). POSIX is a collection of interface definitions based on UNIX with a focus on cross-platform capabilities. Developed by the Institute of Electrical and Electronic Engineers (IEEE), POSIX started with C language functions and has since expanded to include interactive commands.
IBM has made it clear that POSIX support is a very real priority for MVS. The major thrust of MVS/ESA 5.2.2, released in September 1995, is to support the XPG4 base of X/Open. From the announcement letter: "This release is a major step toward IBM's intention to have MVS/ESA branded as a UNIX system."
Whenever encountering a new environment, a new foundation must be built. But not all UNIX systems are created equal. There are multiple UNIX vendors and operating systems, such as AIX, HP-UX, and SunOS. There are various releases of UNIX within each system. Many installations extensively customize their UNIX environments. This article visits a collection of available features; your experience may vary.
Figure 1 illustrates similar services in UNIX and MVS, with OMVS acting as the go-between. Though MVS and UNIX services are similar, UNIX is not as controllable as MVS. This can be attributed to the following differences underlying the two systems:
Accessing OMVS is no different than using any other TSO service. After logging onto TSO, issue any desired TSO commands and then the OMVS command. RACF performs a series of checks to see if you have an OMVS segment containing a UID value (the HOME and PROGRAM fields are optional) and are connected to an OMVS group (GID). Once both conditions are satisfied, your TSO address space is "dubbed" as an OMVS process. You can switch between OMVS and TSO services as needed.
Like the RACF database, UNIX maintains a user definition file, usually /etc/passwd with optional /etc/shadow Records within this file have many fields similar to the OMVS fields handled through RACF. For example, both UNIX and RACF identify the user and maintain an encrypted password. UNIX uses a numeric UID ranging from zero to 2,147,483,647 (minus the commas). RACF uses an eight-character alphanumeric user ID. OMVS carries the UID within the OMVS segment of the RACF user profile. Unlike RACF, UNIX and OMVS have no quarrel with assigning the same UID number to multiple users.
To understand the controls in each system, use the following key with the example in Figure 2 to correlate user definitions between UNIX and RACF:
[a] User identifier (userid). RACF allows up to eight alphanumeric characters. Although
UNIX imposes no restriction, using more than eight characters affects report formatting
for commands such as list directory (ls).
[b] Encrypted password. RACF does not display this value.
[c] User ID number (UID).
[d] User's default group.
[e] Alphabetic information about the user. Restricted to 20 characters in RACF
[f] User's initial directory when logging onto OMVS or UNIX.
[g] User's shell program.
In UNIX and OMVS, anyone using UID=0 is a superuser, with full rights to any file in the HFS system and full access to system resources. This is much like a RACF userid with both system SPECIAL and system OPERATIONS. Extending this into OMVS, a RACF privileged or trusted started task (STC) is also considered a superuser.
Finally, UNIX has daemons. Not supernatural beings, or necessarily superusers, UNIX daemons perform like MVS subsystems, such as DB2 and JES. UNIX daemons include File Transfer Protocol (ftp), mail, and cron (scheduler).
The RACF database is protected from prying eyes with UACC(NONE), which prohibits non-authorized users from reading it. But in UNIX, several system services require that users read the password file, /etc/passwd. Because the password file is not read protected, some versions of UNIX use a second, restricted access shadow file,/etc/shadow to store encrypted passwords. Incidentally, the shadow file provides many of RACF's extended password services, including:
[h] Date of last password change.
[i] Minimum days before changing password is allowed (in UNIX only).
[j] Maximum days before changing password is required.
[k] Password expiration warning interval (global in RACF, user level in UNIX).
[I] Maximum days of inactivity allowed (global in RACF, user level in UNIX).
[m] Expiration date for userid.
Another difference between RACF and UNIX: where RACF sets a flag to revoke a userid, UNIX suspends a user ID by adding an asterisk to the encrypted password. This prevents users from hijacking daemon user IDs to log onto the system. An example is lp in Figure 2. This method of preventing ID use has two advantages: the asterisk is an obvious flag that cannot occur as a result of password encryption, and the previously used password is easily restored by removing the asterisk.
The RACF list of groups option authorizes user access based on the group or groups
to which the user is connected. In UNIX, group numbers and assigned users are defined
within the group file, /etc/group. UNIX recognizes only one group assignment when
authorization checking. However, with the newgrp command, users may change their
current group if they are authorized to connect to the requested group and they know the
group connection password, an optional level of protection. Another option provided by
some versions of UNIX, AIX in particular, checks every group you are in to see if you have
group level access. This is similar to RACF's list of group checking.
Checking user authorization to access OMVS files differs from checking access to MVS datasets. Although in both cases the request is passed to RACF for determination and SMF journaling, the actual checking is very different. Where the RACF database maintains dataset profiles and lists of user IDs and their access levels, OMVS stores the FSP in the RFS and passes it to RACF with user security credentials.
MVS Volume Tables of Contents (VTOCs) carry dataset names and many other data items keyed to the names. In UNIX, the directory maps file names to unique inode numbers, by which all files are known. Similarly, users and groups show up in directory listings when UNIX performs a look up of the user name and group name from the UID and GID stored in the directory (see Figures 2 and 3).
Since there is no internal linkage between OMVS UID and RACF userid, OMVS performs a table lookup to find the RACF userid when given a UID and to find the group when given a GID. Because of the overhead introduced by reading the RACF database for OMVS segments, IBM strongly encourages activation of IRRUMAP and IRRGMAP in the Virtual Lookaside Facility (VLF) to build tables in storage. Instead of reading the RACF database every time it needs to find a userid or group, VLF performs a table lookup in storage and avoids overhead.
Each UNIX file has an owning user and group as shown in Figure 4. Only the owner and the superuser have the ability to change the owner, group association, and permission flags for the file. As illustrated in Figure 5, there are three sets of access permission: owner's permission, the file's group permission, and other (anyone not the owner or belonging to the owning group). Where RACF has hierarchical authorizations, each UNIX set has three access permission values that are discrete and non-hierarchical:
Like RACF, UNIX offers two levels of dataset and file auditing: that controlled by the file owner or superuser and another, separate level, controlled by a user with RACF auditor privileges (see Figure 5). The sequence for auditing the level of access is read, write, and execute. The four values possible for each level of access are "a" for all accesses, "s" for success, 'f" for failure, and "-" for no auditing. Access controls and audit settings are maintained using OMVS commands, not RACF PERMIT commands.
With no file profile in OMVS or UNIX, RACF uses permission flags stored in the FSP to determine authorization and auditing. The FSP consists of: file inode number, version, current file owner UID, current file owner group GID, the Set UID and Set GID (SUID and SGID), file access controls, file audit settings, and the "sticky bit."
The sticky bit has a novel meaning. When applied to an executable file, it indicates the program should be loaded and kept in virtual storage. In OMVS this means the program resides in the Link Pack Area (LPA). However, the sticky bit is losing favor in the UNIX world and may not be an issue in the future.
At times UNIX authorizes user access to a file based on the owner of the program instead of the UID or GID, such as when maintaining an audit log or transaction journal. When the set UID (SUID) or set group id (SGID) flag is on, the file is executed with the values of the program file owner as the effective UID or GlD. Files flagged for SUID or SGID substitution show an 's' for execution authorization. See the authorization list for the listuser file in Figure 4. Since UNIX checks the effective and not the real user or group authorization, it changes authorization checking substantially, approximating program pathing in RACF. Depending on the application and its controls, this is both a benefit and a drawback: a benefit because it gives people access to files based on the program they are using; a drawback because files are exposed to potential misuse.
Although the flow of authorization may vary, the specific checks include:
In OMVS and UNIX, there is no way to exclude a specific user from accessing a file as
RACF provides with ACCESS(NONE). Also, where RACF allows a specified user ID to have less
access than their group, it is impossible for UNIX to grant a user less access than their
group access. A requester is either the owner, a member of the file owner's group, or
other (as illustrated in Figure 5). These are the only
parameters available for authorization checking. Some versions of UNIX are implementing
ACLs (Access Lists) that resemble RACF discrete profiles.
Following is a summary list you can use to review the actual OMVS controls implemented in your installation. The list includes RACF userids and groups, as well as MVS concerns.
UNIX and MVS perform many of the same tasks when it comes to defining users, assigning groups, and establishing file sharing controls. But there are significant differences.
RACF's implementation of OpenEdition MVS provides a blending of the two operating systems. IBM's newly announced OS/390 operating system transforms MVS into an environment even more compatible with UNIX. Because the traditional boundaries are blurring, UNIX administrators and RACF administrators must understand each others operating systems.
Part 2 continues with a look at OMVS security events generated by using UNIX-like commands, and maps them into RACF-like events to further familiarize administrators with the similarities between the two systems.Please take a moment to fill out the Feedback form.
Other articles of interest to MVS Security and IS Auditors can be found in the library.