Re: Is it possible to update CSA from an unauthorized user-key program?

[Wendell Lovewell]

Thank you Jeffrey for the XCFNOTE idea, Bob for mentioning IARVSERV, and 
whoever mentioned Data tables.  

I haven't quite comprehended it, but IARVSERV seems particularly interesting. 
But if I'm catching on at all, it seems the storage shared would be private 
storage?  So the original issuer of IARVSERV SHARE would need to be a region 
that is continually running, like an STC? 

Wendell

Re: Is it possible to update CSA from an unauthorized user-key program?

[Massimo Biancucci]

Bob,

it looks really interesting.
Thanks for sharing.

Max


Mail
priva di virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Il giorno gio 9 dic 2021 alle ore 18:33 Bob Raicer  ha
scritto:

> Using XCF Note Pad might very well be a good choice.  I *think* the
> service was introduced in z/OS 1.13, and enhanced in z/OS 2.2
>
> Here are some links to a SHARE presentation from 2013 which
> describes the facility a bit and offers an example of how SAP has
> exploited it.
>
>
> https://share.confex.com/share/120/webprogram/Handout/Session13083/XCF%20Note%20Pad%20Slides%202013%20Feb.pdf
>
> https://share.confex.com/share/120/webprogram/Handout/Session13083/XCF%20Note%20Pad%20Handout%20%202013%20Feb.pdf
>
> The facility is described in the following IBM pubs for z/OS 2.2
>
> SA23-1399-03 z/OS MVS Setting Up a Sysplex
> Chapter 6. Planning XCF Note Pad Services in a sysplex
>
> SA38-0658-02 z/OS MVS Programming:  Sysplex Services Reference
> Chapter 17. IXCNOTE — XCF Note Pad Interface
>
> SA23-1400-03 z/OS MVS Programming:  Sysplex Services Guide
> Chapter 12. Using Note Pad Services (IXCNOTE)
>
>
> I was in the process of composing a note about using the IARVSERV facility
> which permits shared access to Private Area and Data Space storage among
> cooperating address spaces, and which does not require elevated privileges
> (for example: Supervisor State; System Key; APF Authorization) for its use.
> One of the issues with IARVSERV is that the default amount of storage that
> can be shared is rather small (sixteen 4K pages); system exit IEFUSI can be
> used to increase this amount up to 2**31.  And, of course, the storage is
> shared on a given z/OS system -- it is not cross system.
>
> Bob
>

Re: Is it possible to update CSA from an unauthorized user-key program?

[Bob Raicer]

Using XCF Note Pad might very well be a good choice.  I *think* the
service was introduced in z/OS 1.13, and enhanced in z/OS 2.2

Here are some links to a SHARE presentation from 2013 which
describes the facility a bit and offers an example of how SAP has
exploited it.

https://share.confex.com/share/120/webprogram/Handout/Session13083/XCF%20Note%20Pad%20Slides%202013%20Feb.pdf
https://share.confex.com/share/120/webprogram/Handout/Session13083/XCF%20Note%20Pad%20Handout%20%202013%20Feb.pdf

The facility is described in the following IBM pubs for z/OS 2.2

SA23-1399-03 z/OS MVS Setting Up a Sysplex
Chapter 6. Planning XCF Note Pad Services in a sysplex

SA38-0658-02 z/OS MVS Programming:  Sysplex Services Reference
Chapter 17. IXCNOTE — XCF Note Pad Interface

SA23-1400-03 z/OS MVS Programming:  Sysplex Services Guide
Chapter 12. Using Note Pad Services (IXCNOTE)


I was in the process of composing a note about using the IARVSERV facility
which permits shared access to Private Area and Data Space storage among
cooperating address spaces, and which does not require elevated privileges
(for example: Supervisor State; System Key; APF Authorization) for its use.
One of the issues with IARVSERV is that the default amount of storage that
can be shared is rather small (sixteen 4K pages); system exit IEFUSI can be
used to increase this amount up to 2**31.  And, of course, the storage is
shared on a given z/OS system -- it is not cross system.

Bob

Re: Is it possible to update CSA from an unauthorized user-key program?

[Peter Relson]

Jeffrey Celander wrote:

Coupling Facility XCFNOTE services is a callable service can be used to 
create/read/modify data across applications or the entire Sysplex. Access 
to the data notes can be controlled and locked down by your SAF. The 
services can be called in problem state without the need to create special 
authorized services and managing CSA block anchors.


This is true. But don't make light of the SAF requirement. A problem state 
user does need to be authorized to a FACILITY class resource for the 
notepad.
It is up to the customer to control whether such access is appropriate.

Peter Relson
z/OS Core Technology Design

Re: Is it possible to update CSA from an unauthorized user-key program?

[Jeffrey Celander]

Coupling Facility XCFNOTE services is a callable service can be used to 
create/read/modify data across applications or the entire Sysplex. Access to 
the data notes can be controlled and locked down by your SAF. The services can 
be called in problem state without the need to create special authorized 
services and managing CSA block anchors.

Re: Is it possible to update CSA from an unauthorized user-key program?

[Schmitt, Michael]

If it is an IBM RFE, how about enhancing Window Services so that a temporary 
object could be accessed cross-address space? Then you get all of the other 
goodness of Window Services.

(I say that never having actually used Windows Services, but I assume it has 
goodness since there’s a lot of documentation in the manual.)


From: IBM Mainframe Assembler List  on behalf 
of Farley, Peter x23353 <0dc9d8785c29-dmarc-requ...@listserv.uga.edu>
Date: Tuesday, December 7, 2021 at 5:38 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU 
Subject: Re: Is it possible to update CSA from an unauthorized user-key program?
Re-sent considerably trimmed due to IBM-MAIN restriction of 250 lines per reply.

-Original Message-
From: Farley, Peter x23353
Sent: Tuesday, December 7, 2021 6:36 PM
To: IBM Mainframe Assembler List 
Subject: RE: Is it possible to update CSA from an unauthorized user-key program?

Responses inline below.

Peter

-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of Seymour J Metz
Sent: Tuesday, December 7, 2021 6:09 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Is it possible to update CSA from an unauthorized user-key program?

A few points:

 1. As Peter Relson has noted, the shared storage should not be in CSA/ECSA.

Somewhat agreed.  I was thinking more along the lines of 64-bit user storage 
for the bulk of the data, accessed via the defined interface.  Slightly longer 
path length than direct memory access, but better RAS and security.
(Does C library shmem() supply any RAS or security?)

 2. If, e.g., an ISV, does it on their own, the code is likely to be tied to 
their own needs.

Very likely, but it is at least possible for something more general to come out 
of such an ISV effort, FSVO possible.

 3. The best option if there is a business is for IBM to do it.

Agreed, but then again they might over-complicate it just because that's what 
they often do.  Making a business case is difficult at best, and may be 
impossible given IBM's diminished knowledgeable technical head count in recent 
years (not counting the PFCSK's).

 4. If an RFE would take too long, then ther best option is an open source 
project.

Agreed, assuming an RFE wasn't rejected out of hand for no or insufficient 
business case.

 5. Is corporate sponsorship for such a project likely?

Is it needed?

--

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

Re: Is it possible to update CSA from an unauthorized user-key program?

[Farley, Peter x23353]

Re-sent considerably trimmed due to IBM-MAIN restriction of 250 lines per reply.

-Original Message-
From: Farley, Peter x23353 
Sent: Tuesday, December 7, 2021 6:36 PM
To: IBM Mainframe Assembler List 
Subject: RE: Is it possible to update CSA from an unauthorized user-key program?

Responses inline below.

Peter

-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of Seymour J Metz
Sent: Tuesday, December 7, 2021 6:09 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Is it possible to update CSA from an unauthorized user-key program?

A few points:

 1. As Peter Relson has noted, the shared storage should not be in CSA/ECSA.

Somewhat agreed.  I was thinking more along the lines of 64-bit user storage 
for the bulk of the data, accessed via the defined interface.  Slightly longer 
path length than direct memory access, but better RAS and security.
(Does C library shmem() supply any RAS or security?)

 2. If, e.g., an ISV, does it on their own, the code is likely to be tied to 
their own needs.

Very likely, but it is at least possible for something more general to come out 
of such an ISV effort, FSVO possible.

 3. The best option if there is a business is for IBM to do it.

Agreed, but then again they might over-complicate it just because that's what 
they often do.  Making a business case is difficult at best, and may be 
impossible given IBM's diminished knowledgeable technical head count in recent 
years (not counting the PFCSK's).

 4. If an RFE would take too long, then ther best option is an open source 
project.

Agreed, assuming an RFE wasn't rejected out of hand for no or insufficient 
business case.

 5. Is corporate sponsorship for such a project likely?

Is it needed?

--

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

Re: Is it possible to update CSA from an unauthorized user-key program?

[Seymour J Metz]

Macros, PCs and SVCs to acquire and release access, but there should be no such 
overhead in between; a pointer should suffice, unless you need fancy 
serialization.


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


From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf 
of Charles Mills [charl...@mcn.org]
Sent: Tuesday, December 7, 2021 2:32 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Is it possible to update CSA from an unauthorized user-key program?

I have been composing a post on this topic.

It would seem to be a reasonable ISV (or CBT, from some kind-hearted soul) task 
to provide an STC that would allocate a chunk of memory -- no need for it to 
actually be CSA; could be private to the STC -- and allow PC-based access to it 
(with a nice macro to front-end the PC) and validation based on a RACF class. 
READ access would let you read some named subset of the storage; ALTER access 
would let you allocate and write it (or some such scheme -- this is based on 5 
minutes of design work). Would performance be a problem with the RACF calls? 
Possibly -- an application would want to "cache" and "bunch up" its accesses.

One advantage of a CBT solution is that it would be "open source" and anyone 
could verify the security of its approach.

Of course, even better, IBM could write this into the OS. 

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Gary Weinhold
Sent: Tuesday, December 7, 2021 9:58 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Is it possible to update CSA from an unauthorized user-key program?

That's a legitimate complaint.

We are an ISV and actually have a product that would meet his
requirements; the problem is that it does quite a bit more, so it's
probably not cost-effective for the OPs purposes.

And considering the cost in time, money, software and hardware of
meeting the security requirements of some commercial mainframe
environments, I suspect most ISVs would not see a sufficient market to
provide a narrower solution at an acceptable cost to potential customers.

On 2021-12-07 12:20 a.m., Farley, Peter x23353 wrote:
> 
> I don't know about anyone else, but I am really getting tired of these 
> continuous calls from supposedly knowledgeable people to "invent your own PC 
> or SVC to protect your global shared storage application solution and don’t 
> trust anyone or anything and if you do this your integrity is your own 
> problem not ours".
>
> Why hasn't IBM or even some clever ISV supplied a pre-packaged, 
> integral-part-of-the-operating-system solution to safely share and update 
> global storage any way an application designer can imagine and easily usable 
> from normal HLL application programs?  Protected by standardized SAF security 
> calls and all that is needed for real integrity.  Why do we have to "roll our 
> own" and "own the loss of integrity if you screw it up"?  Why can't those who 
> know more than we do provide the solution?

Re: Is it possible to update CSA from an unauthorized user-key program?

[Seymour J Metz]

A few points:

 1. As Peter Relson has noted, the shared storage should not be in CSA/ECSA.
f
 2. If, e.g., an ISV, does it on their own, the code is likely to be tied to 
their own needs.

 3. The best option if there is a business is for IBM to do it.

 4. If an RFE would take too long, then ther best option is an open source 
project.

 5. Is corporate sponsorship for such a project likely?


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


From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf 
of Farley, Peter x23353 [0dc9d8785c29-dmarc-requ...@listserv.uga.edu]
Sent: Tuesday, December 7, 2021 3:00 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Is it possible to update CSA from an unauthorized user-key program?

Charles,

That is exactly the sort of thing I was imagining/hoping for.  And putting it 
on CBT for all to use would be a great solution.  But not just "a nice macro to 
front-end the PC" -- an LE-enabled prewritten subroutine which uses the "nice 
macro" that any HLL can call without substantial effort, or any shop can update 
to meet its particular needs.

My rant was based in part on the lack of any substantial practical example of 
STC + PC interface code from any available source.  Similarly for a PC that 
schedules an SRB in a client address space and other complex solutions to 
application needs.  Many knowledgeable posters here and on IBM-MAIN have talked 
about the details of doing such things but no one has ever provided a complete 
example that works out of the box (after appropriate SAF authorizations are 
done of course).

Coding such beasts with really good RAS and security is not for the 
faint-hearted, I do realize that it is a substantial and non-trivial effort.

But the benefit would be wide and long-lasting.

Why not instead of just CBT (or in addition to) a git / github open-source 
community effort, perhaps using the auspices of the open mainframe project?  
Share the effort, share the results.

Peter

-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of Charles Mills
Sent: Tuesday, December 7, 2021 2:32 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Is it possible to update CSA from an unauthorized user-key program?

I have been composing a post on this topic.

It would seem to be a reasonable ISV (or CBT, from some kind-hearted soul) task 
to provide an STC that would allocate a chunk of memory -- no need for it to 
actually be CSA; could be private to the STC -- and allow PC-based access to it 
(with a nice macro to front-end the PC) and validation based on a RACF class. 
READ access would let you read some named subset of the storage; ALTER access 
would let you allocate and write it (or some such scheme -- this is based on 5 
minutes of design work). Would performance be a problem with the RACF calls? 
Possibly -- an application would want to "cache" and "bunch up" its accesses.

One advantage of a CBT solution is that it would be "open source" and anyone 
could verify the security of its approach.

Of course, even better, IBM could write this into the OS. 

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Gary Weinhold
Sent: Tuesday, December 7, 2021 9:58 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Is it possible to update CSA from an unauthorized user-key program?

That's a legitimate complaint.

We are an ISV and actually have a product that would meet his requirements; the 
problem is that it does quite a bit more, so it's probably not cost-effective 
for the OPs purposes.

And considering the cost in time, money, software and hardware of meeting the 
security requirements of some commercial mainframe environments, I suspect most 
ISVs would not see a sufficient market to provide a narrower solution at an 
acceptable cost to potential customers.

On 2021-12-07 12:20 a.m., Farley, Peter x23353 wrote:
> 
> I don't know about anyone else, but I am really getting tired of these 
> continuous calls from supposedly knowledgeable people to "invent your own PC 
> or SVC to protect your global shared storage application solution and don’t 
> trust anyone or anything and if you do this your integrity is your own 
> problem not ours".
>
> Why hasn't IBM or even some clever ISV supplied a pre-packaged, 
> integral-part-of-the-operating-system solution to safely share and update 
> global storage any way an application designer can imagine and easily usable 
> from normal HLL application programs?  Protected by standardized SAF security 
> calls and all that is needed for real integrity.  Why do we have to "roll our 
> own" and "own the loss of integrity if you screw it up"?  Why can't those who 
> know more than we do provide

Re: Is it possible to update CSA from an unauthorized user-key program?

[Charles Mills]

> github

Good point. I agree.

> LE HLL support

Good point. I agree.

> not for the feint-hearted

I don't see it as real tricky, but perhaps that is just fools rush in ...

The concurrent access part is a little tricky. The security seems easy to me. 
You follow all the "copy over the data using the user's key" protocols and then 
you do a RACF check for the legality of the access. You would have to get it 
right, but pretty much all programming, you kind of have to get it right. 

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Farley, Peter x23353
Sent: Tuesday, December 7, 2021 12:01 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Is it possible to update CSA from an unauthorized user-key program?

Charles,

That is exactly the sort of thing I was imagining/hoping for.  And putting it 
on CBT for all to use would be a great solution.  But not just "a nice macro to 
front-end the PC" -- an LE-enabled prewritten subroutine which uses the "nice 
macro" that any HLL can call without substantial effort, or any shop can update 
to meet its particular needs.

My rant was based in part on the lack of any substantial practical example of 
STC + PC interface code from any available source.  Similarly for a PC that 
schedules an SRB in a client address space and other complex solutions to 
application needs.  Many knowledgeable posters here and on IBM-MAIN have talked 
about the details of doing such things but no one has ever provided a complete 
example that works out of the box (after appropriate SAF authorizations are 
done of course).

Coding such beasts with really good RAS and security is not for the 
faint-hearted, I do realize that it is a substantial and non-trivial effort.

But the benefit would be wide and long-lasting.

Why not instead of just CBT (or in addition to) a git / github open-source 
community effort, perhaps using the auspices of the open mainframe project?  
Share the effort, share the results.

Re: Is it possible to update CSA from an unauthorized user-key program?

[Farley, Peter x23353]

Charles,

That is exactly the sort of thing I was imagining/hoping for.  And putting it 
on CBT for all to use would be a great solution.  But not just "a nice macro to 
front-end the PC" -- an LE-enabled prewritten subroutine which uses the "nice 
macro" that any HLL can call without substantial effort, or any shop can update 
to meet its particular needs.

My rant was based in part on the lack of any substantial practical example of 
STC + PC interface code from any available source.  Similarly for a PC that 
schedules an SRB in a client address space and other complex solutions to 
application needs.  Many knowledgeable posters here and on IBM-MAIN have talked 
about the details of doing such things but no one has ever provided a complete 
example that works out of the box (after appropriate SAF authorizations are 
done of course).

Coding such beasts with really good RAS and security is not for the 
faint-hearted, I do realize that it is a substantial and non-trivial effort.

But the benefit would be wide and long-lasting.

Why not instead of just CBT (or in addition to) a git / github open-source 
community effort, perhaps using the auspices of the open mainframe project?  
Share the effort, share the results.

Peter

-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of Charles Mills
Sent: Tuesday, December 7, 2021 2:32 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Is it possible to update CSA from an unauthorized user-key program?

I have been composing a post on this topic.

It would seem to be a reasonable ISV (or CBT, from some kind-hearted soul) task 
to provide an STC that would allocate a chunk of memory -- no need for it to 
actually be CSA; could be private to the STC -- and allow PC-based access to it 
(with a nice macro to front-end the PC) and validation based on a RACF class. 
READ access would let you read some named subset of the storage; ALTER access 
would let you allocate and write it (or some such scheme -- this is based on 5 
minutes of design work). Would performance be a problem with the RACF calls? 
Possibly -- an application would want to "cache" and "bunch up" its accesses. 

One advantage of a CBT solution is that it would be "open source" and anyone 
could verify the security of its approach.

Of course, even better, IBM could write this into the OS. 

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Gary Weinhold
Sent: Tuesday, December 7, 2021 9:58 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Is it possible to update CSA from an unauthorized user-key program?

That's a legitimate complaint.

We are an ISV and actually have a product that would meet his requirements; the 
problem is that it does quite a bit more, so it's probably not cost-effective 
for the OPs purposes.

And considering the cost in time, money, software and hardware of meeting the 
security requirements of some commercial mainframe environments, I suspect most 
ISVs would not see a sufficient market to provide a narrower solution at an 
acceptable cost to potential customers.

On 2021-12-07 12:20 a.m., Farley, Peter x23353 wrote:
> 
> I don't know about anyone else, but I am really getting tired of these 
> continuous calls from supposedly knowledgeable people to "invent your own PC 
> or SVC to protect your global shared storage application solution and don’t 
> trust anyone or anything and if you do this your integrity is your own 
> problem not ours".
>
> Why hasn't IBM or even some clever ISV supplied a pre-packaged, 
> integral-part-of-the-operating-system solution to safely share and update 
> global storage any way an application designer can imagine and easily usable 
> from normal HLL application programs?  Protected by standardized SAF security 
> calls and all that is needed for real integrity.  Why do we have to "roll our 
> own" and "own the loss of integrity if you screw it up"?  Why can't those who 
> know more than we do provide the solution?

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

Re: Is it possible to update CSA from an unauthorized user-key program?

[Charles Mills]

> the problem is that it does quite a bit more, so it's probably not 
> cost-effective

Consider stripping out and productizing just this functionality. Elon Musk had 
a company named X.com that was trying to develop software that would let you 
transfer any asset to anyone else electronically. They struggled mightily; it's 
a tough problem. Then they stripped out just the "transfer money" part, renamed 
the company PayPal, and the rest is history.

Seriously, I know at least one other similar ISV success story like this.

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Gary Weinhold
Sent: Tuesday, December 7, 2021 9:58 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Is it possible to update CSA from an unauthorized user-key program?

That's a legitimate complaint.

We are an ISV and actually have a product that would meet his 
requirements; the problem is that it does quite a bit more, so it's 
probably not cost-effective for the OPs purposes.

Re: Is it possible to update CSA from an unauthorized user-key program?

[Charles Mills]

I have been composing a post on this topic.

It would seem to be a reasonable ISV (or CBT, from some kind-hearted soul) task 
to provide an STC that would allocate a chunk of memory -- no need for it to 
actually be CSA; could be private to the STC -- and allow PC-based access to it 
(with a nice macro to front-end the PC) and validation based on a RACF class. 
READ access would let you read some named subset of the storage; ALTER access 
would let you allocate and write it (or some such scheme -- this is based on 5 
minutes of design work). Would performance be a problem with the RACF calls? 
Possibly -- an application would want to "cache" and "bunch up" its accesses. 

One advantage of a CBT solution is that it would be "open source" and anyone 
could verify the security of its approach.

Of course, even better, IBM could write this into the OS. 

Charles


-Original Message-
From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On 
Behalf Of Gary Weinhold
Sent: Tuesday, December 7, 2021 9:58 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Is it possible to update CSA from an unauthorized user-key program?

That's a legitimate complaint.

We are an ISV and actually have a product that would meet his 
requirements; the problem is that it does quite a bit more, so it's 
probably not cost-effective for the OPs purposes.

And considering the cost in time, money, software and hardware of 
meeting the security requirements of some commercial mainframe 
environments, I suspect most ISVs would not see a sufficient market to 
provide a narrower solution at an acceptable cost to potential customers.

On 2021-12-07 12:20 a.m., Farley, Peter x23353 wrote:
> 
> I don't know about anyone else, but I am really getting tired of these 
> continuous calls from supposedly knowledgeable people to "invent your own PC 
> or SVC to protect your global shared storage application solution and don’t 
> trust anyone or anything and if you do this your integrity is your own 
> problem not ours".
>
> Why hasn't IBM or even some clever ISV supplied a pre-packaged, 
> integral-part-of-the-operating-system solution to safely share and update 
> global storage any way an application designer can imagine and easily usable 
> from normal HLL application programs?  Protected by standardized SAF security 
> calls and all that is needed for real integrity.  Why do we have to "roll our 
> own" and "own the loss of integrity if you screw it up"?  Why can't those who 
> know more than we do provide the solution?

Re: Is it possible to update CSA from an unauthorized user-key program?

[Gary Weinhold]

That's a legitimate complaint.

We are an ISV and actually have a product that would meet his
requirements; the problem is that it does quite a bit more, so it's
probably not cost-effective for the OPs purposes.

And considering the cost in time, money, software and hardware of
meeting the security requirements of some commercial mainframe
environments, I suspect most ISVs would not see a sufficient market to
provide a narrower solution at an acceptable cost to potential customers.

On 2021-12-07 12:20 a.m., Farley, Peter x23353 wrote:


I don't know about anyone else, but I am really getting tired of these continuous calls 
from supposedly knowledgeable people to "invent your own PC or SVC to protect your 
global shared storage application solution and don’t trust anyone or anything and if you 
do this your integrity is your own problem not ours".

Why hasn't IBM or even some clever ISV supplied a pre-packaged, 
integral-part-of-the-operating-system solution to safely share and update global storage any way an 
application designer can imagine and easily usable from normal HLL application programs?  Protected 
by standardized SAF security calls and all that is needed for real integrity.  Why do we have to 
"roll our own" and "own the loss of integrity if you screw it up"?  Why can't 
those who know more than we do provide the solution?

This isn't rocket science, it's just programming, and IBM + ISV's have more 
programmers more intimately familiar with how to safely secure memory sharing 
than anyone else, so why aren't they doing it instead of foisting it onto us?

DB2 does it for disk-resident data, why can't something like that (maybe not 
QUITE so complicated or difficult as DB2 though, and definitely NOT via SQL) be 
provided for global memory?  There are exabytes to be exploited!!  Help us use 
them!!


Peter



Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone:+1.613.523.5500 x216
Email: weinh...@dkl.com
Visit us online at www.DKL.com
E-mail Notification: The information contained in this email and any 
attachments is confidential and may be subject to copyright or other 
intellectual property protection. If you are not the intended recipient, you 
are not authorized to use or disclose this information, and we request that you 
notify us by reply mail or telephone and delete the original message from your 
mail system.


-Original Message-

From: IBM Mainframe Assembler List  On Behalf 
Of Gary Weinhold
Sent: Monday, December 6, 2021 9:27 PM
To:ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Is it possible to update CSA from an unauthorized user-key program?

Assuming you could accomplish your objective, which appears to be
user-key (8 or 9) storage updatable by any process running on the lpar,
it would appear that not only is the information stored there not
confidential, but its integrity is not important.  You have no
protection from any user-key program overlaying the storage with any
value it wishes, whether purposely or accidentally.  Even if you have a
plan to restrict access to obtaining the address of this shared storage,
accidental overlays could still occur, like buffer overruns.

a) In general, key 0 memory that is not fetch protected can be read by
any key 8 user
b) By definition, key 8 users cannot update key 0 memory.
c) Considering the restrictions, any value of key 0 to key 7 works for
the macro
d) That would break integrity rules.

One method for updating the storage is to encapsulate the update routine
in a PC or SVC, which includes a security check for whether the  caller
is authorized to update the value and determines the location of the
memory itself (not trusting the caller to supply it).



On 2021-12-06 7:13 p.m., Wendell Lovewell wrote:

Hello Listers,

I'd like to be able to update a common storage area across all CICS and batch 
regions.  I've looked at IARV64 REQUEST=GETCOMMON, but it seems that it 
requires supervisor state and/or key 0-7.

It seems that something like issuing a STORAGE macro similar to:

STORAGE OBTAIN LENGTH=32768,SP=241,KEY=x,LOC=31,OWNER=SYSTEM

...from an authorized program would allocate the storage needed.   But I don't know the 
rules for accessing it from "user-mode" (unauthorized, key 8) programs like a 
CICS application.

a) Given the address of the storage obtained like that, can any user-mode 
program read that storage?
b) Could a user-mode program update that storage?
c) Should the KEY parameter be specified, and if so, what value should I use.  
Afaik it has to be 0-7 since User-key CSA was outlawed.
d) Am I correct that there isn't an IRAV64 option that will allow a user-mode 
program to update the storage?

Thanks for your help!

Wendell

(Cross-posted to the CICS list.)

--

This message and any attachments are intended only for the use of the addressee 
and may conta

Re: Is it possible to update CSA from an unauthorized user-key program?

[Wendell Lovewell]

Thanks for all of the information (and ranting!)  

Peter's explanation was what I suspected.   I mostly wondered if I was missing 
something.  

I appreciate the willingness of people on this list to share their expertise. 
 
Wendell

Re: Is it possible to update CSA from an unauthorized user-key program?

[Seymour J Metz]

I believe that the OP is describing an assumed implementation rather than the 
actual requirement, and that what he actually needs is storage that can be 
safely stored among a limited set of unauthorized address spaces. That's 
something that could easily be built on top of existing facilities, but it 
would take some work to get the RAS and security right. I've suggested that the 
OP submit an RFE, although IMHO something like that should have been  part of 
MVS/SP V3.


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


From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf 
of Peter Relson [rel...@us.ibm.com]
Sent: Tuesday, December 7, 2021 8:39 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Is it possible to update CSA from an unauthorized user-key program?

It is possibly to update only if the CSA is in user-key.

And having user-key CSA is a bad idea. That is why it had been soundly
discouraged for well over a decade, capability to create it had been made
not the default, and indeed the capability to create it was withdrawn,
although subsequently the RUCSA feature was added -- although doing that
adding had little if anything to do with user-key CSA being anything other
than a bad idea.

It has never been possible for an unauthorized program to acquire common
storage.

Peter Relson
z/OS Core Technology Design

Re: Is it possible to update CSA from an unauthorized user-key program?

[Peter Relson]

It is possibly to update only if the CSA is in user-key.

And having user-key CSA is a bad idea. That is why it had been soundly 
discouraged for well over a decade, capability to create it had been made 
not the default, and indeed the capability to create it was withdrawn, 
although subsequently the RUCSA feature was added -- although doing that 
adding had little if anything to do with user-key CSA being anything other 
than a bad idea.

It has never been possible for an unauthorized program to acquire common 
storage. 

Peter Relson
z/OS Core Technology Design

Re: Is it possible to update CSA from an unauthorized user-key program?

[Seymour J Metz]

Sharing key 8/9 storage in [E]CSA presents a security risk. The only secure way 
to share memory is with shared private memory. 

There are several issues that appear to be relevant for shared private storage, 
any one of which is simple to deal with. A solution that deals adequately with 
all of the issues concurrently would take much more work, ugh IMHO it would be 
worth it. If your installation needs it, I suggest building a business case and 
submitting an RFE.


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


From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf 
of Wendell Lovewell [09624390d784-dmarc-requ...@listserv.uga.edu]
Sent: Monday, December 6, 2021 7:13 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Is it possible to update CSA from an unauthorized user-key program?

Hello Listers,

I'd like to be able to update a common storage area across all CICS and batch 
regions.  I've looked at IARV64 REQUEST=GETCOMMON, but it seems that it 
requires supervisor state and/or key 0-7.

It seems that something like issuing a STORAGE macro similar to:

STORAGE OBTAIN LENGTH=32768,SP=241,KEY=x,LOC=31,OWNER=SYSTEM

...from an authorized program would allocate the storage needed.   But I don't 
know the rules for accessing it from "user-mode" (unauthorized, key 8) programs 
like a CICS application.

a) Given the address of the storage obtained like that, can any user-mode 
program read that storage?
b) Could a user-mode program update that storage?
c) Should the KEY parameter be specified, and if so, what value should I use.  
Afaik it has to be 0-7 since User-key CSA was outlawed.
d) Am I correct that there isn't an IRAV64 option that will allow a user-mode 
program to update the storage?

Thanks for your help!

Wendell

(Cross-posted to the CICS list.)

Re: Is it possible to update CSA from an unauthorized user-key program?

[Seymour J Metz]

It is a piece of cake to share the memory safely. The problem is not satisfying 
the security requirement; the problem is satisfying all of the requirements 
concurrently.


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


From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf 
of Gary Weinhold [weinh...@dkl.com]
Sent: Monday, December 6, 2021 9:26 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Is it possible to update CSA from an unauthorized user-key program?

Assuming you could accomplish your objective, which appears to be
user-key (8 or 9) storage updatable by any process running on the lpar,
it would appear that not only is the information stored there not
confidential, but its integrity is not important.  You have no
protection from any user-key program overlaying the storage with any
value it wishes, whether purposely or accidentally.  Even if you have a
plan to restrict access to obtaining the address of this shared storage,
accidental overlays could still occur, like buffer overruns.

a) In general, key 0 memory that is not fetch protected can be read by
any key 8 user
b) By definition, key 8 users cannot update key 0 memory.
c) Considering the restrictions, any value of key 0 to key 7 works for
the macro
d) That would break integrity rules.

One method for updating the storage is to encapsulate the update routine
in a PC or SVC, which includes a security check for whether the  caller
is authorized to update the value and determines the location of the
memory itself (not trusting the caller to supply it).



On 2021-12-06 7:13 p.m., Wendell Lovewell wrote:
> Hello Listers,
>
> I'd like to be able to update a common storage area across all CICS and batch 
> regions.  I've looked at IARV64 REQUEST=GETCOMMON, but it seems that it 
> requires supervisor state and/or key 0-7.
>
> It seems that something like issuing a STORAGE macro similar to:
>
> STORAGE OBTAIN LENGTH=32768,SP=241,KEY=x,LOC=31,OWNER=SYSTEM
>
> ...from an authorized program would allocate the storage needed.   But I 
> don't know the rules for accessing it from "user-mode" (unauthorized, key 8) 
> programs like a CICS application.
>
> a) Given the address of the storage obtained like that, can any user-mode 
> program read that storage?
> b) Could a user-mode program update that storage?
> c) Should the KEY parameter be specified, and if so, what value should I use. 
>  Afaik it has to be 0-7 since User-key CSA was outlawed.
> d) Am I correct that there isn't an IRAV64 option that will allow a user-mode 
> program to update the storage?
>
> Thanks for your help!
>
> Wendell
>
> (Cross-posted to the CICS list.)


Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone:+1.613.523.5500 x216
Email: weinh...@dkl.com
Visit us online at 
http://secure-web.cisco.com/1jTNrWh2-L-DdVmcDpFpeI7wgdzzdd1h1U1ulJ9pNAp-zUwZASDZTxDsYbiROBt1jvn-INbH9EtdCHuYfbssdCQYt4UgfkSGgQDCioCqJQnMZ3iJK4RuTJmn_e2s3mFYEoMUE6kfqIEiqGncABYs_Z07IYSVp1yVqFfwp-0S7bWIYMYP5f1EJWsT7CoWRYZFNTOCecvKDO21lwQRutvCZkvWQatToCQr8V9pKcDCT8lFJhe8BmI4Jw0h1iAMgVEfYknzmLe2g8rMd3ruI02_DfurRBE2ugtypVOmY4MMGXU5G9b9DxKrAGld5qCaTGXakNdVksFMdzRwbqWfpYQOPqszobbvR1E0N72ccIXHFgnRuBXb9bFI6sUAjM83ZbkEkWTeIMK5jclmDlxg8TYGyuTlB2dv39ozgaJzcJ7i7FPx3_jwGqkWaan7tlU_EGC8s/http%3A%2F%2Fwww.DKL.com
E-mail Notification: The information contained in this email and any 
attachments is confidential and may be subject to copyright or other 
intellectual property protection. If you are not the intended recipient, you 
are not authorized to use or disclose this information, and we request that you 
notify us by reply mail or telephone and delete the original message from your 
mail system.

Re: Is it possible to update CSA from an unauthorized user-key program?

[Seymour J Metz]

Why hasn't somebody submitted an RFE? No, it's not rocket science, but it would 
still take a lot of effort to cross all the Ts and dot all the Is.

While I personally think that such a facility should have been there since 
MVS/SP V3, IBM is a business and has to see a probable ROI before they will do 
it.


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


From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf 
of Farley, Peter x23353 [0dc9d8785c29-dmarc-requ...@listserv.uga.edu]
Sent: Tuesday, December 7, 2021 12:20 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Is it possible to update CSA from an unauthorized user-key program?


I don't know about anyone else, but I am really getting tired of these 
continuous calls from supposedly knowledgeable people to "invent your own PC or 
SVC to protect your global shared storage application solution and don’t trust 
anyone or anything and if you do this your integrity is your own problem not 
ours".

Why hasn't IBM or even some clever ISV supplied a pre-packaged, 
integral-part-of-the-operating-system solution to safely share and update 
global storage any way an application designer can imagine and easily usable 
from normal HLL application programs?  Protected by standardized SAF security 
calls and all that is needed for real integrity.  Why do we have to "roll our 
own" and "own the loss of integrity if you screw it up"?  Why can't those who 
know more than we do provide the solution?

This isn't rocket science, it's just programming, and IBM + ISV's have more 
programmers more intimately familiar with how to safely secure memory sharing 
than anyone else, so why aren't they doing it instead of foisting it onto us?

DB2 does it for disk-resident data, why can't something like that (maybe not 
QUITE so complicated or difficult as DB2 though, and definitely NOT via SQL) be 
provided for global memory?  There are exabytes to be exploited!!  Help us use 
them!!


Peter

-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of Gary Weinhold
Sent: Monday, December 6, 2021 9:27 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Is it possible to update CSA from an unauthorized user-key program?

Assuming you could accomplish your objective, which appears to be
user-key (8 or 9) storage updatable by any process running on the lpar,
it would appear that not only is the information stored there not
confidential, but its integrity is not important.  You have no
protection from any user-key program overlaying the storage with any
value it wishes, whether purposely or accidentally.  Even if you have a
plan to restrict access to obtaining the address of this shared storage,
accidental overlays could still occur, like buffer overruns.

a) In general, key 0 memory that is not fetch protected can be read by
any key 8 user
b) By definition, key 8 users cannot update key 0 memory.
c) Considering the restrictions, any value of key 0 to key 7 works for
the macro
d) That would break integrity rules.

One method for updating the storage is to encapsulate the update routine
in a PC or SVC, which includes a security check for whether the  caller
is authorized to update the value and determines the location of the
memory itself (not trusting the caller to supply it).



On 2021-12-06 7:13 p.m., Wendell Lovewell wrote:
> Hello Listers,
>
> I'd like to be able to update a common storage area across all CICS and batch 
> regions.  I've looked at IARV64 REQUEST=GETCOMMON, but it seems that it 
> requires supervisor state and/or key 0-7.
>
> It seems that something like issuing a STORAGE macro similar to:
>
> STORAGE OBTAIN LENGTH=32768,SP=241,KEY=x,LOC=31,OWNER=SYSTEM
>
> ...from an authorized program would allocate the storage needed.   But I 
> don't know the rules for accessing it from "user-mode" (unauthorized, key 8) 
> programs like a CICS application.
>
> a) Given the address of the storage obtained like that, can any user-mode 
> program read that storage?
> b) Could a user-mode program update that storage?
> c) Should the KEY parameter be specified, and if so, what value should I use. 
>  Afaik it has to be 0-7 since User-key CSA was outlawed.
> d) Am I correct that there isn't an IRAV64 option that will allow a user-mode 
> program to update the storage?
>
> Thanks for your help!
>
> Wendell
>
> (Cross-posted to the CICS list.)
--

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

Re: Is it possible to update CSA from an unauthorized user-key program?

[Binyamin Dissen]

I would expect that most ISVs (as well as IBM) have ways to do this
themselves.

There are various issues to make this "shared area" customer friendly, which
include format, integrity, serialization and persistence (possibly other
considerations). 

The end user can currently taken care of that with a dataset, a DB2 table,
CICS named counters, etc. Direct memory may be an optimization, and one can
press IBM for an enhancement to allow problem state programs to do this, but I
don't think the business case would get that many votes over other priorities.

At any rate, assembler-list is the wrong forum for this discussion.

On Tue, 7 Dec 2021 05:20:33 + "Farley, Peter x23353"
<0dc9d8785c29-dmarc-requ...@listserv.uga.edu> wrote:

:>
:>I don't know about anyone else, but I am really getting tired of these 
continuous calls from supposedly knowledgeable people to "invent your own PC or 
SVC to protect your global shared storage application solution and don’t trust 
anyone or anything and if you do this your integrity is your own problem not 
ours".
:>
:>Why hasn't IBM or even some clever ISV supplied a pre-packaged, 
integral-part-of-the-operating-system solution to safely share and update 
global storage any way an application designer can imagine and easily usable 
from normal HLL application programs?  Protected by standardized SAF security 
calls and all that is needed for real integrity.  Why do we have to "roll our 
own" and "own the loss of integrity if you screw it up"?  Why can't those who 
know more than we do provide the solution?
:>
:>This isn't rocket science, it's just programming, and IBM + ISV's have more 
programmers more intimately familiar with how to safely secure memory sharing 
than anyone else, so why aren't they doing it instead of foisting it onto us?
:>
:>DB2 does it for disk-resident data, why can't something like that (maybe not 
QUITE so complicated or difficult as DB2 though, and definitely NOT via SQL) be 
provided for global memory?  There are exabytes to be exploited!!  Help us use 
them!!
:>
:>
:>Peter
:>
:>-Original Message-
:>From: IBM Mainframe Assembler List  On 
Behalf Of Gary Weinhold
:>Sent: Monday, December 6, 2021 9:27 PM
:>To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
:>Subject: Re: Is it possible to update CSA from an unauthorized user-key 
program?
:>
:>Assuming you could accomplish your objective, which appears to be
:>user-key (8 or 9) storage updatable by any process running on the lpar,
:>it would appear that not only is the information stored there not
:>confidential, but its integrity is not important.  You have no
:>protection from any user-key program overlaying the storage with any
:>value it wishes, whether purposely or accidentally.  Even if you have a
:>plan to restrict access to obtaining the address of this shared storage,
:>accidental overlays could still occur, like buffer overruns.
:>
:>a) In general, key 0 memory that is not fetch protected can be read by
:>any key 8 user
:>b) By definition, key 8 users cannot update key 0 memory.
:>c) Considering the restrictions, any value of key 0 to key 7 works for
:>the macro
:>d) That would break integrity rules.
:>
:>One method for updating the storage is to encapsulate the update routine
:>in a PC or SVC, which includes a security check for whether the  caller
:>is authorized to update the value and determines the location of the
:>memory itself (not trusting the caller to supply it).
:>
:>
:>
:>On 2021-12-06 7:13 p.m., Wendell Lovewell wrote:
:>> Hello Listers,
:>>
:>> I'd like to be able to update a common storage area across all CICS and 
batch regions.  I've looked at IARV64 REQUEST=GETCOMMON, but it seems that it 
requires supervisor state and/or key 0-7.
:>>
:>> It seems that something like issuing a STORAGE macro similar to:
:>>
:>> STORAGE OBTAIN LENGTH=32768,SP=241,KEY=x,LOC=31,OWNER=SYSTEM
:>>
:>> ...from an authorized program would allocate the storage needed.   But I 
don't know the rules for accessing it from "user-mode" (unauthorized, key 8) 
programs like a CICS application.
:>>
:>> a) Given the address of the storage obtained like that, can any user-mode 
program read that storage?
:>> b) Could a user-mode program update that storage?
:>> c) Should the KEY parameter be specified, and if so, what value should I 
use.  Afaik it has to be 0-7 since User-key CSA was outlawed.
:>> d) Am I correct that there isn't an IRAV64 option that will allow a 
user-mode program to update the storage?
:>>
:>> Thanks for your help!
:>>
:>> Wendell
:>>
:>> (Cross-posted to the CICS list.)

--
Binyamin Dissen 
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel

Re: Is it possible to update CSA from an unauthorized user-key program?

[Farley, Peter x23353]

I don't know about anyone else, but I am really getting tired of these 
continuous calls from supposedly knowledgeable people to "invent your own PC or 
SVC to protect your global shared storage application solution and don’t trust 
anyone or anything and if you do this your integrity is your own problem not 
ours".

Why hasn't IBM or even some clever ISV supplied a pre-packaged, 
integral-part-of-the-operating-system solution to safely share and update 
global storage any way an application designer can imagine and easily usable 
from normal HLL application programs?  Protected by standardized SAF security 
calls and all that is needed for real integrity.  Why do we have to "roll our 
own" and "own the loss of integrity if you screw it up"?  Why can't those who 
know more than we do provide the solution?

This isn't rocket science, it's just programming, and IBM + ISV's have more 
programmers more intimately familiar with how to safely secure memory sharing 
than anyone else, so why aren't they doing it instead of foisting it onto us?

DB2 does it for disk-resident data, why can't something like that (maybe not 
QUITE so complicated or difficult as DB2 though, and definitely NOT via SQL) be 
provided for global memory?  There are exabytes to be exploited!!  Help us use 
them!!


Peter

-Original Message-
From: IBM Mainframe Assembler List  On Behalf 
Of Gary Weinhold
Sent: Monday, December 6, 2021 9:27 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Is it possible to update CSA from an unauthorized user-key program?

Assuming you could accomplish your objective, which appears to be
user-key (8 or 9) storage updatable by any process running on the lpar,
it would appear that not only is the information stored there not
confidential, but its integrity is not important.  You have no
protection from any user-key program overlaying the storage with any
value it wishes, whether purposely or accidentally.  Even if you have a
plan to restrict access to obtaining the address of this shared storage,
accidental overlays could still occur, like buffer overruns.

a) In general, key 0 memory that is not fetch protected can be read by
any key 8 user
b) By definition, key 8 users cannot update key 0 memory.
c) Considering the restrictions, any value of key 0 to key 7 works for
the macro
d) That would break integrity rules.

One method for updating the storage is to encapsulate the update routine
in a PC or SVC, which includes a security check for whether the  caller
is authorized to update the value and determines the location of the
memory itself (not trusting the caller to supply it).



On 2021-12-06 7:13 p.m., Wendell Lovewell wrote:
> Hello Listers,
>
> I'd like to be able to update a common storage area across all CICS and batch 
> regions.  I've looked at IARV64 REQUEST=GETCOMMON, but it seems that it 
> requires supervisor state and/or key 0-7.
>
> It seems that something like issuing a STORAGE macro similar to:
>
> STORAGE OBTAIN LENGTH=32768,SP=241,KEY=x,LOC=31,OWNER=SYSTEM
>
> ...from an authorized program would allocate the storage needed.   But I 
> don't know the rules for accessing it from "user-mode" (unauthorized, key 8) 
> programs like a CICS application.
>
> a) Given the address of the storage obtained like that, can any user-mode 
> program read that storage?
> b) Could a user-mode program update that storage?
> c) Should the KEY parameter be specified, and if so, what value should I use. 
>  Afaik it has to be 0-7 since User-key CSA was outlawed.
> d) Am I correct that there isn't an IRAV64 option that will allow a user-mode 
> program to update the storage?
>
> Thanks for your help!
>
> Wendell
>
> (Cross-posted to the CICS list.)
--

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

Re: Is it possible to update CSA from an unauthorized user-key program?

[Gary Weinhold]

Assuming you could accomplish your objective, which appears to be
user-key (8 or 9) storage updatable by any process running on the lpar,
it would appear that not only is the information stored there not
confidential, but its integrity is not important.  You have no
protection from any user-key program overlaying the storage with any
value it wishes, whether purposely or accidentally.  Even if you have a
plan to restrict access to obtaining the address of this shared storage,
accidental overlays could still occur, like buffer overruns.

a) In general, key 0 memory that is not fetch protected can be read by
any key 8 user
b) By definition, key 8 users cannot update key 0 memory.
c) Considering the restrictions, any value of key 0 to key 7 works for
the macro
d) That would break integrity rules.

One method for updating the storage is to encapsulate the update routine
in a PC or SVC, which includes a security check for whether the  caller
is authorized to update the value and determines the location of the
memory itself (not trusting the caller to supply it).



On 2021-12-06 7:13 p.m., Wendell Lovewell wrote:

Hello Listers,

I'd like to be able to update a common storage area across all CICS and batch 
regions.  I've looked at IARV64 REQUEST=GETCOMMON, but it seems that it 
requires supervisor state and/or key 0-7.

It seems that something like issuing a STORAGE macro similar to:

STORAGE OBTAIN LENGTH=32768,SP=241,KEY=x,LOC=31,OWNER=SYSTEM

...from an authorized program would allocate the storage needed.   But I don't know the 
rules for accessing it from "user-mode" (unauthorized, key 8) programs like a 
CICS application.

a) Given the address of the storage obtained like that, can any user-mode 
program read that storage?
b) Could a user-mode program update that storage?
c) Should the KEY parameter be specified, and if so, what value should I use.  
Afaik it has to be 0-7 since User-key CSA was outlawed.
d) Am I correct that there isn't an IRAV64 option that will allow a user-mode 
program to update the storage?

Thanks for your help!

Wendell

(Cross-posted to the CICS list.)



Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone:+1.613.523.5500 x216
Email: weinh...@dkl.com
Visit us online at www.DKL.com
E-mail Notification: The information contained in this email and any 
attachments is confidential and may be subject to copyright or other 
intellectual property protection. If you are not the intended recipient, you 
are not authorized to use or disclose this information, and we request that you 
notify us by reply mail or telephone and delete the original message from your 
mail system.

Re: Is it possible to update CSA from an unauthorized user-key program?

[Tom Harper]

Not sure what you’re trying to accomplish but would EXEC CICS named counter 
help you?

Tom Harper 

Phoenix Software International 

Sent from my iPhone

> On Dec 6, 2021, at 7:13 PM, Wendell Lovewell 
> <09624390d784-dmarc-requ...@listserv.uga.edu> wrote:
> 
> Hello Listers,
> 
> I'd like to be able to update a common storage area across all CICS and batch 
> regions.  I've looked at IARV64 REQUEST=GETCOMMON, but it seems that it 
> requires supervisor state and/or key 0-7.  
> 
> It seems that something like issuing a STORAGE macro similar to: 
> 
> STORAGE OBTAIN LENGTH=32768,SP=241,KEY=x,LOC=31,OWNER=SYSTEM 
> 
> ...from an authorized program would allocate the storage needed.   But I 
> don't know the rules for accessing it from "user-mode" (unauthorized, key 8) 
> programs like a CICS application. 
> 
> a) Given the address of the storage obtained like that, can any user-mode 
> program read that storage? 
> b) Could a user-mode program update that storage? 
> c) Should the KEY parameter be specified, and if so, what value should I use. 
>  Afaik it has to be 0-7 since User-key CSA was outlawed.  
> d) Am I correct that there isn't an IRAV64 option that will allow a user-mode 
> program to update the storage? 
> 
> Thanks for your help!
> 
> Wendell
> 
> (Cross-posted to the CICS list.) 



This e-mail message, including any attachments, appended messages and the
information contained therein, is for the sole use of the intended
recipient(s). If you are not an intended recipient or have otherwise
received this email message in error, any use, dissemination, distribution,
review, storage or copying of this e-mail message and the information
contained therein is strictly prohibited. If you are not an intended
recipient, please contact the sender by reply e-mail and destroy all copies
of this email message and do not otherwise utilize or retain this email
message or any or all of the information contained therein. Although this
email message and any attachments or appended messages are believed to be
free of any virus or other defect that might affect any computer system into
which it is received and opened, it is the responsibility of the recipient
to ensure that it is virus free and no responsibility is accepted by the
sender for any loss or damage arising in any way from its opening or use.

Is it possible to update CSA from an unauthorized user-key program?

[Wendell Lovewell]

Hello Listers,

I'd like to be able to update a common storage area across all CICS and batch 
regions.  I've looked at IARV64 REQUEST=GETCOMMON, but it seems that it 
requires supervisor state and/or key 0-7.  

It seems that something like issuing a STORAGE macro similar to: 
 
STORAGE OBTAIN LENGTH=32768,SP=241,KEY=x,LOC=31,OWNER=SYSTEM 

...from an authorized program would allocate the storage needed.   But I don't 
know the rules for accessing it from "user-mode" (unauthorized, key 8) programs 
like a CICS application. 

a) Given the address of the storage obtained like that, can any user-mode 
program read that storage? 
b) Could a user-mode program update that storage? 
c) Should the KEY parameter be specified, and if so, what value should I use.  
Afaik it has to be 0-7 since User-key CSA was outlawed.  
d) Am I correct that there isn't an IRAV64 option that will allow a user-mode 
program to update the storage? 

Thanks for your help!

Wendell

(Cross-posted to the CICS list.)