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

List:       racf-l
Subject:    Re: Question on &RACUID Usage
From:       Marc Van der Meer1 <Marc_vd_Meer () NL ! IBM ! COM>
Date:       2020-02-18 21:38:17
Message-ID: OFD7AB57B4.AD54A1C3-ON00258512.0076DC63-1582061897757 () notes ! na ! collabserv ! com
[Download RAW message or body]


2. Will not work: GAT entries can only allow, not deny

Sent from my iPhone

> On 18 Feb 2020, at 22:20, Sokolsky, Hayim Z. <hsokolsky@dtcc.com> wrote:
> 
> TSOAUTH JCL is only used by TSO itself. It does not prevent an FTP user
or a batch job from submitting another batch job.
> 
> The FTP exit is one way to prevent SITE FILETYPE=JES.
> 
> The most direct method (excluding exits) is:
> 1. Allow normal users to submit their own jobs via GLOBAL JESJOBS
SUBMIT.*.*.&RACUID/READ
> 2. Prevent the FTP users from being included by that by having a more
specific GLOBAL JESJOBS SUBMIT.*.*.FTP*/NONE
> 3. You also have to ensure that the JESJOBS class profiles do not allow
the FTP users to submit jobs.
> 
> 
> 
> 
> Hayim Sokolsky
> Director, Security Architect
> Security Architecture and Technology
> Technology Risk Management
> DTCC Tampa
> hsokolsky@dtcc.com
> 
> 
> 
> Visit us at www.dtcc.com or follow us on Twitter @The_DTCC  and on
LinkedIn.
> To learn about career opportunities at DTCC, please visit
dtcc.com/careers.
> 
> The views I have expressed in this email are my own personal views, and
are not endorsed or supported by, and do not necessarily express or
reflect, the views, positions or strategies of my employer.
> 
> 
> DTCC Public (White)
> 
> -----Original Message-----
> From: RACF Discussion List <RACF-L@LISTSERV.UGA.EDU> On Behalf Of Lennie
Dymoke-Bradshaw
> Sent: Tuesday, 18 February, 2020 16:06
> To: RACF-L@LISTSERV.UGA.EDU
> Subject: Re: Question on &RACUID Usage
> 
> ATTENTION! This email originated outside of DTCC; exercise caution.
> 
> Fred,
> Interestingly we discussed this situation in the ESWG GSE on Feb 6th in
the UK.
> 
> I was proposing that we need a method to disallow the specification of
passwords on job cards. In nearly all cases it is not needed, and allowing
it produces an unnecessary attack vector for people who can find passwords
and have FTP access to a system to submit batch jobs. (Passwords on job
cards were needed decades ago; but I think it is largely an anachronism
now.)
> 
> Using the JESJOBS SUBMIT profiles gives a way to effectively prevent use
of passwords. This can be used to control all use of job submission of one
user by another user. I think this would need a JESJOBS profile of
SUBMIT.*.*.* with UACC(NONE) and no one in the access list, together with a
GLOBAL profile for JESJOBS with SUBMIT.*.*.&RACUID/READ. I have not tested
this however.
> 
> (I don't actually like this solution as it uses a GLOBAL profile as part
of the security design, whereas I prefer that GLOBAL profiles are used
solely for performance improvements. Then when GLOBAL processing fails, the
underlying profiles still implement the same security.)
> 
> Note also that this solution will need extra controls for those userids
used with SURROGAT processing as JESJOBS trumps SURROGAT.
> 
> I think TSOAUTH controls can only control submission through TSO using
the SUBMIT command. Other uses of the internal reader (such as dynamically
under TSO, or simply via JCL) will bypass TSOAUTH.
> 
> I would like to see IBM introduce a single control in SETROPTS that
disallows use of passwords (and password phrases) in all batch jobs. There
should then be extra controls to allow use of passwords for specific
combinations of users and userids. (All of this is a wish list on my part.)
> 
> Lennie Dymoke-Bradshaw | Security Lead | RSM Partners Ltd
> Web:
https://urldefense.proofpoint.com/v2/url?u=https-3A__nam02.safelinks.protection.outloo \
k.com_-3Furl-3Dwww.rsmpartners.com-26amp-3Bdata-3D02-257C01-257Chsokolsky-2540DTCC.COM \
-257C92a14aab83b64f42061608d7b4b65fa9-257C0465519d7f554d47998b55e2a86f04a8-257C0-257C0 \
-257C637176567821088483-26amp-3Bsdata-3DDMO8oxPtPrMb2vco6vcMmUiZUT8qIvx2QoKpvkoVHL4-25 \
3D-26amp-3Breserved-3D0&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=Vf-yuv3szseS0nmdvf8lCvcWRo \
O8BYFpDNlqcyd8L34&m=DkN1_PWoPlHTY1nOc03q2vjH6a5-0G0Fxb3WDJhF8hw&s=UMNsWYhLbbFIUuiE3YovzImzvQeWeovdJMthvlabkAo&e=


> ‘Dance like no one is watching. Encrypt like everyone is.'
> 
> -----Original Message-----
> From: RACF Discussion List <RACF-L@LISTSERV.UGA.EDU> On Behalf Of Fred
Brewer
> Sent: 18 February 2020 19:51
> To: RACF-L@LISTSERV.UGA.EDU
> Subject: Quesion on &RACUID Usage
> 
> We need to restrict SUBMIT access on a hand full of FTP users. Currently
there is an entry in the Global Access table of JESJOBS
SUBMIT.*.*.&RACUID/READ that gives SUBMIT authority to all users.
> 
> The thought is this should be removed from the GAT and a similar one
added to the RACF database in the JESJOBS class. We would then add more
specific profiles for the users that shouldn't use SUBMIT.
> 
> I've tried a profile of JESJOBS SUBMIT.*.*.&RACUID UACC(READ) but it
doesn't appear that &RACUID works in the profile name outside of GAT. Is
that correct or did I just mess something up??
> 
> I then added JESJOBS SUBMIT.*.*.* UACC(READ) which works but we'd like to
retain keeping users from submitting jobs using a different ID other than
what they're signed on with.
> 
> Any ideas??
> 
> Best Regards,
> Fred
> DTCC DISCLAIMER: This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity to
whom they are addressed. If you have received this email in error, please
notify us immediately and delete the email and any attachments from your
system. The recipient should check this email and any attachments for the
presence of viruses. The company accepts no liability for any damage caused
by any virus transmitted by this email.
> Tenzij hierboven anders aangegeven: / Unless stated otherwise above:
IBM Nederland B.V.
Gevestigd te Amsterdam
Inschrijving Handelsregister Amsterdam Nr. 33054214


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