[prev in list] [next in list] [prev in thread] [next in thread] 

List:       racf-l
Subject:    Re: User authority to submit batch jobs from CICS
From:       Phil Emrich <phil.emrich () GO2VANGUARD ! COM>
Date:       2017-03-28 16:11:53
Message-ID: EA2AED43EEEDCC429BF8F21B26929525AB88982C () VIP-9126 ! corp ! go2vanguard ! com
[Download RAW message or body]

On Tuesday, March 28, 2017 8:13 AM US CDT, Hayim Sokolsky responded:
> A few points here...
> 
I agree with all of the points raised by Hayim, with the following clarifications...

> 1. Never allow application spawned batch jobs to run under a CICS region's
> UserID. The authorities of the CICS region UserID are normally far greater
> than needed or appropriate for application work. (Least Privilege)
> 
> 2. Always require an appropriate USER= for any job spawned by a CICS region.
> 

This will require the CICS transaction performing the Job submission to explicitly \
include a USER= parameter on the JOB statement to either specify an appropriate \
application specific user ID or the user ID of the individual associated with the \
transaction performing the submission which can be obtained by an EXEC CICS ASSIGN \
USERID(fieldname) command issued within the transaction.

The user ID specified on the JOB statement must be covered by a profile in the \
SURROGAT class for which the CICS region user ID appears in the access list.   \
Unfortunately, there is no control in CICS or RACF to prevent a transaction, \
executing under user A's authority from specifying a USER= parameter for user B, \
assuming it is also covered by a SURROGAT profile.  Any such control is left to \
inspection of the application logic and perhaps an argument for use of an application \
specific user ID within submitted jobs contained within the obtained JCL, with no \
requirement on the application to dynamically specify or modify the USER= parameter.  \


> 3. I always recommend leaving PROPCNTL off. PROPCNTL came into existence
> in 1984 or so under MVS/XA 2.2. It was superseded in 1990 by JESJOBS
> (MVS/ESA 3.1.3) which is a far better control.
> 
> Let's say you set up PROPCNTL STCCICS. If STCCICS submits a batch job with no
> USER= and you have BATCHALLRACF in effect, the job will die because it has no
> UserID. The violation will not directly indicate who submitted a job, just that the
> job has no UserID. Not exactly helpful.

What I believe Hayim intended was that the submitted job would fail because it had no \
"acceptable" user ID.  It would fail because JES found the STCCICS user ID was \
covered by the PROPCNTL profile. 

> If you set up JESJOBS SUBMIT.*.*.STCCICS UACC(NONE) with no permits, you
> will see a direct violation for SUBMIT.nodename.jobname.STCCICS being tagged
> to STCCICS for submitting a batch job with its own UserID. This directly points
> out who is submitting the job. (There is more setup work, you have to setup
> JESJOBS for all jobs. It is worth the effort.)

Cheers! 

Philip L. Emrich
Senior Consultant, Professional Services

E-mail: pemrich@go2vanguard.com                   

VANGUARD Integrity Professionals
Cybersecurity Experts and Enterprise Security Software
 
6625 S. Eastern Avenue, Suite 100
Las Vegas, Nevada 89119
Phone: (702) 794.0014 | Fax: (702) 794.0023

Live customer support is available 24/7/365 from the US for all customers
worldwide and locally in other countries. 

Enable Yourself™ Learn more about Vanguard zSecurity University training
classes offered online, on-demand by request, or in a traditional classroom
setting in cities worldwide. 

Find out more at www.go2vanguard.com


[prev in list] [next in list] [prev in thread] [next in thread]