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:
</rant>
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!!
<rant/>
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<ASSEMBLER-LIST@LISTSERV.UGA.EDU> 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.
