You've described authorizing CICS to submit, which would be fine if there were only one CICS user. What is needed is for cics to control which users can do what, e.g., limit job submission to transactions that check CICSSUBMIT SUBMIT.nodename.jobname.userid and only allow user1 to submit a job for user2 if user1 has access to CICSSUBMIT SUBMIT.nodename.jobname.user2 and CICS has access to JESJOBS SUBMIT.nodename.jobname.user2
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of Lennie Dymoke-Bradshaw <lenni...@rsmpartners.com> Sent: Tuesday, September 10, 2019 6:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Submitting batch if you don't have TSO If users are able to specify userid and password in the JCL built by a CICS transaction you can still use JESJOBS profiles to selectively allow or disallow them based on the userid and/or the jobname. RDEFINE JESJOBS SUBMIT.nodename.jobname.userid UACC(NONE) So to disallow jobs on all userids (even if the password is included) build, SUBMIT.nodename.*.* Then to allow job JOBNAME1 to be submitted under USER1 construct, SUBMIT.nodename.JOBNAME1.USER1 And grant access to your CICS region userid. You can also define a SURROGAT profile to allow submission without a password. Use of PROPCNTL is a hard rule. It stops ALL security propagation, but not all job submission. Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd Web: http://secure-web.cisco.com/1pVN8rwVYhMkGYzdbOogsAM866IBWF2dEWKdZD0RV9RuojR_wuLYL7A6czr0UrpUigCwghOeewjD239U3nixjB29k5W0H9mwpCZEkdMQj2r4JwzeCEvWcydYa-5e6c-JGjTQfERvHXqTcMa_YurcFmRGBn70iuokXgCf4LQGT3PPz8H-cwr8yshaV41cXWYpypovHZ4AXGoDfvmDDKG0JDEjhtccI4lt61yCpQlaRWDo_3-TzhpEw4P_rkMzBJtr6LPCh1WyPobktFgmFpcf1GTY-TgBwhWMR9Ry3yPLSk86DaVBzvPru-orbmYKxbM9SLZ6ggBz3IMaOIfYqa-k1hHcOAplQdksVc9prNVb7Tp6IgTyo2S3S0cT8e398KvG6bxjWF4c8cTurvjzWBA3OloxwSUmy7fKhSYabIxdkxfeIn0xI3Sx4dPYLKMsH96ty/http%3A%2F%2Fwww.rsmpartners.com ‘Dance like no one is watching. Encrypt like everyone is.’ -----Original Message----- From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Seymour J Metz Sent: 10 September 2019 22:05 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Submitting batch if you don't have TSO 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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of ITschak Mugzach <imugz...@gmail.com> Sent: Tuesday, September 10, 2019 3:34 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 <sme...@gmu.edu>: > 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 <IBM-MAIN@LISTSERV.UA.EDU> on > behalf of Jantje. <jan.moeyers...@gfi.be> > Sent: Tuesday, September 10, 2019 7:04 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Submitting batch if you don't have TSO > > On Wed, 4 Sep 2019 14:06:21 -0400, Bob Bridges <robhbrid...@gmail.com> > 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
