Discussion:
A curiosity Question
(too old to reply)
e***@JUNO.COM
2018-07-23 22:47:56 UTC
Permalink
Raw Message
Hi,
.

Im sure there is an Integrity exposure with these scenarios.

1)Can a Problem Program (Key 8) attach a Surtask that is authorized ?
.
2)Can a Problem Program attach a subtask (with the DCB parameter) that is authorized ? The dcb is not in the steplib concatenation.
.
3)Can a Problem Program invoke a Non Space Switching PC routine to Attach a Subtask that is Authorized ?
.
Im sure there is an Integrity exposure - could someone comment on the above.
.
.
Paul
.
.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Christopher Y. Blaicher
2018-07-23 22:52:59 UTC
Permalink
Raw Message
Don't be so sure of the integrity exposure.
In cases 1 and 2 I know the called program does not run authorized.
Case 3 I would have to investigate, but I bet it is not possible.

Chris Blaicher
Technical Architect
Syncsort, Inc.

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of ***@juno.com
Sent: Monday, July 23, 2018 6:47 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: A curiosity Question

Hi,
.

Im sure there is an Integrity exposure with these scenarios.

1)Can a Problem Program (Key 8) attach a Surtask that is authorized ?
.
2)Can a Problem Program attach a subtask (with the DCB parameter) that is authorized ? The dcb is not in the steplib concatenation.
.
3)Can a Problem Program invoke a Non Space Switching PC routine to Attach a Subtask that is Authorized ?
.
Im sure there is an Integrity exposure - could someone comment on the above.
.
.
Paul
.
.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-07-23 22:54:08 UTC
Permalink
Raw Message
I hope not, and IBM will take an APAR if it's possible. The one exception is that an unauthorized TSO command can ask the TMP to run an authorized command (or service), but the TMP will set the unauthorized command non-dispatchable for the duration.


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

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of ***@juno.com <***@JUNO.COM>
Sent: Monday, July 23, 2018 6:46 PM
To: IBM-***@listserv.ua.edu
Subject: A curiosity Question

Hi,
.

Im sure there is an Integrity exposure with these scenarios.

1)Can a Problem Program (Key 8) attach a Surtask that is authorized ?
.
2)Can a Problem Program attach a subtask (with the DCB parameter) that is authorized ? The dcb is not in the steplib concatenation.
.
3)Can a Problem Program invoke a Non Space Switching PC routine to Attach a Subtask that is Authorized ?
.
Im sure there is an Integrity exposure - could someone comment on the above.
.
.
Paul
.
.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-07-23 22:58:19 UTC
Permalink
Raw Message
Jobsteps are authorized, not subtasks. The jobstep is either authorized or
it is not (in the scenarios you describe below).

There is no (supported, official, "z/OS") way to transition from
non-authorized to authorized. You cannot "become authorized" except at
jobstep initiation time.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of ***@juno.com
Sent: Monday, July 23, 2018 3:47 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: A curiosity Question

Hi,
.

Im sure there is an Integrity exposure with these scenarios.

1)Can a Problem Program (Key 8) attach a Surtask that is authorized ?
.
2)Can a Problem Program attach a subtask (with the DCB parameter) that is
authorized ? The dcb is not in the steplib concatenation.
.
3)Can a Problem Program invoke a Non Space Switching PC routine to Attach a
Subtask that is Authorized ?
.
Im sure there is an Integrity exposure - could someone comment on the above.
.
.
Paul
.
.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-07-23 23:05:43 UTC
Permalink
Raw Message
Actually, you can, but the unauthorized code can't run while the authorized code is running and the unauthorized code can only invoke the authorized code that IBM or the installation allows. Think TSO,


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

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Charles Mills <***@MCN.ORG>
Sent: Monday, July 23, 2018 6:58 PM
To: IBM-***@listserv.ua.edu
Subject: Re: A curiosity Question

Jobsteps are authorized, not subtasks. The jobstep is either authorized or
it is not (in the scenarios you describe below).

There is no (supported, official, "z/OS") way to transition from
non-authorized to authorized. You cannot "become authorized" except at
jobstep initiation time.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of ***@juno.com
Sent: Monday, July 23, 2018 3:47 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: A curiosity Question

Hi,
.

Im sure there is an Integrity exposure with these scenarios.

1)Can a Problem Program (Key 8) attach a Surtask that is authorized ?
.
2)Can a Problem Program attach a subtask (with the DCB parameter) that is
authorized ? The dcb is not in the steplib concatenation.
.
3)Can a Problem Program invoke a Non Space Switching PC routine to Attach a
Subtask that is Authorized ?
.
Im sure there is an Integrity exposure - could someone comment on the above.
.
.
Paul
.
.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-07-24 00:43:08 UTC
Permalink
Raw Message
Yes, and any code that runs in supervisor state (certain exits, for example)
could (using an unapproved and undocumented but easy-to-deduce technique)
presumably change an address space from not-authorized to authorized -- but
the exit code would have to be installation-permitted.

There should be (is, so far as we know) no
available-to-the-average-programmer technique that permits unauthorized code
to make itself authorized, or create an authorized process, other than by
submitting a job with an APF-authorized-library-resident and AC=0 jobstep
program.

If you find one, IBM will take an APAR, ASAP.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Monday, July 23, 2018 4:05 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: A curiosity Question

Actually, you can, but the unauthorized code can't run while the authorized
code is running and the unauthorized code can only invoke the authorized
code that IBM or the installation allows. Think TSO,


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

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of
Charles Mills <***@MCN.ORG>
Sent: Monday, July 23, 2018 6:58 PM
To: IBM-***@listserv.ua.edu
Subject: Re: A curiosity Question

Jobsteps are authorized, not subtasks. The jobstep is either authorized or
it is not (in the scenarios you describe below).

There is no (supported, official, "z/OS") way to transition from
non-authorized to authorized. You cannot "become authorized" except at
jobstep initiation time.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of ***@juno.com
Sent: Monday, July 23, 2018 3:47 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: A curiosity Question

Hi,
.

Im sure there is an Integrity exposure with these scenarios.

1)Can a Problem Program (Key 8) attach a Surtask that is authorized ?
.
2)Can a Problem Program attach a subtask (with the DCB parameter) that is
authorized ? The dcb is not in the steplib concatenation.
.
3)Can a Problem Program invoke a Non Space Switching PC routine to Attach a
Subtask that is Authorized ?
.
Im sure there is an Integrity exposure - could someone comment on the above.
.
.
Paul
.
.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-07-24 15:18:13 UTC
Permalink
Raw Message
ITYM AC(1) and the statement should be that there is no way for an unauthorized program to make itself authorized, no way to invoke an authorized TSO command, program or service not permitted by the installation, no way to invoke an authorized subroutine other than through the TMP interface and no way to create a new process without vetting by the security environment.

Yes, there are Eunix <g> commands that run with UID(0), but the installation can control who is allowed to invoke them, and many of them are safe for general use.


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

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Charles Mills <***@MCN.ORG>
Sent: Monday, July 23, 2018 8:42 PM
To: IBM-***@listserv.ua.edu
Subject: Re: A curiosity Question

Yes, and any code that runs in supervisor state (certain exits, for example)
could (using an unapproved and undocumented but easy-to-deduce technique)
presumably change an address space from not-authorized to authorized -- but
the exit code would have to be installation-permitted.

There should be (is, so far as we know) no
available-to-the-average-programmer technique that permits unauthorized code
to make itself authorized, or create an authorized process, other than by
submitting a job with an APF-authorized-library-resident and AC=0 jobstep
program.

If you find one, IBM will take an APAR, ASAP.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Seymour J Metz
Sent: Monday, July 23, 2018 4:05 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: A curiosity Question

Actually, you can, but the unauthorized code can't run while the authorized
code is running and the unauthorized code can only invoke the authorized
code that IBM or the installation allows. Think TSO,


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

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of
Charles Mills <***@MCN.ORG>
Sent: Monday, July 23, 2018 6:58 PM
To: IBM-***@listserv.ua.edu
Subject: Re: A curiosity Question

Jobsteps are authorized, not subtasks. The jobstep is either authorized or
it is not (in the scenarios you describe below).

There is no (supported, official, "z/OS") way to transition from
non-authorized to authorized. You cannot "become authorized" except at
jobstep initiation time.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of ***@juno.com
Sent: Monday, July 23, 2018 3:47 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: A curiosity Question

Hi,
.

Im sure there is an Integrity exposure with these scenarios.

1)Can a Problem Program (Key 8) attach a Surtask that is authorized ?
.
2)Can a Problem Program attach a subtask (with the DCB parameter) that is
authorized ? The dcb is not in the steplib concatenation.
.
3)Can a Problem Program invoke a Non Space Switching PC routine to Attach a
Subtask that is Authorized ?
.
Im sure there is an Integrity exposure - could someone comment on the above.
.
.
Paul
.
.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Binyamin Dissen
2018-07-23 23:34:29 UTC
Permalink
Raw Message
On Mon, 23 Jul 2018 22:46:52 GMT "***@juno.com" <***@JUNO.COM> wrote:

:>Im sure there is an Integrity exposure with these scenarios.

:>1)Can a Problem Program (Key 8) attach a Surtask that is authorized ?

No.
.
:>2)Can a Problem Program attach a subtask (with the DCB parameter) that is authorized ? The dcb is not in the steplib concatenation.

No.
.
:>3)Can a Problem Program invoke a Non Space Switching PC routine to Attach a Subtask that is Authorized ?

If a PC routine defined with STATE=SUPERVISOR is badly written. Of course,
such a PC routine can only be established by an authorized routine.
.
:>Im sure there is an Integrity exposure - could someone comment on the above.

Such a PC routine would be an integrity exposure.

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-24 01:47:01 UTC
Permalink
Raw Message
Post by Seymour J Metz
I hope not, and IBM will take an APAR if it's possible. The one exception is that an unauthorized TSO command can ask the TMP to run an authorized command (or service), but the TMP will set the unauthorized command non-dispatchable for the duration.
More curious:
Suppose I use JCL DD, or SVC 99, or BPXWDYN to allocate DD=SYSIN,
FREE=CLOSE, DISP=DELETE. Then I JCL EXEC or TSO CALL an authorized
program which OPENs SYSIN for INPUT, READS, and CLOSES it. Will the
CLOSE free and delete it? Which component, at what point ensures that I
have RACF permission to delete that data set?

Similar question for /bin/tso which supports "allocation requests"; environment
variables containing strings eerily similar to BPXWDYN arguments. The Ref.
hints but doesn't directly say that /bin/tso invokes BPXWDYN to perform the
allocations.
Post by Seymour J Metz
________________________________________
From: essteam
Sent: Monday, July 23, 2018 6:46 PM
Im sure there is an Integrity exposure with these scenarios.
1)Can a Problem Program (Key 8) attach a Surtask that is authorized ?
-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Rob Schramm
2018-07-24 01:53:15 UTC
Permalink
Raw Message
TSO is NOT a good example. The flipping in and out of authorization has
been discussed ad infinitum. Pick something else for discussion points
unless we are diverging into what's possible, and there are tons of
inadvisable ways to break mvs integrity.

Rob Schramm

On Mon, Jul 23, 2018, 9:47 PM Paul Gilmartin <
Post by Seymour J Metz
Post by Seymour J Metz
I hope not, and IBM will take an APAR if it's possible. The one exception
is that an unauthorized TSO command can ask the TMP to run an authorized
command (or service), but the TMP will set the unauthorized command
non-dispatchable for the duration.
Suppose I use JCL DD, or SVC 99, or BPXWDYN to allocate DD=SYSIN,
FREE=CLOSE, DISP=DELETE. Then I JCL EXEC or TSO CALL an authorized
program which OPENs SYSIN for INPUT, READS, and CLOSES it. Will the
CLOSE free and delete it? Which component, at what point ensures that I
have RACF permission to delete that data set?
Similar question for /bin/tso which supports "allocation requests"; environment
variables containing strings eerily similar to BPXWDYN arguments. The Ref.
hints but doesn't directly say that /bin/tso invokes BPXWDYN to perform the
allocations.
Post by Seymour J Metz
________________________________________
From: essteam
Sent: Monday, July 23, 2018 6:46 PM
Im sure there is an Integrity exposure with these scenarios.
1)Can a Problem Program (Key 8) attach a Surtask that is authorized ?
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
Rob Schramm

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Binyamin Dissen
2018-07-24 07:41:16 UTC
Permalink
Raw Message
On Mon, 23 Jul 2018 21:52:53 -0400 Rob Schramm <***@GMAIL.COM> wrote:

:>TSO is NOT a good example. The flipping in and out of authorization has
:>been discussed ad infinitum. Pick something else for discussion points
:>unless we are diverging into what's possible, and there are tons of
:>inadvisable ways to break mvs integrity.

Don't know why, as it must maintain security when running the authorized code.
It must not allow currently executing code to read or alter the storage being
used by the authorized code. That may include blocking the task, blocking
exits (such as timers) , not using the system supplied save area (in user
key), not using key8 storage, etc.

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Binyamin Dissen
2018-07-24 07:36:18 UTC
Permalink
Raw Message
Supervisor state does not automatically bypass security. An authorized routine
can play around to do it, but standard code will not.

On Mon, 23 Jul 2018 20:46:54 -0500 Paul Gilmartin
<0000000433f07816-dmarc-***@LISTSERV.UA.EDU> wrote:

:>On Mon, 23 Jul 2018 22:53:59 +0000, Seymour J Metz wrote:

:>>I hope not, and IBM will take an APAR if it's possible. The one exception is that an unauthorized TSO command can ask the TMP to run an authorized command (or service), but the TMP will set the unauthorized command non-dispatchable for the duration.

:>More curious:
:>Suppose I use JCL DD, or SVC 99, or BPXWDYN to allocate DD=SYSIN,
:>FREE=CLOSE, DISP=DELETE. Then I JCL EXEC or TSO CALL an authorized
:>program which OPENs SYSIN for INPUT, READS, and CLOSES it. Will the
:>CLOSE free and delete it? Which component, at what point ensures that I
:>have RACF permission to delete that data set?

:>Similar question for /bin/tso which supports "allocation requests"; environment
:>variables containing strings eerily similar to BPXWDYN arguments. The Ref.
:>hints but doesn't directly say that /bin/tso invokes BPXWDYN to perform the
:>allocations.

--
Binyamin Dissen <***@dissensoftware.com>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-07-24 15:09:01 UTC
Permalink
Raw Message
Neither APF authorization nor supervisor state suspend normal SAF processing for, e.g., OPEN. If you know of a privileged application that bypasses normal resource controls and does not require SAF authorization before doing so, then it's APAR time.


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

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Paul Gilmartin <0000000433f07816-dmarc-***@listserv.ua.edu>
Sent: Monday, July 23, 2018 9:46 PM
To: IBM-***@listserv.ua.edu
Subject: Re: A curiosity Question
Post by Seymour J Metz
I hope not, and IBM will take an APAR if it's possible. The one exception is that an unauthorized TSO command can ask the TMP to run an authorized command (or service), but the TMP will set the unauthorized command non-dispatchable for the duration.
More curious:
Suppose I use JCL DD, or SVC 99, or BPXWDYN to allocate DD=SYSIN,
FREE=CLOSE, DISP=DELETE. Then I JCL EXEC or TSO CALL an authorized
program which OPENs SYSIN for INPUT, READS, and CLOSES it. Will the
CLOSE free and delete it? Which component, at what point ensures that I
have RACF permission to delete that data set?

Similar question for /bin/tso which supports "allocation requests"; environment
variables containing strings eerily similar to BPXWDYN arguments. The Ref.
hints but doesn't directly say that /bin/tso invokes BPXWDYN to perform the
allocations.
Post by Seymour J Metz
________________________________________
From: essteam
Sent: Monday, July 23, 2018 6:46 PM
Im sure there is an Integrity exposure with these scenarios.
1)Can a Problem Program (Key 8) attach a Surtask that is authorized ?
-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-24 02:26:36 UTC
Permalink
Raw Message
Post by Rob Schramm
TSO is NOT a good example. The flipping in and out of authorization has
been discussed ad infinitum. Pick something else for discussion points
I consider TSO a good example in that it illustrates a principle that untrusted
users should not be given access to those facilities that TSO uses.
Post by Rob Schramm
unless we are diverging into what's possible, and there are tons of
inadvisable ways to break mvs integrity.
Here, I'll trust IBM's Statement of Integrity. Nanograms, not tons,
and those known are quietly and rapidly being repaired.

Social engineering, "magic" SVCs, update access to authorized libraries, ...
do not contradict tne SoI, because they do not satisfy its requirements.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2018-07-24 04:11:02 UTC
Permalink
Raw Message
EXACTLY

CharlesSent from a mobile; please excuse the brevity.
-------- Here, I'll trust IBM's Statement of Integrity.  Nanograms, not tons,
and those known are quietly and rapidly being repaired.

Social engineering, "magic" SVCs, update access to authorized libraries, ...
do not contradict tne SoI, because they do not satisfy its requirements.

-


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2018-07-24 11:35:51 UTC
Permalink
Raw Message
I'd say that the questions are not precisely-enough posed.

<snip>
1)Can a Problem Program (Key 8) attach a Subtask that is authorized ?
2)Can a Problem Program attach a subtask (with the DCB parameter) that is
authorized ? The dcb is not in the steplib concatenation.
3)Can a Problem Program invoke a Non Space Switching PC routine to Attach
a Subtask that is Authorized ?
</snip>

What is "authorized" here? APF-authorized? Supervisor state? System key?

A problem key supervisor state user could certainly attach a subtask that
is supervisor state.

An authorized (state, key or APF) issuer of ATTACH can ATTACH a subtask
with pretty much any attribute it wants regarding state or key. Changing
the APF authorization is not part of the programming interface.

So for #1: sure. But that probably is not what is being asked. A problem
state problem key non-APF-authorized task cannot attach a subtask that is
other than that same level of authorization.

For #2, similarly above. "not in the steplib concatenation" is not
relevant. Steplib has no special connotation. A concatenation is a
concatenation. LNKLST has a special connotation depending on the LNKAUTH
system parameter. Nor does the APF state change regardless of whether the
module is AC=1, regardless of whether the module is located from an
APF-authorized concatenation.

For #3, sure, if that PC routine results in the ATTACH being issued in
supervisor state or system key.

Peter Relson
z/OS Core Technology Design


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Rob Schramm
2018-07-24 13:38:09 UTC
Permalink
Raw Message
I am just saying that TSO has done a ton of work to move between states and
maintain integrity. It does not seem to apply or be helpful in this
discussion... since it breaks and attempts to maintain integrity at the
same time. There are tons of examples of attempts to break and maintain
integrity and many failures to do so properly.. I will mention Ray Overby's
work in systematically attempting to break interfaces as an example of the
many failures and the care that must be exercised when exposing MVS's
authorized underbelly to the proverbial magic SVCs etc.

Rob Schramm
Post by Peter Relson
I'd say that the questions are not precisely-enough posed.
<snip>
1)Can a Problem Program (Key 8) attach a Subtask that is authorized ?
2)Can a Problem Program attach a subtask (with the DCB parameter) that is
authorized ? The dcb is not in the steplib concatenation.
3)Can a Problem Program invoke a Non Space Switching PC routine to Attach
a Subtask that is Authorized ?
</snip>
What is "authorized" here? APF-authorized? Supervisor state? System key?
A problem key supervisor state user could certainly attach a subtask that
is supervisor state.
An authorized (state, key or APF) issuer of ATTACH can ATTACH a subtask
with pretty much any attribute it wants regarding state or key. Changing
the APF authorization is not part of the programming interface.
So for #1: sure. But that probably is not what is being asked. A problem
state problem key non-APF-authorized task cannot attach a subtask that is
other than that same level of authorization.
For #2, similarly above. "not in the steplib concatenation" is not
relevant. Steplib has no special connotation. A concatenation is a
concatenation. LNKLST has a special connotation depending on the LNKAUTH
system parameter. Nor does the APF state change regardless of whether the
module is AC=1, regardless of whether the module is located from an
APF-authorized concatenation.
For #3, sure, if that PC routine results in the ATTACH being issued in
supervisor state or system key.
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
Rob Schramm

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2018-07-26 12:50:12 UTC
Permalink
Raw Message
Neither APF authorization nor supervisor state suspend normal SAF processing for, e.g., OPEN. If you know of a privileged application >that bypasses normal resource controls and does not require SAF authorization before doing so, then it's APAR time.
I believe there is one exception to that, unless the behavior has been changed in the past few years: as I recall, OPEN for a VSAM file will bypass security checking if the issuer of OPEN is running in supervisor state. I think it's documented (briefly) deep in some manual, but I forget which one.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2018-07-26 14:54:55 UTC
Permalink
Raw Message
Post by Walt Farrell
Neither APF authorization nor supervisor state suspend normal SAF processing for, e.g., OPEN. If you know of a privileged application >that bypasses normal resource controls and does not require SAF authorization before doing so, then it's APAR time.
I believe there is one exception to that, unless the behavior has been changed in the past few years: as I recall, OPEN for a
VSAM file will bypass security checking if the issuer of OPEN is running in supervisor state. I think it's documented (briefly)
deep in some manual, but I forget which one.
See the last sentence:
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/ods.htm

"Note: RACF protection supersedes password protection for a data set. RACF checking is bypassed for a caller that is in supervisor state or key 0."
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-07-26 23:36:26 UTC
Permalink
Raw Message
Ouch!


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

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Tom Marchant <0000000a2a8c2020-dmarc-***@listserv.ua.edu>
Sent: Thursday, July 26, 2018 10:54 AM
To: IBM-***@listserv.ua.edu
Subject: Re: A curiosity Question
Post by Walt Farrell
Neither APF authorization nor supervisor state suspend normal SAF processing for, e.g., OPEN. If you know of a privileged application >that bypasses normal resource controls and does not require SAF authorization before doing so, then it's APAR time.
I believe there is one exception to that, unless the behavior has been changed in the past few years: as I recall, OPEN for a
VSAM file will bypass security checking if the issuer of OPEN is running in supervisor state. I think it's documented (briefly)
deep in some manual, but I forget which one.
See the last sentence:
https://secure-web.cisco.com/1fEi_APD-dbzkd_iKlhiAA2AVBOGZ5QGmCNii0nYbrJWM2V2A6qipyYe5-tm1FkX-bmtBq2TQf_BrZFhyY5GESiAIdhK6RBb7DWQ077xzPDW4rh2as1AyBl-hJSHUpzFFyZZGlLUgvPjFv7GylTwg8rZIGP9VVE5BhfiTB27BHPn1qnA9ZegbpcUyVT6kLj3-JzxQcDkb03CJdw4W-GjweV3pWEcL95Ck1udp-8vmJa4xGXl9ixcCXA58o6_QxTwFkCBF0PRD4zqDyTl0G-mKbs_xPJ9n4V8bsBvAtVZ7bFz0GO7Jp-YZ1yghGuouUuZanzL9faTjFJH6zH47NZx2iATeomthWOqV2mSKMS5_9R4iF54_zydsOEUVB_KOPk--_BNL9S73rzHl3YtSbOkPkl2VoVveVZ9gudeZERXDgu35SYBHRpVB1vtE7uNvLh_f/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.idad400%2Fods.htm

"Note: RACF protection supersedes password protection for a data set. RACF checking is bypassed for a caller that is in supervisor state or key 0."

--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2018-07-26 23:54:23 UTC
Permalink
Raw Message
Post by Tom Marchant
Post by Walt Farrell
Neither APF authorization nor supervisor state suspend normal SAF processing for, e.g., OPEN. If you know of a privileged application >that bypasses normal resource controls and does not require SAF authorization before doing so, then it's APAR time.
I believe there is one exception to that, unless the behavior has been changed in the past few years: as I recall, OPEN for a
VSAM file will bypass security checking if the issuer of OPEN is running in supervisor state. I think it's documented (briefly)
deep in some manual, but I forget which one.
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/ods.htm
"Note: RACF protection supersedes password protection for a data set. RACF checking is bypassed for a caller that is in supervisor state or key 0."
Thanks, Tom. And, note, for those who may not follow the link, that that statement is for VSAM only.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clark Morris
2018-07-27 01:13:12 UTC
Permalink
Raw Message
[Default] On 26 Jul 2018 16:54:23 -0700, in bit.listserv.ibm-main
Post by Walt Farrell
Post by Tom Marchant
Post by Walt Farrell
Neither APF authorization nor supervisor state suspend normal SAF processing for, e.g., OPEN. If you know of a privileged application >that bypasses normal resource controls and does not require SAF authorization before doing so, then it's APAR time.
I believe there is one exception to that, unless the behavior has been changed in the past few years: as I recall, OPEN for a
VSAM file will bypass security checking if the issuer of OPEN is running in supervisor state. I think it's documented (briefly)
deep in some manual, but I forget which one.
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/ods.htm
"Note: RACF protection supersedes password protection for a data set. RACF checking is bypassed for a caller that is in supervisor state or key 0."
Thanks, Tom. And, note, for those who may not follow the link, that that statement is for VSAM only.
Why would they exclude only VSAM from checking? Is it because of Page
Datasets or some other reason? Are there other ways of bypassing or
ignoring checking for supervisor and key zero code?

Clark Morris

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-07-27 17:33:03 UTC
Permalink
Raw Message
And does the new interface in OA48124 allow a supervisor mode program to turn off the bypass, or does it need to switch to problem state if it wants SAF checking on the VSAM OPEN?


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

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Clark Morris <***@UNISERVE.COM>
Sent: Thursday, July 26, 2018 9:13 PM
To: IBM-***@listserv.ua.edu
Subject: Re: A curiosity Question

[Default] On 26 Jul 2018 16:54:23 -0700, in bit.listserv.ibm-main
Post by Walt Farrell
Post by Walt Farrell
Neither APF authorization nor supervisor state suspend normal SAF processing for, e.g., OPEN. If you know of a privileged application >that bypasses normal resource controls and does not require SAF authorization before doing so, then it's APAR time.
I believe there is one exception to that, unless the behavior has been changed in the past few years: as I recall, OPEN for a
VSAM file will bypass security checking if the issuer of OPEN is running in supervisor state. I think it's documented (briefly)
deep in some manual, but I forget which one.
https://secure-web.cisco.com/1xJWCeiFyNOofavmdTpryQCwlqj7yAIgmZFpF5O4CICnch8KApVMcszC3CywQlgpuCGyBIkx-O2ef9by7pUDOra7IMa9FWXhP0it1R8VLiY67mlmWzwSZ2q3uX9nWezqNURN-f_bcj8wNnz2xEZ74EUMymaFhOYS7gcOSgAOLIl71vsI26gteZdwFi7sfkVKsR03456euyb0H2qGjBVgszAr2XPi0HTYMxgMvVxzuqYhqs2LU6l4SopLvRkK_F_321v_Zxvr4lOI-yL0rxWGeB8tQLmgjl5d1r-u315Du4aIktrInSdZCWHdXeGA_pCH8rwqXRXnySU_G88NO7cLcUQFml0mFJlq_JAOACMLwTW86qikc37IDoyz-NH-7FleFIVCCm4cl2spoSPv7reONVaWnGHyZNhkdQ0DcVdojtZ5wxcBhHMUw2AG3BPlV_y2F/https%3A%2F%2Fwww.ibm.com%2Fsupport%2Fknowledgecenter%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3.idad400%2Fods.htm
"Note: RACF protection supersedes password protection for a data set. RACF checking is bypassed for a caller that is in supervisor state or key 0."
Thanks, Tom. And, note, for those who may not follow the link, that that statement is for VSAM only.
Why would they exclude only VSAM from checking? Is it because of Page
Datasets or some other reason? Are there other ways of bypassing or
ignoring checking for supervisor and key zero code?

Clark Morris

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-27 01:56:14 UTC
Permalink
Raw Message
Post by Clark Morris
Post by Walt Farrell
Post by Tom Marchant
Post by Walt Farrell
I believe there is one exception to that, unless the behavior has been changed in the past few years: as I recall, OPEN for a
VSAM file will bypass security checking if the issuer of OPEN is running in supervisor state. I think it's documented (briefly)
deep in some manual, but I forget which one.
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/ods.htm
"Note: RACF protection supersedes password protection for a data set. RACF checking is bypassed for a caller that is in supervisor state or key 0."
Thanks, Tom. And, note, for those who may not follow the link, that that statement is for VSAM only.
Why would they exclude only VSAM from checking? Is it because of Page
Datasets or some other reason? Are there other ways of bypassing or
ignoring checking for supervisor and key zero code?
My conjecture is that the VSAM address space itself performs the needed check.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Rob Schramm
2018-07-27 02:05:33 UTC
Permalink
Raw Message
How does that interact with ICSF CHECKAUTH that forces security checks for
authorized address spaces?

Rob

On Thu, Jul 26, 2018, 9:56 PM Paul Gilmartin <
Post by Walt Farrell
Post by Clark Morris
Post by Walt Farrell
Post by Tom Marchant
Post by Walt Farrell
I believe there is one exception to that, unless the behavior has been
changed in the past few years: as I recall, OPEN for a
Post by Clark Morris
Post by Walt Farrell
Post by Tom Marchant
Post by Walt Farrell
VSAM file will bypass security checking if the issuer of OPEN is
running in supervisor state. I think it's documented (briefly)
Post by Clark Morris
Post by Walt Farrell
Post by Tom Marchant
Post by Walt Farrell
deep in some manual, but I forget which one.
https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.idad400/ods.htm
Post by Clark Morris
Post by Walt Farrell
Post by Tom Marchant
"Note: RACF protection supersedes password protection for a data set.
RACF checking is bypassed for a caller that is in supervisor state or key
0."
Post by Clark Morris
Post by Walt Farrell
Thanks, Tom. And, note, for those who may not follow the link, that that
statement is for VSAM only.
Post by Clark Morris
Why would they exclude only VSAM from checking? Is it because of Page
Datasets or some other reason? Are there other ways of bypassing or
ignoring checking for supervisor and key zero code?
My conjecture is that the VSAM address space itself performs the needed check.
-- gil
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
Rob Schramm

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Wayne Driscoll
2018-07-27 15:47:23 UTC
Permalink
Raw Message
There is no "VSAM address space" to perform the check. I don’t have any knowledge of why VSAM open bypasses security calls for a KEY 0 or SUP STATE user, but as I recall, it has been this way for decades.

Wayne Driscoll
Rocket Software
Note - All opinions are strictly my own.

-----Original Message-----
From: IBM Mainframe Discussion List <IBM-***@LISTSERV.UA.EDU> On Behalf Of Paul Gilmartin
Sent: Thursday, July 26, 2018 8:56 PM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: A curiosity Question
Post by Clark Morris
Post by Walt Farrell
Post by Walt Farrell
I believe there is one exception to that, unless the behavior has
been changed in the past few years: as I recall, OPEN for a VSAM
file will bypass security checking if the issuer of OPEN is running in supervisor state. I think it's documented (briefly) deep in some manual, but I forget which one.
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
ibm.com%2Fsupport%2Fknowledgecenter%2FSSLTBW_2.3.0%2Fcom.ibm.zos.v2r3
.idad400%2Fods.htm&amp;data=02%7C01%7Cwdriscoll%40ROCKETSOFTWARE.COM%
7C48d6ded2a0c5415d4ab708d5f36420f3%7C79544c1eed224879a082b67a9a672aae
%7C0%7C0%7C636682533747748885&amp;sdata=GbQa7LvBwne0JnI12MQuvvbVMmbve
pfNE7wuIzDaAvw%3D&amp;reserved=0
"Note: RACF protection supersedes password protection for a data set. RACF checking is bypassed for a caller that is in supervisor state or key 0."
Thanks, Tom. And, note, for those who may not follow the link, that that statement is for VSAM only.
Why would they exclude only VSAM from checking? Is it because of Page
Datasets or some other reason? Are there other ways of bypassing or
ignoring checking for supervisor and key zero code?
My conjecture is that the VSAM address space itself performs the needed check.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
================================
Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323
Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences
Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy
================================

This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2018-07-27 20:00:09 UTC
Permalink
Raw Message
Post by Paul Gilmartin
...
Post by Clark Morris
Why would they exclude only VSAM from checking? Is it because of Page
Datasets or some other reason? Are there other ways of bypassing or
ignoring checking for supervisor and key zero code?
My conjecture is that the VSAM address space itself performs the needed check.
No, there is no security check done when a supervisor state or key 0 program OPENs a VSAM cluster. If any checking is deemed necessary, it is up to the caller to perform it by issuing their own RACROUTE or RACHECK.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2018-07-27 20:01:45 UTC
Permalink
Raw Message
Post by Rob Schramm
How does that interact with ICSF CHECKAUTH that forces security checks for
authorized address spaces?
There is no interaction, because you're mixing up different kinds of checks. We've been talking about OPENing VSAM clusters, but you've just asked about ICSF doing checks that are related to crypto requests, not OPEN. Totally different beasts.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Rob Schramm
2018-07-27 20:19:51 UTC
Permalink
Raw Message
You would think that.. but what about the pervasive encryption? Wouldn't
ICSF with CHECKAUTH makes sure the key 0 user was authorized for the crypt
key and possibly checked for use for the data set?

First time I ran with checkauth.. biggest user of ICSF was VTAM .. I think
it was session keys.

Rob Schramm
Post by Walt Farrell
Post by Rob Schramm
How does that interact with ICSF CHECKAUTH that forces security checks for
authorized address spaces?
There is no interaction, because you're mixing up different kinds of
checks. We've been talking about OPENing VSAM clusters, but you've just
asked about ICSF doing checks that are related to crypto requests, not
OPEN. Totally different beasts.
--
Walt
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
Rob Schramm

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2018-07-27 23:40:31 UTC
Permalink
Raw Message
Post by Rob Schramm
You would think that.. but what about the pervasive encryption? Wouldn't
ICSF with CHECKAUTH makes sure the key 0 user was authorized for the crypt
key and possibly checked for use for the data set?
No, I would not expect ICSF to be involved with the data set checks at all. With the encryption you need to have access to the crypto data, and to the data set, but nothing says that ICSF is involved with checking both. Access to the data set can be granted by any of the usual mechanisms, as far as I know.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Rob Schramm
2018-07-28 00:41:11 UTC
Permalink
Raw Message
I am not sure.. They out those extended checks with smf 82's.. and put some
use parameters in the asymuse.

I don't like bypassing security calls.. it's just a slippery slope to
bypassing all of it.

Rob Schramm
Post by Walt Farrell
Post by Rob Schramm
You would think that.. but what about the pervasive encryption? Wouldn't
ICSF with CHECKAUTH makes sure the key 0 user was authorized for the crypt
key and possibly checked for use for the data set?
No, I would not expect ICSF to be involved with the data set checks at
all. With the encryption you need to have access to the crypto data, and to
the data set, but nothing says that ICSF is involved with checking both.
Access to the data set can be granted by any of the usual mechanisms, as
far as I know.
--
Walt
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
Rob Schramm

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Clark Morris
2018-07-28 15:01:03 UTC
Permalink
Raw Message
[Default] On 27 Jul 2018 17:41:11 -0700, in bit.listserv.ibm-main
Post by Rob Schramm
I am not sure.. They out those extended checks with smf 82's.. and put some
use parameters in the asymuse.
I don't like bypassing security calls.. it's just a slippery slope to
bypassing all of it.
Why should OPEN security checking be bypassed for VSAM and no other
access method in key 0 / supervisor state.

Clark Morris
Post by Rob Schramm
Rob Schramm
Post by Walt Farrell
Post by Rob Schramm
You would think that.. but what about the pervasive encryption? Wouldn't
ICSF with CHECKAUTH makes sure the key 0 user was authorized for the crypt
key and possibly checked for use for the data set?
No, I would not expect ICSF to be involved with the data set checks at
all. With the encryption you need to have access to the crypto data, and to
the data set, but nothing says that ICSF is involved with checking both.
Access to the data set can be granted by any of the usual mechanisms, as
far as I know.
--
Walt
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2018-07-30 15:14:33 UTC
Permalink
Raw Message
Post by Clark Morris
[Default] On 27 Jul 2018 17:41:11 -0700, in bit.listserv.ibm-main
Post by Rob Schramm
I am not sure.. They out those extended checks with smf 82's.. and put some
use parameters in the asymuse.
I don't like bypassing security calls.. it's just a slippery slope to
bypassing all of it.
Why should OPEN security checking be bypassed for VSAM and no other
access method in key 0 / supervisor state.
As far as I know only the VSAM designers who made that decision decades ago would know. My guess: some system component that could not tolerate the check (at that time probably for passwords, via an operator prompt) could not tolerate the interruption, so they decided to bypass the security check. Also, there is (or was) very little usage of OPEN for VSAM files by supervisor state or key 0 programs.

I found out about it many years ago while working on a customer problem report while I was in RACF Development. At that time it was undocumented. I recall that the VSAM team determined that behavior to be so old and ingrained to the processing that it could not be changed safely, for compatibility reasons if I remember correctly. But I did convince them it needed to be documented.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Seymour J Metz
2018-07-30 15:56:20 UTC
Permalink
Raw Message
My guess is that the security bypass was for opening paging and swap data sets and maybe STGINDEX.


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

________________________________________
From: IBM Mainframe Discussion List <IBM-***@listserv.ua.edu> on behalf of Walt Farrell <***@GMAIL.COM>
Sent: Monday, July 30, 2018 11:14 AM
To: IBM-***@listserv.ua.edu
Subject: Re: Security bypass on key 0 / sup state VSAM OPEN was Re: A curiosity Question
Post by Clark Morris
[Default] On 27 Jul 2018 17:41:11 -0700, in bit.listserv.ibm-main
Post by Rob Schramm
I am not sure.. They out those extended checks with smf 82's.. and put some
use parameters in the asymuse.
I don't like bypassing security calls.. it's just a slippery slope to
bypassing all of it.
Why should OPEN security checking be bypassed for VSAM and no other
access method in key 0 / supervisor state.
As far as I know only the VSAM designers who made that decision decades ago would know. My guess: some system component that could not tolerate the check (at that time probably for passwords, via an operator prompt) could not tolerate the interruption, so they decided to bypass the security check. Also, there is (or was) very little usage of OPEN for VSAM files by supervisor state or key 0 programs.

I found out about it many years ago while working on a customer problem report while I was in RACF Development. At that time it was undocumented. I recall that the VSAM team determined that behavior to be so old and ingrained to the processing that it could not be changed safely, for compatibility reasons if I remember correctly. But I did convince them it needed to be documented.

--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Rob Schramm
2018-07-31 01:09:10 UTC
Permalink
Raw Message
I love IBM-MAIN.

Rob Schramm
Post by Seymour J Metz
My guess is that the security bypass was for opening paging and swap data
sets and maybe STGINDEX.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
Sent: Monday, July 30, 2018 11:14 AM
Subject: Re: Security bypass on key 0 / sup state VSAM OPEN was Re: A curiosity Question
Post by Clark Morris
[Default] On 27 Jul 2018 17:41:11 -0700, in bit.listserv.ibm-main
Post by Rob Schramm
I am not sure.. They out those extended checks with smf 82's.. and put
some
Post by Clark Morris
Post by Rob Schramm
use parameters in the asymuse.
I don't like bypassing security calls.. it's just a slippery slope to
bypassing all of it.
Why should OPEN security checking be bypassed for VSAM and no other
access method in key 0 / supervisor state.
As far as I know only the VSAM designers who made that decision decades
ago would know. My guess: some system component that could not tolerate the
check (at that time probably for passwords, via an operator prompt) could
not tolerate the interruption, so they decided to bypass the security
check. Also, there is (or was) very little usage of OPEN for VSAM files by
supervisor state or key 0 programs.
I found out about it many years ago while working on a customer problem
report while I was in RACF Development. At that time it was undocumented. I
recall that the VSAM team determined that behavior to be so old and
ingrained to the processing that it could not be changed safely, for
compatibility reasons if I remember correctly. But I did convince them it
needed to be documented.
--
Walt
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
Rob Schramm

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mike Schwab
2018-07-31 01:31:09 UTC
Permalink
Raw Message
How about Master and User catalogs?
Post by Seymour J Metz
My guess is that the security bypass was for opening paging and swap data sets and maybe STGINDEX.
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
________________________________________
Sent: Monday, July 30, 2018 11:14 AM
Subject: Re: Security bypass on key 0 / sup state VSAM OPEN was Re: A curiosity Question
Post by Clark Morris
[Default] On 27 Jul 2018 17:41:11 -0700, in bit.listserv.ibm-main
Post by Rob Schramm
I am not sure.. They out those extended checks with smf 82's.. and put some
use parameters in the asymuse.
I don't like bypassing security calls.. it's just a slippery slope to
bypassing all of it.
Why should OPEN security checking be bypassed for VSAM and no other
access method in key 0 / supervisor state.
As far as I know only the VSAM designers who made that decision decades ago would know. My guess: some system component that could not tolerate the check (at that time probably for passwords, via an operator prompt) could not tolerate the interruption, so they decided to bypass the security check. Also, there is (or was) very little usage of OPEN for VSAM files by supervisor state or key 0 programs.
I found out about it many years ago while working on a customer problem report while I was in RACF Development. At that time it was undocumented. I recall that the VSAM team determined that behavior to be so old and ingrained to the processing that it could not be changed safely, for compatibility reasons if I remember correctly. But I did convince them it needed to be documented.
--
Walt
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2018-07-31 02:52:26 UTC
Permalink
Raw Message
Post by Mike Schwab
How about Master and User catalogs?
Isn't there a catalog address space?

(I know; I was wrong once before.)
Post by Mike Schwab
Post by Seymour J Metz
My guess is that the security bypass was for opening paging and swap data sets and maybe STGINDEX.
-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Loading...