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

List:       racf-l
Subject:    Re: TRUSTED or PRIVILEGED attribute,
From:       "[Data Restricted]" <iplparm () GMAIL ! COM>
Date:       2011-04-14 23:26:12
Message-ID: BANLkTikL6cx8bZ5i5PQzPWT-kygm2oSY+Q () mail ! gmail ! com
[Download RAW message or body]

Hi,
actually CICS checks region User ID quite often (also without MRO, which
adds some extra transactions).
There are many transactions not associated with any terminal and allowed
only for CICS STC User ID.
If you don't allow region User ID to attach those transactions you will
probably have problems with starting/operating CICS*.

* - assuming that security is on :)

Best regards,
Arek Wojtczak
BRE Bank SA


2011/4/14 Walter Farrell <wfarrell@us.ibm.com>
>
> On Thursday, 04/14/2011 at 08:00 EST, "Chase, John" <jchase@USSCO.COM>
> wrote:
> > > -----Original Message-----
> > > From: RACF Discussion List On Behalf Of Robert S. Hansel (RSH)
> > >
> > > VJ,
> > >
> > > In z/OS 1.11, RACROUTE REQUEST=FASTAUTH began honoring Started Task
> > TRUSTED
> > > and PRIVILEGED authority. So now it grants access to CICS
> > transactions.
> >
> > Is that for ANY signed-on user? Or just for the Region User ID?
> >
> > I've never known CICS to even suggest that its address spaces run either
> > TRUSTED or PRIVILEGED.  Indeed, the only "system" attribute I've seen
> > documented for CICS is NOSWAP in the PPT (SCHEDxx) entry, and AFAIK
> > that's only "recommended", not "required".
>
> Likely it would only be for the region ID, as for any other user (signed
> on, or default) CICS would provide the ACEE when making the FASTAUTH call.
>
>
> The only time I know of when the region ID would access a transaction
> would be in some flavors of MRO configuration, I think.
>
> In any case, if you were to run CICS as TRUSTED or PRIVILEGED (or worse,
> with PPT NOPASS, as I've seen some shops do) then you have a very insecure
> system as the transaction code can access non-CICS resources (e.g. data
> sets) and bypass all security checking. That can be particularly
> troublesome for a test environment where programmers can freely install
> uninspected code. It's less troublesome on a production system if you
> perform good code inspections before installing transaction code, but I'm
> not sure how many shops do that. All security within CICS depends on
> having non-malicious transaction code, and for in-house code only good
> code inspections can ensure that.
>
> --
>        Walt
> ------------------------------
> Walt Farrell
> IBM STSM, z/OS Security Design
> e-mail:  wfarrell@us.ibm.com
[prev in list] [next in list] [prev in thread] [next in thread]