You must define administrators for the system. Create one or more administrator accounts, and add them to the SYSADM and ALLUSER groups. Depending on your security configuration, you may need to add them to other groups or grant them additional permissions.
User accounts defined in the default security configuration should be disabled or removed so that well-known user accounts cannot be used to gain access. Remove all permissions of the default JES user, JESUSER, so that no one can submit work anonymously. All users should be required to sign on.
The primary access check for running a JCL job is user authentication with a valid userid and password. This is checked when the user issues a JES command, from the command line or using ESCWA. Commands are also checked for authorization. For example, to submit a job the user must be authenticated and have access to the cassub resource in the OPERCMDS class. Access to ESCWA administration pages can be restricted using the Common Web Administration class.
When a job is submitted, a check is made against the PHYSFILE class that the JES engine can create its parsing files in the specified location by the user submitting the job. If the job requires read access to libraries, a check is made against the DATASET class.
When a job is run, DATASET checks are made for each dataset it accesses. If a new dataset is created, a PHYSFILE check is made against its location.
Having a well-defined naming convention and defining DATASET rules as to who can access which datasets, plus PHYSFILE rules governing access to filesystem locations for the datasets, will restrict dataset creation and access to authorized users. Separating jobs that create datasets from those that only use existing ones also helps limit what permissions users need to be granted.
This section applies to programs named in the PGM attribute of an EXEC card in a JCL job.
Currently, if a program can be found on the search path the search path set as the JES Program Path in Enterprise Server configuration then it will be run. So, any program could be run without limit on what it does. A job can set STEPLIB and JOBLIB libraries to specify private (user) program libraries, and we prepend those locations to the search path.
You can set additional restrictions on how the JES engine searches for programs, using SYS1.LNKLIB and the ES_JES_HIGHER_SECURITY_LEVEL environment variable. See JCL Enhanced Security Checks.
SYS1.LINKLIB starts with the product's \bin or \bin64 folder (Windows) or the /lib directory (UNIX). This is the location that system-supplied utilities can be loaded from. SYS1.LINKLIB does not exist as a dataset in the catalog so users cannot change the PC-DSN.
On Windows:
SYS1.LNKLIB= $TXDIR\binor
SYS1.LNKLIB= $TXDIR\bin64
On UNIX:
SYS1.LNKLIB= $TXDIR/lib
A concatenation of libraries built from SYS1.PARMLIB are added to this location.
SYS1.PARMLIB(IEASYM00) is already used to hold system symbols. It could also hold SYSPARM entries. Alternatively, you could placed these in a new dataset, SYS1.PARMLIB(IEASYM01) such that SYS1.PARMLIB(IEASYM01) could be used to hold SYSPARM entries for the IEASYSnn members to load.
Note that LPARNAME equates to a region name, and SYSPARM gives indexes for IEASYSnnxx members, so different library indexes could be used for different regions. For example:
SYSDEF HWNAME(MVS3090) LPARNAME(JCLTEST)
SYSPARM(01,L)
SYSDEF HWNAME(MVS3090) VMUSERID(VMSYSCB) LPARNAME(ESDEMO)
SYSPARM(03,L)
SYSDEF HWNAME(SYSCC)
SYSPARM(01,02,L)
The different library indexes (01, 02, 03 etc.) for the different systems indicate the index of the IEASYSnn library to load. For example, IEASYS01, IEASYS02 for all regions, IEASYS01, IEASYS02 for JCLTEST, IEASYS01, IEASYS02, and IEASYS03 for ESDEMO. The 'L' in the SYSPARM parameter indicates that the list should be shown on first access.
Each IEASYSnn member contains a list of LNKLST indexes to load:
LNK=(00,01,02,03)
In the format:
LNK={aa }
{(aa,bb,...[,L])}
{(,L) }
SYS1.PARMLIB(LNKLSTnn) members hold lists of datasets that hold programs that can be run:
LNKLST00: SYS1.CMDLIB,SYS1.TSORTNS,SYS1.BTAMLIB, LNKLST01: SYS1.LINKLIB,DBLUE.U30LIB(U30PAK),SYS2.U30LIB LNKLST02: SYS1.AUXLIB,SYS1.JES3 LNKLST03: SYS1.TEST
IEASYS00 is always read so it could contain the only LNK statement for the system. If multiple LNKLST members are to be read, then entries from IEASYM00 and IEASYM01 need to be read in and used to read IEASYSnn, which is used to read the LNKLSTnn.
So, the eventual list of public program libraries would be:
SYS1.LINKLIB, SYS1.CMDLIB,SYS1.TSORTNS,SYS1.BTAMLIB, SYS1.LINKLIB,DBLUE.U30LIB(U30PAK),SYS2.U30LIB, SYS1.AUXLIB,SYS1.JES3, SYS1.TEST
When a program is executed, the JES engine searches all of the libraries in the link list until it finds a program of that name which the user has the necessary access to. At the default security level (see Migrating to Increased Security Checks, and JCL Enhanced Security Checks), a message will be logged to the console if permission has not been granted to the program or the program is not found. When a program is successfully loaded, a message will be logged about which library it was loaded from.
Dynamic PDS are extremely useful in that any file in a folder that is defined as a dynamic PDS immediately becomes a member of the PDS and can therefore be found and used. This is useful because a program just needs to be compiled and put into that folder. It is dangerous for the same reason in that a malicious user could do the same thing with a malicious program. To prevent this, at the BASIC security level dynamic PDS are excluded from program load locations. At the default security level (NONE), a warning is logged if the program is found in a dynamic PDS.
Further security checks can be implemented in ESF by creating the PROGRAM resource class, if it does not exist, and adding resource access rules there. A check would be made that a user has permission to READ or EXECUTE the program in the dataset. A PROGRAM resource access rule would be named program-name.library-name, possibly with wildcards (use ** as a wildcard in the library name to match multiple DSN qualifiers).
An example in LDIF, for use with LDAP-based security:
dn:CN=PROGRAM,CN=Enterprise Server Resources,CN=Micro Focus,DC=mftesting,DC=com objectClass: top objectClass: container description: JES Class for controlling access to programs dn:CN=*.**,CN=PROGRAM,CN=Enterprise Server Resources,CN=Micro Focus,DC=mftesting,DC=com objectClass: microfocus-MFDS-Resource microfocus-MFDS-Resource-Class: PROGRAM microfocus-MFDS-Resource-ACE: allow:*:read microfocus-MFDS-UID: no description: Allow everyone permission to run any program in any library
To specify a program in a library, construct an entry with a CN of program_name.library_name:
dn:CN= MYPROG.MFI01.JOBLIB1,CN=PROGRAM,CN=Enterprise Server Resources,CN=Micro Focus,DC=mftesting,DC=com objectClass: microfocus-MFDS-Resource microfocus-MFDS-Resource-Class: PROGRAM microfocus-MFDS-Resource-ACE: allow:AUTOUSER:read microfocus-MFDS-Resource-ACE: allow:SYSAD:read microfocus-MFDS-Resource-ACE: deny:*:read microfocus-MFDS-UID: no description: Allow AUTOUSER and SYSAD permission to run the MYPROG program in the MFI01.JOBLIB1 library
To use wildcards:
dn:CN= ABC*.MFI01**,CN=PROGRAM,CN=Enterprise Server Resources,CN=Micro Focus,DC=mftesting,DC=com objectClass: microfocus-MFDS-Resource microfocus-MFDS-Resource-Class: PROGRAM microfocus-MFDS-Resource-ACE: allow:AUTOUSER:read microfocus-MFDS-Resource-ACE: allow:SYSAD:read microfocus-MFDS-Resource-ACE: deny:*:read microfocus-MFDS-UID: no description: Allow AUTOUSER and SYSAD permission to run any program starting with ABC (including ABC) program in any library that starts with MFI01
Entries are required for both the program name identified in the JCL and also its alias if it has one - for example, IDCAMS and MFJAMS.
Program libraries should be POs with programs identified as members. Adding member entries to the PDS requires ALTER permission for the dataset. As mentioned above, dynamic PDS would not be permitted in the LNKLIB list. Programs in the library require OS execute permission for the user that the JES Initiator process is running as.
Beginning with release 9.0, the JES engine supports additional security measures. These are not enabled by default because they could cause program loads that were working in earlier versions to fail. This section briefly discusses these additional security features. See JCL Enhanced Security Checks for more information. Micro Focus recommends enabling at least the BASIC security level for improved product security.
The new security features are enabled by setting the ES_JES_HIGHER_SECURITY_LEVEL environment variable.