Jul 24 ’07
Managing Your Unix Superusers
Herding cats, stuffing snakes in a box, managing your z/OS Unix superusers—all are examples of impossible tasks. Well, perhaps all but the last one. With some planning and communication, RACF, or an equivalent mainframe security product, really makes it possible to manage your superusers.
Before we can manage a superuser, it’s necessary to define one. In the z/OS Unix environment (also known as OMVS, MVS/OE, or Unix System Services), there are two users: a normal user and a superuser. The normal user is exactly that, someone who uses the system, but has no extraordinary privileges. On the other hand, superusers can:
- Pass all security checks so they can access any file in the file system
- Manage processes (or tasks)
- Have an unlimited number of processes running concurrently. (For a started procedure, this is true only if it has a Unix id [uid] of zero. It isn’t true for a trusted or privileged process with a different uid.)
- Change identity from one uid to another
- Increase any of the system limits for a process.
While some functions may require a uid of zero, usually there are three ways to authorize the request. The goal is to minimize the number of “human” user IDs (as opposed to started procedures: daemons and servers) set up with superuser authority by assigning uid(0). To introduce the choices:
- uid(0) gives you access to all Unix functions and resources, as is true for all Unix systems.
- Certain users can perform specific privileged functions without being defined as uid(0) in the security system. The RACF BPX.SUPERUSER resource lets a user request an effective uid(0), but they’re a nomal (nonzero uid) user until the change is requested via the su command. There also are some z/OS services, such as SMP/E, that can be invoked without being uid(0) but with access to BPX. SUPERUSER.
- UNIXPRIV class profiles authorize users to perform other sets of privileged functions, such as mounting a file system, killing a process and more, without requesting a change of uid.
The three methods are detailed here in order of their likelihood of being used—and in the inverse order of desirability.
The first and oldest method for a user to become a superuser is to be defined to Unix as uid(0). This method is implemented in z/OS by providing the user with an OMVS segment on their userid—with the uid(0) operand specified (see Figure 1). This method places the user into superuser mode as they logon to z/OS Unix. If the user’s logon script has been compromised (as in a Trojan horse attack), any restricted commands in their script are executed in superuser mode. There are ways to mitigate this exposure.
If the user is required to have access to uid(0) to perform their job functions, rather than define them with uid(0) in their OMVS segment, provide them with their own, unique uid and grant them READ access to the BPX. SUPERUSER profile in RACF.
The BPX.SUPERUSER profile, defined in the FACILITY class, grants users with READ access (greater than READ has no meaning) permission to specify the Unix switch (or substitute) user command (su) without specifying a userid and become a superuser with a uid of 0. While a superuser, enter the exit command and return to the nonzero uid.
The benefits of this approach include:
- The user enters the system in normal user mode, not superuser mode, thereby defeating any attempt to place a Trojan horse command in their logon script.
- “Accident insurance” by ensuring powerful commands aren’t available until needed; more than one user has issued what was meant to be a minor command and had unexpected results.
- The ability to enter and leave superuser mode without logging out of the system. One userid provides both normal and superuser capabilities.
The UNIXPRIV Class
The UNIXPRIV class houses profiles that subdivide superuser privileges. By determining which privileges a user actually requires, it becomes possible to grant those powers to a non-zero uid.
The UNIXPRIV class in RACF is designed to grant Unix superuser privileges on a granular basis. The class must be RACLISTED and global access checking isn’t supported. Auditing of profile usage is different. Whereas most profile access failures are logged, UNIXPRIV primarily logs successful accesses by default, RACLISTED profile usage isn’t logged and failure to gain access to these profiles isn’t a violation, but a denied attempt to use optional extra services.
There are several profiles available for the granular delegation of superuser privileges.
The SUPERUSER Profiles
There’s a set of profiles that grant pieces of superuser authorization—this means that security can give out only the necessary privileges where needed.
SUPERUSER.FILESYS grants access to all local (no access to NFS files granted by this profile) directories and files at the level of access listed below.
- READ access to this profile bestows read access to any local file and search/ read access to any local directory.
- UPDATE access to this profile grants read/write to any local file and search/ read access to any local directory.
- CONTROL or ALTER access to this profile grants read/write to all local files and search/read/write access to all local directories.
Authorizing a user to this profile may grant access to more files than desired. If there are files or directories to be excluded from this global authorization, defining another profile, SUPERUSER.FILESYS.ACLOVERRIDE, brings additional restrictions into play by means of using the Access Control Lists (ACLs) for the files and directories.SUPERUSER.FILESYS.ACLOVERRIDE is a discrete profile specifying that ACL controls take precedence over access granted by the SUPERUSER.FILESYS profile. However, access can still be granted for specific userids—if given the same level of access to this resource as granted by the SUPERUSER.FILESYS profile.
Another authorization profile is the SUPERUSER.FILESYS,** which grants all the file system privileges to these users granted access to this profile, according to their level of access.
When given read access to the SUPERUSER.FILESYS.CHOWN profile, the user may use the Unix change owner (chown) command to change the ownership of any file (as shown in Figure 2) just like a superuser in Unix. Note that the RACF violation message (ICH408I) appears in SYSLOG and not the user’s session.
SUPERUSER.FILESYS.MOUNT profile allows the user to issue the MOUNT, UNMOUNT and CHMOUNT TSO commands:
- When the user has READ access, he is authorized to issue these commands for filesystems mounted (or to be mounted) with the nosetuid option.
- If the user has UPDATE access to the profile, he’s able to issue the MOUNT, UNMOUNT and CHMOUNT commands where the setuid option is or has been specified.
In a similar separation of authorities, the SUPERUSER.FILESYS.QUIESCE profile allows use of the quiesce and unquiesce commands where the nosetuid (READ access required) or seteuid (UPDATE required) has been specified.
Read access to the SUPERUSER. FILESYS.PFSCTL profile allows the user to call the pfsctl() service.
When a user has read access to the SUPERUSER.FILESYS.VREGISTER resource, he is authorized to call the vreg() service, enabling him to register as a VFS file server. This only lets a server such as Network File System (NFS) initialize. Those users who are clients to such facilities don’t gain special privileges based on this or any UNIXPRIV resource profiles.
Additional privileges are granted by other UNIXPRIV class profiles. For example, IPC.RMID access should be granted to users who use the ipcrm command to release IPC resources. When it’s necessary to grant a user access to various system processes (Unix tasks), the SUPERUSER.PROCESS.** family of resource profiles come into play.
The SUPERUSER.PROCESS. GETPSENT controls what output a user or application sees from _getpsent() service calls (see Figure 3).
- Without access to the resource, the user sees only processes owned by their uid.
- With READ access to the profile, the user may see output from the ps command for all processes, as is the Unix default.
Or, users requiring the ability to call the kill() service for sending signals to any process should be given READ access to the SUPERUSER.PROCESS. KILL resource.
The SUPERUSER.PROCESS. PTRACE profile controls use of the ptrace() callable service through the dbx debugger for tracing any process. SUPERUSER.SETPRIORITY lets the user increase his own priority.
While there are other profiles in the UNIXPRIV class, one final profile of interest is the SHARED.IDS profile. It serves as both a switch and an access profile.
- If undefined, duplicate uids and group identifiers (gids) may be assigned.
- If present, only users with RACF System SPECIAL and users with READ access to this profile may assign an existing uid or gid to another user or group. To share a uid or gid assignment, the user issuing the command (add user/alter user or add group/alter group) must specify SHARED. This profile prevents accidental (or deliberate, if the issuing user isn’t authorized) sharing of uids.
This feature is available only where the structure of the RACF database has been upgraded by the IRRIRA00 utility to make these checks practical.
The most commonly shared userid is uid(0) or superuser. When you’re ready to switch your users to their new, non-zero uids, the IBM manual Unix System Services Planning GA22-7900-10 has a section detailing the steps to be followed.
Many of the services required by users who need to support the z/OS Unix environment can be made available without the “all or nothing” approach of classic Unix. Defining the appropriate UNIXPRIV profiles and authorizing those users needing the authorization by means of access to UNIXPRIV resources makes it possible. If UNIXPRIV parceling of authorities can’t resolve the issues, strive to make BPX.SUPERUSER your solution before sharing uid(0) between Unix daemons, servers and personnel.
It’s possible to request RACF log any unauthorized attempts to gain superuser status by way of the su command. While there’s no RACF logging of successful switching from normal to superuser mode, the effective uid is recorded in most SMF records written by the actions of the uid(0) user. UNIXPRIV won’t help herd cats or stuff snakes in a box, but it can make managing your superusers possible. Z