Re: OA49446 on RSU1603 - RACF / DFSMS change

[retired mainframer]

> -Original Message-
> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On
> Behalf Of Jesse 1 Robinson
> Sent: Monday, May 02, 2016 10:38 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> Subject: Re: OA49446 on RSU1603 - RACF / DFSMS change
> 
> I have no experience with the PTF in action. I saw it during APPLY CHECK and 
> decided
> immediately that I would EXCLUDE it in the real APPLY--which has not happened 
> yet. I
> think we need some clarification from the RACF folks...

But RACF doesn't make any decisions or grant any access.  It merely answers 
questions:  Is RACF Active?  Does the profile exist?  Does the user have the 
requested access to the profile?  Etc.

It is the calling function, in this case the one responsible for defining 
aliases or the one responsible for granting access to a dataset, that 
determines if the action will be allowed.  These are the folks who will know 
how the new processing works and who should have done a better job explaining 
it to begin with.

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

Re: OA49446 on RSU1603 - RACF / DFSMS change

[Jesse 1 Robinson]

I have no experience with the PTF in action. I saw it during APPLY CHECK and 
decided immediately that I would EXCLUDE it in the real APPLY--which has not 
happened yet. I think we need some clarification from the RACF folks...

.
.
.
J.O.Skip Robinson
Southern California Edison Company
Electric Dragon Team Paddler 
SHARE MVS Program Co-Manager
323-715-0595 Mobile
626-302-7535 Office
robin...@sce.com

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mark Zelden
Sent: Friday, April 29, 2016 8:49 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: (External):Re: OA49446 on RSU1603 - RACF / DFSMS change

On Fri, 29 Apr 2016 07:15:09 -0400, Robert S. Hansel (RSH) 
<r.han...@rshconsulting.com> wrote:

>(Cross-posting to RACF-L)
>
>Mark,
>
>
>If this works as per my interpretation, then I think the concerns 
>raised by others are  valid. If I can create an alias with a name to 
>which I have access that points to a dataset  to which I do not have access, 
>I've now circumvented access controls for the latter.

Unless my testing is invalid, I've already confirmed this is NOT true.  The 
real data set
name is checked for access as well.

I wouldn't have thought IBM could be that inept to do something like that and 
create the biggest security hole ever seen on this platform (at least that I 
could recall)! Especially in the service stream.  

Best regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 
Foundation Certified mailto:m...@mzelden.com Mark's MVS Utilities: 
http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/


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

Re: OA49446 on RSU1603 - RACF / DFSMS change

[Mark Zelden]

On Fri, 29 Apr 2016 07:15:09 -0400, Robert S. Hansel (RSH) 
 wrote:

>(Cross-posting to RACF-L)
>
>Mark,
>
>
>If this works as per my interpretation, then I think the concerns raised by 
>others are
> valid. If I can create an alias with a name to which I have access that 
> points to a dataset
> to which I do not have access, I've now circumvented access controls for the 
> latter. 

Unless my testing is invalid, I've already confirmed this is NOT true.  The 
real data set
name is checked for access as well.

I wouldn't have thought IBM could be that inept to do something like that and 
create the 
biggest security hole ever seen on this platform (at least that I could 
recall)! Especially 
in the service stream.  

Best regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OA49446 on RSU1603 - RACF / DFSMS change

[Tom Marchant]

On Fri, 29 Apr 2016 07:21:12 -0500, Tom Marchant wrote:

>The old way, which surprises me a little, DEFINE ALIAS required access to the 
>data set to which the alias is related, but not to the alias name being 
>defined.

Sorry, this part seems to be incorrect. The old way didn't require any access 
when defining an alias for a nonvsam data set.

Proofreading is often more effective after posting. 

-- 
Tom Marchant

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

Re: OA49446 on RSU1603 - RACF / DFSMS change

[Tom Marchant]

On Thu, 28 Apr 2016 12:01:17 -0500, Mark Zelden wrote:

>I'm applying z/OS 2.1 RSU1603 and came across this PTF.   Is anyone running 
>with
>it in production and has it caused you any grief?   This seems to change a 
>behavior
>that has been around "forever", so it concerns me a bit even though there 
>is a work around by defining a special RACF profile in the Facility class.

Ok, I finally looked at the actual HOLDDATA in PTF UA80147, the z/OS 2.2 PTF 
for OA49446. This PTF does not change the way access to a data set is granted 
when it an alias is used. It changes the access required to define the alias. 
The old way, which surprises me a little, DEFINE ALIAS required access to the 
data set to which the alias is related, but not to the alias name being defined.

So, for example, if I have a data set TOM.DATA.SET, I can create an alias 
called FRED.DATA.SET, even though I do not have authority to create FRED data 
sets. The new code does not allow me to do that, because I do not have ALTER 
access to FRED.DATA.SET.

OTOH, if I want to create alias TOM.DATA.SET that relates to FRED.DATA SET, I 
can do that because I have alter access to TOM.DATA.SET. However, that does not 
change the fact that when I try to access FRED.DATA.SET using my new alias, the 
access that is checked is to FRED.DATA.SET, so my access will fail.

Without the PTF, if I am reading it correctly, there is no checking when 
defining an alias for a non-vsam data set. I can define either of the above 
aliases. I don't have a system without the PTF applied, so I can't test this.

For DEFINE ALTERNATEINDEX and DEFINE PATH, it is a little different. The 
existing code checks for ALTER access to the cluster name for the DEFINE. The 
new code requires ALTER access to the new entry name (the PATH or AIX name).

This is NOT a RACF PTF. It is a PTF to HDZ2220, DFSMS.

-- 
Tom Marchant

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

Re: OA49446 on RSU1603 - RACF / DFSMS change

[Robert S. Hansel (RSH)]

(Cross-posting to RACF-L)

Mark,

I have not worked with this APAR and PTF. Below is my interpretation of it. I 
agree this is a huge change. I think careful testing is needed to confirm this, 
and as I don't have access to a system with the change, I would be happy to 
help you with the test out of curiosity.

This 'enhancement' appears to address an oft heard desire to be able to grant 
access to an alias, as these tend to be permanent, as an alternative to having 
to granting access to the underlying dataset, which tends to change, with the 
goal of simplify security administration. With this change, one will now be 
able to permit access to alias PRODUCT.LINKLIB instead of the related dataset 
PRODUCT.VERSION1.LINKLIB. Then, whenever a new version arrives, you simply 
point alias PRODUCT.LINKLIB at PRODUCT.VERSION2.LINKLIB and everyone will have 
access to the new version without you having to create a new profile for 
PRODUCT.VERSION2.LINKLIB. It might be possible to permit ordinary users access 
only to aliases and never permit them access to the underlying datasets. This 
might enable you to consolidate and streamline existing profiles.

As for 'required action 1.' , I believe what they are alluding to is that if 
your aliases are currently named something like PRODVER.PRODUCT.LINKLIB and 
there are no RACF profiles for PRODVER, you will experience denial of access if 
RACF's SETROPTS PROTECTALL is in FAILURE mode (as is generally the case). If 
your aliases use existing High Level Qualifiers, and most likely they use the 
same HLQ as the related datasets, then you may not experience access problems 
because they'll already be covered by a profile. However, even if the latter is 
true, an existing alias might be covered by a profile like PRODUCT.** while the 
real dataset might be protected by profile PRODUCT.V*.**, and they could have 
very different access permissions. An exhaustive analysis of profiles and 
permissions is in order to ensure that the sudden switch in access authority 
checking from the dataset to the alias doesn't result in a loss of access. When 
first applying this PTF, I'd also be tempted to temporarily change PROTECTALL 
from FAILURE to WARNING just in case I'd missed something.

If this works as per my interpretation, then I think the concerns raised by 
others are valid. If I can create an alias with a name to which I have access 
that points to a dataset to which I do not have access, I've now circumvented 
access controls for the latter. This is somewhat akin to having ALTER access to 
a catalog which lets you delete VSAM and SMS datasets without having ALTER to 
the dataset profiles. It appears, however, that IBM has addressed this concern. 
Googling APAR OA47269 (APAR OA49446 is essentially an addendum to this APAR) 
brings up links discussing new restrictions on DFSMSdfp DEFINE. To create an 
ALIAS, PATH, OR ALTERNATEINDEX, you will need ALTER access to the related 
dataset.

This is going to make protecting sensitive datasets more complicated. I wonder 
if IBM's Health Check for APF library protection will now include aliases as 
well.

Regards, Bob

Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc.
617-969-8211
www.linkedin.com/in/roberthansel
http://twitter.com/RSH_RACF
www.rshconsulting.com

Upcoming RSH RACF Training
- RACF Audit & Compliance Roadmap - DEC 5-9, 2016
- RACF Level I Administration - MAY 17-20, 2016
- RACF Level II Administration -MAY 3-5, 2016
- RACF Level III Admin, Audit, & Compliance - JUN 14-16, 2016
- Securing z/OS UNIX  - WebEx - JUL 25-29, 2016


-Original Message-
Date:Thu, 28 Apr 2016 12:01:17 -0500
From:Mark Zelden <m...@mzelden.com>
Subject: OA49446 on RSU1603 - RACF / DFSMS change

I'm applying z/OS 2.1 RSU1603 and came across this PTF.   Is anyone running with
it in production and has it caused you any grief?   This seems to change a 
behavior
that has been around "forever", so it concerns me a bit even though there 
is a work around by defining a special RACF profile in the Facility class.


++ HOLD(UA80146) SYS FMID(HDZ2210) REASON(ACTION) DATE(15356)  
   COMMENT 
(  
 * FUNCTION AFFECTED: DFSMS   (OA49446) *  
   
 * DESCRIPTION  : Update security definition*  
   
 * TIMING   : Pre-APPLY *  
   
 

Re: OA49446 on RSU1603 - RACF / DFSMS change

[Mark Zelden]

On Thu, 28 Apr 2016 12:22:17 -0500, Paul Gilmartin  wrote:

>On Thu, 28 Apr 2016 12:01:17 -0500, Mark Zelden wrote:
>
>>I'm applying z/OS 2.1 RSU1603 and came across this PTF.   Is anyone running 
>>with
>>it in production and has it caused you any grief?   This seems to change a 
>>behavior
>>that has been around "forever", so it concerns me a bit even though there 
>>is a work around by defining a special RACF profile in the Facility class.
>>   
>> ...
>> Now, with this PTF, the RACF authority check is performed using   
>> the ALIAS, PATH, or ALTERNATEINDEX name.  
>>  
>WTF!?  Does this mean that I will be able to DEFINE an ALIAS in a profile
>in which I have access, to a dataset to which I have less authority, thereby
>escalating my authority?  Will DEFINE ALIAS verify and enforce that I
>am not so escalating my authority to the RELATED data set?  If an administrator
>subsequently revokes my authority to the RELATED data set, will my authority
>to the ALIAS be correspondingly adjusted?
>
>???
>

No, it doesn't mean that.  Checking will still be done on the real name.  Read 
carefully about "the likely outcome".  

Best regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: OA49446 on RSU1603 - RACF / DFSMS change

[Pinnacle]

On 4/28/2016 1:41 PM, Tom Marchant wrote:

On Thu, 28 Apr 2016 12:28:58 -0500, Mike Schwab wrote:


I would think this would apply to a discrete authorization, without an
ending .**.
I. E. authorize DATA.SET.NAME instead of DATA.SET.NAME.**
Define DS(DATA.SET.NAME) would fail because of no authorization for
DATA.SET.NAME.DATA (optional DATA.SET.NAME.INDEX, DATA.SET.NAME.PATH,
etc) .


I think that what Gil is suggesting is something like this:

My userid is TOM. My colleague FRED has a data set that I don't have access
to, but I want access.
I create an alias for TOM.FRED.DATA.SET and relate it to FRED.DATA.SET. FRED
and TOM are both cataloged in the same user catalog.
Now the change in behavior gives me full access to FRED.DATA.SET through
because I own TOM.



I have a hard time buying that.  Wouldn't you need ALTER to FRED in 
order to RELATE an ALIAS?  If not, then IBM F'd up big time here, and 
you'd better enable that chicken switch.


Regards,
Tom Conley

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

Re: OA49446 on RSU1603 - RACF / DFSMS change

[Tom Marchant]

On Thu, 28 Apr 2016 12:28:58 -0500, Mike Schwab wrote:

>I would think this would apply to a discrete authorization, without an
>ending .**.
>I. E. authorize DATA.SET.NAME instead of DATA.SET.NAME.**
>Define DS(DATA.SET.NAME) would fail because of no authorization for
>DATA.SET.NAME.DATA (optional DATA.SET.NAME.INDEX, DATA.SET.NAME.PATH,
>etc) .

I think that what Gil is suggesting is something like this:

My userid is TOM. My colleague FRED has a data set that I don't have access 
to, but I want access. 
I create an alias for TOM.FRED.DATA.SET and relate it to FRED.DATA.SET. FRED 
and TOM are both cataloged in the same user catalog.
Now the change in behavior gives me full access to FRED.DATA.SET through 
because I own TOM.

-- 
Tom Marchant

>
>On Thu, Apr 28, 2016 at 12:22 PM, Paul Gilmartin
><000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
>> On Thu, 28 Apr 2016 12:01:17 -0500, Mark Zelden wrote:
>>
>>>I'm applying z/OS 2.1 RSU1603 and came across this PTF.   Is anyone running 
>>>with
>>>it in production and has it caused you any grief?   This seems to change a 
>>>behavior
>>>that has been around "forever", so it concerns me a bit even though there
>>>is a work around by defining a special RACF profile in the Facility class.
>>> ...
>>> Now, with this PTF, the RACF authority check is performed using
>>> the ALIAS, PATH, or ALTERNATEINDEX name.
>>>
>> WTF!?  Does this mean that I will be able to DEFINE an ALIAS in a profile
>> in which I have access, to a dataset to which I have less authority, thereby
>> escalating my authority?  Will DEFINE ALIAS verify and enforce that I
>> am not so escalating my authority to the RELATED data set?  If an 
>> administrator
>> subsequently revokes my authority to the RELATED data set, will my authority
>> to the ALIAS be correspondingly adjusted?
>>
>> ???
>>
>> -- gil
>>
>> --
>> For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
>
>
>--
>Mike A Schwab, Springfield IL USA
>Where do Forest Rangers go to get away from it all?
>
>--
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

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

Re: OA49446 on RSU1603 - RACF / DFSMS change

[Mike Schwab]

I would think this would apply to a discrete authorization, without an
ending .**.
I. E. authorize DATA.SET.NAME instead of DATA.SET.NAME.**
Define DS(DATA.SET.NAME) would fail because of no authorization for
DATA.SET.NAME.DATA (optional DATA.SET.NAME.INDEX, DATA.SET.NAME.PATH,
etc) .

On Thu, Apr 28, 2016 at 12:22 PM, Paul Gilmartin
<000433f07816-dmarc-requ...@listserv.ua.edu> wrote:
> On Thu, 28 Apr 2016 12:01:17 -0500, Mark Zelden wrote:
>
>>I'm applying z/OS 2.1 RSU1603 and came across this PTF.   Is anyone running 
>>with
>>it in production and has it caused you any grief?   This seems to change a 
>>behavior
>>that has been around "forever", so it concerns me a bit even though there
>>is a work around by defining a special RACF profile in the Facility class.
>> ...
>> Now, with this PTF, the RACF authority check is performed using
>> the ALIAS, PATH, or ALTERNATEINDEX name.
>>
> WTF!?  Does this mean that I will be able to DEFINE an ALIAS in a profile
> in which I have access, to a dataset to which I have less authority, thereby
> escalating my authority?  Will DEFINE ALIAS verify and enforce that I
> am not so escalating my authority to the RELATED data set?  If an 
> administrator
> subsequently revokes my authority to the RELATED data set, will my authority
> to the ALIAS be correspondingly adjusted?
>
> ???
>
> -- gil
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN



-- 
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

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

Re: OA49446 on RSU1603 - RACF / DFSMS change

[Paul Gilmartin]

On Thu, 28 Apr 2016 12:01:17 -0500, Mark Zelden wrote:

>I'm applying z/OS 2.1 RSU1603 and came across this PTF.   Is anyone running 
>with
>it in production and has it caused you any grief?   This seems to change a 
>behavior
>that has been around "forever", so it concerns me a bit even though there 
>is a work around by defining a special RACF profile in the Facility class. 
>  
> ...
> Now, with this PTF, the RACF authority check is performed using   
> the ALIAS, PATH, or ALTERNATEINDEX name.  
>  
WTF!?  Does this mean that I will be able to DEFINE an ALIAS in a profile
in which I have access, to a dataset to which I have less authority, thereby
escalating my authority?  Will DEFINE ALIAS verify and enforce that I
am not so escalating my authority to the RELATED data set?  If an administrator
subsequently revokes my authority to the RELATED data set, will my authority
to the ALIAS be correspondingly adjusted?

???

-- gil

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

OA49446 on RSU1603 - RACF / DFSMS change

[Mark Zelden]

I'm applying z/OS 2.1 RSU1603 and came across this PTF.   Is anyone running with
it in production and has it caused you any grief?   This seems to change a 
behavior
that has been around "forever", so it concerns me a bit even though there 
is a work around by defining a special RACF profile in the Facility class.


++ HOLD(UA80146) SYS FMID(HDZ2210) REASON(ACTION) DATE(15356)  
   COMMENT 
(  
 * FUNCTION AFFECTED: DFSMS   (OA49446) *  
   
 * DESCRIPTION  : Update security definition*  
   
 * TIMING   : Pre-APPLY *  
   
   
 This service requires certain actions to be performed before the  
 PTF is applied. All the required actions appear in this PTF   
 cover letter. 
   
 RACF authorization checking is changed by this PTF for ALIASes,   
 PATHs, and ALTERNATEINDEXes. Before, if the ALIAS was for a   
 generation data set or a nonVSAM data set, the generation data
 set name or the nonVSAM name was used for the RACF authority  
 check; for PATH and ALTERNATEINDEX, the associated CLUSTER
 name was used.
   
 Now, with this PTF, the RACF authority check is performed using   
 the ALIAS, PATH, or ALTERNATEINDEX name.  
   
 The required actions are: 
   
 1. Review the RACF profiles for names involving ALIASes, PATHs
and ALTERNATEINDEXes. Depending on your naming conventions,
no change may be necessary. The likely outcome if your ALIAS,  
PATH or ALTERNATEINDEX is not covered by an existing profile,  
will be a RACF failure due to insufficient authority. If this  
is the case, add or change RACF profiles for ALIASes, PATHs
and ALTERNATEINDEXes to grant appropriate RACF authority.  
   
 2. If your installation cannot immediately tolerate the change
in RACF authority checking, the old method of checking can be  
reinstated by defining a facility class profile with the name  
of STGADMIN.IGG.CATALOG.SECURITY.CHANGE and giving the user
READ authority to that facility class.).


  
Best regards,

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
Systems Programming expert at http://search390.techtarget.com/ateExperts/


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