Newbie RACROUTE question: how to *test* authorization?

[David Eisenberg]

Anyone,

I'm just getting familiar with the RACROUTE macro. I have a working example
of the macro with REQUEST=AUTH that generates a violation when
appropriate.

My question is: is there a way to interrogate RACF (presumably via the
RACROUTE macro) to simply *ask* whether or not a particular user has read
or write access to a dataset, but without actually issuing a violation if the
user is unauthorized? All I want to do is get a yea or nay answer (via R15, I
assume), then proceed accordingly and programmatically.

I hope this makes sense... thank you!

David

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Mark Jacobs]

David Eisenberg wrote:
> Anyone,
>
> I'm just getting familiar with the RACROUTE macro. I have a working example
> of the macro with REQUEST=AUTH that generates a violation when
> appropriate.
>
> My question is: is there a way to interrogate RACF (presumably via the
> RACROUTE macro) to simply *ask* whether or not a particular user has read
> or write access to a dataset, but without actually issuing a violation if the
> user is unauthorized? All I want to do is get a yea or nay answer (via R15, I
> assume), then proceed accordingly and programmatically.
>
> I hope this makes sense... thank you!
>
> David
>
>
>

LOG=NOFAIL on the macro call?

--
Mark Jacobs
Time Customer Service
Tampa, FL
----

The dogmas of the quiet past are inadequate to the stormy present.
The occasion is piled high with difficulty, and we must rise to
the occasion. We cannot escape history. We will be remembered in
spite of ourselves. The fiery trial through which we pass will
light us down in honor or dishonor, to the last generation.

Abraham Lincoln

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[McKown, John]

> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-***@BAMA.UA.EDU] On Behalf Of Mark Jacobs
> Sent: Friday, February 22, 2008 1:16 PM
> To: IBM-***@BAMA.UA.EDU
> Subject: Re: Newbie RACROUTE question: how to *test* authorization?
>
>
> David Eisenberg wrote:
> > Anyone,
> >
> > I'm just getting familiar with the RACROUTE macro. I have a
> working example
> > of the macro with REQUEST=AUTH that generates a violation when
> > appropriate.
> >
> > My question is: is there a way to interrogate RACF
> (presumably via the
> > RACROUTE macro) to simply *ask* whether or not a particular
> user has read
> > or write access to a dataset, but without actually issuing
> a violation if the
> > user is unauthorized? All I want to do is get a yea or nay
> answer (via R15, I
> > assume), then proceed accordingly and programmatically.
> >
> > I hope this makes sense... thank you!
> >
> > David
> >
> >
> >
>
> LOG=NOFAIL on the macro call?
>
> --
> Mark Jacobs

I think that LOG=NONE might be better. That way, successful access is
not logged either (in the case where the resource or user is AUDIT'ed).
I'd also use USER= to specify the userid for 3rd party access.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential. It is for intended addressee(s) only. If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense. If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Gregory, Gary G]

Another way is to issue a RACROUTE REQUEST=EXTRACT and specify the UACC
and/or USERACS fields on the extract FIELDS parameter list.

Refer to the RACROUTE Macro Reference appendix-B.

That's what we did on last year when we developed the SAF Interface for
CA Tape Encryption. (Of course, if I'm wrong I'll let Russ bail me
out).

Regards,

Gary

> David Eisenberg wrote:
> > Anyone,
> >
> > I'm just getting familiar with the RACROUTE macro. I have a
> working example
> > of the macro with REQUEST=AUTH that generates a violation when
> > appropriate.
> >
> > My question is: is there a way to interrogate RACF
> (presumably via the
> > RACROUTE macro) to simply *ask* whether or not a particular
> user has read
> > or write access to a dataset, but without actually issuing
> a violation if the
> > user is unauthorized? All I want to do is get a yea or nay
> answer (via R15, I
> > assume), then proceed accordingly and programmatically.
> >
> > I hope this makes sense... thank you!
> >
> > David
> >
> >
> >
>
> LOG=NOFAIL on the macro call?
>
> --
> Mark Jacobs

I think that LOG=NONE might be better. That way, successful access is
not logged either (in the case where the resource or user is AUDIT'ed).
I'd also use USER= to specify the userid for 3rd party access.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[R.S.]

Gregory, Gary G wrote:
> Another way is to issue a RACROUTE REQUEST=EXTRACT and specify the UACC
> and/or USERACS fields on the extract FIELDS parameter list.

Does it mean to check the profile, not the access authorities ?
IMHO bad idea. Access can be granted i.e. due to OPERATIONS attribute or
WARNING. Checking UACC and ACL changes the logic. RACF guys would hate it.

My $0.02
--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego,
nr rejestru przedsibiorców KRS 0000025237
NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Gregory, Gary G]

It's not something that we used to determine whether someone had authority but more of a logging mechanism.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On Behalf Of R.S.
Sent: Friday, February 22, 2008 2:47 PM
To: IBM-***@BAMA.UA.EDU
Subject: Re: Newbie RACROUTE question: how to *test* authorization?

Gregory, Gary G wrote:
> Another way is to issue a RACROUTE REQUEST=EXTRACT and specify the UACC
> and/or USERACS fields on the extract FIELDS parameter list.

Does it mean to check the profile, not the access authorities ?
IMHO bad idea. Access can be granted i.e. due to OPERATIONS attribute or
WARNING. Checking UACC and ACL changes the logic. RACF guys would hate it.

My $0.02
--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego,
nr rejestru przedsibiorców KRS 0000025237
NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[David Eisenberg]

>Another way is to issue a RACROUTE REQUEST=EXTRACT<
>LOG=NONE<

Am I correct when I say that both of these solutions require APF-authorization
(or similar)? Might there be a way that would not require this?

I wouldn't have thought that there would be a security issue with merely
interrogating an authorization level, but perhaps I'm wrong...

David

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[McKown, John]

> -----Original Message-----
> From: IBM Mainframe Discussion List
> [mailto:IBM-***@BAMA.UA.EDU] On Behalf Of David Eisenberg
> Sent: Friday, February 22, 2008 2:43 PM
> To: IBM-***@BAMA.UA.EDU
> Subject: Re: Newbie RACROUTE question: how to *test* authorization?
>
>
> >Another way is to issue a RACROUTE REQUEST=EXTRACT<
> >LOG=NONE<
>
> Am I correct when I say that both of these solutions require
> APF-authorization
> (or similar)? Might there be a way that would not require this?
>
> I wouldn't have thought that there would be a security issue
> with merely
> interrogating an authorization level, but perhaps I'm wrong...
>
> David

Yes, almost any RACROUTE function requires APF authorization. It could
be considered a security breach otherwise because if anybody could do
it, they could possibly find which RACF ids to target in order to get
the access that they want to specific resources, rather than attempting
to crack random IDs and hope for access.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential. It is for intended addressee(s) only. If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense. If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Walt Farrell]

On Fri, 22 Feb 2008 15:21:29 -0500, Gregory, Gary G <***@CA.COM> wrote:
>Another way is to issue a RACROUTE REQUEST=EXTRACT and specify the UACC
>and/or USERACS fields on the extract FIELDS parameter list.
>
>Refer to the RACROUTE Macro Reference appendix-B.
>
>That's what we did on last year when we developed the SAF Interface for
>CA Tape Encryption. (Of course, if I'm wrong I'll let Russ bail me
>out).
>

The obvious disadvantages of that approach, of course, are that it burdens
you with processing groups to determine the users they contain, and of
processing conditional access lists to see if they apply. And it bypasses
GLOBAL processing, which an administrator may have decided to use to grant
accesses. And you can get the wrong answer for general resource classes (if
they're RACLISTed and you make the request the wrong way) or for data sets
(if their generic profile is already in storage but the profile has changed
on the database).

But other than that, and anything else I've forgotten at the moment, and
anything we add in the future, I suppose it's an approach you could use. I
wouldn't, though.

--
Walt Farrell, CISSP
IBM STSM, z/OS Security Design

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Walt Farrell]

On Fri, 22 Feb 2008 13:09:26 -0600, David Eisenberg
<***@OPTONLINE.NET> wrote:

>I'm just getting familiar with the RACROUTE macro. I have a working example
>of the macro with REQUEST=AUTH that generates a violation when
>appropriate.
>
>My question is: is there a way to interrogate RACF (presumably via the
>RACROUTE macro) to simply *ask* whether or not a particular user has read
>or write access to a dataset, but without actually issuing a violation if the
>user is unauthorized? All I want to do is get a yea or nay answer (via R15, I
>assume), then proceed accordingly and programmatically.
>

Running APF-authorized you could specify LOG=NONE.

However, in most cases I recommend simply letting the system make the
appropriate checks and, if necessary, trapping any ABENDs that result.
Otherwise there are a lot of odd conditions you may need to deal with, and
that can cause you to get the wrong answer and act incorrectly. You might
think that the user will have access, and then the request might fail
anyway. Or you might think the user does not have access, and refuse the
action, when it would have worked if you had actually tried it.

Of course, without knowing more about what your program does I can't say for
that you'll have those problems. Still, I generally recommend just letting
the system make the decisions.

--
Walt Farrell, CISSP
IBM STSM, z/OS Security Design

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[shmuel+ (Shmuel Metz , Seymour J.)]

In <LISTSERV%***@BAMA.UA.EDU>, on 02/22/2008
at 02:52 PM, Walt Farrell <***@US.IBM.COM> said:

>Running APF-authorized you could specify LOG=NONE.

>However, in most cases I recommend simply letting the system make the
>appropriate checks

Doesn't LOG=NONE allow that?

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Walt Farrell]

On Fri, 22 Feb 2008 14:43:03 -0600, David Eisenberg
<***@OPTONLINE.NET> wrote:
>>Another way is to issue a RACROUTE REQUEST=EXTRACT<
>>LOG=NONE<
>
>Am I correct when I say that both of these solutions require APF-authorization
>(or similar)? Might there be a way that would not require this?
>

Yes, all the methods discussed so far would require APF authorization. One
that would not (with RACF) is to specify STATUS=ACCESS.

>I wouldn't have thought that there would be a security issue with merely
>interrogating an authorization level, but perhaps I'm wrong...

One could argue that letting you determine your access to resources without
actually trying to use them (and thus without causing audit records) is a
form of hacking. You're looking around trying to figure out what you can
do, rather than simply doing your job.

It may be clearer if you consider that perhaps *you* are not the one looking
around, but perhaps you've unintentionally executed a trojan horse program
of some sort, that is trying to figure out what damage it could do using
your authorities.

I'm not sure why RACF allowed STATUS=ACCESS without APF authorization, but
in hindsight I consider it to have been a mistake. However, changing it at
this point would break an unpredictable number of applications.

By the way, I also would not recommend that you use this function. My
advice in another message about letting the system do the checking still stands.

--
Walt Farrell, CISSP
IBM STSM, z/OS Security Design

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Rick Fochtman]

-----------------------<snip>---------------------
My advice in another message about letting the system do the checking
still stands.
-----------------------<unsnip>--------------------
I strongly agree.

Consider that a potential customer may WANT all the logging he can get,
possibly weeding out dishonest employees, or at least preventing them
from doing damage and revealing their presence. Other shops, like the
ones I've been involved with, may want their own complete control. And
auditors LOVE audit trails, the more complete the better.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[shmuel+ (Shmuel Metz , Seymour J.)]

In <LISTSERV%***@BAMA.UA.EDU>, on 02/23/2008
at 10:07 AM, Walt Farrell <***@US.IBM.COM> said:

>One could argue that letting you determine your access to resources
>without actually trying to use them (and thus without causing audit
>records) is a form of hacking.

Perhaps, but some IBM code does exactly that, and for what seems to be
good cause. I don't recall the details, but it was discussed here in the
last few years.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Chase, John]

> -----Original Message-----
> From: IBM Mainframe Discussion List On Behalf Of Shmuel Metz (Seymour
J.)
>
> In <LISTSERV%***@BAMA.UA.EDU>, on 02/23/2008
> at 10:07 AM, Walt Farrell said:
>
> >One could argue that letting you determine your access to resources
> >without actually trying to use them (and thus without causing audit
> >records) is a form of hacking.
>
> Perhaps, but some IBM code does exactly that, and for what
> seems to be good cause. I don't recall the details, but it
> was discussed here in the last few years.

CICS offers the EXEC CICS QUERY SECURITY command as a supported API.....

-jc-

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Arthur T.]

On 23 Feb 2008 08:07:34 -0800, in bit.listserv.ibm-main
(Message-ID:<LISTSERV%***@BAMA.UA.EDU>)
***@US.IBM.COM (Walt Farrell) wrote:

>>I wouldn't have thought that there would be a security
>>issue with merely
>>interrogating an authorization level, but perhaps I'm
>>wrong...
>
>One could argue that letting you determine your access to
>resources without
>actually trying to use them (and thus without causing
>audit records) is a
>form of hacking. You're looking around trying to figure
>out what you can
>do, rather than simply doing your job.

For your own userid, you can use LISTDSD or RLIST to
check resource authorization without cutting audit
records. But, unless you have sufficient RACF or APF
authorization, you can't check the access *someone else*
has to resources.


--
I cannot receive mail at the address this was sent from.
To reply directly, send to ar23hur "at" intergate "dot" com

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[David Eisenberg]

>For your own userid, you can use LISTDSD or RLIST to check resource
authorization without cutting audit records.<

That would be perfect... is LISTDSD something I can do from within an
assembler program? Or is there an assembler macro equivalent?

All I really need to do is, from within an assembler application, invoke some
function that will tell me whether or not the current userid is authorized via a
given RACF profile to *read* a resource. The userid will always be either the
person who is logged onto TSO or is the submitter of a batch job. It will never
be anyone else.

I guess I should have said that up front... sorry...

David

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[George Fogg]

You can call IRRSEQ00 (R_Admin) services within an assembler program to
issue RACF commands like LISTDSD and RLIST and you don't need to be APFed
for what you want to do. No audit records are cut and no messages to syslog
for violations.
The command results are sent back into a buffer that you need to parse to
find the access level message.
See http://tinyurl.com/29f4x9 for the manual, and if you wish, I can send
you an assembler example on how to do this to get you started.

George Fogg

PS: IBM states that command output is not a programming interface.


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On Behalf
Of David Eisenberg
Sent: Saturday, February 23, 2008 6:29 PM
To: IBM-***@BAMA.UA.EDU
Subject: Re: Newbie RACROUTE question: how to *test* authorization?

>For your own userid, you can use LISTDSD or RLIST to check resource
authorization without cutting audit records.<

That would be perfect... is LISTDSD something I can do from within an
assembler program? Or is there an assembler macro equivalent?

All I really need to do is, from within an assembler application, invoke
some
function that will tell me whether or not the current userid is authorized
via a
given RACF profile to *read* a resource. The userid will always be either
the
person who is logged onto TSO or is the submitter of a batch job. It will
never
be anyone else.

I guess I should have said that up front... sorry...

David

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[David Eisenberg]

>All I really need to do is, from within an assembler application, invoke some
function that will tell me whether or not the current userid is authorized via a
given RACF profile to *read* a resource. The userid will always be either the
person who is logged onto TSO or is the submitter of a batch job. It will never
be anyone else.<

And of course (as I indicated in my original post), I need to be able to do this
without producing a RACF violation if the user is not authorized to read the
resource.

I'll shut up now...

David

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[P***@AIM.COM]

On Sat, 23 Feb 2008 10:07:24 -0600, Walt Farrell wrote:
>
>One could argue that letting you determine your access to resources without
>actually trying to use them (and thus without causing audit records) is a
>form of hacking. You're looking around trying to figure out what you can
>do, rather than simply doing your job.
>
>I'm not sure why RACF allowed STATUS=ACCESS without APF authorization, but
>in hindsight I consider it to have been a mistake. However, changing it at
>this point would break an unpredictable number of applications.
>
That may be the price of increased security awareness. Perhaps YA
PARMLIB option to control it or enable logging negative responses?

Should similar concerns apply to LISTDSD, mentioned elsewhere in
this thread?

Do sites similarly log, audit, and investigate storage protection
exceptions?

OTOH, I can readily imagine a utility that attempts an access but
on failure proceeds with restricted function. As an example for
Shmuel, see message GIM69158I, or perhaps IEB1099I.

--gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Steve Comstock]

IBM-***@BAMA.UA.EDU wrote:
> On Sat, 23 Feb 2008 10:07:24 -0600, Walt Farrell wrote:
>> One could argue that letting you determine your access to resources without
>> actually trying to use them (and thus without causing audit records) is a
>> form of hacking. You're looking around trying to figure out what you can
>> do, rather than simply doing your job.
>>
>> I'm not sure why RACF allowed STATUS=ACCESS without APF authorization, but
>> in hindsight I consider it to have been a mistake. However, changing it at
>> this point would break an unpredictable number of applications.
>>
> That may be the price of increased security awareness. Perhaps YA
> PARMLIB option to control it or enable logging negative responses?
>
> Should similar concerns apply to LISTDSD, mentioned elsewhere in
> this thread?
>
> Do sites similarly log, audit, and investigate storage protection
> exceptions?
>
> OTOH, I can readily imagine a utility that attempts an access but
> on failure proceeds with restricted function. As an example for
> Shmuel, see message GIM69158I, or perhaps IEB1099I.
>
> --gil

And YA email address, eh, Paul? Is this another
manifestation of the merger finally taking place?


Kind regards,

-Steve Comstock
The Trainer's Friend, Inc.

303-393-8716
http://www.trainersfriend.com

z/OS Application development made easier
* Our classes include
+ How things work
+ Programming examples with realistic applications
+ Starter / skeleton code
+ Complete working programs
+ Useful utilities and subroutines
+ Tips and techniques

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[shmuel+ (Shmuel Metz , Seymour J.)]

In <LISTSERV%***@BAMA.UA.EDU>, on 02/24/2008
at 12:13 PM, "IBM-***@BAMA.UA.EDU" <***@AIM.COM> said:

>OTOH, I can readily imagine a utility that attempts an access but on
>failure proceeds with restricted function. As an example for Shmuel, see
>message GIM69158I, or perhaps IEB1099I.

I was thinking of a case where it checks authorization before it knows
that the access will be required, as part of its initialization. In the
situation you describe I would wasn't RACF to log the violation, assuming
that I didn't misunderstand you.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Mark Zelden]

On Sat, 23 Feb 2008 19:01:19 -0500, Shmuel Metz (Seymour J.)
<shmuel+ibm-***@PATRIOT.NET> wrote:

>In <LISTSERV%***@BAMA.UA.EDU>, on 02/23/2008
> at 10:07 AM, Walt Farrell <***@US.IBM.COM> said:
>
>>One could argue that letting you determine your access to resources
>>without actually trying to use them (and thus without causing audit
>>records) is a form of hacking.
>
>Perhaps, but some IBM code does exactly that, and for what seems to be
>good cause. I don't recall the details, but it was discussed here in the
>last few years.
>

You may be thinking of ISPF 3.4 and data set name hiding or may be
thinking of ISPF 3.4 checking for ALTER access to the catalog.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:***@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Reza Fatemi]

I don't think you are fixing the problem correctly. Now I do apologize but
if it was me I go MVS native and Forget about installing VM

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On Behalf
Of Mark Zelden
Sent: Sunday, February 24, 2008 10:42 AM
To: IBM-***@BAMA.UA.EDU
Subject: Re: Newbie RACROUTE question: how to *test* authorization?

On Sat, 23 Feb 2008 19:01:19 -0500, Shmuel Metz (Seymour J.)
<shmuel+ibm-***@PATRIOT.NET> wrote:

>In <LISTSERV%***@BAMA.UA.EDU>, on 02/23/2008
> at 10:07 AM, Walt Farrell <***@US.IBM.COM> said:
>
>>One could argue that letting you determine your access to resources
>>without actually trying to use them (and thus without causing audit
>>records) is a form of hacking.
>
>Perhaps, but some IBM code does exactly that, and for what seems to be
>good cause. I don't recall the details, but it was discussed here in the
>last few years.
>

You may be thinking of ISPF 3.4 and data set name hiding or may be
thinking of ISPF 3.4 checking for ALTER access to the catalog.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:***@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 2898 (20080223) __________

The message was checked by ESET NOD32 Antivirus.

part000.txt - is OK

http://www.eset.com



__________ Information from ESET NOD32 Antivirus, version of virus signature
database 2898 (20080223) __________

The message was checked by ESET NOD32 Antivirus.

Email message - is OK
Email message - is OK

http://www.eset.com


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Reza Fatemi]

I HAVENT WORKED IN THAT AREA FOR a while but I think possibly I can look the
dump and fix it permanently

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On Behalf
Of Reza Fatemi
Sent: Sunday, February 24, 2008 7:10 PM
To: IBM-***@BAMA.UA.EDU
Subject: Re: Newbie RACROUTE question: how to *test* authorization?
Importance: High

I don't think you are fixing the problem correctly. Now I do apologize but
if it was me I go MVS native and Forget about installing VM

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On Behalf
Of Mark Zelden
Sent: Sunday, February 24, 2008 10:42 AM
To: IBM-***@BAMA.UA.EDU
Subject: Re: Newbie RACROUTE question: how to *test* authorization?

On Sat, 23 Feb 2008 19:01:19 -0500, Shmuel Metz (Seymour J.)
<shmuel+ibm-***@PATRIOT.NET> wrote:

>In <LISTSERV%***@BAMA.UA.EDU>, on 02/23/2008
> at 10:07 AM, Walt Farrell <***@US.IBM.COM> said:
>
>>One could argue that letting you determine your access to resources
>>without actually trying to use them (and thus without causing audit
>>records) is a form of hacking.
>
>Perhaps, but some IBM code does exactly that, and for what seems to be
>good cause. I don't recall the details, but it was discussed here in the
>last few years.
>

You may be thinking of ISPF 3.4 and data set name hiding or may be
thinking of ISPF 3.4 checking for ALTER access to the catalog.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:***@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 2898 (20080223) __________

The message was checked by ESET NOD32 Antivirus.

part000.txt - is OK

http://www.eset.com



__________ Information from ESET NOD32 Antivirus, version of virus signature
database 2898 (20080223) __________

The message was checked by ESET NOD32 Antivirus.

Email message - is OK
Email message - is OK

http://www.eset.com


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

__________ Information from ESET NOD32 Antivirus, version of virus signature
database 2898 (20080223) __________

The message was checked by ESET NOD32 Antivirus.

part000.txt - is OK

http://www.eset.com



__________ Information from ESET NOD32 Antivirus, version of virus signature
database 2898 (20080223) __________

The message was checked by ESET NOD32 Antivirus.

Email message - is OK
Email message - is OK

http://www.eset.com


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Randy Evans]

>>
>>>One could argue that letting you determine your access to resources
>>>without actually trying to use them (and thus without causing audit
>>>records) is a form of hacking.
>>
>>Perhaps, but some IBM code does exactly that, and for what seems to be
>>good cause. I don't recall the details, but it was discussed here in
the
>>last few years.
>>
>
>You may be thinking of ISPF 3.4 and data set name hiding or may be
>thinking of ISPF 3.4 checking for ALTER access to the catalog.
>

Following extracted from the CICS/TS RACF Security Guide:

"2.7.6.2 Checking which transactions to offer a user
You can use the QUERY SECURITY command to check whether a user is
authorized to use a particular transaction before displaying the
transaction code as part of an introductory menu. When you use the
command for this purpose, you will probably want to avoid logging the
checks for users who are not allowed to use certain transactions. To do
this, use the NOLOG option."

...and the QUERY SECURITY command invokes a RACROUTE to perform this
function. So CICS is documenting use of preemptive RACROUTE requests as
reasonable design in presenting usable options on a user's menu.

Randy Evans, Viaserv, Inc.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Chase, John]

> -----Original Message-----
> From: IBM Mainframe Discussion List On Behalf Of Randy Evans
>
> >>
> >>>One could argue that letting you determine your access to
> resources
> >>>without actually trying to use them (and thus without causing audit
> >>>records) is a form of hacking.
> >>
> >>Perhaps, but some IBM code does exactly that, and for what
> seems to be
> >>good cause. I don't recall the details, but it was discussed here in
> the
> >>last few years.
> >>
> >
> >You may be thinking of ISPF 3.4 and data set name hiding or may be
> >thinking of ISPF 3.4 checking for ALTER access to the catalog.
> >
>
> Following extracted from the CICS/TS RACF Security Guide:
>
> "2.7.6.2 Checking which transactions to offer a user
> You can use the QUERY SECURITY command to check whether a
> user is authorized to use a particular transaction before
> displaying the transaction code as part of an introductory
> menu. When you use the command for this purpose, you will
> probably want to avoid logging the checks for users who are
> not allowed to use certain transactions. To do this, use the
> NOLOG option."
>
> ...and the QUERY SECURITY command invokes a RACROUTE to
> perform this function. So CICS is documenting use of
> preemptive RACROUTE requests as reasonable design in
> presenting usable options on a user's menu.

I've "heard" that CICS issues RACROUTE REQUEST=FASTAUTH "under the
covers" to do that..... CICS also issues RACROUTE
REQUEST=LIST,GLOBAL=YES during its startup for each of the
"CICS-related" classes "activated" via the DFHSIT Xyyy parms, so
RACLISTing of one sort or another may be a "pre-req" for FASTAUTH.

-jc-

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Rick Fochtman]

--------------------------<snip>-------------------

>Following extracted from the CICS/TS RACF Security Guide:
>
>"2.7.6.2 Checking which transactions to offer a user
>You can use the QUERY SECURITY command to check whether a user is
>authorized to use a particular transaction before displaying the
>transaction code as part of an introductory menu. When you use the
>command for this purpose, you will probably want to avoid logging the
>checks for users who are not allowed to use certain transactions. To do
>this, use the NOLOG option."
>
>...and the QUERY SECURITY command invokes a RACROUTE to perform this
>function. So CICS is documenting use of preemptive RACROUTE requests as
>reasonable design in presenting usable options on a user's menu.
>
>
--------------------------<unsnip>-------------------
IIRC, under this particular set of circumstances, RACROUTE will do the
equivalent of a FRACHECK, which does no logging. Has to do with the
resource definitions for CICS transactions.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Wayne Driscoll]

One major difference. In CICS, the query security is for a subset of RACF
information, and is already running in the proper environment, ie CICS, and
is using the logged on userid's ACEE. You cannot issue a query security to
see if another user has the authority, and you also cannot check for access
to non-CICS resources. Because of things like PADS or WHEN() processing, it
is hard to guarantee that you can get the same answer if the environment is
different.

Wayne Driscoll
Product Developer

***@comcast.net
(Direct) [phone]
(Mobile) [phone]



-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On Behalf
Of Randy Evans
Sent: Monday, February 25, 2008 9:05 AM
To: IBM-***@BAMA.UA.EDU
Subject: Re: Newbie RACROUTE question: how to *test* authorization?

>>
>>>One could argue that letting you determine your access to resources
>>>without actually trying to use them (and thus without causing audit
>>>records) is a form of hacking.
>>
>>Perhaps, but some IBM code does exactly that, and for what seems to be
>>good cause. I don't recall the details, but it was discussed here in
the
>>last few years.
>>
>
>You may be thinking of ISPF 3.4 and data set name hiding or may be
>thinking of ISPF 3.4 checking for ALTER access to the catalog.
>

Following extracted from the CICS/TS RACF Security Guide:

"2.7.6.2 Checking which transactions to offer a user
You can use the QUERY SECURITY command to check whether a user is
authorized to use a particular transaction before displaying the
transaction code as part of an introductory menu. When you use the
command for this purpose, you will probably want to avoid logging the
checks for users who are not allowed to use certain transactions. To do
this, use the NOLOG option."

...and the QUERY SECURITY command invokes a RACROUTE to perform this
function. So CICS is documenting use of preemptive RACROUTE requests as
reasonable design in presenting usable options on a user's menu.

Randy Evans, Viaserv, Inc.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Chase, John]

> -----Original Message-----
> From: IBM Mainframe Discussion List On Behalf Of Wayne Driscoll
>
> One major difference. In CICS, the query security is for a
> subset of RACF information, and is already running in the
> proper environment, ie CICS, and is using the logged on
> userid's ACEE. You cannot issue a query security to see if
> another user has the authority, ...

True.

> ... and you also cannot check for
> access to non-CICS resources.

Check out the RESCLASS keyword on QUERY SECURITY:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DFHP4C00/1.16
8

"RESCLASS(data-value)
specifies an 8-character field identifying the name of a valid resource
class, that could be non-CICS, in the ESM. The class name identified by
RESCLASS is treated literally with no translation."

-jc-

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Dave Kopischke]

On Sat, 23 Feb 2008 10:07:24 -0600, Walt Farrell wrote:

>One could argue that letting you determine your access to resources without
>actually trying to use them (and thus without causing audit records) is a
>form of hacking. You're looking around trying to figure out what you can
>do, rather than simply doing your job.
>

We have a JCL checker application that verifies dataset access for a JOB.
Through routine use of this product, we end up with thousands of access
warnings on our daily RACF reports. This is not a hacking attempt. If there
were hacking attempts occuring, it would be tough to see them through the
noise though.

I'm going to try to see if I can have this product changed to use a non-logged
access check.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Don Leahy]

On Mon, Feb 25, 2008 at 2:08 PM, Dave Kopischke
<***@oppenheimerfunds.com> wrote:
> On Sat, 23 Feb 2008 10:07:24 -0600, Walt Farrell wrote:
>
>
> >One could argue that letting you determine your access to resources without
> >actually trying to use them (and thus without causing audit records) is a
>
> >form of hacking. You're looking around trying to figure out what you can
> >do, rather than simply doing your job.
> >
>
> We have a JCL checker application that verifies dataset access for a JOB.
> Through routine use of this product, we end up with thousands of access
> warnings on our daily RACF reports. This is not a hacking attempt. If there
> were hacking attempts occuring, it would be tough to see them through the
> noise though.
>
> I'm going to try to see if I can have this product changed to use a non-logged
> access check.
>
Another legitimate (IMO) use of this sort of function is a to
automatically convert an ISPF Edit request to View in the event that
the user does not have UPDATE access to the requested data set. This
helps to reduce accidental violations.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Paul Gilmartin]

On Mon, 25 Feb 2008 13:08:53 -0600, Dave Kopischke wrote:
>
>We have a JCL checker application that verifies dataset access for a JOB.
>Through routine use of this product, we end up with thousands of access
>warnings on our daily RACF reports. This is not a hacking attempt. If there
>were hacking attempts occuring, it would be tough to see them through the
>noise though.
>
I wonder that you get "thousands of access warnings ... daily". Are
your programmers commiting so many potential access errors in the course
of coding their JCL? How many programmers does it take to do that?

And my thanks to Randy Evans for reminding us that design of interactive
systems imposes requirements that are not encountered in batch jobs.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Don Leahy]

On Tue, Feb 26, 2008 at 1:48 AM, Paul Gilmartin <***@aim.com> wrote:
> On Mon, 25 Feb 2008 13:08:53 -0600, Dave Kopischke wrote:
> >
> >We have a JCL checker application that verifies dataset access for a JOB.
> >Through routine use of this product, we end up with thousands of access
> >warnings on our daily RACF reports. This is not a hacking attempt. If there
> >were hacking attempts occuring, it would be tough to see them through the
> >noise though.
> >
> I wonder that you get "thousands of access warnings ... daily". Are
> your programmers commiting so many potential access errors in the course
> of coding their JCL? How many programmers does it take to do that?

Perhaps the programmers are coding Production JCL and then running it
through the syntax checker before handing it over to Operations.
That would account for the # of access warnings.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Mark Zelden]

On Tue, 26 Feb 2008 00:48:34 -0600, Paul Gilmartin <***@AIM.COM> wrote:


>I wonder that you get "thousands of access warnings ... daily". Are
>your programmers commiting so many potential access errors in the course
>of coding their JCL? How many programmers does it take to do that?
>

In many shops the application programmers "control" and update production
JCL related to their applications. However, the access control software (RACF,
ACF2, TSS) does is (correctly) set up to not allow update to production
data sets and in some cases not even read access (for example, payroll).
The JCL "check" products can test this access when you scan your JCL.

Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:***@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Walt Farrell]

On Sat, 23 Feb 2008 20:32:13 -0600, David Eisenberg
<***@OPTONLINE.NET> wrote:

>And of course (as I indicated in my original post), I need to be able to do
this
>without producing a RACF violation if the user is not authorized to read the
>resource.

What you haven't said, though, is why you "need" to avoid a violation
message. If the user has given you a data set name and asked you to operate
on it, and he does not have the proper authority, then it is most
appropriate to have the violation occur. And it's most appropriate to get
that violation by simply acceding to the user's request and trying to
operate upon the data set as he requested.

If the user has not asked you to operate on the data set, why are you doing
so? Perhaps it would help if you explained your application's purpose.

--
Walt Farrell, CISSP
IBM STSM, z/OS Security Design

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Walt Farrell]

On Mon, 25 Feb 2008 13:08:53 -0600, Dave Kopischke
<***@OPPENHEIMERFUNDS.COM> wrote:

>On Sat, 23 Feb 2008 10:07:24 -0600, Walt Farrell wrote:
>
>>One could argue that letting you determine your access to resources without
>>actually trying to use them (and thus without causing audit records) is a
>>form of hacking. You're looking around trying to figure out what you can
>>do, rather than simply doing your job.
>>
>
>We have a JCL checker application that verifies dataset access for a JOB.
>Through routine use of this product, we end up with thousands of access
>warnings on our daily RACF reports. This is not a hacking attempt. If there
>were hacking attempts occuring, it would be tough to see them through the
>noise though.
>
>I'm going to try to see if I can have this product changed to use a non-logged
>access check.

That makes sense. Perhaps what you need, though, is a method allowing your
application developers to run the JCL checking procedure against the proper
user ID. You could let them put the JCL into a library with a known name,
for example, and then have them run a program that either:
(a) issued a command to run an STC to do the check, with the STC running
under a more appropriate user ID; or
(b) switched identity to the proper production ID and then submitted the JCL
Check job.


--
Walt Farrell, CISSP
IBM STSM, z/OS Security Design

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Brian Fitzgibbon]

There are also "newer" JCL checkers on the market that allow remote
checking of JCL on production from the users on the test side. Similar
to the description outlined by Walt Farrell.

Brian


Walt Farrell wrote:
> On Mon, 25 Feb 2008 13:08:53 -0600, Dave Kopischke
> <***@OPPENHEIMERFUNDS.COM> wrote:
>
>
>> On Sat, 23 Feb 2008 10:07:24 -0600, Walt Farrell wrote:
>>
>>
>>> One could argue that letting you determine your access to resources without
>>> actually trying to use them (and thus without causing audit records) is a
>>> form of hacking. You're looking around trying to figure out what you can
>>> do, rather than simply doing your job.
>>>
>>>
>> We have a JCL checker application that verifies dataset access for a JOB.
>> Through routine use of this product, we end up with thousands of access
>> warnings on our daily RACF reports. This is not a hacking attempt. If there
>> were hacking attempts occuring, it would be tough to see them through the
>> noise though.
>>
>> I'm going to try to see if I can have this product changed to use a non-logged
>> access check.
>>
>
> That makes sense. Perhaps what you need, though, is a method allowing your
> application developers to run the JCL checking procedure against the proper
> user ID. You could let them put the JCL into a library with a known name,
> for example, and then have them run a program that either:
> (a) issued a command to run an STC to do the check, with the STC running
> under a more appropriate user ID; or
> (b) switched identity to the proper production ID and then submitted the JCL
> Check job.
>
>
>

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[shmuel+ (Shmuel Metz , Seymour J.)]

In
<!&!AAAAAAAAAAAYAAAAAAAAAB66LUsEaSBFo+HxrSDe0gLCgAAAEAAAAFm5HdUvc41IlN8HF88O3xIBAAAAAA==@cox.net>,
on 02/24/2008
at 07:10 PM, Reza Fatemi <***@COX.NET> said:

>You may be thinking of ISPF 3.4 and data set name hiding or may be
>thinking of ISPF 3.4 checking for ALTER access to the catalog.

The latter sounds familiar; it was in a thread about violation messages
for resources that the user wasn't actually trying to use.

--
Shmuel (Seymour J.) Metz, SysProg and JOAT
ISO position; see <http://patriot.net/~shmuel/resume/brief.html>
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Randy Evans]

>>
>>...and the QUERY SECURITY command invokes a RACROUTE to perform this
>>function. So CICS is documenting use of preemptive RACROUTE requests
as
>>reasonable design in presenting usable options on a user's menu.
>>
>>
>--------------------------<unsnip>-------------------
>IIRC, under this particular set of circumstances, RACROUTE will do the
>equivalent of a FRACHECK, which does no logging. Has to do with the
>resource definitions for CICS transactions.
>

No FRACHECK is performed in this case according to the doc. CICS
performs a RACROUTE REQUEST=FASTAUTH for QUERY SECURITY with RESTYPE and
a RACROUTE REQUEST=AUTH for QUERY SECURITY with RESCLASS. This is stated
in the CICS/TS RACF Security Guide.

Randy Evans, Viaserv, Inc.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Dave Kopischke]

On Tue, 26 Feb 2008 00:48:34 -0600, Paul Gilmartin wrote:

>On Mon, 25 Feb 2008 13:08:53 -0600, Dave Kopischke wrote:
>>
>>We have a JCL checker application that verifies dataset access for a JOB.
>>Through routine use of this product, we end up with thousands of access
>>warnings on our daily RACF reports. This is not a hacking attempt. If there
>>were hacking attempts occuring, it would be tough to see them through the
>>noise though.
>>
>I wonder that you get "thousands of access warnings ... daily". Are
>your programmers commiting so many potential access errors in the course
>of coding their JCL? How many programmers does it take to do that?
>

When I run a JCL scan under TSO, the product uses my user ID information to
evaluate access. If I'm not going to be allowed access, it notes it and logs it
even though when the JCL actually runs in production, it will use a different
JOB card and different USER parameters.

I can change this by coding JCL parameters to mimic production, but if I don't
notice it or don't know what the proper parameters are, I get security
violations. If it's a large JOB, I get lots of security violations. It's still not a
hacking attempt.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[George Fogg]

>Dave wrote:
>I can change this by coding JCL parameters to mimic production, but if I
don't notice it or don't know what the proper parameters are, I get security
>violations. If it's a large JOB, I get lots of security violations. It's
still not a hacking attempt.
>

Perhaps someone else could use your JCL scan to hack with? I don't know and
I wouldn't do it myself.

I wrote a REXX interface to our JCL scan product so it can check a
production userid access to a dataset resource. I told the folks that use it
that they must understand the fact that they cannot rely on the results of
the access when the "real" task opens the dataset in its environment during
OPEN time if:
1.) the task at OPEN is running Privileged or Trusted,
2.) the task at OPEN happened to have a trusted token,
3.) the task flipped one or more of those "bypass authority checking" bits
before OPEN,
4.) the task at OPEN when the REQUEST=AUTH was a CSA or PRIVATE request,
therefore bypassing GAC authority,
5.) that the Rexx interface call does not check for conditional access
entries.
The REXX interface function does a RACROUTE REQUEST=AUTH and uses:
USERID=user_id (for third party checking)
STATUS=ACCESS (send back the access code (NONE, READ, UPDATE, CONTROL,
ALTER)
LOG=NONE (do not cut SMF audit records)
And a few other necessary parameters. USERID and LOG require APF.
I also check if the caller has the authority to use this function with a
profile in the FACILITY class.
George Fogg

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Dave Kopischke]

On Tue, 26 Feb 2008 08:35:10 -0600, Walt Farrell wrote:

>On Mon, 25 Feb 2008 13:08:53 -0600, Dave Kopischke
><***@OPPENHEIMERFUNDS.COM> wrote:
>
>>On Sat, 23 Feb 2008 10:07:24 -0600, Walt Farrell wrote:
>>
>>>One could argue that letting you determine your access to resources
without
>>>actually trying to use them (and thus without causing audit records) is a
>>>form of hacking. You're looking around trying to figure out what you can
>>>do, rather than simply doing your job.
>>>
>>
>>We have a JCL checker application that verifies dataset access for a JOB.
>>Through routine use of this product, we end up with thousands of access
>>warnings on our daily RACF reports. This is not a hacking attempt. If there
>>were hacking attempts occuring, it would be tough to see them through the
>>noise though.
>>
>>I'm going to try to see if I can have this product changed to use a non-
logged
>>access check.
>
>That makes sense. Perhaps what you need, though, is a method allowing
your
>application developers to run the JCL checking procedure against the proper
>user ID. You could let them put the JCL into a library with a known name,
>for example, and then have them run a program that either:
>(a) issued a command to run an STC to do the check, with the STC running
>under a more appropriate user ID; or
>(b) switched identity to the proper production ID and then submitted the JCL
>Check job.
>

Walt,
This sounds like a better approach, but we've got different combinations of
USER= parameters to match up to dataset requirements within particular JOBs.
I'll have to map this out and see if something like this can be workable.

Thanks !!!!!!!!!!!!

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[David Eisenberg]

>If the user has given you a data set name and asked you to operate on it,
and he does not have the proper authority, then it is most appropriate to
have the violation occur.<

Not in this case, IMO.

The violations are occurring as a result of a text string scan across all
members of a production source code library in CA's Panvalet format. The
library contains hundreds of members, but a handful of them have
UACC=NONE. Here's how: Panvalet supports *member-level* security. We
create RACF "pseudo-profiles" that contain the member name as the last
qualifier, and if we wish to read-protect a member, we set that profile to have
UACC=NONE. A Panvalet security exit constructs the pseudo-profile name, and
invokes RACROUTE to see if read access to the member is permitted or not.

Under normal circumstances, if the security exit detects a violation of any
kind, we want to know about it. But if a programmer issues a text scan of the
entire library, he/she typically has no need or intention of scanning the
handful of read-protected members. He's just looking for all occurrences of a
variable name in the source code library (for example). The problem is that
there's no easy way to instruct the scanning program to skip the read-
protected members. So the programmer gets a meaningless violation for each
read-protected member in the library.

In my view, this ought to be an acceptable use of LOG=NONE. If the
programmer isn't allowed to view the member, the security exit won't let it be
scanned. The members are secure. Why record endless violations that are
essentially noise, and might mask an actual hacking attempt?

David

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Farley, Peter x23353]

> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:IBM-***@BAMA.UA.EDU] On
> Behalf Of David Eisenberg
> Sent: Tuesday, February 26, 2008 8:54 PM
> To: IBM-***@BAMA.UA.EDU
> Subject: Re: Newbie RACROUTE question: how to *test* authorization?
<Snipped>
> The violations are occurring as a result of a text string scan across
all
> members of a production source code library... The problem is that
> there's no easy way to instruct the scanning program to skip the read-
> protected members. So the programmer gets a meaningless violation for
each
> read-protected member in the library.
>
> In my view, this ought to be an acceptable use of LOG=NONE. If the
> programmer isn't allowed to view the member, the security exit won't
let
> it be scanned. The members are secure. Why record endless violations
that
> are essentially noise, and might mask an actual hacking attempt?

I agree with you about this type of "harmless" testing of authority to
access. However, given the god-like authority of auditors these days,
maybe it would be more helpful to you (and easier to get past the
auditors) to have an additional parameter to RACROUTE which said, in
effect, "Don't tell me about any violations. I don't care if you record
the attempted access in SMF, but don't bother telling me about it."

I.E., suppress the message but go ahead and cut a record if you want to.

Of course, that doesn't address the SMF noise issue for those who really
need to track attempted accesses to truly important resources to detect
actual hacking attempts.

Just my USD$0.02 worth.

Peter
This message and any attachments are intended only for the use of the addressee and
may contain information that is privileged and confidential. If the reader of the
message is not the intended recipient or an authorized representative of the
intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication in
error, please notify us immediately by e-mail and delete the message and any
attachments from your system.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[George Fogg]

>I agree with you about this type of "harmless" testing of authority to
access. However, given the god-like authority of auditors these days, maybe
it would be more helpful to you (and easier to get past the
auditors) to have an additional parameter to RACROUTE which said, in effect,
"Don't tell me about any violations. I don't care if you record the
attempted access in SMF, but don't bother telling me about it."

I.E., suppress the message but go ahead and cut a record if you want to.
>
You can supress the ICH408I message is you wish with MSGSUPP=YES in the
RACROUTE=AUTH call and you can supress the message and SMF logging with
LOG=NONE.
My .02 cents worth.
George Fogg

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Walt Farrell]

On Tue, 26 Feb 2008 19:53:42 -0600, David Eisenberg
<***@OPTONLINE.NET> wrote:

>Not in this case, IMO.
>
>The violations are occurring as a result of a text string scan across all
>members of a production source code library in CA's Panvalet format. The
>library contains hundreds of members, but a handful of them have
>UACC=NONE. Here's how: Panvalet supports *member-level* security. We
>create RACF "pseudo-profiles" that contain the member name as the last
>qualifier, and if we wish to read-protect a member, we set that profile to have
>UACC=NONE. A Panvalet security exit constructs the pseudo-profile name, and
>invokes RACROUTE to see if read access to the member is permitted or not.

I would agree that's a reasonable case for using LOG=NONE. It will,
however, require you to run APF-authorized, and I think it's appropriate to
require APF in this case.

--
Walt Farrell, CISSP
IBM STSM, z/OS Security Design

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Walt Farrell]

On Tue, 26 Feb 2008 21:49:22 -0500, Farley, Peter x23353
<***@BROADRIDGE.COM> wrote:

>I agree with you about this type of "harmless" testing of authority to
>access. However, given the god-like authority of auditors these days,
>maybe it would be more helpful to you (and easier to get past the
>auditors) to have an additional parameter to RACROUTE which said, in
>effect, "Don't tell me about any violations. I don't care if you record
>the attempted access in SMF, but don't bother telling me about it."
>
>I.E., suppress the message but go ahead and cut a record if you want to.
>
>Of course, that doesn't address the SMF noise issue for those who really
>need to track attempted accesses to truly important resources to detect
>actual hacking attempts.

That's MSGSUPP=YES, which does not require APF authorization because it does
not hide anything from the auditors.

--
Walt Farrell, CISSP
IBM STSM, z/OS Security Design

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[Walt Farrell]

On Tue, 26 Feb 2008 16:08:17 -0800, George Fogg <***@NWLINK.COM> wrote:

>I wrote a REXX interface to our JCL scan product so it can check a
>production userid access to a dataset resource. I told the folks that use it
>that they must understand the fact that they cannot rely on the results of
>the access when the "real" task opens the dataset in its environment during
>OPEN time if:
>1.) the task at OPEN is running Privileged or Trusted,
>2.) the task at OPEN happened to have a trusted token,
>3.) the task flipped one or more of those "bypass authority checking" bits
>before OPEN,
>4.) the task at OPEN when the REQUEST=AUTH was a CSA or PRIVATE request,
>therefore bypassing GAC authority,
>5.) that the Rexx interface call does not check for conditional access
>entries.
>The REXX interface function does a RACROUTE REQUEST=AUTH and uses:
>USERID=user_id (for third party checking)
>STATUS=ACCESS (send back the access code (NONE, READ, UPDATE, CONTROL,
>ALTER)
>LOG=NONE (do not cut SMF audit records)
>And a few other necessary parameters. USERID and LOG require APF.
>I also check if the caller has the authority to use this function with a
>profile in the FACILITY class.

Good description, George. Thanks.

I'll note that your results should also be inaccurate if they try to use
PADS (Program Access to Data Sets) to grant access only when running a
specific program. Since your program is a different one, it might indicate
a failure when the actual job would work properly.

That's a case that none of the JCL checking products can handle, as far as I
know, because the results can not be checked except during actual execution.
Any outside attempt to check them may give either a false "success" or a
false "failure" indication.

--
Walt Farrell, CISSP
IBM STSM, z/OS Security Design

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

[George Fogg]

> On Tue, 26 Feb 2008 16:08:17 -0800, George Fogg <***@NWLINK.COM> wrote:
>
>>I wrote a REXX interface to our JCL scan product so it can check a
>>production userid access to a dataset resource. I told the folks that use it
>>that they must understand the fact that they cannot rely on the results of
>>the access when the "real" task opens the dataset in its environment during
>>OPEN time if:
>>1.) the task at OPEN is running Privileged or Trusted,
>>2.) the task at OPEN happened to have a trusted token,
>>3.) the task flipped one or more of those "bypass authority checking" bits
>>before OPEN,
>>4.) the task at OPEN when the REQUEST=AUTH was a CSA or PRIVATE request,
>>therefore bypassing GAC authority,
>>5.) that the Rexx interface call does not check for conditional access
>>entries.
>>The REXX interface function does a RACROUTE REQUEST=AUTH and uses:
>>USERID=user_id (for third party checking)
>>STATUS=ACCESS (send back the access code (NONE, READ, UPDATE, CONTROL,
>>ALTER)
>>LOG=NONE (do not cut SMF audit records)
>>And a few other necessary parameters. USERID and LOG require APF.
>>I also check if the caller has the authority to use this function with a
>>profile in the FACILITY class.
>
> Good description, George. Thanks.
>
> I'll note that your results should also be inaccurate if they try to use
> PADS (Program Access to Data Sets) to grant access only when running a
> specific program. Since your program is a different one, it might indicate
> a failure when the actual job would work properly.
>
> That's a case that none of the JCL checking products can handle, as far as I
> know, because the results can not be checked except during actual execution.
> Any outside attempt to check them may give either a false "success" or a
> false "failure" indication.

Yes, I should have added PADS to the list above. I have racked what little
brains I have left on how to do PADS authority checking and I haven't found a
way so far and accept the fact that it can't be done. So I chould add number 6
to the list above "PADS authority checking will not work in the REXX
function".
Thanks Walt.
George Fogg

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html