RACF and Member Level Protection

[Steven Conway]

CA Top Secret supports member level security in a PDS or PDSE, allowing a 
variance of access authority to users of the dataset versus an individual 
member.  We have that plugged in.  A few months ago, there was a problem 
that led me to open an issue with Top Secret to verify what they do, and 
with another vendor to determine why their program hung on failed access 
at the member level.

The other vendor runs RACF, and today told me his RACF Admin says RACF 
does not support member level protection.  Not being a RACF guy, I went to 
the books.  Neither the Admin Guide or User's Guide yielded anything to 
searches on 'member protection' or 'member level protection'. 

I would have sworn all three major security packages supported this 
function, but I can't find anything to verify that. 

Will someone who knows the true scoop hook me up with either "No, RACF 
doesn't do that" or "Hey, dope.  Look at ".


Cheers,,,Steve

Steve Conway
Lead Systems Programmer
Information Systems & Services Division
Computer & Network Operations
Phone:   (703) 450-3156
Fax:(703) 450-3197

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

Re: RACF and Member Level Protection

[Tim Hare]

RACF does not protect individual members - and I don't see how Top Secret 
does either.   SAF is called from OPEN, which is a dataset-level, not 
member-level function.  Top Secret could of course intercept BLDL and STOW 
to provide some sort of member security - but I think those intercepts 
would have a performance penalty given all of the PDS searches in an MVS 
shop, and of course there are always programs which don't bother with BLDL 
to worry about.

I am not a RACF "expert" (I'll leave that to Walt and Russ and others) but 
reasoning tells me member protection can't be 100% - too many ways around 
it.

Tim Hare
Senior Systems Programmer
Florida Department of Transportation
(850) 414-4209

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

Re: RACF and Member Level Protection

[R.S.]

Steve,
RACF does not support member-level protection. It was widely discussed 
several times on RACF-L. IBM claims such protection can be circumvented 
(which I agree), however it's not easy (and maybe that's why it would be 
worth to be implemented).


An exemption from Security Administrator Guide:
1.  All of the members of a partitioned data set are protected by one 
profile, the profile that protects the data set.


(chapter 6.1.5.3 Choosing between Discrete and Generic Data Set Profiles)

HTH
--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sd Rejonowy dla m. st. Warszawy 
XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, 
nr rejestru przedsibiorców KRS 025237

NIP: 526-021-50-88
Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci 
opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego 
podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 
r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 
z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone.

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

Re: RACF and Member Level Protection

[Anthony Saul Babonas]

ToP Secret can and does do this.  It's a bit kludgey but it does work as
advertised.  For us security folks it's a bother.   

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf
Of Tim Hare
Sent: Wednesday, April 04, 2007 2:48 PM
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: RACF and Member Level Protection

RACF does not protect individual members - and I don't see how Top Secret 
does either.   SAF is called from OPEN, which is a dataset-level, not 
member-level function.  Top Secret could of course intercept BLDL and STOW
to provide some sort of member security - but I think those intercepts would
have a performance penalty given all of the PDS searches in an MVS shop, and
of course there are always programs which don't bother with BLDL to worry
about.

I am not a RACF "expert" (I'll leave that to Walt and Russ and others) but
reasoning tells me member protection can't be 100% - too many ways around
it.

Tim Hare
Senior Systems Programmer
Florida Department of Transportation
(850) 414-4209

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

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

Re: RACF and Member Level Protection

[Walter Farrell]

On 4/4/2007 3:33 PM, Steven Conway wrote:
CA Top Secret supports member level security in a PDS or PDSE, allowing a 
variance of access authority to users of the dataset versus an individual 
member.  We have that plugged in.  A few months ago, there was a problem 
that led me to open an issue with Top Secret to verify what they do, and 
with another vendor to determine why their program hung on failed access 
at the member level.


The other vendor runs RACF, and today told me his RACF Admin says RACF 
does not support member level protection.  Not being a RACF guy, I went to 
the books.  Neither the Admin Guide or User's Guide yielded anything to 
searches on 'member protection' or 'member level protection'. 

I would have sworn all three major security packages supported this 
function, but I can't find anything to verify that. 

Will someone who knows the true scoop hook me up with either "No, RACF 
doesn't do that" or "Hey, dope.  Look at ".


It is more appropriate to say that z/OS does not support member level 
protection.  As the resource manager for data sets, it would be up to 
DFP or DFSMS to call the security product to make security checks for 
members, and DFP/DFSMS does not do so.


Any security product that provides such protection has therefore had to 
modify z/OS in some way in order to do so.  RACF does not make such 
modifications to other components of z/OS.


If you would like member level protection supported natively in z/OS, 
please submit a requirement via SHARE or directly via someone on your 
IBM account team, and ask DFSMS for that support.


Walt Farrell, CISSP
z/OS Security Design, IBM

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

Re: RACF and Member Level Protection

[Ed Gould]

On Apr 4, 2007, at 2:48 PM, Tim Hare wrote:



I am not a RACF "expert" (I'll leave that to Walt and Russ and  
others) but
reasoning tells me member protection can't be 100% - too many ways  
around

it.


I agree there are just too many ways around it. You *might* be able  
to do via "normal" (BLDL SCRATCH etc) but after that there are a few  
ways around it.


Ed



Tim Hare
Senior Systems Programmer
Florida Department of Transportation
(850) 414-4209

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


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

Re: RACF and Member Level Protection

[John P Kalinich]

Tim Hare of the IBM Mainframe Discussion List  wrote
on 04/04/2007 02:48:09 PM:

> RACF does not protect individual members - and I don't see how Top Secret

> does either.   SAF is called from OPEN, which is a dataset-level, not
> member-level function.  Top Secret could of course intercept BLDL and
STOW
> to provide some sort of member security - but I think those intercepts
> would have a performance penalty given all of the PDS searches in an MVS
> shop, and of course there are always programs which don't bother with
BLDL
> to worry about.
>
> I am not a RACF "expert" (I'll leave that to Walt and Russ and others)
but
> reasoning tells me member protection can't be 100% - too many ways around

> it.

I went to an ACF2 presentation in the late 1990's about member level
protection, and IIRC, ACF2 checks the CCHHR address somewhere in the EXCP
process.

Regards,
John Kalinich
Computer Sciences Corp

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

Re: RACF and Member Level Protection

[Rob Scott]

>I went to an ACF2 presentation in the late 1990's about member level
protection, and IIRC, ACF2 checks the CCHHR address somewhere in the
EXCP process.
I imagine those developers had some "fun" when PDS-Es were
introduced

IMHO - this sounds like too much "brave and clever" code. 


Rob Scott
Rocket Software, Inc
275 Grove Street
Newton, MA 02466
617-614-2305
[EMAIL PROTECTED]
http://www.rs.com/portfolio/mxi_g2

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of John P Kalinich
Sent: 05 April 2007 08:11
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: RACF and Member Level Protection

Tim Hare of the IBM Mainframe Discussion List 
wrote on 04/04/2007 02:48:09 PM:

> RACF does not protect individual members - and I don't see how Top 
> Secret

> does either.   SAF is called from OPEN, which is a dataset-level, not
> member-level function.  Top Secret could of course intercept BLDL and
STOW
> to provide some sort of member security - but I think those intercepts

> would have a performance penalty given all of the PDS searches in an 
> MVS shop, and of course there are always programs which don't bother 
> with
BLDL
> to worry about.
>
> I am not a RACF "expert" (I'll leave that to Walt and Russ and others)
but
> reasoning tells me member protection can't be 100% - too many ways 
> around

> it.

I went to an ACF2 presentation in the late 1990's about member level
protection, and IIRC, ACF2 checks the CCHHR address somewhere in the
EXCP process.

Regards,
John Kalinich
Computer Sciences Corp

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

Re: RACF and Member Level Protection

[John P Kalinich]

Rob Scott of the IBM Mainframe Discussion List  wrote
on 04/05/2007 08:26:52 AM:

>>I went to an ACF2 presentation in the late 1990's about member level
>> protection, and IIRC, ACF2 checks the CCHHR address somewhere in the
>> EXCP process.

> I imagine those developers had some "fun" when PDS-Es were
> introduced




O  PDS/E data sets are not under member-level controls.

http://bama.ua.edu/archives/ibm-main.html

Re: RACF and Member Level Protection

[Rob Scott]

>PDS/E data sets are not under member-level controls.

Surely that is a very good reason *not* to have member level controls -
regardless of the vendor software having its (as CC would put it) "hands
down the pants" of EXCP, BLDL and STOW.   


Rob Scott
Rocket Software, Inc
275 Grove Street
Newton, MA 02466
617-614-2305
[EMAIL PROTECTED]
http://www.rs.com/portfolio/mxi_g2

-Original Message-
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On
Behalf Of John P Kalinich
Sent: 05 April 2007 09:32
To: IBM-MAIN@BAMA.UA.EDU
Subject: Re: RACF and Member Level Protection

Rob Scott of the IBM Mainframe Discussion List 
wrote on 04/05/2007 08:26:52 AM:

>>I went to an ACF2 presentation in the late 1990's about member level  
>>protection, and IIRC, ACF2 checks the CCHHR address somewhere in the  
>>EXCP process.

> I imagine those developers had some "fun" when PDS-Es were 
> introduced




O  PDS/E data sets are not under member-level controls.

http://bama.ua.edu/archives/ibm-main.html

Re: RACF and Member Level Protection

[Shane]

On Wed, 2007-04-04 at 18:15 -0400, Walter Farrell wrote:

> If you would like member level protection supported natively in z/OS, 
> please submit a requirement ... and ask DFSMS for that support.

Says it all really.
Get it done at the "lowest" component, not the highest - no doubt gil is
quietly cheering the concept.

Shane ...

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

Re: RACF and Member Level Protection

[Shmuel Metz (Seymour J.)]

In
<[EMAIL PROTECTED]>,
on 04/04/2007
   at 03:32 PM, Steven Conway <[EMAIL PROTECTED]> said:

>CA Top Secret supports member level security in a PDS or PDSE,
>allowing a  variance of access authority to users of the dataset
>versus an individual  member.  We have that plugged in.  A few months
>ago, there was a problem  that led me to open an issue with Top
>Secret to verify what they do, and  with another vendor to determine
>why their program hung on failed access  at the member level.

The first question is what they mean by "supports member level
security in a PDS or PDSE." Are they talking about checking access
only on OPEN, or also on FIND and STOW? It would be trivial to
circumvent controls on FIND for PDS.

>The other vendor runs RACF, and today told me his RACF Admin says
>RACF does not support member level protection.

Correct; if you want to submit a requirement for that facility, spell
out in detail what you want protected.

-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: RACF and Member Level Protection

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 04/04/2007
   at 10:03 PM, "R.S." <[EMAIL PROTECTED]> said:

>RACF does not support member-level protection. It was widely
>discussed  several times on RACF-L. IBM claims such protection can be
>circumvented  (which I agree), however it's not easy

Nonsense! It would be trivial to circumvent it, at least for PDS. PDSE
might be more secure.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: RACF and Member Level Protection

[Walt Farrell]

On Thu, 5 Apr 2007 10:50:12 -0300, Shmuel Metz (Seymour J.)
<[EMAIL PROTECTED]> wrote:

>In <[EMAIL PROTECTED]>, on 04/04/2007
>   at 10:03 PM, "R.S." <[EMAIL PROTECTED]> said:
>
>>RACF does not support member-level protection. It was widely
>>discussed  several times on RACF-L. IBM claims such protection can be
>>circumvented  (which I agree), however it's not easy
>
>Nonsense! It would be trivial to circumvent it, at least for PDS. 

I can envision implementations that would make circumvention non-trivial,
Shmuel.

However, they would involve changes in EXCP processing for all channel
programs addressed to any member-protected PDS.  The change would examine
all CCWs to make sure the channel program was going to process a member the
user was allowed to use.  

I can also see that approach as having some (large?) performance impact. 
But I don't see a simple way to circumvent it.

   Walt Farrell, CISSP
   z/OS Security Design

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

Re: RACF and Member Level Protection

[Rick Fochtman]

I agree there are just too many ways around it. You *might* be able  to 
do via "normal" (BLDL SCRATCH etc) but after that there are a few  ways 
around it.

---
If a user has UPDATE authority to a PDS, he can scratch a member using 
STOW, with the DELETE operand. Member-level protection won't exist until 
there are mechanisms in the BSAM/BPAM access code, as well as STOW, BLDL 
and FIND. And EXCP/XDAP access brings up a whole new set of issues.


I'm not holding my breath; the overhead would be staggering.

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

Re: RACF and Member Level Protection

[Knutson, Sam]

Hi,

It seems like marketing or SHARE requirements to IBM for DFSMSdfp to
support member level protection in just PDSE data sets might be in
order.   PDSE code is newer and probably less costly and lower risk for
IBM to insert new function into.  PDSE internal structure is not known
or used by customers and vendors so lower level access should be less of
an issue.  PDSE access is only through known interfaces.   PDSE is
actively being enhanced.  If we want to get this funded as a line item
for a z/OS release then we need to start asking.  If IBM satisfied
existing requirements only for DSORG PDSE it seems like that would be a
reasonable response.

My .02  

Best Regards, 

Sam Knutson, GEICO 
Performance and Availability Management 
mailto:[EMAIL PROTECTED] 
(office)  301.986.3574 

"Think big, act bold, start simple, grow fast..."

-Original Message-
Subject: Re: RACF and Member Level Protection

Rob Scott of the IBM Mainframe Discussion List 
wrote on 04/05/2007 08:26:52 AM:

>>I went to an ACF2 presentation in the late 1990's about member level  
>>protection, and IIRC, ACF2 checks the CCHHR address somewhere in the  
>>EXCP process.

> I imagine those developers had some "fun" when PDS-Es were 
> introduced




O  PDS/E data sets are not under member-level controls.

http://bama.ua.edu/archives/ibm-main.html

Re: RACF and Member Level Protection

[Binyamin Dissen]

On Thu, 5 Apr 2007 10:54:24 -0500 Walt Farrell <[EMAIL PROTECTED]> wrote:

:>On Thu, 5 Apr 2007 10:50:12 -0300, Shmuel Metz (Seymour J.)
:><[EMAIL PROTECTED]> wrote:

:>>In <[EMAIL PROTECTED]>, on 04/04/2007
:>>   at 10:03 PM, "R.S." <[EMAIL PROTECTED]> said:

:>>>RACF does not support member-level protection. It was widely
:>>>discussed  several times on RACF-L. IBM claims such protection can be
:>>>circumvented  (which I agree), however it's not easy

:>>Nonsense! It would be trivial to circumvent it, at least for PDS. 

:>I can envision implementations that would make circumvention non-trivial,
:>Shmuel.

:>However, they would involve changes in EXCP processing for all channel
:>programs addressed to any member-protected PDS.  The change would examine
:>all CCWs to make sure the channel program was going to process a member the
:>user was allowed to use.  

:>I can also see that approach as having some (large?) performance impact. 
:>But I don't see a simple way to circumvent it.

If done properly, there is no way to circumvent.

The CCWs would be examined to make sure that they do not modify themselves and
the CCHHRs verified to make sure that they are in the accessible members.

It can be done more cheaply by not allowing a single CCW chain to access
multiple members.

The real performance impact would be to programs that do multiple member
processing, i.e., IEBCOPY, which one could legitimately argue should not be
done by a user that does not have full access to the PDS. 

If the product requires explicit DSNAME(MEMBER) and not allow access out of
the member the processing cost is not too bad.

--
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com

Director, Dissen Software, Bar & Grill - Israel


Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.

I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: RACF and Member Level Protection

[Ted MacNEIL]

>PDSE code is newer and probably less costly and lower risk for IBM to insert 
>new function into.

I wouldn't think so.
PDSE is so buggy right now.
I wouldn't want anybody adding new function into it until the old function is 
fixed.

I do have a question, though:

Why do YOU want member-level security.
Just move the members to another (protected) library.

-
Too busy driving to stop for gas!  

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

Re: RACF and Member Level Protection

[R.S.]

Ted MacNEIL wrote:

PDSE code is newer and probably less costly and lower risk for IBM to insert 
new function into.


I wouldn't think so.
PDSE is so buggy right now.
I wouldn't want anybody adding new function into it until the old function is 
fixed.

I do have a question, though:

Why do YOU want member-level security.
Just move the members to another (protected) library.


This is the IBM-advertised way. In many cases it is feasible, but it can be 
unconvenient.

--
Radoslaw Skorupka
Lodz, Poland


--
BRE Bank SA
ul. Senatorska 18
00-950 Warszawa
www.brebank.pl

Sąd Rejonowy dla m. st. Warszawy 
XII Wydział Gospodarczy Krajowego Rejestru Sądowego, 
nr rejestru przedsiębiorców KRS 025237

NIP: 526-021-50-88
Według stanu na dzień 01.01.2007 r. kapitał zakładowy BRE Banku SA (w całości 
opłacony) wynosi 118.064.140 zł. W związku z realizacją warunkowego 
podwyższenia kapitału zakładowego, na podstawie uchwał XVI WZ z dnia 21.05.2003 
r., kapitał zakładowy BRE Banku SA może ulec podwyższeniu do kwoty 118.760.528 
zł. Akcje w podwyższonym kapitale zakładowym będą w całości opłacone.

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

Re: RACF and Member Level Protection

[Ted MacNEIL]

>> Why do YOU want member-level security.
>> Just move the members to another (protected) library.

>This is the IBM-advertised way. In many cases it is feasible, but it can be 
>unconvenient.

Inconvenient, yes.

But, so is lousy performance and introducing more bugs to an already buggy 
product (PDSE).

-
Too busy driving to stop for gas!  

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

Re: RACF and Member Level Protection

[Walt Farrell]

On Thu, 5 Apr 2007 18:48:49 +, Ted MacNEIL <[EMAIL PROTECTED]> wrote:
>I do have a question, though:
>
>Why do YOU want member-level security.
>Just move the members to another (protected) library.
>

That can work in some very restrictive cases, Ted, but not all cases.

Consider, for example, using a concatenation for SYS1.PARMLIB, say you have
SYS1.PARMLIB.A and SYS1.PARMLIB.B, concatenated in that order.

Further, suppose that user A should have UPDATE authority to members A1, A2,
and A3, while member B should have UPDATE access to members B1, B2, and B3.

Yes, you could put A1, A2, and A3 in SYS1.PARMLIB.A and give user A access
to only that data set.  And you could put B1, B2, and B3 in SYS1.PARMLIB.B
and give user B access to only that data set.

Problem: What stops user A from creating B1 in SYS1.PARMLIB.A?

  Walt

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

Re: RACF and Member Level Protection

[Steven Conway]

Shmuel,
 
The first question is what they mean by "supports member level
security in a PDS or PDSE." Are they talking about checking access
only on OPEN, or also on FIND and STOW? It would be trivial to
circumvent controls on FIND for PDS.

I don't know the particulars of what, precisely, Top Secret checks.  Top 
Secret allows a security admin to restrict access to certain members 
within a PDS, while allowing access to others.  When it checks, how it 
checks, what it does when checks fail or succeed, is not my concern at 
this time. 

Correct; if you want to submit a requirement for that facility, spell
out in detail what you want protected.

I didn't say I wanted RACF to do anything.  As stated in my original post, 
I wanted to know if it offered the member level protection functionality.


Cheers,,,Steve

Steve Conway
Lead Systems Programmer
Information Systems & Services Division
Computer & Network Operations
Phone:   (703) 450-3156
Fax:(703) 450-3197

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

Re: RACF and Member Level Protection

[Paul Gilmartin]

In a recent note, Walt Farrell said:

> Date: Fri, 6 Apr 2007 10:12:02 -0500
> 
> >Just move the members to another (protected) library.
> 
> That can work in some very restrictive cases, Ted, but not all cases.
> 
Since BPAM now supports read access to HFS directories (barring
those utilities that balk at this), might an alternative be to
use HFS rather than PDS, and protect the members with ACLs?  If
so, it's a solved problem.

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

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

Re: RACF and Member Level Protection

[Steven Conway]

Trying again, with a bit of formatting this time:

Shmuel,
 
> The first question is what they mean by "supports member level
> security in a PDS or PDSE." Are they talking about checking access
> only on OPEN, or also on FIND and STOW? It would be trivial to
> circumvent controls on FIND for PDS.

I don't know the particulars of what, precisely, Top Secret checks.  Top 
Secret allows a security admin to restrict access to certain members 
within a PDS, while allowing access to others.  When it checks, how it 
checks, what it does when checks fail or succeed, is not my concern at 
this time. 

> Correct; if you want to submit a requirement for that facility, spell
> out in detail what you want protected.

I didn't say I wanted RACF to do anything.  As stated in my original post, 

I wanted to know if it offered the member level protection functionality.


Cheers,,,Steve

Steve Conway
Lead Systems Programmer
Information Systems & Services Division
Computer & Network Operations
Phone:   (703) 450-3156
Fax:(703) 450-3197

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

Re: RACF and Member Level Protection

[Edward Jaffe]

Paul Gilmartin wrote:

Since BPAM now supports read access to HFS directories (barring
those utilities that balk at this), might an alternative be to
use HFS rather than PDS, and protect the members with ACLs?  If
so, it's a solved problem.
  


What about write access?

--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

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

Re: RACF and Member Level Protection

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe
> Sent: Monday, April 09, 2007 12:25 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: RACF and Member Level Protection
> 
> 
> Paul Gilmartin wrote:
> > Since BPAM now supports read access to HFS directories (barring
> > those utilities that balk at this), might an alternative be to
> > use HFS rather than PDS, and protect the members with ACLs?  If
> > so, it's a solved problem.
> >   
> 
> What about write access?
> 
> -- 
> Edward E Jaffe

What about WRITE access? A UNIX file has three sets of three accesses:

READ FOR OWNER
WRITE FOR OWNER
EXECUTE FOR OWNER

READ FOR GROUP
WRITE FOR GROUP
EXECUTE FOR GROUP

READ FOR OTHER
WRITE FOR OTHER
EXECUTE FOR OTHER

With ACLs, you can even do more security.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

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

Re: RACF and Member Level Protection

[Walter Farrell]

On 4/9/2007 1:25 PM, Edward Jaffe wrote:

Paul Gilmartin wrote:

Since BPAM now supports read access to HFS directories (barring
those utilities that balk at this), might an alternative be to
use HFS rather than PDS, and protect the members with ACLs?  If
so, it's a solved problem.
  


What about write access?



That gets back to the question about what one really means by member 
protection, I think.


Many times when I've heard the question it really has meant a desire to 
control who can update which members.  If all the readers of the PDS 
support the simulation of a PDS by a UNIX directory, then you could 
(perhaps) simply tell all the updaters that they needed to update UNIX 
files rather than updating a PDS directory.


I can envision a lot of cases that would not handle, of course.

Walt

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

Re: RACF and Member Level Protection

[Edward Jaffe]

McKown, John wrote:

What about WRITE access? A UNIX file has three sets of three accesses:

READ FOR OWNER
WRITE FOR OWNER
EXECUTE FOR OWNER

READ FOR GROUP
WRITE FOR GROUP
EXECUTE FOR GROUP

READ FOR OTHER
WRITE FOR OTHER
EXECUTE FOR OTHER

With ACLs, you can even do more security.
  


That's all well and good. But, the suggestion was to use BPAM emulation 
in HFS to address the need for member level security. But, that 
emulation provides read access only.


--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/

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

Re: RACF and Member Level Protection

[McKown, John]

> -Original Message-
> From: IBM Mainframe Discussion List 
> [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe
> Sent: Tuesday, April 10, 2007 6:36 PM
> To: IBM-MAIN@BAMA.UA.EDU
> Subject: Re: RACF and Member Level Protection
> 



> 
> That's all well and good. But, the suggestion was to use BPAM 
> emulation 
> in HFS to address the need for member level security. But, that 
> emulation provides read access only.
> 
> -- 
> Edward E Jaffe

Ah. My bad. I misunderstood your comment.

--
John McKown
Senior Systems Programmer
HealthMarkets
Keeping the Promise of Affordable Coverage
Administrative Services Group
Information Technology

The information contained in this e-mail message may be privileged
and/or confidential.  It is for intended addressee(s) only.  If you are
not the intended recipient, you are hereby notified that any disclosure,
reproduction, distribution or other use of this communication is
strictly prohibited and could, in certain circumstances, be a criminal
offense.  If you have received this e-mail in error, please notify the
sender by reply and delete this message without copying or disclosing
it. 

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

Re: RACF and Member Level Protection

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 04/05/2007
   at 10:54 AM, Walt Farrell <[EMAIL PROTECTED]> said:

>However, they would involve changes in EXCP processing for all
>channel programs addressed to any member-protected PDS.  The change
>would examine all CCWs to make sure the channel program was going to
>process a member the user was allowed to use.

That would require reading the entire member in order to determine
where to set the limits.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: RACF and Member Level Protection

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 04/05/2007
   at 09:29 PM, Binyamin Dissen <[EMAIL PROTECTED]> said:

>The real performance impact would be to programs that do multiple
>member processing,

No. It would have to read the entire member in order to determine
where to set the limits, even for single member processing.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: RACF and Member Level Protection

[Paul Gilmartin]

In a recent note, "Shmuel Metz (Seymour J.)" said:

> Date: Tue, 24 Apr 2007 15:56:06 -0300
> 
> >channel programs addressed to any member-protected PDS.  The change
> >would examine all CCWs to make sure the channel program was going to
> >process a member the user was allowed to use.
> 
> That would require reading the entire member in order to determine
> where to set the limits.
> 
Not if the changes also retained information about where each
member ends.  After all, we're talking about massive changes
to PDS processing.  Why stop halfway?

I believe it's agreed that there are ISV products that provide
member-level protection.  How do they do it?

I believe I've heard also of ISV products that track unused
space in PDSes.  How do they do that?  Knowing where each
unused area begins would be sufficient information to deduce
where any member ends (the upper limit).

-- gil
-- 
StorageTek
INFORMATION made POWERFUL

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

Re: RACF and Member Level Protection

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 04/24/2007
   at 03:18 PM, Paul Gilmartin <[EMAIL PROTECTED]> said:

>Not if the changes also retained information about where each member
>ends.

Are you taking about modifying the directory structure? If not, they
have to find it before they can retain it. If so, they'd have to
modify IEBCOPY compress processing, and they'd break every program
that reads the directory.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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

Re: RACF and Member Level Protection

[Tom Marchant]

On Wed, 25 Apr 2007 11:13:15 -0300, Shmuel Metz (Seymour J.) wrote:

>In <[EMAIL PROTECTED]>, on 04/24/2007
>   at 03:18 PM, Paul Gilmartin <[EMAIL PROTECTED]> said:
>
>>Not if the changes also retained information about where each member
>>ends.
>
>Are you taking about modifying the directory structure? If not, they
>have to find it before they can retain it. If so, they'd have to
>modify IEBCOPY compress processing, and they'd break every program
>that reads the directory.

Probably not.  There is already space in the directory for "user data" and
IEBCOPY can already deal with that just fine.  They would, however,
break every program that uses the user data area in the directory entries.

-- 
Tom Marchant

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

Re: RACF and Member Level Protection

[Shmuel Metz (Seymour J.)]

In <[EMAIL PROTECTED]>, on 04/25/2007
   at 01:33 PM, Tom Marchant <[EMAIL PROTECTED]> said:

>Probably not.  There is already space in the directory for "user
>data" and IEBCOPY can already deal with that just fine.  They would,
>however, break every program that uses the user data area in the
>directory entries.


That includes breaking the Binder, Fetch, the Linkage Editor and the
Loader.
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

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