Security of Code Pipeline
This section describes how Code Pipeline can be secured. Code Pipeline uses standard SAF facilities to secure the functions in Code Pipeline. Functions in Code Pipeline are secured by the use of Objects and Methods. Security Rules can be defined at the Object/Method level to secure these functions. It is possible to install Code Pipeline with no security at first, and then add rules to define security checking later.
How does it work?
Input cards to the Code Pipeline CM started task determine how Code Pipeline is to make SAF checks and for which Objects/Methods these checks are to be made. Code Pipeline will dynamically build the SAF Resource Name to check based upon the rules specified to Code Pipeline. Security profiles/rules need to be defined to the local security product in line with the Security Rules specified to Code Pipeline. Security-Objects-and-Methods contains the complete list of Objects/Methods and the attributes that can be used in the security checking.
Code Pipeline Security
“Statement of Integrity”
Code Pipeline’s use of APF authorized code is only for the functionality of Code Pipeline, as described in the product documentation. Code Pipeline has been rigorously tested for security exposures, and any security exposures that come to light in the future will be given BMC's highest priority.
Preparing for Security
Defining a SAF Class for Code Pipeline
Code Pipeline makes security checks to SAF which require a Class Name (Generic). It is recommended that a separate SAF Class be defined specifically for Code Pipeline because the Code Pipeline CM started task issues (RACROUTE REQUEST=LIST) against the class at start-up to pre-load all of the profiles. Keeping the Code Pipeline profiles separate provides the maximum level of optimization under SAF.
SAF Class Attributes
An example of a dynamic RACF CDT class definition is shown in the following figure.
Dynamic RACF CDT Class Definition
DEFAULTUACC(ACEE) FIRST(ALPHA NATIONAL NUMERIC) GENLIST(DISALLOWED) +
KEYQUALIFIERS(0) MACPROCESSING(NORMAL) MAXLENX(80) MAXLENGTH(80) +
OPERATIONS(NO) OTHER(ALPHA NATIONAL NUMERIC SPECIAL) POSIT(25) +
PROFILESALLOWED(YES) RACLIST(DISALLOWED) SIGNAL(NO) +
SECLABELSREQUIRED(NO))
This can be refreshed using the RACF command:
Defining Security
Server Definition
Input cards are placed in the dataset allocated to the REFRDATA DDName specified for the CM started task. Input cards for security are required for:
- Specification of the SAF Class which Code Pipeline checks for authorities
- Specification of an optional prefix used when building the resource string
- Specification of the Security Rules to define how Code Pipeline functions are to be secured.
Define RACF Class
The format of the input card for the definition of the SAF Class is:
SECCLASS=xxxxxxxx
where xxxxxxxx is the name of the Class.
If a class is specified which does not exist—or no class is specified at all—Code Pipeline will write a message in the log to indicate that it could not load the profiles and internal Code Pipeline security is unavailable.
Define Resource Name Prefix
The format of the input card for the definition of the Resource Name Prefix is:
SECPREFIX=xxxxxxxx
where xxxxxxxx is the text of the prefix. This card is optional and should rarely need to be specified if the Code Pipeline Server variable is used in the definition of the Security Rules.
Define Delimiter for Resource Name Variables
The Code Pipeline parameter SECDELIM is used to specify the delimiter for variables in the name. The default is that no delimiter is required, causing recognized variable names to be substituted. For example, a resource name in the Security Rules of SERVER.RL.APPL.METHOD will have SERVER, APPL, and METHOD substituted with the runtime values. This can make it difficult to discern what was a literal and what would be substituted, occasionally leading to unexpected results. So using the parameter SECDELIM=$ makes the variables in the resource name more obvious, as you would use $SERVER.RL.$APPL.$METHOD.
Define Security Rules
Input cards can be defined for each Code Pipeline Object and Method using the following format:
This is described further in the following table.
Define Security Rules
Parameter | Description |
|---|---|
Object | A Code Pipeline defined Object (for example, RELEASE). The wildcard symbol “*” can be used to specify all Objects, but only if “*” has also been used for the Method. See Security-Objects-and-Methods for a complete list of Objects. |
Method | A Code Pipeline defined Method that is valid for a specific Object. (For example, the Method ADD is valid for Object RELEASE.) The wildcard symbol “*” can be used to specify all Methods. The wildcard value for the Method can be specified for both a specific Object and for an Object of “*”. See Security-Objects-and-Methods for a complete list of Methods. |
ResourceName | The value here determines what resource string Code Pipeline builds to pass to the security product for the authorization check. For each Object there are a specified number of variables which can be used in the definition of this string (for example, SERVER, APPL, LEVEL, etc.). These variables are resolved at security check time to build the actual Resource Name to check against. See Security-Objects-and-Methods for a complete list of available variables. |
Access | The SAF authority to be checked for. (For example, does the user have READ authority on the Resource Name.) See Security-Objects-and-Methods for a complete list of available Access levels. |
SECRULE Order Impact
When defining SECRULEs in Code Pipeline, the order in which they are specified is important. Code Pipeline processes SECRULEs from top to bottom, and later rules can override earlier ones.
To ensure correct and expected behavior:
- Always define the least specific rule first, followed by more specific rules for the same object or method.
- Avoid placing wildcarded OBJECT and METHOD rules at the end of the REFRDATA DD, as they will override all previously defined SECRULEs.
Example of an Overriding Wildcard Rule
The following wildcard rule, if placed last, will override all other rules:
This entry should only be placed at the beginning of the REFRDATA DD to prevent unintended overrides.
Consider the following examples of SECRULEs defined for the TASK object:
Example 1: Incorrect Order (First rule is ignored)
SECRULE =’TASK * ISPW.TS.APPL.LVL.SLEVEL ALTER’
In this case, the least specific definition is defined last, which causes it to override the specific definition. As a result, a TASK ADD operation will perform a security check for ALTER access on ISPW.TS.APPL.LVL.SLEVEL resource, effectively ignoring the first rule.
Example 2: Correct Order (Both rules take effect)
SECRULE =’TASK ADD ISPW.TS.APPL.LVL UPDATE’
In the second example, because the least specific definition is defined first, the more specific TASK ADD rule takes precedence. As a result, the security check is performed as expected for UPDATE access on the ISPW.TS.APPL.LVL resource.
Default Security
Code Pipeline comes pre-defined with internal rules to determine which security checks are to be made. This default security is described in Security-Objects-and-Methods against each Object and Method. The user-defined Security Rules override these defaults.
Previewing Security Rules
There is a Code Pipeline-supplied program which takes as input the defined Security Rules and produces a report detailing all the Code Pipeline Objects and Methods with the Resource Name string Code Pipeline will check against and the authority required. This is a useful report to validate the rules with the definitions in the security product. The JCL for running this report is shown in the following figure. This JCL can be found in the Code Pipeline SAMPLIB dataset member WZZACDMP.
Previewing Security Rules
//*
//*-------------------------------------------------------------------
//* EXECUTE THE ROUTINE WZZACDMP TO DUMP OUT SECURITY RULES
//*-------------------------------------------------------------------
//RUN EXEC PGM=WZZRCJOB,PARM='PROD/WZZACDMP WZACISPW'
//STEPLIB DD DISP=SHR,DSN=ISPW.CONFIG.AUTHLOAD
//SYSPRINT DD SYSOUT=*
//SYSUDUMP DD SYSOUT=*
//SDEFISPW DD DISP=SHR,DSN=YOUR.ISPW.PARMLIB(SDEFREFR)
Report Layout
See Security-Objects-and-Methods for examples of this report.
The report has three sections:
- Heading
- Input Cards
- Altered Rules.
Heading
Input Cards
The input cards that were input into the program are re-printed.
Altered Rules
The security rules are printed out in the format shown in the following section.
Altered Rules
The security rules for the Objects and Methods are printed out in the format listed in the following table.
AlteredRules
Column | Field | Description |
|---|---|---|
1 | Modify Indicator | This indicates whether the input cards have altered the default rules defined in Code Pipeline. An “M” identifies it as modified. |
3 | Object | The Code Pipeline Object. |
12 | Method | The Code Pipeline Method for the Object. |
21 | Access | The access level that is required for the Object/Method combination. |
30 | Resource String | The SAF Resource String which is checked against to see if the user has the required access. |
Secure Test Level (Secure Edit)
PTF IWH314A introduces the ability to set an application type to have a Secure Test Level. This is also referred to as a Secured Test Level, or Secure Edit when set to "S".
This functionality allows authorized users to edit source code at the TEST level through the Code Pipeline. Edits are permitted only if the user has access to perform Edit operations on the associated Task. This can allow administrators to limit users from direct UPDATE access to source lifecycle datasets at the TEST level, enabling better auditing and tracking of changes to their source.
The following are the important assumptions:
- Users must retain READ access to the source-type lifecycle datasets of the components that they are authorized to work on. Users still require UPDATE access to generate-part-type datasets at the “TEST” level.
- SECRULEs are in place to restrict users access to TASK SETPROC function for the following operations:
C (checkout)
S (select/edit)
These operation values fill in the popt field in the SECRULE template. - All operations that involve HOLD levels must occur within a Set. This can be enforced by having a DUMMY approval rule set up for every non-TEST level.
- First DDL DDL2201K (which adds new columns) can be performed before the PTF is “live” on the Code Pipeline system. This means it can be done before the PTF is applied or before the SMPE datasets, if differing from runtime libraries, are copied to the runtime libraries.
- Second DDL DDL2202K which removes obsolete columns must not be run before the PTF is “live”. It can be deferred until after the PTF has been tested. This DDL will put the tables into Pending Reorg status (resulting in SQLCODE -601). If the two SELECT statements in this DDL return non-zero rows, we recommend saving off the output.
Started Task Setup
The following steps outline the setup requirements for CT started tasks when using Code Pipeline through the TSO interface.
- A CT started task is required on any LPAR where users are using Code Pipeline through the TSO interface.
- Each CT required for this purpose must be specified in the M.SV Server Name Table with a unique Cross-Memory ID.
- If the CT defined by M.ER variable CTLOCAL specifies a CT started task that does not have access to all lifecycle datasets (for example: some code is only on other LPARs), then each CI started task on an LPAR where users are accessing non-shared lifecycle datasets must have WZCTDFLT defined to point to that LPAR’s CT.
Security Setup
The following outlines the required security setup for enabling Secure Test Level.
- The SECRULE for TASK SETPROC must be specified to restrict user access to the “C” and “S” operation to only tasks which they are allowed to access.
IMPORTANT
If your site’s TASK SETPROC rule is too non-restrictive, a user who was previously unable to edit a task at a TEST level due only to restricted dataset access may potentially be able to edit the source of that task once the Secure Test Level flag is enabled. In that case, security software-defined resource rules to the SECRULE-defined resources and/or the SECRULEs themselves should be reviewed and updated.
- UPDATE access to TEST level source datasets should be downgraded to READ access for most/all TSO users. CT started tasks should retain UPDATE access to those datasets.
- Users will need to keep UPDATE access to TEST level generated part datasets (example: OBJ, LOAD, etc) for generates to run correctly.
Security example
For the basics of defining SECRULEs, see the Defining Security and Security Objects and Methods sections of the Code Pipeline Technical Reference Guide. The security check which is used for a user to edit or checkout a task is the object “TASK” method “SETPROC”.
The documentation provides the following example input card for this SECRULE:
SECRULE='TASK * ISPW.TS.APPL.LEVEL.SLEVEL.POPT UPDATE'
The * represents a wildcard for any method. For the SETPROC method, this is equivalent to the following:
SECRULE='TASK SETPROC ISPW.TS.APPL.LEVEL.SLEVEL.POPT UPDATE'
With Secure Edit configured for an application component type (M.AD/T), when a user attempts to edit a task in the PLAY application at DEV1 level, their access to this security software defined resource (not dataset access) will be tested:
ISPW.TS.PLAY.DEV1.DEV1.S
If the user has UPDATE access or higher to that resource, they can perform the edit. Otherwise, a 'Not authorized' error is returned.
To verify which access checks are being performed, you can enable access check tracing by specifying M on the M.SM server control panel, and specifying the trace control statement DEBUG=AC (without quotes). After performing the operation, review the trace output in the CM job log. The output will include statements such as the ones shown below, which you can use to confirm that the correct checks are being executed:
WZZACCHK OBJECT=TASK , METHOD=SETPROC
WZZACCHK RES=ISPW.TS.PLAY.DEV1.DEV1.S
WZZACCHK USERID=TESTUSR , ACC=UPDT, RC=0000, RACFRC=0000, RACFRS=0000
Configuring and Validating Secure Test Level
The following are the steps to configure and validate Secure Test Level settings for application component types:
Step 1: Configure Secure Test Level
To provide granular control, enable limited rollout or usage of the Secure Test Level, and allow for site-specific testing and validation, the feature is applied individually to each Type within each application in the M.AD/T (Application Stream -> Component Type) configuration.
Set the Secure Test Level? flag in M.AD/T to S. This enables CT-authorized editing of the Source components for that Type.
Example:
M.AD/T MODIFY STREAM/APPL/SUBAPPL:PLAY/PLAY/PLAY COMPONENT
Command ===>
Enter required details:
Component Type (KEY) ==> ASM Component Domain ==>
Component Class (KEY) ==>
Description ==>
*Content Type ==>
*Generate Skeleton ==> *Test Gen. Panel ==>
*Generate Table ==> *Hold Gen. Panel ==>
*Generate Job ==> *Cust Gen. Panel ==>
*Prod. Move Job ==> Hold Move Time ==> (HH:MM)
Secure Test Level?==> S
*Model DSN(MEMBER) ==>
Press ENTER to complete the change or END to terminate
Note: You can add a new entry by overtyping the Keys with new unique values
Step 2: Refresh the Server
After updating the configuration, refresh the server using the M.SM “R” (Server Refresh) option.
Validation
Task 1: Verify Edit Access
Attempt to edit a TEST level element. If the configuration is active, the dataset name will display with the “SE:” prefix.
This prefix is visible in Edit mode only (not in View or Browse).
Example:
EDIT SE:ISPWTEST.PLAY.DEV1.ASM(IEFBR14)
Command ===>
****** ********************************* Top of Data **************
000001 IEFBR14 CSECT
000002 IEFBR14 AMODE 31
000003 IEFBR14 RMODE ANY
000004 SR 15,15
000005 BR 14
000006 END IEFBR14
****** ******************************** Bottom of Data ************
Task 2: Make and Verify Changes
- Make a change, save it, and confirm the update.
- Perform promote and regress operations.
- Review the CT audit log to ensure the CT accessed the member for reading and writing during the processes above.
Sample Audit Log:
WCT81820I Secure Edit Manager starting, USER=TESTUSR, DSN=ISPWTEST.PLAY.DEV1.ASM(IEFBR14)
WCT81201I Access Manager 0014FFD0 starting for ISPWTEST.PLAY.DEV1.ASM
WCT81203I Access Manager 0014FFD0 reading ISPWTEST.PLAY.DEV1.ASM(IEFBR14)
WCT81203I Access Manager 0014FFD0 closing ISPWTEST.PLAY.DEV1.ASM(IEFBR14)
WCT81206I Access Manager 0014FFD0 read 6 records
WCT81820I Secure Edit Manager waiting, USER=TESTUSR, DSN=ISPWTEST.PLAY.DEV1.ASM(IEFBR14)
WCT81174I Copying from local dataset=ISPWTEST.PLAY.DEV1.ASM(IEFBR14)
WCT81190I to server=TESTUSR
WCT81203I Access Manager 0014FFD0 writing ISPWTEST.PLAY.DEV1.ASM(IEFBR14)
WCT81820I Secure Edit Manager waiting, USER=TESTUSR, DSN=ISPWTEST.PLAY.DEV1.ASM(IEFBR14)
WCT81203I Access Manager 0014FFD0 closing ISPWTEST.PLAY.DEV1.ASM(IEFBR14)
WCT81206I Access Manager 0014FFD0 wrote 6 records
WCT81179I Copying from server=TESTUSR
WCT81184I to local dataset=ISPWTEST.PLAY.DEV1.ASM(IEFBR14)
WCT81820I Secure Edit Manager stopping, USER=TESTUSR, DSN=ISPWTEST.PLAY.DEV1.ASM(IEFBR14)
WCT81201I Access Manager 0014FFD0 stopping for ISPWTEST.PLAY.DEV1.ASM