That's the same as any other address space. If you don't have a userid on the 
job, or specify *, then the job inherits from the submitting address space. If 
you have a userid and password, the password must be valid. If you have proxy 
authority, you don't need a password on the JOB statement. 

If you have a CICS transaction that let's the user submit a job without a 
userid, then that job will run with the full authority of the CICS userid. Your 
kindly security auditor may not be pleased. The same applies to any other 
multi-user address space; if you let your users submit jobs, put in appropriate 
controls.


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3


________________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of 
ITschak Mugzach <[email protected]>
Sent: Tuesday, September 10, 2019 3:34 PM
To: [email protected]
Subject: Re: Submitting batch if you don't have TSO

Seymour,

The exception is CICS. If you write to the internal read you don't need to
specify user in the jobcard. This cics attribute is controlled by propcntl
class.

ITschak

בתאריך יום ג׳, 10 בספט׳ 2019, 20:08, מאת Seymour J Metz ‏<[email protected]>:

> Any user who can submit a job can submit a job with USER=. For that job to
> run he needs to either include the password for that userid of have
> surrogate authority to it.
>
> I he is submitting jobs with a password than there is a risk that he will
> compromise that password; surrogate authority is a much safer way to enable
> the submissions.
>
>
> --
> Shmuel (Seymour J.) Metz
> http://mason.gmu.edu/~smetz3
>
>
> ________________________________________
> From: IBM Mainframe Discussion List <[email protected]> on behalf
> of Jantje. <[email protected]>
> Sent: Tuesday, September 10, 2019 7:04 AM
> To: [email protected]
> Subject: Re: Submitting batch if you don't have TSO
>
> On Wed, 4 Sep 2019 14:06:21 -0400, Bob Bridges <[email protected]>
> wrote:
>
> >Not sure where to ask this,
> Here is fine...
>
>
> So, I've read the whole thread and unless I am missing something, I don't
> think you run any more risk than what you would have if none of your users
> have a TSO segment.
>
> As others have pointed out, the USER=<region> is superfluous, because, by
> default, when CICS submits the job it is with that userID anyway.
>
> Then, yes, there are tons of ways to get a job into the system, but
> submitting JCL from TSO in se will not allow any user to submit that job as
> the CICS region userID. Unless of course your security set-up allows
> uncontrolled usage of the USER= clause on the job card.
>
> For any mere mortal to submit a job with a USER= on the job card, your
> security package (TSS in your case, RACF in mine) will have to be
> instructed to allow that particular mortal to do so. SURROGAT does indeed
> cover your fear. Set a (very) generic profile that forbids any surrogate
> user and then set specific profiles to grant the access to only those that
> actually need it.
>
> Apart from that, I would recommend to use the USER= clause on the job card
> of the jobs that are submitted by your CICS regions, but then to specify a
> DIFFERENT user ID than that of the region. Give the CICS region user ID
> (and nobody else) SURROGATE on this other user ID.
>
> O, and, yes, I would worry about what JCL can be submitted from CICS, but
> I understand that is under control in your installation (the assembler
> program, you spoke about).
>
>
> Very best regards,
>
> Jantje.
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to