@bama.ua.edu
Subject: Re: Need to find alternative to shared storage because of
ALLOWUSERKEYCSA parm
In listserv%201003240922582291.0...@bama.ua.edu, on 03/24/2010
at 09:22 AM, Diane Goodwin dgood...@amica.com said:
LAR1,SVCSAVE HOLD AREA FOR SVC 255
SVC 255
In 33a9a3874f87c24aab996586c367def805bf2...@hoex01.amica.com, on
03/29/2010
at 08:10 AM, GOODWIN, DIANE M. dgood...@amica.com said:
So, can I still use subpool 241 and just change the key?
As long as whoever allocates and updates it is privileged.
--
Shmuel (Seymour J.) Metz, SysProg
Gilmartin paulgboul...@aim.com
To: IBM-MAIN@bama.ua.edu
Sent: Thu, March 25, 2010 4:18:33 PM
Subject: Re: Need to find alternative to shared storage because of
ALLOWUSERKEYCSA parm
On Wed, 24 Mar 2010 09:22:58 -0500, Diane Goodwin wrote:
We all know the default setting for ALLOWUSERKEYCSA was changed
On Wed, 24 Mar 2010 09:22:58 -0500, Diane Goodwin wrote:
We all know the default setting for ALLOWUSERKEYCSA was changed
to NO from yes. This causes a problem for our CICS regions (address
spaces).
We have a storage area that we obtain at the first CICS address space
start up. The area
-Original Message-
From: IBM Mainframe Discussion List
[mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin
Sent: Thursday, March 25, 2010 3:19 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Need to find alternative to shared storage
because of ALLOWUSERKEYCSA parm
On Wed, 24
ALLOWUSERKEYCSA(YES).
I get to figure out the best way to change this because higher-ups want
us to be able to run with the default.
Why? Do they also want to eliminate that user SVC?
Subpool 241 is common csa, not fetch protected, pageable and system
owned.
I cannot find a subpool that is common
SWITCH TO PROBLEM STATE
The new default of ALLOWUSERKEYCSA of NO of course makes this
fail. We did set it to YES since this is necessary for our CICS to run.
However, I've been given the task to see if we can have a shared area
and run with the default of NO.
Subpool 241 is CSA, system
Hello, Please bear with me. I'm normally a CICS System programmer.
We all know the default setting for ALLOWUSERKEYCSA was changed
to NO from yes. This causes a problem for our CICS regions (address
spaces).
We have a storage area that we obtain at the first CICS address space
start up
On Wed, Mar 24, 2010 at 2:22 PM, Diane Goodwin dgood...@amica.com wrote:
Hello, Please bear with me. I'm normally a CICS System programmer.
We all know the default setting for ALLOWUSERKEYCSA was changed
to NO from yes. This causes a problem for our CICS regions (address
spaces).
We have
] On
Behalf Of Sam Siegel
Sent: Wednesday, March 24, 2010 10:40 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Need to find alternative to shared storage because of
ALLOWUSERKEYCSA parm
On Wed, Mar 24, 2010 at 2:22 PM, Diane Goodwin dgood...@amica.com
wrote:
Hello, Please bear with me. I'm normally
: Wednesday, March 24, 2010 10:00 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Need to find alternative to shared storage because of
ALLOWUSERKEYCSA parm
I was just going through the book on what and how dataspaces work.
The other issue is that we save the address of this shared storage in a
common
On Wed, Mar 24, 2010 at 9:59 AM, GOODWIN, DIANE M. dgood...@amica.comwrote:
I was just going through the book on what and how dataspaces work.
The other issue is that we save the address of this shared storage in a
common area. Then all application programs have the address in common,
will
] On
Behalf Of Tony Lubrano
Sent: Wednesday, March 24, 2010 11:16 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Need to find alternative to shared storage because of
ALLOWUSERKEYCSA parm
Diane,
Does anybody need to update this storage area? If this is read-only,
you can obtain the storage in Key 0
Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On
Behalf Of Sam Siegel
Sent: Wednesday, March 24, 2010 10:40 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Need to find alternative to shared storage because of
ALLOWUSERKEYCSA parm
On Wed, Mar 24, 2010 at 2:22 PM, Diane Goodwin dgood
So is my problem the subpool or the key 9? This is one thing that I'm
unclear about.
The area has to be obtained and then altered from one region. This
region I do have a lot of the control of the programs in it.
Then the area needs to be able to be referenced by a pass address for
read only
to shared storage because of
ALLOWUSERKEYCSA parm
Diane,
Does anybody need to update this storage area? If this is read-only,
you can obtain the storage in Key 0 for everyones reading enjoyment.
Maybe the list of things that actually update this storage area is
significantly smaller
This may not fit the bill for you, but have you considered using a
SCOPE=COMMON dataspace?
I would strongly recommend against using a user key
SCOPE=COMMON data space. It would have a security exposure
which is similar to user key CSA.
Jim Mulder z/OS System Test IBM Corp.
@bama.ua.edu
Subject: Re: Need to find alternative to shared storage because of
ALLOWUSERKEYCSA parm
Are programs accessing the memory directly? Or though an in-house API
or
program?
--
For IBM-MAIN subscribe / signoff / archive access
.
===
Wayne Driscoll
OMEGAMON DB2 L3 Support/Development
wdrisco(AT)us.ibm.com
===
From:
Diane Goodwin dgood...@amica.com
To:
IBM-MAIN@bama.ua.edu
Date:
03/24/2010 09:18 AM
Subject:
Trying to understand ALLOWUSERKEYCSA and subpool storage
On Wed, 24 Mar 2010 11:25:28 -0400, GOODWIN, DIANE M. wrote:
So is my problem the subpool or the key 9? This is one thing that I'm
unclear about.
The problem is that you are trying to allocate user key common storage. For
your purposes, you need it to be common, but you need to get it with a
Diane,
Yes, when ALLOWUSERKEYCSA(NO) is specified, all CSA allocations must be made in
key 0-7. Otherwise, you abend with an SB78 or SB0A RSN=5C.
Tony Lubrano
Product Author
NEON Enterprise Software, LLC.
p: 281 207 4922 f: 281 207 4973
tony.lubr...@neon.com
What is zPrime? Find out
alternative to shared storage because of
ALLOWUSERKEYCSA parm
Diane,
Yes, when ALLOWUSERKEYCSA(NO) is specified, all CSA allocations must be
made in key 0-7. Otherwise, you abend with an SB78 or SB0A RSN=5C.
Tony Lubrano
Product Author
NEON Enterprise Software, LLC.
p: 281 207 4922 f: 281 207 4973
for
ALLOWUSERKEYCSA to NO, IBM is forcing users to intentionally change the
setting to allow key 8 (i.e., uncontrolled access) storage in CSA. In order
to exchange data between address spaces with some type of access control is
likely to require significant changes to those applications. If you want to
continue
@bama.ua.edu
Subject: Re: Need to find alternative to shared storage because of
ALLOWUSERKEYCSA parm
Are programs accessing the memory directly? Or though an in-house API
or
program?
--
For IBM-MAIN subscribe / signoff / archive
Of
GOODWIN, DIANE M.
Sent: Wednesday, March 24, 2010 10:53 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Need to find alternative to shared storage because of
ALLOWUSERKEYCSA parm
So I really just need to change the key?
I can still use the same subpool?
-Original Message-
From: IBM
In my opinion, a magic SVC is a MUCH WORSE integrity exposure than
allowing authorized code to GETMAIN Key 8 CSA.
Brian
On Wed, 24 Mar 2010 10:45:22 -0500, Wayne Driscoll wrote:
Diane,
Based on the below code snip segment, your installation has a magic SVC
to get into SUP STATE KEY 0. which is
On Wed, Mar 24, 2010 at 11:56 AM, Brian Peterson
brian.peterson.ibm.m...@comcast.net wrote:
In my opinion, a magic SVC is a MUCH WORSE integrity exposure than
allowing authorized code to GETMAIN Key 8 CSA.
Indeed!
--
This email might be from the
artist formerly known as CC
(or not) You be
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of
Brian Peterson
Sent: Wednesday, March 24, 2010 11:57 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Trying to understand ALLOWUSERKEYCSA and subpool storage
In my opinion, a magic SVC
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Williamson, James R
-Original Message-
From: IBM Mainframe Discussion List On Behalf Of Brian Peterson
In my opinion, a magic SVC is a MUCH WORSE integrity exposure than
allowing authorized code to
Suppose your magic SVC does nothing unless the caller is APF
authorized?
In that case it wouldn't be sufficiently magic for use within CICS,
which runs unauthorized.
true. And what would be the point of a magic svc for an authorized caller
anyway? They could just as easily use MODESET
--
Agreed. For that reason I usually call them rape SVCs. I certainly wouldn't
publish that I had one, and show everyone what the number is.
Brian Peterson brian.peterson.ibm.m...@comcast.net 3/24/2010 12:56 PM
In my opinion, a magic SVC is a MUCH WORSE integrity exposure than
allowing
Then what is the point?
Williamson, James R james.r.william...@uscg.mil 3/24/2010 1:01 PM (
mailto:james.r.william...@uscg.mil )
Suppose your magic SVC does nothing unless the caller is APF authorized?
--
For IBM-MAIN
On Wed, 24 Mar 2010 12:00:07 -0500, Chris Craddock wrote:
On Wed, Mar 24, 2010 at 11:56 AM, Brian Peterson wrote:
In my opinion, a magic SVC is a MUCH WORSE integrity exposure than
allowing authorized code to GETMAIN Key 8 CSA.
Indeed!
One solution is to change the SVC to do the work that
Just curious what MXI means. Google finds MXI Multisystem eXtention
Interface Bus, but I don't think that fits here.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the
:[EMAIL PROTECTED] On
Behalf Of Don Williams
Sent: Wednesday, October 29, 2008 9:31 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: ALLOWUSERKEYCSA and key 10
Just curious what MXI means. Google finds MXI Multisystem eXtention
Interface Bus, but I don't think that fits here
, October 29, 2008 9:31 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: ALLOWUSERKEYCSA and key 10
Just curious what MXI means. Google finds MXI Multisystem eXtention
Interface Bus, but I don't think that fits here.
--
For IBM-MAIN
Good day list
I would like to know what is the impact of the parameter ALLOWUSERKEYCSA
when the storage is in key ten (10) ...
I'm curious because when just looking at a dump I found some chunks in ECSA
key 10 ...
If I understand correctly, at the dump I looked the PKM allowed only keys 8
. The intent of Key9 is to stop
user-code from overlaying subsystem (CICS) storage.
2 - Will ALLOWUSERKEYCSA(NO) cause an CSA getmain for a chunk in key 10 to
fail ?
Keys 10-15 are reserved for problem state V=R programs (does anyone still use
this today??). My guess is that ALLOWUSERKEYCSA
Hi Rob:
Thanks for the answer ... And for MXI ...
I undertand why CICS needs keys 8-9 ... The question is: May sometimes
found that a problem program is running with a PKM of for example 8, 9 and 10
that will allow the user program to SPKA to key 10 ?
BTW, my bet is the same than ours ... I
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mauri Kanter
Sent: Tuesday, October 28, 2008 7:55 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: ALLOWUSERKEYCSA and key 10
Hi Rob:
Thanks for the answer ... And for MXI ...
I undertand why CICS
No PROLOG ...
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
-614-2305
[EMAIL PROTECTED]
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of
Mauri Kanter
Sent: 28 October 2008 12:55
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: ALLOWUSERKEYCSA and key 10
Hi Rob:
Thanks for the answer ... And for MXI ...
I
On Tue, 28 Oct 2008 09:59:08 -0400, Rob Scott
[EMAIL PROTECTED] wrote:
The ability to SPKA to Key10 is controlled by the contents of CR3 and for
V=V programs I would expect a PPT entry for the program (unless the program
concerned is manipulating CR3 using something like the LCTL instruction).
Mauri Kanter wrote:
I would like to know what is the impact of the parameter ALLOWUSERKEYCSA
when the storage is in key ten (10) ...
All user keys 8-15 are affected by AllowUserKeyCsa in DIAGxx.
Are you sure the storage you see in the dump is in key ten (x'A0') and
not key one (x'10
Are you sure the storage you see in the dump is in key ten (x'A0') and
not key one (x'10')?
Yes I'm sure
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message:
Just got an email Jobtrac 3.5 support extended to 3-2-2009.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at
We fixed our issues with Tivoli Identity Manager by uprading its RACF Agent to
the current version/release. The original RACF Agent code for z/OS had Key 8
CSA issues, but the current version (available for some years now) has none.
Brian
On Fri, 18 Jul 2008 03:17:30 -0400, Jim Mulder wrote:
Zelden on this, especially as we are upgrading
to z/OS 1.9 with ALLOWUSERKEYCSA(YES) mainly because of 2 IBM products:
Tivoli Identity Manager Omegamon/IMS.
Fix what you can, when you can.
Stephen Hall
Mainframe Platform Manager
Platform Support Services
Technology Services
INSURANCE
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/18/2008
02:39:40 AM:
Personally, I'm with Mark Zelden on this, especially as we are upgrading
to z/OS 1.9 with ALLOWUSERKEYCSA(YES) mainly because of 2 IBM products:
Tivoli Identity Manager Omegamon/IMS.
There is an open APAR
While it is true that many might not care about someone corrupting a user
key CSA area (even if it potentially compromises their system), that is not
the only integrity exposure that user key CSA can result in.
Allowing unauthorized communication between address spaces (i.e., covert
channels) is
the installation/implementation and its
integrity. IBM has an option available as part of the IPL parameters
(ALLOWUSERKEYCSA()) that will disable a known feature, that if enabled,
will allow for an exploit to be developed. Make sure you have documented
reasons for allowing key 8 CSA as the business risk
On Thu, 17 Jul 2008 07:17:01 -0400, Peter Relson [EMAIL PROTECTED]
wrote:
...
Allowing unauthorized communication between address spaces (i.e., covert
channels) is also made possible by this.
Unauthorized communication? Give me a break, there must be a thousand
other ways for address spaces
It is real fun to send dumps to vendors who have used Key 8 CSA to store
programs
I have used Omegamon MVS classic to get a list of such storage areas
then via TASID option 7, gone to that area in storage, and then overlayed the
area with nulls ('00'x). The resulting abends are good to
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/14/2008
02:52:12 PM:
Indeed. Though in fairness, it must be pointed out that not every use
of user key CSA is a security or integrity exposure. Distinguishing
the many cases that are from those that are not is so difficult,
2008/7/15 Jim Mulder [EMAIL PROTECTED] wrote:
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 07/14/2008
02:52:12 PM:
Indeed. Though in fairness, it must be pointed out that not every use
of user key CSA is a security or integrity exposure. Distinguishing
the many cases that are
One could perhaps argue that a malicious user could trick some other code into
doing something it shouldn't by virtue of being able to place arbitrary data
into this piece of CSA, but that is certainly the
fault of that other code's doing a bogus validity check. That kind of checking
went out
message was added to Exec Manager to block the use of IMFEXEC SUBMIT and give
the user a RC=16. The message documentation
suggests that
the user switch to using JESSUBM instead.
CIRCUMVENTIONS:
Run the PAS in key8. Under z/OS 1.8, this may require setting the DIAG
parameter named ALLOWUSERKEYCSA
I kind of figured that *someone* would rise to this
What I wanted to address is the fact that there are quite a few sysprogs who
don't care to solve a CSA key8 problem like the one described by that BMC apar.
If it had been me, I would have attempted to use the suggested circumvention
and
On Mon, 14 Jul 2008 08:25:06 -0500, David Waldman
[EMAIL PROTECTED] wrote:
We tried to run 3.5 on our z/OS 1.9 system. We had problems because we
have ALLOWUSERKEYCSA(NO). Jobtrac would abend. CA's official response
was to step-up to r11 on 1.9.
Ironically, with the ALLOWUSERKEYCSA parameter
On Mon, 14 Jul 2008 09:03:20 -0500, Mark Zelden wrote:
While I applaud IBM for finally making this change and all the
vendors who are modifying their code for this (and Sam K. and others
for pushing the vendors), I really don't have a problem running with
ALLOWUSERKEYCSA(YES) on my systems
Mark Zelden wrote:
While I applaud IBM for finally making this change and all the
vendors who are modifying their code for this (and Sam K. and others
for pushing the vendors), I really don't have a problem running with
ALLOWUSERKEYCSA(YES) on my systems at this point. The exposure
has been
I believe SYSB-II requires ALLOWUSERKEYCSA(NO).
Some months ago, HW sent out an email asking for guidance in setting a
priority for modifying SYSB-II to make it work with YES. I don't know
what kind of response they got, but, given the fact that there's been no
fix, it doesn't appear
About a year ago, I wrote that I had activated ALLOWUSERKEYCSA(NO) on my
tech LPAR.
This past weekend, I've managed to get my first production LPAR up and
running with this setting. This means that the software stack on that LPAR is
now completely compatable with ALLOWUSERKEYCSA(NO). Thank
really don't have a problem running with
ALLOWUSERKEYCSA(YES) on my systems at this point. The exposure
has been there forever and making it go away overnight (in relative
terms of time) just isn't a big concern for me.
What other schedule would you propose as more comfortable?
I'm not sure what you
these integrity
issues was in the ten-year period after the IgvNoUserKeyCsa DIAG TRAP came
out with OS/390 V2R6 (September 1997) and before the AllowUserKeyCsa option
became available with z/OS 1.8 (September 2007). Conscientious developers
took full advantage of that ten-year opportunity. The lazy
We received mixed feedback regarding our letter asking customers about
their timing for implementing ALLOWUSERKEYCSA(NO). The purpose of the
letter was actually to help us in making decisions to move forward that
would have the least impact on customers. We had already performed due
diligence
Paul Gilmartin wrote:
How long has user key CSA been recognized as undesirable?
At least:
MVS/ESA SP V4 Planning: Security
Edition Notice
Second Edition, March 1993
Bob
--
For
Tony Harminc wrote:
In any case, it should be obvious that the best policy, when dealing with
potentially serious integrity exposures, is secrecy.
I'd say it's far from obvious. Intelligent and informed people differ
on this topic, and there is no consensus.
Regardless of what others
, this may require setting the DIAG
parameter named ALLOWUSERKEYCSA to YES.
Needless to say, I was told that my colleagues cannot use JESSUBM. I am
currently waiting for a wide awake auditor who knows what he's doing. Also, I
will NOT delete the health check stating that we don't run
Hi,
We ran into an issue at DRP with the recovery jobs getting ABEND B78-5C running
BACKUP AND RECOVERY FOR IMS VERSION 4.2.00 MAINTENANCE DATE 11/09/06 with
z/OS setting ALLOWUSERKEYCSA(NO).
BMC DBU December 2007 maintenance level plus a PTF (BPQ2035) is required to
finally remove
-Original Message-
Michael Babcock wrote:
As I understand it, IDMS specifically has a problem with NO.
Since I see a CV running on our sandbox, I'm guessing there
are pills for that.
CA have a PIB, QI82743, which covers this.
Summary:
If you have allowuserkeycsa(yes), you'll
, QI82743, which covers this.
Summary:
If you have allowuserkeycsa(yes), you'll be OK
If allowuserkeycsa(no) is specified, IDMS will abend B78-5C at startup.
If you can't specify allowuserkeycsa(yes), you need to :
* Put the IDMS startup module, RHDCTCKR RHDCCKUR into a separate
loadlib
* Add that library
On Wed, 7 May 2008 07:26:59 -0500, Mark Zelden [EMAIL PROTECTED] wrote:
On Wed, 7 May 2008 10:24:21 +0100, Iain Robertson [EMAIL PROTECTED]
wrote:
-Original Message-
Michael Babcock wrote:
As I understand it, IDMS specifically has a problem with NO.
Since I see a CV running on our
We've been using the default of YES up to z/OS 1.8, but will now take the
default of NO for z/OS 1.9.
Shouldn't be any problem, as we will discover any issues when rolling out
through various systems. So far we've discovered a bug in our Sysprog
sysplex with a BMC DB2 utility, but they've
As I understand it, IDMS specifically has a problem with NO.
Patrick Loftus wrote:
We've been using the default of YES up to z/OS 1.8, but will now take the
default of NO for z/OS 1.9.
Shouldn't be any problem, as we will discover any issues when rolling out
through various systems. So far
On Tue, 6 May 2008 12:53:57 -0500, Michael Babcock [EMAIL PROTECTED]
wrote:
As I understand it, IDMS specifically has a problem with NO.
As does CA-DATACOM the last I checked. There is an option to change
it for current version(s?) (which we do for CA-11's DATACOM) but when
our DBA checked
Michael Babcock wrote:
As I understand it, IDMS specifically has a problem with NO.
Since I see a CV running on our sandbox, I'm guessing there are pills for that.
Bob
--
For IBM-MAIN subscribe / signoff / archive access
2008/5/6 Patrick Loftus [EMAIL PROTECTED]:
We've been using the default of YES up to z/OS 1.8, but will now take the
default of NO for z/OS 1.9.
Shouldn't be any problem, as we will discover any issues when rolling out
through various systems. So far we've discovered a bug in our Sysprog
The only issue with allowuserkeycsa=yes is that you forego the protection
of disallowing it. It's been allowed 'forever' until recently. There used
to be no external control at all. Now the control defaults to 'no'.
We have to run with 'yes' on several systems because of some old software
that we
On Sun, 4 May 2008 22:42:54 -0500, Tom Eden [EMAIL PROTECTED] wrote:
I would like to know how many are specifying allowuserkeycsa=yes in a z/OS
1.9 environment and if there have been any issues?
No one would have issues with running with the YES setting. The OS has
always allowed
we have an old vendor written product (MEMO) which we could not change
and which was getting a b0a-5c abend under z/os 1.9 and we had to change
the default to ALLOWUSERKEYCSA=YES.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Mark Zelden
Eileen Barkow of the IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU
wrote on 05/05/2008 08:10:03 AM:
we have an old vendor written product (MEMO) which we could not change
and which was getting a b0a-5c abend under z/os 1.9 and we had to change
the default to ALLOWUSERKEYCSA=YES.
Instead
that is a good idea assuming you know in advance all of the programs
which may need ALLOWUSERKEYCSA=YES. and in our case, the vendor product
executes more than 1 program and we cannot pretest all of the options.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL
z/os 1.9 and we had to change
the default to ALLOWUSERKEYCSA=YES.
Instead of an all inclusive ALLOWUSERKEYCSA=YES, why not something like
ALLOWUSERKEYCSA=(program1,program2,...) for situations where there is no
source code or support.
Not a bad idea, but remember there was little programming
On Mon, 5 May 2008 09:05:27 -0500, John P Kalinich wrote:
Instead of an all inclusive ALLOWUSERKEYCSA=YES, why not something like
ALLOWUSERKEYCSA=(program1,program2,...) for situations where there is no
source code or support.
But the hazard is manifest not when an authorized program obtains
On Mon, 5 May 2008 09:51:04 -0500 Paul Gilmartin [EMAIL PROTECTED] wrote:
:On Mon, 5 May 2008 09:05:27 -0500, John P Kalinich wrote:
:Instead of an all inclusive ALLOWUSERKEYCSA=YES, why not something like
:ALLOWUSERKEYCSA=(program1,program2,...) for situations where there is no
:source code
I agree. I can see this being added to the checklist for auditors.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul
Gilmartin
Sent: Monday, May 05, 2008 9:51 AM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: allowuserkeycsa
On Mon, 5 May 2008 09
On Mon, 5 May 2008 09:51:04 -0500, Paul Gilmartin wrote:
But the hazard is manifest not when an authorized program obtains
storage in a user key, but when an unauthorized program modifies
that storage. Perhaps the solution would be to allocate user key
CSA only in a subpool that would be
Paul Gilmartin wrote:
But the hazard is manifest not when an authorized program obtains
storage in a user key, but when an unauthorized program modifies
that storage. Perhaps the solution would be to allocate user key
CSA only in a subpool that would be segment-protected from
modification by
-5c abend under z/os 1.9 and we had to
change
the default to ALLOWUSERKEYCSA=YES.
Instead of an all inclusive ALLOWUSERKEYCSA=YES, why not something like
ALLOWUSERKEYCSA=(program1,program2,...) for situations where there is no
source code or support.
From a system integrity point
i do not understand why ALLOWUSERKEYCSA is such an issue now.
things worked for years when it defaulted to NO under pre z/os 1.9
releases, so why is it suddenly a security risk to reset the current
default so that it remains set
Sorry, i meant default YES, not NO.
-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of Barkow, Eileen
Sent: Monday, May 05, 2008 3:59 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: allowuserkeycsa
i do not understand why ALLOWUSERKEYCSA
Barkow, Eileen wrote:
i do not understand why ALLOWUSERKEYCSA is such an issue now.
things worked for years when it defaulted to NO under pre z/os 1.9
releases, so why is it suddenly a security risk to reset the current
default so that it remains set to NO.
It is not sudden. The risk has
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 05/05/2008
03:59:25 PM:
i do not understand why ALLOWUSERKEYCSA is such an issue now.
things worked for years when it defaulted to (YES) under pre z/os 1.9
releases, so why is it suddenly a security risk to reset the current
default
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 05/05/2008
08:42:51 AM:
If you are going to let it default or specify NO, make sure you can test
this
well first. Even without testing, if you have a common storage monitor,
or download MXI from the CBT you can find out who / what
The one advantage that AllowUserKeyCSA=(program1,program2)
would have over the current AllowUserKeyCSA=YES/NO is that
it would prevent any new code from allocating User Key CSA while
an installation is trying to get converted over to full protection.
(Better still would be a SAF call, but I
I would like to know how many are specifying allowuserkeycsa=yes in a z/OS
1.9 environment and if there have been any issues?
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED
Hi,
If you intend to run with ALLOWUSERKEYCSA(NO)in DIAGxx and have CA-OPSMVS you
will want fix OPB5083. This was an unusual invocation of automation that
exposed a problem in this case. The guys in Pittsburgh promptly knocked out a
fix which is OPB5083.
Best Regards
Hi,
We found another issue with PHOENIX and PREFERENCE which was promptly fixed by
the vendor when ALLOWUSERKEYCSA(NO) was set.
Remember that user key does not mean just key 8 in this case the allocation was
being done in key 11. The developer at Sum Total wrote us a fix S791006.
PHOENIX
If you have CA-MIM(MIA) nee GTAF once upon a time STAM you will need PTF
QO91316 11.5 or version 11.6 where this fix is included in the base in order to
run with ALLOWUSERKEYCSA(NO) set or defaulted.
We ran into a problem and got excellent support from the CA Pittsburgh lab
getting a fix
1 - 100 of 105 matches
Mail list logo
