Discussion:
ATTACH with RSAPF=YES
(too old to reply)
Robin Atwood
2017-05-15 08:17:48 UTC
Permalink
Raw Message
We have a requirement to attach user modules from an unauthorised library
and execute them from an STC which

runs APF authorised. Calling ATTACH with RSAPF=YES seems to do exactly what
I want but every time I try it

I get abend S306-0C, "authorised program attaching module from an
unauthorized library". The ATTACH macro

description states:



RSAPF=YES when these conditions are met:

. The caller is running in supervisor state, system key (0-7),
or both

. The caller is running non-APF authorized

. The subtask is attached in the problem program state and with
a nonsystem key.



Conditions 1 and 2 seem mutually exclusive. I tried coding MODESET MODE=SUP
and adding SM=PROB,KEY=PROP

to the ATTACH but it made no difference. I seem to be missing something
fairly massive here! Can anyone shed

some light on this?



Thanks

Robin


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Greg Dyck
2017-05-15 12:29:39 UTC
Permalink
Raw Message
Be aware that what you are attempting to do is dangerous and has the
potential to create system integrity exposures that would allow a
problem state program to cause a system failure. I am not saying that
it can not be done safely, because it can be. But to do it safely
without creating a system integrity exposure requires a lot more than
just using RSAPF=YES on the ATTACH.
Post by Robin Atwood
Conditions 1 and 2 seem mutually exclusive. I tried coding MODESET MODE=SUP
and adding SM=PROB,KEY=PROP
to the ATTACH but it made no difference. I seem to be missing something
fairly massive here! Can anyone shed some light on this?
You need to get into key 0 and reset JSCBAUTH prior to issuing the
ATTACH in order to meet qualification #2 below for RSAPF=YES to be
performed, and the ATTACH must then be issued in either a system key or
supervisor state (or both)-

RSAPF=YES when these conditions are met:
- The caller is running in supervisor state, system key (0-7), or
both
- The caller is running non-APF authorized
- The subtask is attached in the problem program state and with a
non-system key.

Regards, Greg

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-05-15 12:37:38 UTC
Permalink
Raw Message
Post by Greg Dyck
Be aware that what you are attempting to do is dangerous and has the
potential to create system integrity exposures that would allow a problem
state program to cause a system failure. I am not saying that it can not
be done safely, because it can be. But to do it safely without creating a
system integrity exposure requires a lot more than just using RSAPF=YES on
the ATTACH.
Post by Robin Atwood
Conditions 1 and 2 seem mutually exclusive. I tried coding MODESET MODE=SUP
and adding SM=PROB,KEY=PROP
to the ATTACH but it made no difference. I seem to be missing something
fairly massive here! Can anyone shed some light on this?
​<snip>
Regards, Greg
​Just coming out of left field here. I don't know what the OP is trying to
accomplish (at a high level) by doing this. But in the context were I need
differing security attributes (such as APF), I would go with a UNIX fork().
Of course, if the ATTACH'd program needs to communicate with the parent
through shared memory, that complicates things a bit. But should be
possible using the z/OS shared memory API.​ Or my "marshalling" the data
and using some IPC such as pipe or, better, UNIX messages. The problem with
all this is the CPU overhead and complexity.
--
Advertising is a valuable economic factor because it is the cheapest way of
selling goods, particularly if the goods are worthless. -- Sinclair Lewis


Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Binyamin Dissen
2017-05-15 13:55:04 UTC
Permalink
Raw Message
Well, if you want to run unauthorized stuff you would first need to set your
job as non-APF by resetting the bit.

Of course, your authorized key8 storage will be subject to change by the
unauthorized task, thus your authorized code must not use Key8 storage.

(1) and (2) are not exclusive, as your authorized task would need to remain in
supervisor state after resetting APF (assuming you still need APF services).
If you no longer need APF services, simply reset APF do MODESET PROB and the
garden variety ATTACH(X)

Why do you want to run unauthorized code from this STC? What is the business
case?

On Mon, 15 May 2017 15:18:38 +0700 Robin Atwood <***@GMAIL.COM> wrote:

:>We have a requirement to attach user modules from an unauthorised library
:>and execute them from an STC which
:>
:>runs APF authorised. Calling ATTACH with RSAPF=YES seems to do exactly what
:>I want but every time I try it
:>
:>I get abend S306-0C, "authorised program attaching module from an
:>unauthorized library". The ATTACH macro
:>
:>description states:
:>
:>
:>
:>RSAPF=YES when these conditions are met:
:>
:>. The caller is running in supervisor state, system key (0-7),
:>or both
:>
:>. The caller is running non-APF authorized
:>
:>. The subtask is attached in the problem program state and with
:>a nonsystem key.
:>
:>
:>
:>Conditions 1 and 2 seem mutually exclusive. I tried coding MODESET MODE=SUP
:>and adding SM=PROB,KEY=PROP
:>
:>to the ATTACH but it made no difference. I seem to be missing something
:>fairly massive here! Can anyone shed
:>
:>some light on this?
:>
:>
:>
:>Thanks
:>
:>Robin
:>
:>
:>----------------------------------------------------------------------
:>For IBM-MAIN subscribe / signoff / archive access instructions,
:>send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

--
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
Robin Atwood
2017-05-16 07:08:59 UTC
Permalink
Raw Message
Thanks to everyone for replying, I would never realised you had to flip
JSCBAUTH from the macro documentation.
The actual business requirement is that we run Rexx execs that call ISPF
services on behalf of workstation users
running an IDE. The STC doing this must run authorised because it
communicates with a comms task via cross-memory services. So we will have
control over what gets executed. This is still very much an experiment, I am
not
sure it will actually work.

Thanks
Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Binyamin Dissen
Sent: 15 May 2017 20:56
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES

Well, if you want to run unauthorized stuff you would first need to set your
job as non-APF by resetting the bit.

Of course, your authorized key8 storage will be subject to change by the
unauthorized task, thus your authorized code must not use Key8 storage.

(1) and (2) are not exclusive, as your authorized task would need to remain
in supervisor state after resetting APF (assuming you still need APF
services).
If you no longer need APF services, simply reset APF do MODESET PROB and the
garden variety ATTACH(X)

Why do you want to run unauthorized code from this STC? What is the business
case?

On Mon, 15 May 2017 15:18:38 +0700 Robin Atwood <***@GMAIL.COM> wrote:

:>We have a requirement to attach user modules from an unauthorised library
:>and execute them from an STC which :> :>runs APF authorised. Calling
ATTACH with RSAPF=YES seems to do exactly what :>I want but every time I try
it :> :>I get abend S306-0C, "authorised program attaching module from an
:>unauthorized library". The ATTACH macro :> :>description states:
:>
:>
:>
:>RSAPF=YES when these conditions are met:
:>
:>. The caller is running in supervisor state, system key (0-7),
:>or both
:>
:>. The caller is running non-APF authorized
:>
:>. The subtask is attached in the problem program state and
with
:>a nonsystem key.
:>
:>
:>
:>Conditions 1 and 2 seem mutually exclusive. I tried coding MODESET
MODE=SUP :>and adding SM=PROB,KEY=PROP :> :>to the ATTACH but it made no
difference. I seem to be missing something :>fairly massive here! Can anyone
shed :> :>some light on this?
:>
:>
:>
:>Thanks
:>
:>Robin
:>
:>
:>----------------------------------------------------------------------
:>For IBM-MAIN subscribe / signoff / archive access instructions, :>send
email to ***@listserv.ua.edu with the message: INFO IBM-MAIN

--
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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-05-16 12:40:32 UTC
Permalink
Raw Message
So we will have control over what gets executed
As others have pointed out, you are exposing yourself to risks that you will
have to manage. MVS would be willing to take on some of that management for
you, but you are overriding that facility.

You need to make absolutely sure of who has the ability to write into every
single dataset used as a load or parameter or script library by every single
thing called by your STC.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Robin Atwood
Sent: Tuesday, May 16, 2017 12:10 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES

Thanks to everyone for replying, I would never realised you had to flip
JSCBAUTH from the macro documentation.
The actual business requirement is that we run Rexx execs that call ISPF
services on behalf of workstation users running an IDE. The STC doing this
must run authorised because it communicates with a comms task via
cross-memory services. So we will have control over what gets executed. This
is still very much an experiment, I am not sure it will actually work.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2017-05-15 14:15:34 UTC
Permalink
Raw Message
Post by Robin Atwood
We have a requirement to attach user modules from an unauthorised library
and execute them from an STC which
runs APF authorised. Calling ATTACH with RSAPF=YES seems to do exactly what
I want ...
It _can_ do what you want, Robin, but as others have said it is very risky to do this, and very complex to do it safely. Basically, what you're trying will only work safely if your STC is designed properly to allow it. At a minimum, I believe that means making sure that none of your STC code runs in key 8 or uses key 8 storage. It would need to start from the beginning in a system key, specified by the Program Properties Table in PARMLIB. You could then, possibly, invoke the non-APF code safely as long as you run it in key 8.

But the question then becomes what do you expect the non-APF code to do, and how do you expect to communicate with it.

It really would be better and safer, in my opinion, to find another solution. This might possibly involve using multiple address spaces (via UNIX fork()) as John McKown suggested. But we would really need to know a lot more information about your STC, and the non-APF code, to be able to provide the best advice.

(It is very unlikely, in my experience, that your current STC is designed to allow you to do this safely. A major redesign and reimplementation of the STC would probably be required if you haven't been thinking about this from the very beginning of its development.)
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Steve Smith
2017-05-15 14:27:43 UTC
Permalink
Raw Message
RSAPF probably shouldn't even be documented. AFAIK, it's only purpose is
to allow the system to support unauthorized tasks and jobs, and is used
only with the creation of a new job-step task. And there is no
communication between the initiator task and the user task.

Authorized programs aren't allowed to invoke unauthorized code for a very
good reason. Trying to circumvent that in any way compromises your system
integrity. That said, running bad authorized code does as well, so caveat
emptor.

sas
Post by Walt Farrell
Post by Robin Atwood
We have a requirement to attach user modules from an unauthorised library
and execute them from an STC which
runs APF authorised. Calling ATTACH with RSAPF=YES seems to do exactly
what
Post by Robin Atwood
I want ...
It _can_ do what you want, Robin, but as others have said it is very risky
to do this, and very complex to do it safely. Basically, what you're trying
will only work safely if your STC is designed properly to allow it. At a
minimum, I believe that means making sure that none of your STC code runs
in key 8 or uses key 8 storage. It would need to start from the beginning
in a system key, specified by the Program Properties Table in PARMLIB. You
could then, possibly, invoke the non-APF code safely as long as you run it
in key 8.
But the question then becomes what do you expect the non-APF code to do,
and how do you expect to communicate with it.
It really would be better and safer, in my opinion, to find another
solution. This might possibly involve using multiple address spaces (via
UNIX fork()) as John McKown suggested. But we would really need to know a
lot more information about your STC, and the non-APF code, to be able to
provide the best advice.
(It is very unlikely, in my experience, that your current STC is designed
to allow you to do this safely. A major redesign and reimplementation of
the STC would probably be required if you haven't been thinking about this
from the very beginning of its development.)
--
Walt
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
sas

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-05-15 16:06:02 UTC
Permalink
Raw Message
At a long-gone bank, we ran IBM's check processing application CPCS, which needed to run APF authorized. This meant that any program called by CPCS needed to come from an APF library. For whatever reason, CPCS invoked standard utilities such as DFSORT, which meant that those libraries also had to be APF just so the programs could be called by CPCS.

We learned at some point about the possibility of flipping JSCBAUTH to tweak the APF mode. But CPCS was a multitasking application that was doing lots of things concurrently. There is only one JSCBAUTH flag. If turned it off for, say, SORT processing, we would very likely kill some other subtask that needed APF on. We decided that was pretty much impossible to manage. So everything that ran within CPCS came from an APF library. Note that individual programs do not need APF=1, but the library needs to be in APF list.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Steve Smith
Sent: Monday, May 15, 2017 7:29 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: ATTACH with RSAPF=YES

RSAPF probably shouldn't even be documented. AFAIK, it's only purpose is to allow the system to support unauthorized tasks and jobs, and is used only with the creation of a new job-step task. And there is no communication between the initiator task and the user task.

Authorized programs aren't allowed to invoke unauthorized code for a very good reason. Trying to circumvent that in any way compromises your system integrity. That said, running bad authorized code does as well, so caveat emptor.

sas
Post by Walt Farrell
Post by Robin Atwood
We have a requirement to attach user modules from an unauthorised
library and execute them from an STC which
runs APF authorised. Calling ATTACH with RSAPF=YES seems to do
exactly
what
Post by Robin Atwood
I want ...
It _can_ do what you want, Robin, but as others have said it is very
risky to do this, and very complex to do it safely. Basically, what
you're trying will only work safely if your STC is designed properly
to allow it. At a minimum, I believe that means making sure that none
of your STC code runs in key 8 or uses key 8 storage. It would need to
start from the beginning in a system key, specified by the Program
Properties Table in PARMLIB. You could then, possibly, invoke the
non-APF code safely as long as you run it in key 8.
But the question then becomes what do you expect the non-APF code to
do, and how do you expect to communicate with it.
It really would be better and safer, in my opinion, to find another
solution. This might possibly involve using multiple address spaces
(via UNIX fork()) as John McKown suggested. But we would really need
to know a lot more information about your STC, and the non-APF code,
to be able to provide the best advice.
(It is very unlikely, in my experience, that your current STC is
designed to allow you to do this safely. A major redesign and
reimplementation of the STC would probably be required if you haven't
been thinking about this from the very beginning of its development.)
--
Walt
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-05-15 16:27:09 UTC
Permalink
Raw Message
Post by Steve Smith
RSAPF probably shouldn't even be documented. AFAIK, it's only purpose is
to allow the system to support unauthorized tasks and jobs, and is used
only with the creation of a new job-step task. And there is no
communication between the initiator task and the user task.
What does the TSO TMP use to accomplish this?

(Topic drift: What's the difference between INTRDR and TSOINRDR?)
Post by Steve Smith
Authorized programs aren't allowed to invoke unauthorized code for a very
good reason. Trying to circumvent that in any way compromises your system
integrity. That said, running bad authorized code does as well, so caveat
emptor.
A couple contributors have suggested fork(). A similar option is BPX1EXM.
But all such facilities introduce complexities in communication between
parent and child processes.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Greg Dyck
2017-05-15 16:45:13 UTC
Permalink
Raw Message
Post by Paul Gilmartin
What does the TSO TMP use to accomplish this?
Extreme care ;-)

It has been a while, but my memory is that the TMP stops all of the
tasks above (or is that below?) it in the task tree and then passes the
request to a special jobstep task (with it's own JSCB) to execute the
command.

Regards,
Greg

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Mike Shaw
2017-05-15 17:18:39 UTC
Permalink
Raw Message
Post by Greg Dyck
Post by Paul Gilmartin
What does the TSO TMP use to accomplish this?
Extreme care ;-)
It has been a while, but my memory is that the TMP stops all of the
tasks above (or is that below?) it in the task tree and then passes the
request to a special jobstep task (with it's own JSCB) to execute the
command.
Regards,
Greg
Greg is correct; IKJEFT02 and its subtasks are STATUS STOP'ed, and a new
parallel (sister) task is attached to invoke anything needing APF
authorization. The TSO/E TSOEXEC command exists to do just that.

Mike Shaw
MVS/QuickRef Support Group
Chicago-Soft, Ltd.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2017-05-16 13:14:17 UTC
Permalink
Raw Message
Post by Robin Atwood
Thanks to everyone for replying, I would never realised you had to flip
JSCBAUTH from the macro documentation.
The actual business requirement is that we run Rexx execs that call ISPF
services on behalf of workstation users
running an IDE. The STC doing this must run authorised because it
communicates with a comms task via cross-memory services. So we will have
control over what gets executed. This is still very much an experiment, I am
not sure it will actually work.
Technically, for the communication you've described, only the comms task would have to run authorized. The STC could run unauthorized, using mechanisms setup by the authorized comms task.

However, as you're running work on behalf of various end-users, I hope you're authenticating those users and running the work under the proper end-user identity in each case. And that would probably require authorization of the STC.

It is a very tricky situation to manage properly and without introducing either system integrity or security issues.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Robin Atwood
2017-05-16 13:41:51 UTC
Permalink
Raw Message
However, as you're running work on behalf of various end-users, I hope you're authenticating those users and >running the work under the proper end-user identity in each case. And that would probably require authorization >of the STC.
Yes, we run under the ACEE of the user.

Robin

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-05-16 13:57:45 UTC
Permalink
Raw Message
<snip>
We have a requirement to attach user modules from an unauthorised library
and execute them from an STC which runs APF authorised.
</snip>

You need to reject that requirement. It cannot be accomplished while
maintaining system integrity. Use of something like "fork" can perhaps
accomplish the goal without meeting the letter of the requirement.

<snip>
Well, if you want to run unauthorized stuff you would first need to set
your
job as non-APF by resetting the bit.
</snip>

And if you do that, you must *never* turn the bit back on. Turning of
JSCBAUTH is a fairly common approach, once the "authorized stuff" has been
done. But you must then leave it off in order to maintain system
integrity.

In all likelihood you should NEVER use RSAPF=YES. It is provided so that
the initiator can attach the jobstep program task. I have no idea why it
was documented. Way back when, even internal things were documented. Maybe
when internal-only things were being removed from the books, no one
realized how internal this one was.

The only z/OS-supported mechanism for authority-decreasing is SYNCH(X).
And I do intentionally exclude authority-decreasing PC's (e.g., a PC that
gets control in problem state when the invoker was supervisor state) from
what is supported by z/OS. You can't be stopped from doing so, but things
likely won't behave the way you need if there was a (E)SPIE present. There
might be cases other than (E)SPIE that similarly would cause anomalous
behavior. I have no idea if this is documented explicitly. It's just
something I remember being told long long ago.

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
Robin Atwood
2017-05-17 07:34:40 UTC
Permalink
Raw Message
Peter-
Thanks for this, I shall ponder.

Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: 16 May 2017 20:58
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES

<snip>
We have a requirement to attach user modules from an unauthorised library
and execute them from an STC which runs APF authorised.
</snip>

You need to reject that requirement. It cannot be accomplished while
maintaining system integrity. Use of something like "fork" can perhaps
accomplish the goal without meeting the letter of the requirement.

<snip>
Well, if you want to run unauthorized stuff you would first need to set your
job as non-APF by resetting the bit.
</snip>

And if you do that, you must *never* turn the bit back on. Turning of
JSCBAUTH is a fairly common approach, once the "authorized stuff" has been
done. But you must then leave it off in order to maintain system integrity.

In all likelihood you should NEVER use RSAPF=YES. It is provided so that the
initiator can attach the jobstep program task. I have no idea why it was
documented. Way back when, even internal things were documented. Maybe when
internal-only things were being removed from the books, no one realized how
internal this one was.

The only z/OS-supported mechanism for authority-decreasing is SYNCH(X).
And I do intentionally exclude authority-decreasing PC's (e.g., a PC that
gets control in problem state when the invoker was supervisor state) from
what is supported by z/OS. You can't be stopped from doing so, but things
likely won't behave the way you need if there was a (E)SPIE present. There
might be cases other than (E)SPIE that similarly would cause anomalous
behavior. I have no idea if this is documented explicitly. It's just
something I remember being told long long ago.

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Robin Atwood
2017-05-18 12:55:39 UTC
Permalink
Raw Message
What is the situation of a module that is loaded from an authorised library
but was linked with AC=0? Is it authorised? Can it get authorised?

Thanks
Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: 16 May 2017 20:58
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES

<snip>
We have a requirement to attach user modules from an unauthorised library
and execute them from an STC which runs APF authorised.
</snip>

You need to reject that requirement. It cannot be accomplished while
maintaining system integrity. Use of something like "fork" can perhaps
accomplish the goal without meeting the letter of the requirement.

<snip>
Well, if you want to run unauthorized stuff you would first need to set your
job as non-APF by resetting the bit.
</snip>

And if you do that, you must *never* turn the bit back on. Turning of
JSCBAUTH is a fairly common approach, once the "authorized stuff" has been
done. But you must then leave it off in order to maintain system integrity.

In all likelihood you should NEVER use RSAPF=YES. It is provided so that the
initiator can attach the jobstep program task. I have no idea why it was
documented. Way back when, even internal things were documented. Maybe when
internal-only things were being removed from the books, no one realized how
internal this one was.

The only z/OS-supported mechanism for authority-decreasing is SYNCH(X).
And I do intentionally exclude authority-decreasing PC's (e.g., a PC that
gets control in problem state when the invoker was supervisor state) from
what is supported by z/OS. You can't be stopped from doing so, but things
likely won't behave the way you need if there was a (E)SPIE present. There
might be cases other than (E)SPIE that similarly would cause anomalous
behavior. I have no idea if this is documented explicitly. It's just
something I remember being told long long ago.

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-05-18 15:08:22 UTC
Permalink
Raw Message
Tom answered most of your question but in addition
Post by Robin Atwood
Can it get authorised?
I don't think there is any supported way for a program that is already
running to "get authorized."

I hope you are getting the idea how risky this entire approach is. You are
playing "you bet your mainframe." You might get it right today but what
happens five years from now (that's not very long. Remember 2012?) when you
have moved to other responsibilities, there is a new RACF administrator who
does not understand all the ramifications of your process, etc., etc.?

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Robin Atwood
Sent: Thursday, May 18, 2017 5:56 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES

What is the situation of a module that is loaded from an authorised library
but was linked with AC=0? Is it authorised? Can it get authorised?

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tony Harminc
2017-05-18 16:22:25 UTC
Permalink
Raw Message
Post by Robin Atwood
What is the situation of a module that is loaded from an authorised library
but was linked with AC=0? Is it authorised? Can it get authorised?
Modules are not authorized. Job steps are authorized.

If you are able to get your job step from an unauthorized to an authorized
state using IBM supplied facilities, IBM promises to fix it so you can't.
And probably pretty quickly.

I don't mean to sound pedantic about this. There is indeed an important
distinction between modules marked AC(1) and those not, when they live in
an authorized library. Nothing prevents an AC(0) module from being loaded
from such a library by an authorized job step, and given control in an
authorized state. This is the normal situation. The only modules that
should be marked AC(1) are those that are intended to be invoked as the
initial program of a job step, which typically means EXEC PGM= in JCL, or
CALL in TSO. (TSO has additional requirements to make CALL invoke a program
in an authorized state.) Such modules must be prepared to deal safely with
their environment, parms, and input data and not compromise system
integrity, because any user can invoke them with any parms and input.
Modules that are intended to run authorized, but to be invoked only by
other code running authorized, may not need such general protection against
malicious invokers.

Tony H.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Robin Atwood
2017-05-19 07:08:40 UTC
Permalink
Raw Message
I thought this must be the case but wanted to check. This is indeed how the product I am working on is set up: the
top-level job step module is AC=1, the rest not.

Thanks
Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tony Harminc
Sent: 18 May 2017 23:23
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES
Post by Robin Atwood
What is the situation of a module that is loaded from an authorised
library but was linked with AC=0? Is it authorised? Can it get authorised?
Modules are not authorized. Job steps are authorized.

If you are able to get your job step from an unauthorized to an authorized state using IBM supplied facilities, IBM promises to fix it so you can't.
And probably pretty quickly.

I don't mean to sound pedantic about this. There is indeed an important distinction between modules marked AC(1) and those not, when they live in an authorized library. Nothing prevents an AC(0) module from being loaded from such a library by an authorized job step, and given control in an authorized state. This is the normal situation. The only modules that should be marked AC(1) are those that are intended to be invoked as the initial program of a job step, which typically means EXEC PGM= in JCL, or CALL in TSO. (TSO has additional requirements to make CALL invoke a program in an authorized state.) Such modules must be prepared to deal safely with their environment, parms, and input data and not compromise system integrity, because any user can invoke them with any parms and input.
Modules that are intended to run authorized, but to be invoked only by other code running authorized, may not need such general protection against malicious invokers.

Tony H.

----------------------------------------------------------------------
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
2017-05-16 15:32:09 UTC
Permalink
Raw Message
Post by Robin Atwood
However, as you're running work on behalf of various end-users, I hope you're authenticating those users and >running the work under the proper end-user identity in each case. And that would probably require authorization >of the STC.
Yes, we run under the ACEE of the user.
However, unless your STC runs single-threaded (handling requests for only 1 user at a time) it's not possible for you to run REXX execs invokiing ISPF services with proper security.

It would require ensuring that none of the execs, or the services they invoke, perform any ATTACH requests., The new subtask created by ATTACH would not inherit the ACEE of the user on whose behalf you're running the request. (There is one exception to that, but it's used rarely enough that it probably won't apply to you. You would have to be using WLM services, and operating as a WLM servant to manage the requests that you're processing. Then, and only then as far as I know, would the user's ACEE propagate down to a new subtask.)
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Robin Atwood
2017-05-17 07:26:37 UTC
Permalink
Raw Message
We set the ASXBSENV to the ACEE of the user. The requests are run single-threaded, we will have a pool of STCs
available.

Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Walt Farrell
Sent: 16 May 2017 22:33
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES
Post by Robin Atwood
However, as you're running work on behalf of various end-users, I hope you're authenticating those users and >running the work under the proper end-user identity in each case. And that would probably require authorization >of the STC.
Yes, we run under the ACEE of the user.
However, unless your STC runs single-threaded (handling requests for only 1 user at a time) it's not possible for you to run REXX execs invokiing ISPF services with proper security.

It would require ensuring that none of the execs, or the services they invoke, perform any ATTACH requests., The new subtask created by ATTACH would not inherit the ACEE of the user on whose behalf you're running the request. (There is one exception to that, but it's used rarely enough that it probably won't apply to you. You would have to be using WLM services, and operating as a WLM servant to manage the requests that you're processing. Then, and only then as far as I know, would the user's ACEE propagate down to a new subtask.)

--
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
Binyamin Dissen
2017-05-17 11:59:11 UTC
Permalink
Raw Message
In which case you should supply two calls to the non-privileged STC, one which
will get the work element and set the security and a second which will return
results. The calls can be PC's or SVCs.

On Wed, 17 May 2017 14:27:25 +0700 Robin Atwood <***@GMAIL.COM> wrote:

:>We set the ASXBSENV to the ACEE of the user. The requests are run single-threaded, we will have a pool of STCs
:>available.
:>
:>Robin
:>
:>-----Original Message-----
:>From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Walt Farrell
:>Sent: 16 May 2017 22:33
:>To: IBM-***@LISTSERV.UA.EDU
:>Subject: Re: ATTACH with RSAPF=YES
:>
:>On Tue, 16 May 2017 20:42:42 +0700, Robin Atwood <***@GMAIL.COM> wrote:
:>
:>>>However, as you're running work on behalf of various end-users, I hope you're authenticating those users and >running the work under the proper end-user identity in each case. And that would probably require authorization >of the STC.
:>>
:>>Yes, we run under the ACEE of the user.
:>
:>However, unless your STC runs single-threaded (handling requests for only 1 user at a time) it's not possible for you to run REXX execs invokiing ISPF services with proper security.
:>
:>It would require ensuring that none of the execs, or the services they invoke, perform any ATTACH requests., The new subtask created by ATTACH would not inherit the ACEE of the user on whose behalf you're running the request. (There is one exception to that, but it's used rarely enough that it probably won't apply to you. You would have to be using WLM services, and operating as a WLM servant to manage the requests that you're processing. Then, and only then as far as I know, would the user's ACEE propagate down to a new subtask.)

--
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
Tom Marchant
2017-05-18 13:55:02 UTC
Permalink
Raw Message
Post by Robin Atwood
What is the situation of a module that is loaded from an authorised library
but was linked with AC=0? Is it authorised? Can it get authorised?
Loaded by whom?

When you EXEC PGM=x, if program X is linked AC=1 and is loaded from
an APF authorized library, and all JOBLIB/STEPLIB libraries are APF
authorized, the address space is authorized.

If program X, running in an authorized address space loads program Y,
it does not matter whether program Y is linked AC=0 or AC=1. It must
come from an APF authorized library. The address space is still authorized.
The system can't tell when control passes between program X and
program Y.

This simplified version of what happens is basic APF authorization stuff.
I would expect that anyone who wants to do what you propose would
have a thorough understanding of this.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jesse 1 Robinson
2017-05-18 15:57:26 UTC
Permalink
Raw Message
Early versions of SDSF provided an SVC that would make the user authorized. It was 'supported' in that it was part of an official IBM program product. There was a general discomfort with this strategy even though the SVC code tried very hard to validate the environment. Eventually (I believe) the SVC was discarded as being too difficult to make airtight.

.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-543-6132 Office ⇐=== NEW
***@sce.com


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Charles Mills
Sent: Thursday, May 18, 2017 8:09 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: (External):Re: ATTACH with RSAPF=YES

Tom answered most of your question but in addition
Post by Robin Atwood
Can it get authorised?
I don't think there is any supported way for a program that is already running to "get authorized."

I hope you are getting the idea how risky this entire approach is. You are playing "you bet your mainframe." You might get it right today but what happens five years from now (that's not very long. Remember 2012?) when you have moved to other responsibilities, there is a new RACF administrator who does not understand all the ramifications of your process, etc., etc.?

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Robin Atwood
Sent: Thursday, May 18, 2017 5:56 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES

What is the situation of a module that is loaded from an authorised library but was linked with AC=0? Is it authorised? Can it get authorised?


----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Charles Mills
2017-05-18 16:18:31 UTC
Permalink
Raw Message
"Magic" SVCs are the scourge of z/OS integrity.

The amount of validation you have to do to make a magic SVC airtight exceeds the burden of simply doing it right: linking the program AC=1 into an APF-authorized library.

They used to be common in vendor products: easier to write a magic SVC than to get the customer to authorize the library. I think the practice is on the decline.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson
Sent: Thursday, May 18, 2017 8:58 AM
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES

Early versions of SDSF provided an SVC that would make the user authorized. It was 'supported' in that it was part of an official IBM program product. There was a general discomfort with this strategy even though the SVC code tried very hard to validate the environment. Eventually (I believe) the SVC was discarded as being too difficult to make airtight.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Tom Marchant
2017-05-18 18:46:49 UTC
Permalink
Raw Message
Post by Charles Mills
I hope you are getting the idea how risky this entire approach is. You are
playing "you bet your mainframe." You might get it right today....
And if you don't get it right, you might discover that, or you might not.
It is very difficult to demonstrate that you have not created an integrity exposure.
--
Tom Marchant

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Robin Atwood
2017-05-19 07:31:40 UTC
Permalink
Raw Message
The situation would be that the client routes a command to the server on the host which routes it to a dependent ASID. The DA gets the ACEE of the user and executes the command via IJKEFTSR. The command is one of a suite of
Rexx execs in a library allocated to the DA which executes ISPF services (eg, to copy some members). Without wilful
collaboration of a sysprog I am struggling to see how this could be subverted by a malicious user. However, if you can see something please let me know!

Thanks
Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Tom Marchant
Sent: 19 May 2017 01:47
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES
Post by Charles Mills
I hope you are getting the idea how risky this entire approach is. You
are playing "you bet your mainframe." You might get it right today....
And if you don't get it right, you might discover that, or you might not.
It is very difficult to demonstrate that you have not created an integrity exposure.

--
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
2017-05-19 12:33:03 UTC
Permalink
Raw Message
Post by Robin Atwood
The situation would be that the client routes a command to the server on the host which routes it to a dependent ASID. The DA gets the ACEE of the user and executes the command via IJKEFTSR. The command is one of a suite of
Rexx execs in a library allocated to the DA which executes ISPF services (eg, to copy some members). Without wilful
collaboration of a sysprog I am struggling to see how this could be subverted by a malicious user. However, if you can see something >please let me know!
It all comes down to the fine (and unknown to us) details of how your dependent ASID initializes, what storage key the initiator ATTACHes it in, what storage keys it uses, and how you plan to remove authorization (JSCBAUTH) before invoking IKJEFTSR. (And that you never restore authorization (JSCBAUTH) once you've removed it.)

Ideally you would not run the dependent ASID authorized at all. There are at least two ways you could do that, I believe:
(1) z/OS provides services via WLM that (if I remember correctly) allow an authorized server to route requests to an unauthorized servant, with z/OS managing the identity that is used for each request.

(2) Using UNIX functions you could fork() a new address space to handle the request, switch the identity while still running authorized, and then execmvs() a new unauthorized program to run the request, return the results, and terminate. This does have the dependent ASID running authorized briefly, but the execmvs() takes care of cleaning things up so unauthorized code can then run safely.

In any case, if you have not been running REXX execs and TSO or ISPF functions before in your dependent address spaces, you will probably have some major redesign to do in order to run them safely. And if you're going to do some major redesign you should start afresh with something that is architecturally safer, such as (1) or (2) above.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Robin Atwood
2017-05-19 13:05:01 UTC
Permalink
Raw Message
(2) is interesting. Actually my first thought was to use ASCRE to spawn a new ASID to execute the command but
I have heard that address space creation/destruction is a major overhead and so focused on ATTACH.

Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Walt Farrell
Sent: 19 May 2017 19:34
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES
Post by Robin Atwood
The situation would be that the client routes a command to the server
on the host which routes it to a dependent ASID. The DA gets the ACEE
of the user and executes the command via IJKEFTSR. The command is one of a suite of Rexx execs in a library allocated to the DA which executes ISPF services (eg, to copy some members). Without wilful collaboration of a sysprog I am struggling to see how this could be subverted by a malicious user. However, if you can see something >please let me know!
It all comes down to the fine (and unknown to us) details of how your dependent ASID initializes, what storage key the initiator ATTACHes it in, what storage keys it uses, and how you plan to remove authorization (JSCBAUTH) before invoking IKJEFTSR. (And that you never restore authorization (JSCBAUTH) once you've removed it.)

Ideally you would not run the dependent ASID authorized at all. There are at least two ways you could do that, I believe:
(1) z/OS provides services via WLM that (if I remember correctly) allow an authorized server to route requests to an unauthorized servant, with z/OS managing the identity that is used for each request.

(2) Using UNIX functions you could fork() a new address space to handle the request, switch the identity while still running authorized, and then execmvs() a new unauthorized program to run the request, return the results, and terminate. This does have the dependent ASID running authorized briefly, but the execmvs() takes care of cleaning things up so unauthorized code can then run safely.

In any case, if you have not been running REXX execs and TSO or ISPF functions before in your dependent address spaces, you will probably have some major redesign to do in order to run them safely. And if you're going to do some major redesign you should start afresh with something that is architecturally safer, such as (1) or (2) above.

--
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
Walt Farrell
2017-05-19 13:36:02 UTC
Permalink
Raw Message
Post by Robin Atwood
(2) is interesting. Actually my first thought was to use ASCRE to spawn a new ASID to execute the command but
I have heard that address space creation/destruction is a major overhead and so focused on ATTACH.
My first question would be whether you're processing enough requests, frequently enough, to worry about the overhead. If you're not used that frequently, maybe the overhead won't matter?

But if it does matter, UNIX processes tend to run in different address spaces, and the system has optimization for that. Using UNIX functions like fork()/execmvs() rather than ASCRE should eliminate a lot of the overhead you're concerned about.

Using the WLM functions that z/OS provides for situations such as yours might do even better. I'm not sure about that.

Either should (more) easily avoid the integrity pitfalls you're headed toward.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-05-19 15:42:27 UTC
Permalink
Raw Message
Post by Walt Farrell
Post by Robin Atwood
(2) is interesting. Actually my first thought was to use ASCRE to spawn a new ASID to execute the command but
I have heard that address space creation/destruction is a major overhead and so focused on ATTACH.
My first question would be whether you're processing enough requests, frequently enough, to worry about the overhead. If you're not used that frequently, maybe the overhead won't matter?
And, an address space created by fork()/BPXAS lingers after the process terminates
(I've observed in system log for 30 minutes) so another fork() within that interval
needn't start a new address space.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Robin Atwood
2017-05-22 07:12:59 UTC
Permalink
Raw Message
Thanks. Potentially there will be a lot of transactions so I will look into this, although starting the TMP after a fork() seems a bit fraught!

--
Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin
Sent: 19 May 2017 22:43
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES
Post by Walt Farrell
Post by Robin Atwood
(2) is interesting. Actually my first thought was to use ASCRE to
spawn a new ASID to execute the command but I have heard that address space creation/destruction is a major overhead and so focused on ATTACH.
My first question would be whether you're processing enough requests, frequently enough, to worry about the overhead. If you're not used that frequently, maybe the overhead won't matter?
And, an address space created by fork()/BPXAS lingers after the process terminates (I've observed in system log for 30 minutes) so another fork() within that interval needn't start a new address space.

-- 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
Peter Relson
2017-05-22 17:23:07 UTC
Permalink
Raw Message
As best I can tell (unless I missed it), the OP has not answered the
question of whether they understand that after doing something to remove
authorization from the space, they are OK with leaving the space
unauthorized. If that is not the case, we might as well end the
discussion because there is no way to do that while maintaining system
integrity, and it is unlikely anyone would accept such a "solution".

Walt Farrell has pointed out approaches that are conceivably OK.

ATTACH with RSAPF=YES should be off the table.

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
Robin Atwood
2017-05-23 07:43:04 UTC
Permalink
Raw Message
Yes, the point was taken. I am now investigating using fork() to spin-off
another address space.

Thanks
Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On
Behalf Of Peter Relson
Sent: 23 May 2017 00:24
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES

As best I can tell (unless I missed it), the OP has not answered the
question of whether they understand that after doing something to remove
authorization from the space, they are OK with leaving the space
unauthorized. If that is not the case, we might as well end the discussion
because there is no way to do that while maintaining system integrity, and
it is unlikely anyone would accept such a "solution".

Walt Farrell has pointed out approaches that are conceivably OK.

ATTACH with RSAPF=YES should be off the table.

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

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-05-23 12:40:31 UTC
Permalink
Raw Message
Post by Robin Atwood
Yes, the point was taken. I am now investigating using fork() to spin-off
another address space.
​From my vague monitoring of this thread, I think that is a wonderful idea.
I don't know how much you're "in to" what can be done, but there are some
nice(!) facilities that fork() can leverage.

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxb200/bpxenv.htm

You can use the C language setenv() to set a number of UNIX environment
variables with can affect the results of fork() if you have the right RACF
authorities set up.

_BPX_JOB NAME can set the name of the fork'd address space (such as to the
user's name)
_B PX_USERID can set the RACF owner for the fork'd address space. The
address space doing the fork() needs some "heavy" RACF authorities for this.
Post by Robin Atwood
Thanks
Robin
--
Windows. A funny name for a operating system that doesn't let you see
anything.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Robin Atwood
2017-05-23 13:21:13 UTC
Permalink
Raw Message
Thanks, John. I have constructed a bare-bones testbed in HLASM and called BPX1FRK and it "Just Worked". :) The
cool thing is the child process is created in a BPXAS address space that is just lying around and doesn't need to be
created. And, according to the doc, in the real case where the STC is multi-TCB only the TCB issuing the fork gets cloned in the new ASID, exactly what I want.

--
Robin

-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-***@LISTSERV.UA.EDU] On Behalf Of John McKown
Sent: 23 May 2017 19:41
To: IBM-***@LISTSERV.UA.EDU
Subject: Re: ATTACH with RSAPF=YES
Post by Robin Atwood
Yes, the point was taken. I am now investigating using fork() to
spin-off another address space.
​From my vague monitoring of this thread, I think that is a wonderful idea.
I don't know how much you're "in to" what can be done, but there are some
nice(!) facilities that fork() can leverage.

https://www.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.bpxb200/bpxenv.htm

You can use the C language setenv() to set a number of UNIX environment variables with can affect the results of fork() if you have the right RACF authorities set up.

_BPX_JOB NAME can set the name of the fork'd address space (such as to the user's name) _B PX_USERID can set the RACF owner for the fork'd address space. The address space doing the fork() needs some "heavy" RACF authorities for this.
Post by Robin Atwood
Thanks
Robin
--
Windows. A funny name for a operating system that doesn't let you see anything.

Maranatha! <><
John McKown

----------------------------------------------------------------------
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
Clem Clarke
2017-05-24 05:25:08 UTC
Permalink
Raw Message
I am afraid I have not been able to follow the whole conversation.
However, it seems that perhaps attaching as a job step may be an answer?

This is the way the Initiator attaches a program. The Initiator is
authorised, and uses a special attach which will either attach a program
in Problem State, or allow it to keep it's authorised state, if it is
being loaded from an authorised library, and is linked with the
appropriate option.

This code has been used for 40 years in my enhanced JCL language Jol,
from which I created a program that allows parameters to be passed up to
3,000 bytes. The program is called LONGPARM and is CBT file number 839.

The enhanced JCL Language can be seen at www.Oscar-Jol.com

Here is the part of the code that shows how the Job Step option can be used.

------
***********************************************************
*
*
*
* NOW ATTACH PROBLEM PROGRAM. 75311
*
* Note: We could set up the SCT so that SMF records the "correct"
* program. Wait for user feedback.
*
*
ATTACH LA R1,#PARMPP Get Address of User Parameters
LH R15,#PARMPP Put some blanks at the end
LA R15,2(R1,R15) Point to end of string
MVC 0(20,R15),BLANKS
ST R1,ATASKPRM Store it
OI ATASKPRM,X'80' Set Hi Bit 75311
LA R1,ATASKPRM Set R1 for Attach 75311
XC TASKECB,TASKECB CLEAR ECB 75311
MVC ATTACHL(ATTACHLN),ATTACHW INITIALISE ATTACH
* BECAUSE 'E' FORM DOESN'T INITIALISE
* ALL THE BITS.
ATTACH EPLOC=TASKNAME,ECB=TASKECB,SF=(E,ATTACHL), *
RSAPF=YES, *
JSTCB=YES,MF=(E,(1)) 76200
LR R5,R1
WAIT ECB=TASKECB
MVC TASKRETN(1),X'1D'(R5) SHIFT IN ABEND CODE
MVC TASKRETN+1(3),TASKECB+1 AND RETURN CODE
* NOW I'M BACK IN CONTROL,I.E THE SUBTASK FINISHED.
* WHAT AM I TO DO NOW ?
ST R5,CALLAREA
DETACH CALLAREA
TABEND TM TASKRETN,128 NORMAL RETURN FOR TASK? 75003
BNO TESTGOBK YES,SO TEST GOBACK TO OS INDIC 76200
IC R7,TASKRETN SET R7 = ABEND CODE
L R1,TASKRETN LOAD TASKRETN TO REG 1
ABEND (1)
* N R1,=X'00FFFFFF' LEAVE RETURN CODE
TESTGOBK EQU *
SPACE 3
RETNOS EQU *
LH R10,TASKRETN+2 LOAD 2ND 2 BYTES OF RETURN CODE
BADRETN EQU *
L R7,4(R13) LOAD R7 WITH PREVIOUS SAVEAREA ADDRESS
LR R1,R13 LOAD R1 WITH THE ADDRESS OF GOTTEN
* STORAGE
FREEMAIN R,LV=CONEND-CONSTART,A=(1)
LR R13,R7 SET R13=OLD SAVE
LR R15,R10 SET UP RETURN CODE
L R14,12(13) AND RETURN ADDRESS
LM R0,R12,20(R13) AND OLD REGISTERS
BR R14 AND BACK WE GO
*
------


Clem Clarke
Post by Robin Atwood
Yes, the point was taken. I am now investigating using fork() to spin-off
another address space.
Thanks
Robin
-----Original Message-----
Behalf Of Peter Relson
Sent: 23 May 2017 00:24
Subject: Re: ATTACH with RSAPF=YES
As best I can tell (unless I missed it), the OP has not answered the
question of whether they understand that after doing something to remove
authorization from the space, they are OK with leaving the space
unauthorized. If that is not the case, we might as well end the discussion
because there is no way to do that while maintaining system integrity, and
it is unlikely anyone would accept such a "solution".
Walt Farrell has pointed out approaches that are conceivably OK.
ATTACH with RSAPF=YES should be off the table.
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
----------------------------------------------------------------------
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
Jim Mulder
2017-05-24 17:21:39 UTC
Permalink
Raw Message
That is not the way the Initiator works. The Initiator is not
APF-authorized.

Does your program use any key 8 storage (like the save area that was
provided when your program was ATTACHed, or the subpool 0 area that you
FREEMAIN when the program that you ATTACHed ends)?
Could the unauthorized program that you ATTACHed modify these area in such
a way
that when your code does the LM and BR 14, it branches to some code
created
by the unauthorized program, so that the unauthorized program can cause
code
it created to run authorized under your task?

When you ATTACH an authorized program and pass it a parm that is longer
than 100 bytes, how do you prevent a buffer overflow security exposure if
the
authorized program you are ATTACHing copies the parm to a 100 byte buffer
(which it assumes is a safe thing to do, because the system documentation
stated
that the maximum PARM= length was 100 bytes)?

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
Post by Clem Clarke
I am afraid I have not been able to follow the whole conversation.
However, it seems that perhaps attaching as a job step may be an answer?
This is the way the Initiator attaches a program. The Initiator is
authorised, and uses a special attach which will either attach a program
in Problem State, or allow it to keep it's authorised state, if it is
being loaded from an authorised library, and is linked with the
appropriate option.
This code has been used for 40 years in my enhanced JCL language Jol,
from which I created a program that allows parameters to be passed up to
3,000 bytes. The program is called LONGPARM and is CBT file number 839.
The enhanced JCL Language can be seen at www.Oscar-Jol.com
Here is the part of the code that shows how the Job Step option can be used.
------
***********************************************************
*
*
*
* NOW ATTACH PROBLEM PROGRAM. 75311
*
* Note: We could set up the SCT so that SMF records the "correct"
* program. Wait for user feedback.
*
*
ATTACH LA R1,#PARMPP Get Address of User Parameters
LH R15,#PARMPP Put some blanks at the end
LA R15,2(R1,R15) Point to end of string
MVC 0(20,R15),BLANKS
ST R1,ATASKPRM Store it
OI ATASKPRM,X'80' Set Hi Bit 75311
LA R1,ATASKPRM Set R1 for Attach 75311
XC TASKECB,TASKECB CLEAR ECB 75311
MVC ATTACHL(ATTACHLN),ATTACHW INITIALISE ATTACH
* BECAUSE 'E' FORM DOESN'T INITIALISE
* ALL THE BITS.
ATTACH EPLOC=TASKNAME,ECB=TASKECB,SF=(E,ATTACHL), *
RSAPF=YES, *
JSTCB=YES,MF=(E,(1)) 76200
LR R5,R1
WAIT ECB=TASKECB
MVC TASKRETN(1),X'1D'(R5) SHIFT IN ABEND CODE
MVC TASKRETN+1(3),TASKECB+1 AND RETURN CODE
* NOW I'M BACK IN CONTROL,I.E THE SUBTASK FINISHED.
* WHAT AM I TO DO NOW ?
ST R5,CALLAREA
DETACH CALLAREA
TABEND TM TASKRETN,128 NORMAL RETURN FOR TASK? 75003
BNO TESTGOBK YES,SO TEST GOBACK TO OS INDIC 76200
IC R7,TASKRETN SET R7 = ABEND CODE
L R1,TASKRETN LOAD TASKRETN TO REG 1
ABEND (1)
* N R1,=X'00FFFFFF' LEAVE RETURN CODE
TESTGOBK EQU *
SPACE 3
RETNOS EQU *
LH R10,TASKRETN+2 LOAD 2ND 2 BYTES OF RETURN CODE
BADRETN EQU *
L R7,4(R13) LOAD R7 WITH PREVIOUS SAVEAREA ADDRESS
LR R1,R13 LOAD R1 WITH THE ADDRESS OF GOTTEN
* STORAGE
FREEMAIN R,LV=CONEND-CONSTART,A=(1)
LR R13,R7 SET R13=OLD SAVE
LR R15,R10 SET UP RETURN CODE
L R14,12(13) AND RETURN ADDRESS
LM R0,R12,20(R13) AND OLD REGISTERS
BR R14 AND BACK WE GO
*
------
Clem Clarke
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-05-24 17:47:06 UTC
Permalink
Raw Message
Post by Jim Mulder
That is not the way the Initiator works. The Initiator is not
APF-authorized.
Does your program use any key 8 storage (like the save area that was
provided when your program was ATTACHed, or the subpool 0 area that you
FREEMAIN when the program that you ATTACHed ends)?
Could the unauthorized program that you ATTACHed modify these area in such
a way
that when your code does the LM and BR 14, it branches to some code
created
by the unauthorized program, so that the unauthorized program can cause
code
it created to run authorized under your task?
When you ATTACH an authorized program and pass it a parm that is longer
than 100 bytes, how do you prevent a buffer overflow security exposure if
the
authorized program you are ATTACHing copies the parm to a 100 byte buffer
(which it assumes is a safe thing to do, because the system documentation
stated
that the maximum PARM= length was 100 bytes)?
Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
​The above is why I really "push" the UNIX fork() alternative. The
"controller" program does not even need APF authorization. To start a new
address space on behalf of another user only requires some RACF authorities
for the RACF id doing the fork(), unlike ASCRE. I am assuming that the
child process does _not_ need any special DDs for data sets to be
"preallocated". but the child can use DYNALLOC to allocate DDs based on
parameters or (IMO better) environment variables. If a "steplib" is needed,
the initial child program can simply DYNALLOC the DSNs and then use an
ATTACHX with a TASKLIB. As an aside, if the child program is COBOL or PL/I,
then it can just let LE do the DYNALLOC by having the "controller" set up
the proper environment variables as documented in the COBOL or PL/I manuals.
--
Windows. A funny name for a operating system that doesn't let you see
anything.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-05-25 13:10:50 UTC
Permalink
Raw Message
Post by John McKown
The above is why I really "push" the UNIX fork() alternative.
[snip]
Post by John McKown
If a "steplib" is needed, the initial child program can simply DYNALLOC
the DSNs and then use an ATTACHX with a TASKLIB.
Assuming there will be an exec() in the forked process, a steplib can be
setup simply by setting the STEPLIB environment variable, and passing that
to exec().
​That is true. As I read the doc on fork(), the parent's
TASKLIB/STEPLIB/JOBLIB is propagated to the child. As best as I can tell,
the OP's program is _not_ really designed as a UNIX program, per se. That
is, I am assuming that his programs (and specifically the non-APF program
to be invoked for some purpose) reside in a _library_ (PDS or PDSE) and not
a UNIX directory. So I was not envisioning him using a UNIX exec() function
to run the non-APF program in the child. I was thinking the "historic" use
of LINKX or maybe ATTACHX.​ The mention of a TASKLIB for a dynamically
allocated was just in the case that the OP's design called for the
specification of a user designed set of libraries as well as just a program
name.

If I get really bored, I may actually write a smallish HLASM program which
uses BPX1FRK to fork my process and then do a LINKX in the child for a
program in my personal link library (which will be on the parent's STEPLIB)
just to make sure that what I have in my mind actually works as I think it
does.
--
Peter Hunkeler
--
Windows. A funny name for a operating system that doesn't let you see
anything.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Out The Darkness Just for All My Haters
2017-05-24 18:12:34 UTC
Permalink
Raw Message
All I can tell you is this. There are hard drives being brought into my
home with CD blanks and being taken out one at a time and sold.

Various devices being connected to the router and live streamed.
When Bright House came to install the new router I ordered I was told it
was set up and secure.

I started to see the same issues within a day. I noticed the router was
rewired and new connections hooked to it.

I grabbed the instruction book to secure the router and the system will not
let me. It gives an error code. Ive reset it a dozen times bought 4 new
phones in the past year with Metro and I cant stop the issues.

I wake up some morings to sometimes 60 to 70 open tabs on my phone.

My chrome book is no longer chrome it says windiws or linxis.

I have no iphone or ipad or windows computer yet those devices access my
accounts.

Im locked out of all social media my pages load incorrectly and I have to
change my passwords at least 4 times a day.

So maybe you all can help me explain all that.

Tanya
Post by Jim Mulder
That is not the way the Initiator works. The Initiator is not
APF-authorized.
Does your program use any key 8 storage (like the save area that was
provided when your program was ATTACHed, or the subpool 0 area that you
FREEMAIN when the program that you ATTACHed ends)?
Could the unauthorized program that you ATTACHed modify these area in such
a way
that when your code does the LM and BR 14, it branches to some code
created
by the unauthorized program, so that the unauthorized program can cause
code
it created to run authorized under your task?
When you ATTACH an authorized program and pass it a parm that is longer
than 100 bytes, how do you prevent a buffer overflow security exposure if
the
authorized program you are ATTACHing copies the parm to a 100 byte buffer
(which it assumes is a safe thing to do, because the system documentation
stated
that the maximum PARM= length was 100 bytes)?
Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
Post by Clem Clarke
I am afraid I have not been able to follow the whole conversation.
However, it seems that perhaps attaching as a job step may be an answer?
This is the way the Initiator attaches a program. The Initiator is
authorised, and uses a special attach which will either attach a program
in Problem State, or allow it to keep it's authorised state, if it is
being loaded from an authorised library, and is linked with the
appropriate option.
This code has been used for 40 years in my enhanced JCL language Jol,
from which I created a program that allows parameters to be passed up to
3,000 bytes. The program is called LONGPARM and is CBT file number 839.
The enhanced JCL Language can be seen at www.Oscar-Jol.com
Here is the part of the code that shows how the Job Step option can be
used.
Post by Clem Clarke
------
***********************************************************
*
*
*
* NOW ATTACH PROBLEM PROGRAM. 75311
*
* Note: We could set up the SCT so that SMF records the "correct"
* program. Wait for user feedback.
*
*
ATTACH LA R1,#PARMPP Get Address of User Parameters
LH R15,#PARMPP Put some blanks at the end
LA R15,2(R1,R15) Point to end of string
MVC 0(20,R15),BLANKS
ST R1,ATASKPRM Store it
OI ATASKPRM,X'80' Set Hi Bit 75311
LA R1,ATASKPRM Set R1 for Attach 75311
XC TASKECB,TASKECB CLEAR ECB 75311
MVC ATTACHL(ATTACHLN),ATTACHW INITIALISE ATTACH
* BECAUSE 'E' FORM DOESN'T INITIALISE
* ALL THE BITS.
ATTACH EPLOC=TASKNAME,ECB=TASKECB,SF=(E,ATTACHL), *
RSAPF=YES, *
JSTCB=YES,MF=(E,(1)) 76200
LR R5,R1
WAIT ECB=TASKECB
MVC TASKRETN(1),X'1D'(R5) SHIFT IN ABEND CODE
MVC TASKRETN+1(3),TASKECB+1 AND RETURN CODE
* NOW I'M BACK IN CONTROL,I.E THE SUBTASK FINISHED.
* WHAT AM I TO DO NOW ?
ST R5,CALLAREA
DETACH CALLAREA
TABEND TM TASKRETN,128 NORMAL RETURN FOR TASK? 75003
BNO TESTGOBK YES,SO TEST GOBACK TO OS INDIC 76200
IC R7,TASKRETN SET R7 = ABEND CODE
L R1,TASKRETN LOAD TASKRETN TO REG 1
ABEND (1)
* N R1,=X'00FFFFFF' LEAVE RETURN CODE
TESTGOBK EQU *
SPACE 3
RETNOS EQU *
LH R10,TASKRETN+2 LOAD 2ND 2 BYTES OF RETURN CODE
BADRETN EQU *
L R7,4(R13) LOAD R7 WITH PREVIOUS SAVEAREA ADDRESS
LR R1,R13 LOAD R1 WITH THE ADDRESS OF GOTTEN
* STORAGE
FREEMAIN R,LV=CONEND-CONSTART,A=(1)
LR R13,R7 SET R13=OLD SAVE
LR R15,R10 SET UP RETURN CODE
L R14,12(13) AND RETURN ADDRESS
LM R0,R12,20(R13) AND OLD REGISTERS
BR R14 AND BACK WE GO
*
------
Clem Clarke
----------------------------------------------------------------------
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
Out The Darkness Just for All My Haters
2017-05-24 18:24:04 UTC
Permalink
Raw Message
I know nothing about programming at all. I worked in Real Estate and Escrow
and Banking my entire life. I try and fix the tickets that come up it seems
I make it worse.

I would love to learn IT but with the zillion other issues this has all
created for me for 3 years now I became a basket case and I am trying now
to pull my life together and fix this mess surrounding me over computer
access being given to so many people the fraud is ridiculous

I am threatened my children are bullied this has not been easy. Like I said
if it is something I caused by hitting a link I will own that. However when
your watching hard drives and burners come in and out your house adding
other strange behavior it gets overwhelming and yes at times I panic. I can
ot seem to get any help and its not from lack of trying like some think, It
is from lack of trust in the system in this county.
Post by Clem Clarke
I am afraid I have not been able to follow the whole conversation.
However, it seems that perhaps attaching as a job step may be an answer?
This is the way the Initiator attaches a program. The Initiator is
authorised, and uses a special attach which will either attach a program in
Problem State, or allow it to keep it's authorised state, if it is being
loaded from an authorised library, and is linked with the appropriate
option.
This code has been used for 40 years in my enhanced JCL language Jol, from
which I created a program that allows parameters to be passed up to 3,000
bytes. The program is called LONGPARM and is CBT file number 839.
The enhanced JCL Language can be seen at www.Oscar-Jol.com
Here is the part of the code that shows how the Job Step option can be used.
------
***********************************************************
*
*
*
* NOW ATTACH PROBLEM PROGRAM. 75311
*
* Note: We could set up the SCT so that SMF records the "correct"
* program. Wait for user feedback.
*
*
ATTACH LA R1,#PARMPP Get Address of User Parameters
LH R15,#PARMPP Put some blanks at the end
LA R15,2(R1,R15) Point to end of string
MVC 0(20,R15),BLANKS
ST R1,ATASKPRM Store it
OI ATASKPRM,X'80' Set Hi Bit 75311
LA R1,ATASKPRM Set R1 for Attach 75311
XC TASKECB,TASKECB CLEAR ECB 75311
MVC ATTACHL(ATTACHLN),ATTACHW INITIALISE ATTACH
* BECAUSE 'E' FORM DOESN'T INITIALISE
* ALL THE BITS.
ATTACH EPLOC=TASKNAME,ECB=TASKECB,SF=(E,ATTACHL), *
RSAPF=YES, *
JSTCB=YES,MF=(E,(1)) 76200
LR R5,R1
WAIT ECB=TASKECB
MVC TASKRETN(1),X'1D'(R5) SHIFT IN ABEND CODE
MVC TASKRETN+1(3),TASKECB+1 AND RETURN CODE
* NOW I'M BACK IN CONTROL,I.E THE SUBTASK FINISHED.
* WHAT AM I TO DO NOW ?
ST R5,CALLAREA
DETACH CALLAREA
TABEND TM TASKRETN,128 NORMAL RETURN FOR TASK? 75003
BNO TESTGOBK YES,SO TEST GOBACK TO OS INDIC 76200
IC R7,TASKRETN SET R7 = ABEND CODE
L R1,TASKRETN LOAD TASKRETN TO REG 1
ABEND (1)
* N R1,=X'00FFFFFF' LEAVE RETURN CODE
TESTGOBK EQU *
SPACE 3
RETNOS EQU *
LH R10,TASKRETN+2 LOAD 2ND 2 BYTES OF RETURN CODE
BADRETN EQU *
L R7,4(R13) LOAD R7 WITH PREVIOUS SAVEAREA ADDRESS
LR R1,R13 LOAD R1 WITH THE ADDRESS OF GOTTEN
* STORAGE
FREEMAIN R,LV=CONEND-CONSTART,A=(1)
LR R13,R7 SET R13=OLD SAVE
LR R15,R10 SET UP RETURN CODE
L R14,12(13) AND RETURN ADDRESS
LM R0,R12,20(R13) AND OLD REGISTERS
BR R14 AND BACK WE GO
*
------
Clem Clarke
Post by Robin Atwood
Yes, the point was taken. I am now investigating using fork() to spin-off
another address space.
Thanks
Robin
-----Original Message-----
Behalf Of Peter Relson
Sent: 23 May 2017 00:24
Subject: Re: ATTACH with RSAPF=YES
As best I can tell (unless I missed it), the OP has not answered the
question of whether they understand that after doing something to remove
authorization from the space, they are OK with leaving the space
unauthorized. If that is not the case, we might as well end the discussion
because there is no way to do that while maintaining system integrity, and
it is unlikely anyone would accept such a "solution".
Walt Farrell has pointed out approaches that are conceivably OK.
ATTACH with RSAPF=YES should be off the table.
Peter Relson
z/OS Core Technology Design
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
----------------------------------------------------------------------
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
Paul Gilmartin
2017-05-24 19:27:41 UTC
Permalink
Raw Message
Post by Jim Mulder
That is not the way the Initiator works. The Initiator is not
APF-authorized.
I'll assume Initiator uses an SVC or PC to launch the program with
suitable APF-authority (in a separate address space?) similar to what
fork() and BPX1EXM do. What component performs the allocations,
since those don't cross address spaces?
Post by Jim Mulder
When you ATTACH an authorized program and pass it a parm that is longer
than 100 bytes, how do you prevent a buffer overflow security exposure if the
authorized program you are ATTACHing copies the parm to a 100 byte buffer
(which it assumes is a safe thing to do, because the system documentation stated
that the maximum PARM= length was 100 bytes)?
Moribund horse. The LONGPARM option was provided to control this.
But does ATTACH verify LONGPARM? If not, the calling program should.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jim Mulder
2017-05-24 20:39:38 UTC
Permalink
Raw Message
Post by Paul Gilmartin
Post by Jim Mulder
That is not the way the Initiator works. The Initiator is not
APF-authorized.
I'll assume Initiator uses an SVC or PC to launch the program with
suitable APF-authority (in a separate address space?) similar to what
fork() and BPX1EXM do. What component performs the allocations,
since those don't cross address spaces?
You assumed ... poorly.

The Iniatiator ATTACHes the program in the same address space.
The Initiator is not APF-authorized. It runs in supervisor state.
Post by Paul Gilmartin
Post by Jim Mulder
When you ATTACH an authorized program and pass it a parm that is longer
than 100 bytes, how do you prevent a buffer overflow security
exposure if the
Post by Jim Mulder
authorized program you are ATTACHing copies the parm to a 100 byte buffer
(which it assumes is a safe thing to do, because the system
documentation stated
Post by Jim Mulder
that the maximum PARM= length was 100 bytes)?
Moribund horse. The LONGPARM option was provided to control this.
But does ATTACH verify LONGPARM? If not, the calling program should.
I'll be the judge of which horses are moribund. LONGPARM
checking is done by the system when the Initiator requests it.

Uhhh, Clem's program is not the Initiator, and does not
do what the Initiator does to request LongParm checking, so no
LongParm checking is done for its ATTACHes.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY



----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Paul Gilmartin
2017-05-24 22:38:51 UTC
Permalink
Raw Message
Post by Jim Mulder
Uhhh, Clem's program is not the Initiator, and does not
do what the Initiator does to request LongParm checking, so no
LongParm checking is done for its ATTACHes.
Sounds like a bug. Or an integrity threat. If I had Clem's program
I'd report it.

Does the Initiator check LongParm for AC=0 programs? While they
can't threaten system integrity, PARMDD has exposed them to
new unpleasant failures. It would be easy enough to relink programs
with LongParm when appropriate.

-- gil

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Jim Mulder
2017-05-24 23:07:34 UTC
Permalink
Raw Message
As the documentation clearly states:

"The system checks for this attribute only when the program is being
invoked
with a parameter string of more than 100 bytes and the program is
APF authorized. In this case, if the LONGPARM attribute is not set on,
the system fails the invocation. "

What would you report, and to whom? If you were to install
Clem's program into an APF-authorized library on your system, you
could then report yourself to your own management for having
compromised the security on your system by installing freeware
without understanding that it allows any user to run a simple
unauthorized program which exploits his program to run any
program from an unauthorized library with APF-authorization.

Jim Mulder z/OS Diagnosis, Design, Development, Test IBM Corp.
Poughkeepsie NY
Post by Paul Gilmartin
Post by Jim Mulder
Uhhh, Clem's program is not the Initiator, and does not
do what the Initiator does to request LongParm checking, so no
LongParm checking is done for its ATTACHes.
Sounds like a bug. Or an integrity threat. If I had Clem's program
I'd report it.
Does the Initiator check LongParm for AC=0 programs? While they
can't threaten system integrity, PARMDD has exposed them to
new unpleasant failures. It would be easy enough to relink programs
with LongParm when appropriate.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Peter Relson
2017-05-25 14:44:42 UTC
Permalink
Raw Message
Post by Clem Clarke
perhaps attaching as a job step may be an answer?
No it is not.

The fact that the initiator uses RSAPF=YES simply correlates to the fact
that that option is intended for the initiator's use.

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
Walt Farrell
2017-05-25 15:43:25 UTC
Permalink
Raw Message
Post by John McKown
Post by John McKown
The above is why I really "push" the UNIX fork() alternative.
[snip]
Post by John McKown
If a "steplib" is needed, the initial child program can simply DYNALLOC
the DSNs and then use an ATTACHX with a TASKLIB.
Assuming there will be an exec() in the forked process, a steplib can be
setup simply by setting the STEPLIB environment variable, and passing that
to exec().
​That is true. As I read the doc on fork(), the parent's
TASKLIB/STEPLIB/JOBLIB is propagated to the child. As best as I can tell,
the OP's program is _not_ really designed as a UNIX program, per se. That
is, I am assuming that his programs (and specifically the non-APF program
to be invoked for some purpose) reside in a _library_ (PDS or PDSE) and not
a UNIX directory. So I was not envisioning him using a UNIX exec() function
to run the non-APF program in the child. I was thinking the "historic" use
of LINKX or maybe ATTACHX.​ The mention of a TASKLIB for a dynamically
allocated was just in the case that the OP's design called for the
specification of a user designed set of libraries as well as just a program
name.
execmvs() would be better than LINKX or ATTACHX for this scenario, in general, as it handles all the environmental cleanup and handles any necessary authorization issues.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-05-25 16:45:25 UTC
Permalink
Raw Message
Post by Greg Dyck
​<snip>
Post by John McKown
a UNIX directory. So I was not envisioning him using a UNIX exec()
function
Post by John McKown
to run the non-APF program in the child. I was thinking the "historic" use
of LINKX or maybe ATTACHX.​ The mention of a TASKLIB for a dynamically
allocated was just in the case that the OP's design called for the
specification of a user designed set of libraries as well as just a
program
Post by John McKown
name.
execmvs() would be better than LINKX or ATTACHX for this scenario, in
general, as it handles all the environmental cleanup and handles any
necessary authorization issues.
​I was looking at both execmvs() and attach_execmvs(). execmvs() says that
it "replaces the previous process image". IIRC, that means that the child
process no longer has access to the point-in-time-of-original-fork copy of
the parent's key 8 storage. So, no passing "read only" type data in memory.
Which is possibly a good thing. UNIX likes to pass data using something
like environment variables or "shared memory" (which is what I'd likely use
if the child needs to update the original program's memory).
attach_execmvs() starts a new process __in the same address space__ and so
has the "plus" of retaining all the parent's memory. That is, the new
process which runs the requested child program will still have the copy of
the original parent's​ (grandparent's) key 8 storage.
Post by Greg Dyck
--
Walt
--
Windows. A funny name for a operating system that doesn't let you see
anything.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2017-05-25 18:49:09 UTC
Permalink
Raw Message
Post by John McKown
Post by Walt Farrell
execmvs() would be better than LINKX or ATTACHX for this scenario, in
general, as it handles all the environmental cleanup and handles any
necessary authorization issues.
​I was looking at both execmvs() and attach_execmvs(). execmvs() says that
it "replaces the previous process image". IIRC, that means that the child
process no longer has access to the point-in-time-of-original-fork copy of
the parent's key 8 storage. So, no passing "read only" type data in memory.
Which is possibly a good thing. UNIX likes to pass data using something
like environment variables or "shared memory" (which is what I'd likely use
if the child needs to update the original program's memory).
attach_execmvs() starts a new process __in the same address space__ and so
has the "plus" of retaining all the parent's memory. That is, the new
process which runs the requested child program will still have the copy of
the original parent's​ (grandparent's) key 8 storage.
I don't know for sure, but I see issues with considering attach_execmvs() in this scenario. You can't end up with two processes in the same address space without dealing with authorization issues.

For example, how will attach_execmvs() deal with an APF-authorized parent process trying to attach a non-authorized child process? I think that's a guaranteed S306 abend (or some equivalent UNIX error code).

Therefor, I think the existing (parent) APF-authorized process would have to give up APF authorization before it could safely use attach_execmvs() in this scenario.

However, once it's done that, what happens if attach_execmvs() determines that the new process needs to run APF-authorized? It could not do that in the same address space as the (now) unauthorized parent. Therefore, another failure.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-05-25 19:23:26 UTC
Permalink
Raw Message
On Thu, 25 May 2017 11:46:20 -0500, John McKown <
Post by John McKown
Post by Walt Farrell
execmvs() would be better than LINKX or ATTACHX for this scenario, in
general, as it handles all the environmental cleanup and handles any
necessary authorization issues.
​I was looking at both execmvs() and attach_execmvs(). execmvs() says that
it "replaces the previous process image". IIRC, that means that the child
process no longer has access to the point-in-time-of-original-fork copy of
the parent's key 8 storage. So, no passing "read only" type data in
memory.
Post by John McKown
Which is possibly a good thing. UNIX likes to pass data using something
like environment variables or "shared memory" (which is what I'd likely
use
Post by John McKown
if the child needs to update the original program's memory).
attach_execmvs() starts a new process __in the same address space__ and so
has the "plus" of retaining all the parent's memory. That is, the new
process which runs the requested child program will still have the copy of
the original parent's​ (grandparent's) key 8 storage.
I don't know for sure, but I see issues with considering attach_execmvs()
in this scenario. You can't end up with two processes in the same address
space without dealing with authorization issues.
For example, how will attach_execmvs() deal with an APF-authorized parent
process trying to attach a non-authorized child process? I think that's a
guaranteed S306 abend (or some equivalent UNIX error code).
Therefor, I think the existing (parent) APF-authorized process would have
to give up APF authorization before it could safely use attach_execmvs() in
this scenario.
However, once it's done that, what happens if attach_execmvs() determines
that the new process needs to run APF-authorized? It could not do that in
the same address space as the (now) unauthorized parent. Therefore, another
failure.
​Well, from what I vaguely gather, this entire thread started off with the
question of "how does an APF authorized program run a non-APF authorized
program from a library not on the APF list?". Apparently the OP was trying
this and got a S306-C. Or maybe he just want something like the TSO TMP
does to "safely" (FSVO safely) invoke a program as a subroutine without APF
authorization.

My solution for the above was to architect do a fork() to create a new
,non-APF authorized, address space. The child would be running the same
program at the same point in the 2nd address space (and with a different
PID). And if I'm reading the documentation correctly, the new address space
is _NOT_ running APF authorized. So the program, in the child, would set
things up to invoke the desired program. That background is why I was
thinking LINK instead of execmvs()​. Also LINK does not replace the process
image, so the copy of parent's key 8 storage is still accessible. If the
child needs to update the parent's memory, then said memory needs to be set
up as "shared" in both processes (address spaces).
--
Walt
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
--
Windows. A funny name for a operating system that doesn't let you see
anything.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2017-05-25 21:51:08 UTC
Permalink
Raw Message
Post by John McKown
​Well, from what I vaguely gather, this entire thread started off with the
question of "how does an APF authorized program run a non-APF authorized
program from a library not on the APF list?". Apparently the OP was trying
this and got a S306-C. Or maybe he just want something like the TSO TMP
does to "safely" (FSVO safely) invoke a program as a subroutine without APF
authorization.
My solution for the above was to architect do a fork() to create a new
,non-APF authorized, address space. The child would be running the same
program at the same point in the 2nd address space (and with a different
PID). And if I'm reading the documentation correctly, the new address space
is _NOT_ running APF authorized. So the program, in the child, would set
things up to invoke the desired program. That background is why I was
thinking LINK instead of execmvs()​. Also LINK does not replace the process
image, so the copy of parent's key 8 storage is still accessible. If the
child needs to update the parent's memory, then said memory needs to be set
up as "shared" in both processes (address spaces).
If an APF-authorized task does a fork() then the child should also end up running APF-authorized. It is basically an exact copy of the parent except for the DD allocations (and loss of other TCBs). The exec() or execmvs() that one expects the child to do next is what will take care of removing APF-authorization during the cleanup prior to running the program that replaces the previous process.
--
Walt

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
John McKown
2017-05-26 00:32:26 UTC
Permalink
Raw Message
On Thu, 25 May 2017 14:24:05 -0500, John McKown <
Post by John McKown
​Well, from what I vaguely gather, this entire thread started off with the
question of "how does an APF authorized program run a non-APF authorized
program from a library not on the APF list?". Apparently the OP was trying
this and got a S306-C. Or maybe he just want something like the TSO TMP
does to "safely" (FSVO safely) invoke a program as a subroutine without
APF
Post by John McKown
authorization.
My solution for the above was to architect do a fork() to create a new
,non-APF authorized, address space. The child would be running the same
program at the same point in the 2nd address space (and with a different
PID). And if I'm reading the documentation correctly, the new address
space
Post by John McKown
is _NOT_ running APF authorized. So the program, in the child, would set
things up to invoke the desired program. That background is why I was
thinking LINK instead of execmvs()​. Also LINK does not replace the
process
Post by John McKown
image, so the copy of parent's key 8 storage is still accessible. If the
child needs to update the parent's memory, then said memory needs to be
set
Post by John McKown
up as "shared" in both processes (address spaces).
If an APF-authorized task does a fork() then the child should also end up
running APF-authorized. It is basically an exact copy of the parent except
for the DD allocations (and loss of other TCBs). The exec() or execmvs()
that one expects the child to do next is what will take care of removing
APF-authorization during the cleanup prior to running the program that
replaces the previous process.
​Thanks. I may put in an RFC on the BPX1FRK documentation to ask that it
explicitly state that the APF status is maintained. Granted, in the Usage
Notes, there is the sentence: "​In other respects, for z/OS UNIX the child
is identical to the parent." But it also states: "
The child address space inherits the following address space attributes of
the parent address space:

1. Region size
2. Time limi
​t​


​"​
​I really wish the list above had included: "3. APF authorization state."​
I just think that would make the documentation clearer. At least to me. Oh,
well, I really need to "play around" with this and maybe do some actual
testing.
--
Walt
--
Windows. A funny name for a operating system that doesn't let you see
anything.

Maranatha! <><
John McKown

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to ***@listserv.ua.edu with the message: INFO IBM-MAIN
Walt Farrell
2017-05-26 00:37:21 UTC
Permalink
Raw Message
Post by John McKown
​Thanks. I may put in an RFC on the BPX1FRK documentation to ask that it
explicitly state that the APF status is maintained. Granted, in the Usage
Notes, there is the sentence: "​In other respects, for z/OS UNIX the child
is identical to the parent." But it also states: "
The child address space inherits the following address space attributes of
1. Region size
2. Time limi​t​
​I really wish the list above had included: "3. APF authorization state."​
I just think that would make the documentation clearer. At least to me. Oh,
well, I really need to "play around" with this and maybe do some actual
testing.
To be pedantic, APF authorization is not an attribute of an address space, but of a jobstep. Therefore the documentation is correct, as far as address space attributes go. It does not directly discuss jobstep or task attributes, except as implied by "the child is identical to the parent".

Yes, it could be clearer :)
--
Walt

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