Maintaining a clean environment in BASIC or ENHANCED mode

As previously mentioned, several functions require a clean or controlled program environment:

Use of PADS
Use of program access to SERVAUTH resources
Use of EXECUTE access for programs or libraries
Improved UNIX security through the definition of FACILITY profile BPX.DAEMON

A program environment consists of a job step in a batch job, a started procedure or job, a user's TSO session, or a UNIX address space. In TSO, you can also create a separate program environment by invoking a TSO command using the TSO/E TSOEXEC command or the underlying IKJEFTSR programming service.

A clean or controlled environment indicates that the user has run only programs defined as controlled programs. You define programs through the PROGRAM class in RACF®, as shown earlier. You can also define programs that reside in the UNIX file system as controlled programs, by using the UNIX extattr command with the +p option. Refer to z/OS UNIX System Services Planning for more information.

Guidelines:

To simplify the work of keeping a user's environment clean, define certain libraries using the PROGRAM profile * or **, rather than trying to define each of the programs in the libraries individually. Also, use PROGRAM ** rather than PROGRAM *. Just as with generic profiles in other classes, using ** enables you to list just that profile when you want it with the RLIST command. If you define PROGRAM *, you will list all profiles in the PROGRAM class when you issue the RLIST command. This might provide several listings and make it more difficult for you to find the profiles you are most interested in.

As a starting point for defining a clean environment, examine your system link list and define PROGRAM ** entries for the IBM® supplied libraries in the link list to ensure that RACF considers all the programs in those libraries controlled. You might also want to add other supplied libraries.

Examples: (Note that the following data sets names are only examples and might be different in your installation.)

RDEFINE PROGRAM ** ADDMEM('SYS1.LINKLIB'//NOPADCHK) UACC(READ) 
RALTER  PROGRAM ** ADDMEM('SYS1.MIGLIB'//NOPADCHK)             
RALTER  PROGRAM ** ADDMEM('SYS1.CMDLIB'//NOPADCHK)             
RALTER  PROGRAM ** ADDMEM('cee.version.SCEERUN'//NOPADCHK)     
RALTER  PROGRAM ** ADDMEM( +	                                   
   'TCPIP.SEZALOAD'//NOPADCHK +                                
   'TCPIP.SEZATCP'//NOPADCHK +                                 
   'db2.DSNLOAD'//NOPADCHK +                         
   'db2.DSNEXIT'//NOPADCHK +                         
   'ftp.userexits'//NOPADCHK)

If you include SYS1.LINKLIB in PROGRAM ** or PROGRAM *, you should define specific profiles for programs ICHDSM00 and IRRDPI00, two programs that RACF ships in SYS1.LINKLIB and that you probably do not want available to all users. Refer to z/OS Security Server RACF System Programmer's Guide for a description of IRRDPI00, and to z/OS Security Server RACF Auditor's Guide for a description of ICHDSM00, which should help you decide which users to authorize for these programs.
```
RDEFINE PROGRAM ICHDSM00 ADDMEM('SYS1.LINKLIB'//NOPADCHK) UACC(NONE)
RDEFINE PROGRAM IRRDPI00 ADDMEM('SYS1.LINKLIB'//NOPADCHK) UACC(NONE)

PERMIT ICHDSM00 CLASS(PROGRAM) ID(authorized IDs) ACCESS(READ)
PERMIT IRRDPI00 CLASS(PROGRAM) ID(authorized IDs) ACCESS(READ)
```
Specify UACC(READ) for PROGRAM ** or PROGRAM *. With these definitions, you are only trying to keep the environment clean, and are not actually trying to control which users can run programs. Using a value other than READ for UACC on this profile can cause system problems. To avoid some of these problems, RACF grants READ authority when all of the following conditions are true:
- A user loads a program from SYS1.LINKLIB
- The program is protected by PROGRAM ** or PROGRAM *
- The access request is processed using the profile values UACC(NONE) or ID(*) with ACCESS(NONE)
If you have users with the RESTRICTED attribute and want to allow them to execute programs in the clean or controlled program environment, you must specifically authorize them for protected resources in the PROGRAM class. (A UACC of READ does not allow a restricted user to access a RACF-protected resource. See Defining restricted user IDs.)

Tips:

For the purposes of keeping the environment clean, you do not need to worry about defining programs in the system link pack area (LPA, PLPA, FLPA, MLPA, dynamic LPA) because RACF always considers those programs controlled.
If a user tries to do something that requires a clean environment and RACF disallows that action because the user has a dirty environment, RACF issues messages to the job log or system log describing why the problem occurred.