Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
RACF command
524 views
Skip to first unread message
Bodoh John Robert
May 21, 2012, 2:00:08 PM5/21/12
to
All,
Where I work, we have to answer a report of RACF authorization violations that we made. That is, if I try to access a data set and I am not authorized, not only do I get the RACF error messages but my user ID appears on a list for which I have to answer why I was trying to access the data set.
I wrote a simple REXX EXEC that is supposed to tell me if I am authorized to access any data set. It uses the high level qualifier to look up the profiles for that qualifier. It scans each profile, listing the data sets protected by that profile. If the data set that I am checking on is in the list, I display the access authority.
It works pretty good for user data sets when there aren't a whole bunch of data sets. However, if there are a whole bunch of data sets or the high level qualifier is that of some system data set, it takes a long time to process.
I tried looking for a RACF command that I can pass a data set name and it will return the access authorization but I cannot find any such command.
Is there such a command?
John
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
Where I work, we have to answer a report of RACF authorization violations that we made. That is, if I try to access a data set and I am not authorized, not only do I get the RACF error messages but my user ID appears on a list for which I have to answer why I was trying to access the data set.
I wrote a simple REXX EXEC that is supposed to tell me if I am authorized to access any data set. It uses the high level qualifier to look up the profiles for that qualifier. It scans each profile, listing the data sets protected by that profile. If the data set that I am checking on is in the list, I display the access authority.
It works pretty good for user data sets when there aren't a whole bunch of data sets. However, if there are a whole bunch of data sets or the high level qualifier is that of some system data set, it takes a long time to process.
I tried looking for a RACF command that I can pass a data set name and it will return the access authorization but I cannot find any such command.
Is there such a command?
John
----------------------------------------------------------------------
For TSO-REXX subscribe / signoff / archive access instructions,
send email to LIST...@VM.MARIST.EDU with the message: INFO TSO-REXX
Paul Gilmartin
May 21, 2012, 2:31:46 PM5/21/12
to
On May 21, 2012, at 11:59, Bodoh John Robert wrote:
>
> Where I work, we have to answer a report of RACF authorization violations that we made. That is, if I try to access a data set and I am not authorized, not only do I get the RACF error messages but my user ID appears on a list for which I have to answer why I was trying to access the data set.
>
Walt Farrell, IBM-MAIN's RACF guru emeritus has asserted that
>
> Where I work, we have to answer a report of RACF authorization violations that we made. That is, if I try to access a data set and I am not authorized, not only do I get the RACF error messages but my user ID appears on a list for which I have to answer why I was trying to access the data set.
>
this is an exercise in futility:
o The rules are too complicated to make such an outboard test
practical.
To which I'll add:
o There's a timing window: the rules may change between your
probe and the access attempt.
o Your security admins are misguided. Any attempt to determine
a priori whether the user has permissions should be treated as
an incident as serious as the attempt to access.
-- gil
Bodoh John Robert
May 21, 2012, 4:26:14 PM5/21/12
to
Walt,
I must disagree:
* I don't understand why the rules would be too complicated: "Here's a data set RACF, tell me what my access permission is."
* Even if the rules change between the time of the query and the time of access, the likelihood of that happening are very remote. 99% of the time it will work. For the 1% of the times it won't work is quite adequate. At least the report will be small enough that it won't ruffle any feathers.
* I also think that trying to access a data set is worse than checking to see if you can access it. It would sound as though even knowing of the data set's existence should be treated as a security violation. Do they protect against that? Is some cases, a user may need to access a particular data set as part of his/her job. Checking on your ability to access it first would enable one to avoid the violation report. How would you recommend avoiding the RACF violation report?
John
I must disagree:
* I don't understand why the rules would be too complicated: "Here's a data set RACF, tell me what my access permission is."
* Even if the rules change between the time of the query and the time of access, the likelihood of that happening are very remote. 99% of the time it will work. For the 1% of the times it won't work is quite adequate. At least the report will be small enough that it won't ruffle any feathers.
* I also think that trying to access a data set is worse than checking to see if you can access it. It would sound as though even knowing of the data set's existence should be treated as a security violation. Do they protect against that? Is some cases, a user may need to access a particular data set as part of his/her job. Checking on your ability to access it first would enable one to avoid the violation report. How would you recommend avoiding the RACF violation report?
John
Jeremy Nicoll - ls mainframes
May 21, 2012, 5:24:12 PM5/21/12
to
Bodoh John Robert <John.Rob...@IRS.GOV> wrote:
> * I also think that trying to access a data set is worse than
> checking to see if you can access it.
You're looking at things from the point of view of someone who's planning to
> * I also think that trying to access a data set is worse than
> checking to see if you can access it.
access the dataset anyway.
Data security people look at the problem from the pov of using the
violations to find out if someone is trying to spot any gaps in the rules to
access data they shouldn't, not just the rule for the specific dataset you
care about in this paerticular case. If there was a way to test "what
if..." some people would use it to look for anything (they'd no need to see
for their job) to peek inside it.
Similar questions asked about ACF2 produced the same answers... the data
security people want the violations to happen so they can see what people
are exploring.
> Is some cases, a user may need to access a particular data set as part of
> his/her job. Checking on your ability to access it first would enable one
> to avoid the violation report.
temporary access granted.
--
Jeremy C B Nicoll - my opinions are my own.
Styles, Andy , SMS - Scheduling and SCM Infrastructure Support
May 21, 2012, 6:16:34 PM5/21/12
to
Doesn't the LD command show you your access to a dataset (and the profile that covers it actually)? Okay, you've got to parse the output, but it does tell you want you want to know..
LD DA('ENDEVOR.TEST.DATASET') GEN ALL
INFORMATION FOR DATASET ENDEVOR.* (G)
LEVEL OWNER UNIVERSAL ACCESS WARNING ERASE
----- -------- ---------------- ------- -----
70 ENDEVOR READ NO NO
AUDITING
--------
FAILURES(READ)
NOTIFY
--------
NO USER TO BE NOTIFIED
YOUR ACCESS CREATION GROUP DATASET TYPE
----------- -------------- ------------
ALTER XXXXXXXX NON-VSAM
Moving onto the reporting side of things, why are they interested to know what people are exploring? Surely if RACF prevents them, that's a good thing, and they've got their rules set up properly (in theory). What about where the rules aren't right, but people can access data they shouldn't be able to? I don't believe someone is going to review a report of successful accesses, but that's just as important as what people can't access..
Andy Styles
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Jeremy Nicoll - ls mainframes
Sent: 21 May 2012 22:18
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] RACF command
Lloyds TSB Bank plc. Registered Office: 25 Gresham Street, London EC2V 7HN. Registered in England and Wales, number 2065. Telephone: 020 7626 1500.
Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland, number 327000. Telephone: 0870 600 5000
Lloyds TSB Scotland plc. Registered Office: Henry Duncan House, 120 George Street, Edinburgh EH2 4LH. Registered in Scotland, number 95237. Telephone: 0131 225 4555.
Cheltenham & Gloucester plc. Registered Office: Barnett Way, Gloucester GL4 3RL. Registered in England and Wales, number 2299428. Telephone: 01452 372372.
Lloyds TSB Bank plc, Lloyds TSB Scotland plc, Bank of Scotland plc and Cheltenham & Gloucester plc are authorised and regulated by the Financial Services Authority.
Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester Savings is a division of Lloyds TSB Bank plc.
HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland, number 218813. Telephone: 0870 600 5000
Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland, number 95000. Telephone: 0131 225 4555
This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments.
Telephone calls may be monitored or recorded.
LD DA('ENDEVOR.TEST.DATASET') GEN ALL
INFORMATION FOR DATASET ENDEVOR.* (G)
LEVEL OWNER UNIVERSAL ACCESS WARNING ERASE
----- -------- ---------------- ------- -----
70 ENDEVOR READ NO NO
AUDITING
--------
FAILURES(READ)
NOTIFY
--------
NO USER TO BE NOTIFIED
YOUR ACCESS CREATION GROUP DATASET TYPE
----------- -------------- ------------
ALTER XXXXXXXX NON-VSAM
Moving onto the reporting side of things, why are they interested to know what people are exploring? Surely if RACF prevents them, that's a good thing, and they've got their rules set up properly (in theory). What about where the rules aren't right, but people can access data they shouldn't be able to? I don't believe someone is going to review a report of successful accesses, but that's just as important as what people can't access..
Andy Styles
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Jeremy Nicoll - ls mainframes
Sent: 21 May 2012 22:18
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] RACF command
Bank of Scotland plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland, number 327000. Telephone: 0870 600 5000
Lloyds TSB Scotland plc. Registered Office: Henry Duncan House, 120 George Street, Edinburgh EH2 4LH. Registered in Scotland, number 95237. Telephone: 0131 225 4555.
Cheltenham & Gloucester plc. Registered Office: Barnett Way, Gloucester GL4 3RL. Registered in England and Wales, number 2299428. Telephone: 01452 372372.
Lloyds TSB Bank plc, Lloyds TSB Scotland plc, Bank of Scotland plc and Cheltenham & Gloucester plc are authorised and regulated by the Financial Services Authority.
Halifax is a division of Bank of Scotland plc. Cheltenham & Gloucester Savings is a division of Lloyds TSB Bank plc.
HBOS plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland, number 218813. Telephone: 0870 600 5000
Lloyds Banking Group plc. Registered Office: The Mound, Edinburgh EH1 1YZ. Registered in Scotland, number 95000. Telephone: 0131 225 4555
This e-mail (including any attachments) is private and confidential and may contain privileged material. If you have received this e-mail in error, please notify the sender and delete it (including any attachments) immediately. You must not copy, distribute, disclose or use any of the information in it or any attachments.
Telephone calls may be monitored or recorded.
Kopischke, David G.
May 21, 2012, 7:12:30 PM5/21/12
to
From a safe distance from this conversation...
In my observations, this is what hackers do. They probe around looking for things. If you can identify when someone is doing that, you can possibly protect yourself. If you just allow everyone to wander around, they will eventually find something to access.
mailgate3.oppenheimerfunds.com made the following annotations
---------------------------------------------------------------------
This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications.
---------------------------------------------------------------------
In my observations, this is what hackers do. They probe around looking for things. If you can identify when someone is doing that, you can possibly protect yourself. If you just allow everyone to wander around, they will eventually find something to access.
---------------------------------------------------------------------
This e-mail transmission may contain information that is proprietary, privileged and/or confidential and is intended exclusively for the person(s) to whom it is addressed. Any use, copying, retention or disclosure by any person other than the intended recipient or the intended recipient's designees is strictly prohibited. If you are not the intended recipient or their designee, please notify the sender immediately by return e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, monitor, review, retain and/or disclose the content of all email communications.
---------------------------------------------------------------------
Paul Gilmartin
May 22, 2012, 1:24:17 AM5/22/12
to
On May 21, 2012, at 14:25, Bodoh John Robert wrote:
> Walt,
>
Walt has retired. And I don't recall that he followed this
forum.
> I must disagree:
>
> * I don't understand why the rules would be too complicated: "Here's a data set RACF, tell me what my access permission is."
>
> * Even if the rules change between the time of the query and the time of access, the likelihood of that happening are very remote. 99% of the time it will work. For the 1% of the times it won't work is quite adequate. At least the report will be small enough that it won't ruffle any feathers.
>
> * I also think that trying to access a data set is worse than checking to see if you can access it. It would sound as though even knowing of the data set's existence should be treated as a security violation. Do they protect against that?
>
UNIX does, by allowing a user to deny read access to a directory.
My employer mandates and enforces this practice.
> Is some cases, a user may need to access a particular data set as part of his/her job. Checking on your ability to access it first would enable one to avoid the violation report. How would you recommend avoiding the RACF violation report?
>
Several other followups have explained that whatever the security
admins' concerns are, they defeat their purpose if they allow
avoiding RACF violation reports.
But your security admins are paranoid, and there's nothing you or
I can do about that. When RACF denies access, it's doing its job
effectively; no harm, no foul; and there shouldn't be a reportable
incident. The true hazard is of a resource owner's neglecting to
protect a critical resource and allowing undue acccess to occur.
But that's harder to check for. So your security admins instead
report that they detected, reported, and cleared X hundred
violations last month and get a gold star for diligence in
accomplishing nothing.
> Walt,
>
Walt has retired. And I don't recall that he followed this
forum.
> I must disagree:
>
> * I don't understand why the rules would be too complicated: "Here's a data set RACF, tell me what my access permission is."
>
> * Even if the rules change between the time of the query and the time of access, the likelihood of that happening are very remote. 99% of the time it will work. For the 1% of the times it won't work is quite adequate. At least the report will be small enough that it won't ruffle any feathers.
>
> * I also think that trying to access a data set is worse than checking to see if you can access it. It would sound as though even knowing of the data set's existence should be treated as a security violation. Do they protect against that?
>
My employer mandates and enforces this practice.
> Is some cases, a user may need to access a particular data set as part of his/her job. Checking on your ability to access it first would enable one to avoid the violation report. How would you recommend avoiding the RACF violation report?
>
admins' concerns are, they defeat their purpose if they allow
avoiding RACF violation reports.
But your security admins are paranoid, and there's nothing you or
I can do about that. When RACF denies access, it's doing its job
effectively; no harm, no foul; and there shouldn't be a reportable
incident. The true hazard is of a resource owner's neglecting to
protect a critical resource and allowing undue acccess to occur.
But that's harder to check for. So your security admins instead
report that they detected, reported, and cleared X hundred
violations last month and get a gold star for diligence in
accomplishing nothing.
Styles, Andy , SMS - Scheduling and SCM Infrastructure Support
May 22, 2012, 5:23:48 AM5/22/12
to
Well yes...but you won't know when they have been successful, because they don't appear on the report..and as shown below, you don't need to appear on the report to determine the access you have.
Andreas Fischer
May 22, 2012, 5:54:25 AM5/22/12
to
hi john,
there is no such command you've been asking for - at least i would not
know such a command, and i use rexx execs frequently for maintaing our
racf database. maybe it's possible via IRRXUTIL, i haven't experienced
this service so far - but as far as i know, you need special
authorizations to use that service anyway.
if i understand you correctly, your goal is to simplify the process of
determining the current profile in effect for a given data set. i think
the best way to do is something like this:
mask = 'your.data.set.name'
trap = outtrap('LIST.',, 'NOCONCAT')
"listdsd dataset ('" !! mask !! "') all"
if rc = 4 then do
"listdsd dataset ('" !! mask !! "') all generic"
end
then check if variable list.1 contains the string 'NOT AUTHORIZED' or
'PROCESSING TERMINATED'
if those strings does not appear but the rc ist still 4 then, there is no
racf description found for the data set
if rc is 0, you get the profile including a possibly generic flag with:
parse var list.1 =25 profile ' ' .
...and you have the list output in the stem variable for further
processing.
BUT:
1) i use a similar routine as a racf sysadmin for maintanance purposes. i
don't think it's much use for other users to find out authorizations for
specific data sets. in a well maintained racf environment, you have access
to those data sets you need, and you will ask for permission if you find
out that some access is missing. checking access to data sets that you
don't need officilly seems somehow obscure to me.
2) the example above relates to the data set profile that covers a data
set, but racf might grant access to a ressource for other reason like
there's a profile in the global table or the userid has the system or
group operations attribute and does not apear in the access list. adding
those checks for non-special userids doesn't make any sense since they
will or should lack of authorization. therefore, scanning the access list
might give you a good result in most cases, but you cannot rely on the
result 100%.
regards,
andi
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> schrieb am 21.05.2012
19:59:10:
there is no such command you've been asking for - at least i would not
know such a command, and i use rexx execs frequently for maintaing our
racf database. maybe it's possible via IRRXUTIL, i haven't experienced
this service so far - but as far as i know, you need special
authorizations to use that service anyway.
if i understand you correctly, your goal is to simplify the process of
determining the current profile in effect for a given data set. i think
the best way to do is something like this:
mask = 'your.data.set.name'
trap = outtrap('LIST.',, 'NOCONCAT')
"listdsd dataset ('" !! mask !! "') all"
if rc = 4 then do
"listdsd dataset ('" !! mask !! "') all generic"
end
then check if variable list.1 contains the string 'NOT AUTHORIZED' or
'PROCESSING TERMINATED'
if those strings does not appear but the rc ist still 4 then, there is no
racf description found for the data set
if rc is 0, you get the profile including a possibly generic flag with:
parse var list.1 =25 profile ' ' .
...and you have the list output in the stem variable for further
processing.
BUT:
1) i use a similar routine as a racf sysadmin for maintanance purposes. i
don't think it's much use for other users to find out authorizations for
specific data sets. in a well maintained racf environment, you have access
to those data sets you need, and you will ask for permission if you find
out that some access is missing. checking access to data sets that you
don't need officilly seems somehow obscure to me.
2) the example above relates to the data set profile that covers a data
set, but racf might grant access to a ressource for other reason like
there's a profile in the global table or the userid has the system or
group operations attribute and does not apear in the access list. adding
those checks for non-special userids doesn't make any sense since they
will or should lack of authorization. therefore, scanning the access list
might give you a good result in most cases, but you cannot rely on the
result 100%.
regards,
andi
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> schrieb am 21.05.2012
19:59:10:
Tony Netley
May 22, 2012, 6:26:09 AM5/22/12
to
I have a copy of George Fogg's RACFACL Rexx function from Feb. 2002
which I can send if it helps, or you may be able to track it down on the
web.
Regards
Tony
Farley, Peter x23353
May 22, 2012, 8:54:48 AM5/22/12
to
Was that on the TSO-REXX list or on the RACF-L list? I could not find it in the TSO-REXX archives anyway.
Peter
--
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.
Peter
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.
Tony Netley
May 22, 2012, 9:04:19 AM5/22/12
to
It was discussed on the TSO/REXX list, June 4/5, 2003
This e-mail message has been scanned and cleared by Postini / Google Message Security and the UNICOM Global security systems. This message is for the named person's use only. If you receive this message in error, please delete it and notify the sender.
Farley, Peter x23353
May 22, 2012, 9:14:06 AM5/22/12
to
Thanks. June 2003 is not Feb. 2002, but I see that from the discussion the routine itself is dated 2002. My confusion, sorry about that.
Bodoh John Robert
May 22, 2012, 10:37:03 AM5/22/12
to
I guess my real problem is that when I get a RACF violation against a data set, it is logged somewhere. A report is generated once every couple of months and sorted by user ID. It then gets sent to those users where the number of violations exceed some arbitrary count. The user needs to justify their violation.
When I receive the report, It is impossible for me to remember exactly what I was doing one or two months ago with some data set. I have had to create and maintain my own spreadsheet of violations so that I have a record of the violation, when it occurred and why. Then I can respond to the report.
It's a lot easier to have a command and avoid wasting time on paper work.
John
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@vm.marist.edu] On Behalf Of Adrian Stern
Sent: Tuesday, May 22, 2012 3:20 AM
To: TSO-...@vm.marist.edu
Subject: Re: [TSO-REXX] RACF command
Been there and explained just that too - as I couldn't access the dataset
you can see RACF's doing it's job. I also added like Gil their time would be
better spent looking at lists of who accessed what!
As an avid user of isrddn's search function I've produced pallet loads of
violations! Really! At one firm the RACF reports went straight to the
printer - searching lpa etc many times a day I produced several pallet loads
of violation reports. They stopped printing them after that. And it was part
of my job if anyone's wondering.
Taking a more sober look there may be a point in looking for someone fishing
for access and maybe they should ask why people have tried to access certain
datasets and failed - but in that case the innocent have nothing to fear!
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Paul Gilmartin
Sent: den 22 maj 2012 07:23
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] RACF command
When I receive the report, It is impossible for me to remember exactly what I was doing one or two months ago with some data set. I have had to create and maintain my own spreadsheet of violations so that I have a record of the violation, when it occurred and why. Then I can respond to the report.
It's a lot easier to have a command and avoid wasting time on paper work.
John
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@vm.marist.edu] On Behalf Of Adrian Stern
Sent: Tuesday, May 22, 2012 3:20 AM
To: TSO-...@vm.marist.edu
Subject: Re: [TSO-REXX] RACF command
you can see RACF's doing it's job. I also added like Gil their time would be
better spent looking at lists of who accessed what!
As an avid user of isrddn's search function I've produced pallet loads of
violations! Really! At one firm the RACF reports went straight to the
printer - searching lpa etc many times a day I produced several pallet loads
of violation reports. They stopped printing them after that. And it was part
of my job if anyone's wondering.
Taking a more sober look there may be a point in looking for someone fishing
for access and maybe they should ask why people have tried to access certain
datasets and failed - but in that case the innocent have nothing to fear!
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of
Paul Gilmartin
Sent: den 22 maj 2012 07:23
To: TSO-...@VM.MARIST.EDU
Subject: Re: [TSO-REXX] RACF command
Bodoh John Robert
May 22, 2012, 10:42:05 AM5/22/12
to
The suggestion by Andy Styles of using "LD DA(dsname) GEN ALL" works file and I have incorporated into a REXX to tell me if I can view the data set.
I am not a hacker trying to break in. Anybody that would do that where I work would be in big, big trouble...not just a lost job.
John
I am not a hacker trying to break in. Anybody that would do that where I work would be in big, big trouble...not just a lost job.
John
Baldon, David
May 22, 2012, 10:53:27 AM5/22/12
to
Sounds to me like you have a very taxing job. :)
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Bodoh John Robert
Sent: Tuesday, May 22, 2012 9:41 AM
To: TSO-...@VM.MARIST.EDU
Subject: Re: Antwort: [TSO-REXX] RACF command
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] On Behalf Of Bodoh John Robert
Sent: Tuesday, May 22, 2012 9:41 AM
To: TSO-...@VM.MARIST.EDU
Subject: Re: Antwort: [TSO-REXX] RACF command
Andreas Fischer
May 22, 2012, 10:58:17 AM5/22/12
to
hi john,
the reason you should issue both commands in the order i sent you is that
you don't know if the data set is covered by a discrete or generic
profile.
"listdsd ... all" will work for both a discrete or generic profiles that
represents the data set name 1:1.
"listdsd ... all generic" will work for generic profiles.
if you only use the command with the parameter all and generic and the
data set is covered by a discrete profile, the result will be incorrect.
by the way, if you only want to find out your own access, you don't need
to go through the access list but will find it in the output under "YOUR
ACCESS". i misread that when answering you first mail.
regards,
andi
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> schrieb am 22.05.2012
16:40:57:
> Von: Bodoh John Robert <John.Rob...@IRS.GOV>
> An: TSO-...@VM.MARIST.EDU,
> Datum: 22.05.2012 16:42
> Betreff: Re: [TSO-REXX] Antwort: [TSO-REXX] RACF command
> Gesendet von: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
>
the reason you should issue both commands in the order i sent you is that
you don't know if the data set is covered by a discrete or generic
profile.
"listdsd ... all" will work for both a discrete or generic profiles that
represents the data set name 1:1.
"listdsd ... all generic" will work for generic profiles.
if you only use the command with the parameter all and generic and the
data set is covered by a discrete profile, the result will be incorrect.
by the way, if you only want to find out your own access, you don't need
to go through the access list but will find it in the output under "YOUR
ACCESS". i misread that when answering you first mail.
regards,
andi
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> schrieb am 22.05.2012
16:40:57:
> Von: Bodoh John Robert <John.Rob...@IRS.GOV>
> An: TSO-...@VM.MARIST.EDU,
> Datum: 22.05.2012 16:42
> Betreff: Re: [TSO-REXX] Antwort: [TSO-REXX] RACF command
> Gesendet von: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
>
> The suggestion by Andy Styles of using "LD DA(dsname) GEN ALL" works
> file and I have incorporated into a REXX to tell me if I can view
> the data set.
>
> I am not a hacker trying to break in. Anybody that would do that
> where I work would be in big, big trouble...not just a lost job.
>
> John
>
> file and I have incorporated into a REXX to tell me if I can view
> the data set.
>
> I am not a hacker trying to break in. Anybody that would do that
> where I work would be in big, big trouble...not just a lost job.
>
> John
>
Binyamin Dissen
May 22, 2012, 11:21:12 AM5/22/12
to
But it is a breach of security to allow snooping. The result of the query
would assist the user who wants to snoop.
If you access data that you have not been explicitly granted permission, well
"Lucy - you have a bit of explaining to do". Should you need access, you
should ask the data owner for permission and give a justification.
P.S. I agree that waiting two months is a bad idea.
On Tue, 22 May 2012 14:36:05 +0000 Bodoh John Robert
<John.Rob...@IRS.GOV> wrote:
:>I guess my real problem is that when I get a RACF violation against a data set, it is logged somewhere. A report is generated once every couple of months and sorted by user ID. It then gets sent to those users where the number of violations exceed some arbitrary count. The user needs to justify their violation.
--
Binyamin Dissen <bdi...@dissensoftware.com>
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.
would assist the user who wants to snoop.
If you access data that you have not been explicitly granted permission, well
"Lucy - you have a bit of explaining to do". Should you need access, you
should ask the data owner for permission and give a justification.
P.S. I agree that waiting two months is a bad idea.
On Tue, 22 May 2012 14:36:05 +0000 Bodoh John Robert
<John.Rob...@IRS.GOV> wrote:
:>I guess my real problem is that when I get a RACF violation against a data set, it is logged somewhere. A report is generated once every couple of months and sorted by user ID. It then gets sent to those users where the number of violations exceed some arbitrary count. The user needs to justify their violation.
Binyamin Dissen <bdi...@dissensoftware.com>
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.
Thomas Berg
May 22, 2012, 11:26:24 AM5/22/12
to
And how do You know that You have permission ?
As You - as mentioned - is not allowed to know if You have permission...
Regards,
Thomas Berg
______________________________________________________
Thomas Berg Specialist AM/DQS SWEDBANK AB (publ)
> -----Ursprungligt meddelande-----
> Från: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] För
> Binyamin Dissen
> Skickat: den 22 maj 2012 17:16
> Till: TSO-...@VM.MARIST.EDU
> Ämne: Re: [TSO-REXX] RACF command
As You - as mentioned - is not allowed to know if You have permission...
Regards,
Thomas Berg
______________________________________________________
Thomas Berg Specialist AM/DQS SWEDBANK AB (publ)
> -----Ursprungligt meddelande-----
> Från: TSO REXX Discussion List [mailto:TSO-...@VM.MARIST.EDU] För
> Binyamin Dissen
> Skickat: den 22 maj 2012 17:16
> Till: TSO-...@VM.MARIST.EDU
> Ämne: Re: [TSO-REXX] RACF command
Bodoh John Robert
May 22, 2012, 11:39:03 AM5/22/12
to
How can it be a breach of security if I can find out my access authority using the LD command, as Andy Styles suggested. Why would a company that is strict on accessing data sets (as mine is) allow anybody to use the LD command?
Glenn Knickerbocker
May 22, 2012, 11:46:19 AM5/22/12
to
On 5/22/2012 10:42 AM, Bodoh John Robert wrote:
> then check if variable list.1 contains the string 'NOT AUTHORIZED' or
> 'PROCESSING TERMINATED'
Wouldn't that still get him reported for an access violation?
> then check if variable list.1 contains the string 'NOT AUTHORIZED' or
> 'PROCESSING TERMINATED'
�R
Andreas Fischer
May 22, 2012, 12:16:28 PM5/22/12
to
well i cannot tell since that depends on their reports. in my shop, we get
automatically informed about any racf command against critical ressources
that was issued from someone who is not a local or system racf
administrator.
anyway, i mentioned in my first mail that i don't see the point in
checking the racf access. if someone needs to access a resource and isn't
allowed, he will likely ask for permission. checking the access for data
sets that i'm not going to use then if i don't have the proper right
doesn't make any sense to me.
regards,
andi
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> schrieb am 22.05.2012
17:44:21:
> Von: Glenn Knickerbocker <No...@BESTWEB.NET>
> An: TSO-...@VM.MARIST.EDU,
> Datum: 22.05.2012 17:48
> Betreff: Re: [TSO-REXX] Antwort: [TSO-REXX] RACF command
> Gesendet von: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
>
automatically informed about any racf command against critical ressources
that was issued from someone who is not a local or system racf
administrator.
anyway, i mentioned in my first mail that i don't see the point in
checking the racf access. if someone needs to access a resource and isn't
allowed, he will likely ask for permission. checking the access for data
sets that i'm not going to use then if i don't have the proper right
doesn't make any sense to me.
regards,
andi
TSO REXX Discussion List <TSO-...@VM.MARIST.EDU> schrieb am 22.05.2012
17:44:21:
> Von: Glenn Knickerbocker <No...@BESTWEB.NET>
> An: TSO-...@VM.MARIST.EDU,
> Datum: 22.05.2012 17:48
> Betreff: Re: [TSO-REXX] Antwort: [TSO-REXX] RACF command
> Gesendet von: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
>
> On 5/22/2012 10:42 AM, Bodoh John Robert wrote:
> > then check if variable list.1 contains the string 'NOT AUTHORIZED' or
> > 'PROCESSING TERMINATED'
>
> Wouldn't that still get him reported for an access violation?
>
> ŹR
> > then check if variable list.1 contains the string 'NOT AUTHORIZED' or
> > 'PROCESSING TERMINATED'
>
> Wouldn't that still get him reported for an access violation?
>
Ted MacNEIL
May 22, 2012, 1:49:37 PM5/22/12
to
And, this is beneficial and productive?
-
Ted MacNEIL
eama...@yahoo.ca
Twitter: @TedMacNEIL
-----Original Message-----
From: Adrian Stern <adrian...@TELE2.SE>
Sender: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Date: Tue, 22 May 2012 17:59:29
To: <TSO-...@VM.MARIST.EDU>
Reply-To: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Subject: Re: [TSO-REXX] RACF command
Try doing what I did! Generate millions of violations! That'll stop 'em.
Bunch of cretins obviously if they really expect you to remember -
especially since some may even me mistakes.
-
Ted MacNEIL
eama...@yahoo.ca
Twitter: @TedMacNEIL
-----Original Message-----
From: Adrian Stern <adrian...@TELE2.SE>
Sender: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Date: Tue, 22 May 2012 17:59:29
To: <TSO-...@VM.MARIST.EDU>
Reply-To: TSO REXX Discussion List <TSO-...@VM.MARIST.EDU>
Subject: Re: [TSO-REXX] RACF command
Bunch of cretins obviously if they really expect you to remember -
especially since some may even me mistakes.
Robert S. Hansel , RSH
May 23, 2012, 8:53:48 AM5/23/12
to
RACF does not log usage of the LISTDSD (LD), RLIST (RL), and SEARCH (SR)
commands. These commands can be used to probe the defenses of a system as
discussed in the article entitled " Should You Monitor or Restrict LISTDSD,
RLIST, or SEARCH?" in the October 2009 issue of our RACF Tips Newsletters
(available via URL www.rshconsulting.com/racfres.htm). As a RACF security
professional, I share the concerns expressed by others about the proposed
use of the LD command.
On the other hand, I can appreciate John's dilemma and his desire to avoid
violations. Asking months after the fact why a violation occurred seems
counterproductive both for the user and the security staff. We believe a
better approach is the timely identification and investigation of unusual
patterns and trends of access and violations, such as repeated attempts to
access restricted APF libraries or production files.
Regards, Bob
Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc. *** Celebrating our Twentieth Anniversary ***
617-969-8211
www.linkedin.com/in/roberthansel
www.rshconsulting.com
---------------------------------------------------------------------
2012 RACF Training
- Audit for Results - Boston - OCT 30 - NOV 1
- Securing z/OS UNIX - WebEx - JUL 31 - AUG 2
- Intro & Basic Admin - WebEx - OCT 15-19
---------------------------------------------------------------------
commands. These commands can be used to probe the defenses of a system as
discussed in the article entitled " Should You Monitor or Restrict LISTDSD,
RLIST, or SEARCH?" in the October 2009 issue of our RACF Tips Newsletters
(available via URL www.rshconsulting.com/racfres.htm). As a RACF security
professional, I share the concerns expressed by others about the proposed
use of the LD command.
On the other hand, I can appreciate John's dilemma and his desire to avoid
violations. Asking months after the fact why a violation occurred seems
counterproductive both for the user and the security staff. We believe a
better approach is the timely identification and investigation of unusual
patterns and trends of access and violations, such as repeated attempts to
access restricted APF libraries or production files.
Regards, Bob
Robert S. Hansel
Lead RACF Specialist
RSH Consulting, Inc. *** Celebrating our Twentieth Anniversary ***
617-969-8211
www.linkedin.com/in/roberthansel
www.rshconsulting.com
---------------------------------------------------------------------
2012 RACF Training
- Audit for Results - Boston - OCT 30 - NOV 1
- Securing z/OS UNIX - WebEx - JUL 31 - AUG 2
- Intro & Basic Admin - WebEx - OCT 15-19
---------------------------------------------------------------------
Bob Bridges
May 23, 2012, 11:06:35 AM5/23/12
to
In any sane shop, the security auditors have far too much to do to worry
about EVERY violation. People fat-finger DSNs all the time, not only
on-line but in their program code as well. I've been responsible for
monitoring the violations reports at several companies; I glance over them
not for individual events but for (as Robert said) patterns that raise my
eyebrows. In fact, usually I write some REXX tools to filter out certain
routine patterns and pass on to me everything else.
There may be individual datasets that get my attention - certain payroll
files, for example, and data related to RACF itself - but mostly to make me
look twice requires multiple hits AND other characteristics. And even when
I'm moved to inquire into an event, it's almost always just a mistake of
some kind. In 19 years of mainframe security work I don't think I've run
across more than half a dozen users about whom I am still suspicious.
Individual violations are just too routine to bother your head about.
John, if your name merely appears on a violations report once in a while,
that wouldn't cause anyone even to notice you at any company I've ever
worked at. If once in a while someone asks you what you were doing, well,
someone's trying to be vigilant, I suppose; just tell 'em and forget it.
But if you're actually being contacted about every individual violation,
that sounds pretty dumb to me. And if they're batching up their violations
and handling them - trying to handle them - no more often than every two
months, that's just crazy.
---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313
/* Maybe those of us who have never been Beatles shouldn't judge them too
severely. That degree of celebrity would test anyone's maturity, never mind
four boys in their twenties. Still, we might reflect on the fact that none
of Nat Cole's fans ever tried to shoot him. -Joseph Sobran, 2001-12-06 */
-----Original Message-----
From: Adrian Stern
Sent: Wednesday, May 23, 2012 09:36
Hurrah! A voice of reason!
Sorry, but I was really impressed by the line "timely identification and
investigation of unusual patterns and trends of access and violations" which
is what I believe security staff should be doing rather than demanding a
reason for every violation.
-----Original Message-----
From: Robert S. Hansel (RSH)
Sent: den 23 maj 2012 14:53
RACF does not log usage of the LISTDSD (LD), RLIST (RL), and SEARCH (SR)
commands. These commands can be used to probe the defenses of a system as
discussed in the article entitled " Should You Monitor or Restrict LISTDSD,
RLIST, or SEARCH?" in the October 2009 issue of our RACF Tips Newsletters
(available via URL www.rshconsulting.com/racfres.htm). As a RACF security
professional, I share the concerns expressed by others about the proposed
use of the LD command.
On the other hand, I can appreciate John's dilemma and his desire to avoid
violations. Asking months after the fact why a violation occurred seems
counterproductive both for the user and the security staff. We believe a
better approach is the timely identification and investigation of unusual
patterns and trends of access and violations, such as repeated attempts to
access restricted APF libraries or production files.
about EVERY violation. People fat-finger DSNs all the time, not only
on-line but in their program code as well. I've been responsible for
monitoring the violations reports at several companies; I glance over them
not for individual events but for (as Robert said) patterns that raise my
eyebrows. In fact, usually I write some REXX tools to filter out certain
routine patterns and pass on to me everything else.
There may be individual datasets that get my attention - certain payroll
files, for example, and data related to RACF itself - but mostly to make me
look twice requires multiple hits AND other characteristics. And even when
I'm moved to inquire into an event, it's almost always just a mistake of
some kind. In 19 years of mainframe security work I don't think I've run
across more than half a dozen users about whom I am still suspicious.
Individual violations are just too routine to bother your head about.
John, if your name merely appears on a violations report once in a while,
that wouldn't cause anyone even to notice you at any company I've ever
worked at. If once in a while someone asks you what you were doing, well,
someone's trying to be vigilant, I suppose; just tell 'em and forget it.
But if you're actually being contacted about every individual violation,
that sounds pretty dumb to me. And if they're batching up their violations
and handling them - trying to handle them - no more often than every two
months, that's just crazy.
---
Bob Bridges, rhb...@attglobal.net, cell 336 382-7313
/* Maybe those of us who have never been Beatles shouldn't judge them too
severely. That degree of celebrity would test anyone's maturity, never mind
four boys in their twenties. Still, we might reflect on the fact that none
of Nat Cole's fans ever tried to shoot him. -Joseph Sobran, 2001-12-06 */
-----Original Message-----
From: Adrian Stern
Hurrah! A voice of reason!
Sorry, but I was really impressed by the line "timely identification and
investigation of unusual patterns and trends of access and violations" which
is what I believe security staff should be doing rather than demanding a
reason for every violation.
-----Original Message-----
From: Robert S. Hansel (RSH)
Sent: den 23 maj 2012 14:53
RACF does not log usage of the LISTDSD (LD), RLIST (RL), and SEARCH (SR)
commands. These commands can be used to probe the defenses of a system as
discussed in the article entitled " Should You Monitor or Restrict LISTDSD,
RLIST, or SEARCH?" in the October 2009 issue of our RACF Tips Newsletters
(available via URL www.rshconsulting.com/racfres.htm). As a RACF security
professional, I share the concerns expressed by others about the proposed
use of the LD command.
On the other hand, I can appreciate John's dilemma and his desire to avoid
violations. Asking months after the fact why a violation occurred seems
counterproductive both for the user and the security staff. We believe a
better approach is the timely identification and investigation of unusual
patterns and trends of access and violations, such as repeated attempts to
access restricted APF libraries or production files.
Bob Bridges
May 23, 2012, 11:50:26 AM5/23/12
to
Yeah, for that leave off the ALL argument in both commands. The ALL
argument tells it to list everyone who has access, but I'm pretty sure you
get your own access without it.
/* It is a little unfair, I think, to criticize a person for not sharing the
enlightenment of a later epoch....The question raises nagging uncertainties
about which of the conventional truths of our own age will be considered
unforgivable bigotry by the next. -Carl Sagan, from "Broca's Brain" */
-----Original Message-----
From: Andreas Fischer
Sent: Tuesday, May 22, 2012 10:57
the reason you should issue both commands in the order i sent you is that
you don't know if the data set is covered by a discrete or generic
profile.
"listdsd ... all" will work for both a discrete or generic profiles that
represents the data set name 1:1.
"listdsd ... all generic" will work for generic profiles.
if you only use the command with the parameter all and generic and the
data set is covered by a discrete profile, the result will be incorrect.
by the way, if you only want to find out your own access, you don't need
to go through the access list but will find it in the output under "YOUR
ACCESS". i misread that when answering you first mail.
--- Bodoh John Robert <John.Rob...@IRS.GOV> schrieb am 22.05.2012
16:40:57:
argument tells it to list everyone who has access, but I'm pretty sure you
get your own access without it.
/* It is a little unfair, I think, to criticize a person for not sharing the
enlightenment of a later epoch....The question raises nagging uncertainties
about which of the conventional truths of our own age will be considered
unforgivable bigotry by the next. -Carl Sagan, from "Broca's Brain" */
-----Original Message-----
From: Andreas Fischer
Sent: Tuesday, May 22, 2012 10:57
the reason you should issue both commands in the order i sent you is that
you don't know if the data set is covered by a discrete or generic
profile.
"listdsd ... all" will work for both a discrete or generic profiles that
represents the data set name 1:1.
"listdsd ... all generic" will work for generic profiles.
if you only use the command with the parameter all and generic and the
data set is covered by a discrete profile, the result will be incorrect.
by the way, if you only want to find out your own access, you don't need
to go through the access list but will find it in the output under "YOUR
ACCESS". i misread that when answering you first mail.
16:40:57:
> The suggestion by Andy Styles of using "LD DA(dsname) GEN ALL" works
> file and I have incorporated into a REXX to tell me if I can view
> the data set.
> file and I have incorporated into a REXX to tell me if I can view
> the data set.
Bodoh John Robert
May 23, 2012, 12:23:25 PM5/23/12
to
Bob,
I have worked at my company for 2 years and this is the first RACF violation report I have ever seen. These reports are sent out, I think, once a month. The reports are sent to the managers and they forward them to individuals. I know that I have had RACF violations in the past. However, this is the first time a report actually got to me. Maybe I received the report because I had five violations in the month, I don't know their rules.
I did notice other people on the report with only one or two violations. This makes me think that all violations are reported to managers who forward them to the individuals that exceeded the number of violations.
There is another person in my office working for the same company but for a different manager and he will get a report every month if his name is on it. This makes me suspect that who gets notified might be up to the discretion of the manager. I gave this other person my REXX that does the LD command to determine what his access would be and he loves it. Now he won't be appearing on the monthly report.
We have the most security I have ever seen just to get into the company. I have never heard of anyone ever hacking into our systems. I have also not heard of anyone authorized to connect to our systems ever facing disciplinary action because of intentional access attempts. Although, it is certainly possible.
John
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@vm.marist.edu] On Behalf Of Bob Bridges
Sent: Wednesday, May 23, 2012 11:05 AM
To: TSO-...@vm.marist.edu
Subject: Re: [TSO-REXX] RACF command
I have worked at my company for 2 years and this is the first RACF violation report I have ever seen. These reports are sent out, I think, once a month. The reports are sent to the managers and they forward them to individuals. I know that I have had RACF violations in the past. However, this is the first time a report actually got to me. Maybe I received the report because I had five violations in the month, I don't know their rules.
I did notice other people on the report with only one or two violations. This makes me think that all violations are reported to managers who forward them to the individuals that exceeded the number of violations.
There is another person in my office working for the same company but for a different manager and he will get a report every month if his name is on it. This makes me suspect that who gets notified might be up to the discretion of the manager. I gave this other person my REXX that does the LD command to determine what his access would be and he loves it. Now he won't be appearing on the monthly report.
We have the most security I have ever seen just to get into the company. I have never heard of anyone ever hacking into our systems. I have also not heard of anyone authorized to connect to our systems ever facing disciplinary action because of intentional access attempts. Although, it is certainly possible.
John
-----Original Message-----
From: TSO REXX Discussion List [mailto:TSO-...@vm.marist.edu] On Behalf Of Bob Bridges
Sent: Wednesday, May 23, 2012 11:05 AM
To: TSO-...@vm.marist.edu
Subject: Re: [TSO-REXX] RACF command
0 new messages