Re: Newbie RACROUTE question: how to *test* authorization?
On Tue, 26 Feb 2008 19:53:42 -0600, David Eisenberg [EMAIL PROTECTED] wrote: Not in this case, IMO. The violations are occurring as a result of a text string scan across all members of a production source code library in CA's Panvalet format. The library contains hundreds of members, but a handful of them have UACC=NONE. Here's how: Panvalet supports *member-level* security. We create RACF pseudo-profiles that contain the member name as the last qualifier, and if we wish to read-protect a member, we set that profile to have UACC=NONE. A Panvalet security exit constructs the pseudo-profile name, and invokes RACROUTE to see if read access to the member is permitted or not. I would agree that's a reasonable case for using LOG=NONE. It will, however, require you to run APF-authorized, and I think it's appropriate to require APF in this case. -- Walt Farrell, CISSP IBM STSM, 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: Newbie RACROUTE question: how to *test* authorization?
On Tue, 26 Feb 2008 21:49:22 -0500, Farley, Peter x23353 [EMAIL PROTECTED] wrote: I agree with you about this type of harmless testing of authority to access. However, given the god-like authority of auditors these days, maybe it would be more helpful to you (and easier to get past the auditors) to have an additional parameter to RACROUTE which said, in effect, Don't tell me about any violations. I don't care if you record the attempted access in SMF, but don't bother telling me about it. I.E., suppress the message but go ahead and cut a record if you want to. Of course, that doesn't address the SMF noise issue for those who really need to track attempted accesses to truly important resources to detect actual hacking attempts. That's MSGSUPP=YES, which does not require APF authorization because it does not hide anything from the auditors. -- Walt Farrell, CISSP IBM STSM, 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: Newbie RACROUTE question: how to *test* authorization?
On Tue, 26 Feb 2008 16:08:17 -0800, George Fogg [EMAIL PROTECTED] wrote: I wrote a REXX interface to our JCL scan product so it can check a production userid access to a dataset resource. I told the folks that use it that they must understand the fact that they cannot rely on the results of the access when the real task opens the dataset in its environment during OPEN time if: 1.) the task at OPEN is running Privileged or Trusted, 2.) the task at OPEN happened to have a trusted token, 3.) the task flipped one or more of those bypass authority checking bits before OPEN, 4.) the task at OPEN when the REQUEST=AUTH was a CSA or PRIVATE request, therefore bypassing GAC authority, 5.) that the Rexx interface call does not check for conditional access entries. The REXX interface function does a RACROUTE REQUEST=AUTH and uses: USERID=user_id (for third party checking) STATUS=ACCESS (send back the access code (NONE, READ, UPDATE, CONTROL, ALTER) LOG=NONE (do not cut SMF audit records) And a few other necessary parameters. USERID and LOG require APF. I also check if the caller has the authority to use this function with a profile in the FACILITY class. Good description, George. Thanks. I'll note that your results should also be inaccurate if they try to use PADS (Program Access to Data Sets) to grant access only when running a specific program. Since your program is a different one, it might indicate a failure when the actual job would work properly. That's a case that none of the JCL checking products can handle, as far as I know, because the results can not be checked except during actual execution. Any outside attempt to check them may give either a false success or a false failure indication. -- Walt Farrell, CISSP IBM STSM, 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: Newbie RACROUTE question: how to *test* authorization?
On Tue, 26 Feb 2008 16:08:17 -0800, George Fogg [EMAIL PROTECTED] wrote: I wrote a REXX interface to our JCL scan product so it can check a production userid access to a dataset resource. I told the folks that use it that they must understand the fact that they cannot rely on the results of the access when the real task opens the dataset in its environment during OPEN time if: 1.) the task at OPEN is running Privileged or Trusted, 2.) the task at OPEN happened to have a trusted token, 3.) the task flipped one or more of those bypass authority checking bits before OPEN, 4.) the task at OPEN when the REQUEST=AUTH was a CSA or PRIVATE request, therefore bypassing GAC authority, 5.) that the Rexx interface call does not check for conditional access entries. The REXX interface function does a RACROUTE REQUEST=AUTH and uses: USERID=user_id (for third party checking) STATUS=ACCESS (send back the access code (NONE, READ, UPDATE, CONTROL, ALTER) LOG=NONE (do not cut SMF audit records) And a few other necessary parameters. USERID and LOG require APF. I also check if the caller has the authority to use this function with a profile in the FACILITY class. Good description, George. Thanks. I'll note that your results should also be inaccurate if they try to use PADS (Program Access to Data Sets) to grant access only when running a specific program. Since your program is a different one, it might indicate a failure when the actual job would work properly. That's a case that none of the JCL checking products can handle, as far as I know, because the results can not be checked except during actual execution. Any outside attempt to check them may give either a false success or a false failure indication. Yes, I should have added PADS to the list above. I have racked what little brains I have left on how to do PADS authority checking and I haven't found a way so far and accept the fact that it can't be done. So I chould add number 6 to the list above PADS authority checking will not work in the REXX function. Thanks Walt. George Fogg -- 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: Newbie RACROUTE question: how to *test* authorization?
On Tue, Feb 26, 2008 at 1:48 AM, Paul Gilmartin [EMAIL PROTECTED] wrote: On Mon, 25 Feb 2008 13:08:53 -0600, Dave Kopischke wrote: We have a JCL checker application that verifies dataset access for a JOB. Through routine use of this product, we end up with thousands of access warnings on our daily RACF reports. This is not a hacking attempt. If there were hacking attempts occuring, it would be tough to see them through the noise though. I wonder that you get thousands of access warnings ... daily. Are your programmers commiting so many potential access errors in the course of coding their JCL? How many programmers does it take to do that? Perhaps the programmers are coding Production JCL and then running it through the syntax checker before handing it over to Operations. That would account for the # of access warnings. -- 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: Newbie RACROUTE question: how to *test* authorization?
On Tue, 26 Feb 2008 00:48:34 -0600, Paul Gilmartin [EMAIL PROTECTED] wrote: I wonder that you get thousands of access warnings ... daily. Are your programmers commiting so many potential access errors in the course of coding their JCL? How many programmers does it take to do that? In many shops the application programmers control and update production JCL related to their applications. However, the access control software (RACF, ACF2, TSS) does is (correctly) set up to not allow update to production data sets and in some cases not even read access (for example, payroll). The JCL check products can test this access when you scan your JCL. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: Newbie RACROUTE question: how to *test* authorization?
On Sat, 23 Feb 2008 20:32:13 -0600, David Eisenberg [EMAIL PROTECTED] wrote: And of course (as I indicated in my original post), I need to be able to do this without producing a RACF violation if the user is not authorized to read the resource. What you haven't said, though, is why you need to avoid a violation message. If the user has given you a data set name and asked you to operate on it, and he does not have the proper authority, then it is most appropriate to have the violation occur. And it's most appropriate to get that violation by simply acceding to the user's request and trying to operate upon the data set as he requested. If the user has not asked you to operate on the data set, why are you doing so? Perhaps it would help if you explained your application's purpose. -- Walt Farrell, CISSP IBM STSM, 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: Newbie RACROUTE question: how to *test* authorization?
On Mon, 25 Feb 2008 13:08:53 -0600, Dave Kopischke [EMAIL PROTECTED] wrote: On Sat, 23 Feb 2008 10:07:24 -0600, Walt Farrell wrote: One could argue that letting you determine your access to resources without actually trying to use them (and thus without causing audit records) is a form of hacking. You're looking around trying to figure out what you can do, rather than simply doing your job. We have a JCL checker application that verifies dataset access for a JOB. Through routine use of this product, we end up with thousands of access warnings on our daily RACF reports. This is not a hacking attempt. If there were hacking attempts occuring, it would be tough to see them through the noise though. I'm going to try to see if I can have this product changed to use a non-logged access check. That makes sense. Perhaps what you need, though, is a method allowing your application developers to run the JCL checking procedure against the proper user ID. You could let them put the JCL into a library with a known name, for example, and then have them run a program that either: (a) issued a command to run an STC to do the check, with the STC running under a more appropriate user ID; or (b) switched identity to the proper production ID and then submitted the JCL Check job. -- Walt Farrell, CISSP IBM STSM, 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: Newbie RACROUTE question: how to *test* authorization?
There are also newer JCL checkers on the market that allow remote checking of JCL on production from the users on the test side. Similar to the description outlined by Walt Farrell. Brian Walt Farrell wrote: On Mon, 25 Feb 2008 13:08:53 -0600, Dave Kopischke [EMAIL PROTECTED] wrote: On Sat, 23 Feb 2008 10:07:24 -0600, Walt Farrell wrote: One could argue that letting you determine your access to resources without actually trying to use them (and thus without causing audit records) is a form of hacking. You're looking around trying to figure out what you can do, rather than simply doing your job. We have a JCL checker application that verifies dataset access for a JOB. Through routine use of this product, we end up with thousands of access warnings on our daily RACF reports. This is not a hacking attempt. If there were hacking attempts occuring, it would be tough to see them through the noise though. I'm going to try to see if I can have this product changed to use a non-logged access check. That makes sense. Perhaps what you need, though, is a method allowing your application developers to run the JCL checking procedure against the proper user ID. You could let them put the JCL into a library with a known name, for example, and then have them run a program that either: (a) issued a command to run an STC to do the check, with the STC running under a more appropriate user ID; or (b) switched identity to the proper production ID and then submitted the JCL Check job. -- 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: Newbie RACROUTE question: how to *test* authorization?
In [EMAIL PROTECTED], on 02/24/2008 at 12:13 PM, IBM-MAIN@BAMA.UA.EDU [EMAIL PROTECTED] said: OTOH, I can readily imagine a utility that attempts an access but on failure proceeds with restricted function. As an example for Shmuel, see message GIM69158I, or perhaps IEB1099I. I was thinking of a case where it checks authorization before it knows that the access will be required, as part of its initialization. In the situation you describe I would wasn't RACF to log the violation, assuming that I didn't misunderstand you. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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: Newbie RACROUTE question: how to *test* authorization?
In ![EMAIL PROTECTED], on 02/24/2008 at 07:10 PM, Reza Fatemi [EMAIL PROTECTED] said: You may be thinking of ISPF 3.4 and data set name hiding or may be thinking of ISPF 3.4 checking for ALTER access to the catalog. The latter sounds familiar; it was in a thread about violation messages for resources that the user wasn't actually trying to use. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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: Newbie RACROUTE question: how to *test* authorization?
...and the QUERY SECURITY command invokes a RACROUTE to perform this function. So CICS is documenting use of preemptive RACROUTE requests as reasonable design in presenting usable options on a user's menu. --unsnip--- IIRC, under this particular set of circumstances, RACROUTE will do the equivalent of a FRACHECK, which does no logging. Has to do with the resource definitions for CICS transactions. No FRACHECK is performed in this case according to the doc. CICS performs a RACROUTE REQUEST=FASTAUTH for QUERY SECURITY with RESTYPE and a RACROUTE REQUEST=AUTH for QUERY SECURITY with RESCLASS. This is stated in the CICS/TS RACF Security Guide. Randy Evans, Viaserv, Inc. -- 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: Newbie RACROUTE question: how to *test* authorization?
On Tue, 26 Feb 2008 00:48:34 -0600, Paul Gilmartin wrote: On Mon, 25 Feb 2008 13:08:53 -0600, Dave Kopischke wrote: We have a JCL checker application that verifies dataset access for a JOB. Through routine use of this product, we end up with thousands of access warnings on our daily RACF reports. This is not a hacking attempt. If there were hacking attempts occuring, it would be tough to see them through the noise though. I wonder that you get thousands of access warnings ... daily. Are your programmers commiting so many potential access errors in the course of coding their JCL? How many programmers does it take to do that? When I run a JCL scan under TSO, the product uses my user ID information to evaluate access. If I'm not going to be allowed access, it notes it and logs it even though when the JCL actually runs in production, it will use a different JOB card and different USER parameters. I can change this by coding JCL parameters to mimic production, but if I don't notice it or don't know what the proper parameters are, I get security violations. If it's a large JOB, I get lots of security violations. It's still not a hacking attempt. -- 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: Newbie RACROUTE question: how to *test* authorization?
On Tue, 26 Feb 2008 08:35:10 -0600, Walt Farrell wrote: On Mon, 25 Feb 2008 13:08:53 -0600, Dave Kopischke [EMAIL PROTECTED] wrote: On Sat, 23 Feb 2008 10:07:24 -0600, Walt Farrell wrote: One could argue that letting you determine your access to resources without actually trying to use them (and thus without causing audit records) is a form of hacking. You're looking around trying to figure out what you can do, rather than simply doing your job. We have a JCL checker application that verifies dataset access for a JOB. Through routine use of this product, we end up with thousands of access warnings on our daily RACF reports. This is not a hacking attempt. If there were hacking attempts occuring, it would be tough to see them through the noise though. I'm going to try to see if I can have this product changed to use a non- logged access check. That makes sense. Perhaps what you need, though, is a method allowing your application developers to run the JCL checking procedure against the proper user ID. You could let them put the JCL into a library with a known name, for example, and then have them run a program that either: (a) issued a command to run an STC to do the check, with the STC running under a more appropriate user ID; or (b) switched identity to the proper production ID and then submitted the JCL Check job. Walt, This sounds like a better approach, but we've got different combinations of USER= parameters to match up to dataset requirements within particular JOBs. I'll have to map this out and see if something like this can be workable. Thanks -- 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: Newbie RACROUTE question: how to *test* authorization?
Dave wrote: I can change this by coding JCL parameters to mimic production, but if I don't notice it or don't know what the proper parameters are, I get security violations. If it's a large JOB, I get lots of security violations. It's still not a hacking attempt. Perhaps someone else could use your JCL scan to hack with? I don't know and I wouldn't do it myself. I wrote a REXX interface to our JCL scan product so it can check a production userid access to a dataset resource. I told the folks that use it that they must understand the fact that they cannot rely on the results of the access when the real task opens the dataset in its environment during OPEN time if: 1.) the task at OPEN is running Privileged or Trusted, 2.) the task at OPEN happened to have a trusted token, 3.) the task flipped one or more of those bypass authority checking bits before OPEN, 4.) the task at OPEN when the REQUEST=AUTH was a CSA or PRIVATE request, therefore bypassing GAC authority, 5.) that the Rexx interface call does not check for conditional access entries. The REXX interface function does a RACROUTE REQUEST=AUTH and uses: USERID=user_id (for third party checking) STATUS=ACCESS (send back the access code (NONE, READ, UPDATE, CONTROL, ALTER) LOG=NONE (do not cut SMF audit records) And a few other necessary parameters. USERID and LOG require APF. I also check if the caller has the authority to use this function with a profile in the FACILITY class. George Fogg -- 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: Newbie RACROUTE question: how to *test* authorization?
If the user has given you a data set name and asked you to operate on it, and he does not have the proper authority, then it is most appropriate to have the violation occur. Not in this case, IMO. The violations are occurring as a result of a text string scan across all members of a production source code library in CA's Panvalet format. The library contains hundreds of members, but a handful of them have UACC=NONE. Here's how: Panvalet supports *member-level* security. We create RACF pseudo-profiles that contain the member name as the last qualifier, and if we wish to read-protect a member, we set that profile to have UACC=NONE. A Panvalet security exit constructs the pseudo-profile name, and invokes RACROUTE to see if read access to the member is permitted or not. Under normal circumstances, if the security exit detects a violation of any kind, we want to know about it. But if a programmer issues a text scan of the entire library, he/she typically has no need or intention of scanning the handful of read-protected members. He's just looking for all occurrences of a variable name in the source code library (for example). The problem is that there's no easy way to instruct the scanning program to skip the read- protected members. So the programmer gets a meaningless violation for each read-protected member in the library. In my view, this ought to be an acceptable use of LOG=NONE. If the programmer isn't allowed to view the member, the security exit won't let it be scanned. The members are secure. Why record endless violations that are essentially noise, and might mask an actual hacking attempt? David -- 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: Newbie RACROUTE question: how to *test* authorization?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Eisenberg Sent: Tuesday, February 26, 2008 8:54 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Newbie RACROUTE question: how to *test* authorization? Snipped The violations are occurring as a result of a text string scan across all members of a production source code library... The problem is that there's no easy way to instruct the scanning program to skip the read- protected members. So the programmer gets a meaningless violation for each read-protected member in the library. In my view, this ought to be an acceptable use of LOG=NONE. If the programmer isn't allowed to view the member, the security exit won't let it be scanned. The members are secure. Why record endless violations that are essentially noise, and might mask an actual hacking attempt? I agree with you about this type of harmless testing of authority to access. However, given the god-like authority of auditors these days, maybe it would be more helpful to you (and easier to get past the auditors) to have an additional parameter to RACROUTE which said, in effect, Don't tell me about any violations. I don't care if you record the attempted access in SMF, but don't bother telling me about it. I.E., suppress the message but go ahead and cut a record if you want to. Of course, that doesn't address the SMF noise issue for those who really need to track attempted accesses to truly important resources to detect actual hacking attempts. Just my USD$0.02 worth. 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. -- 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: Newbie RACROUTE question: how to *test* authorization?
I agree with you about this type of harmless testing of authority to access. However, given the god-like authority of auditors these days, maybe it would be more helpful to you (and easier to get past the auditors) to have an additional parameter to RACROUTE which said, in effect, Don't tell me about any violations. I don't care if you record the attempted access in SMF, but don't bother telling me about it. I.E., suppress the message but go ahead and cut a record if you want to. You can supress the ICH408I message is you wish with MSGSUPP=YES in the RACROUTE=AUTH call and you can supress the message and SMF logging with LOG=NONE. My .02 cents worth. George Fogg -- 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: Newbie RACROUTE question: how to *test* authorization?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Shmuel Metz (Seymour J.) In [EMAIL PROTECTED], on 02/23/2008 at 10:07 AM, Walt Farrell said: One could argue that letting you determine your access to resources without actually trying to use them (and thus without causing audit records) is a form of hacking. Perhaps, but some IBM code does exactly that, and for what seems to be good cause. I don't recall the details, but it was discussed here in the last few years. CICS offers the EXEC CICS QUERY SECURITY command as a supported API. -jc- -- 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: Newbie RACROUTE question: how to *test* authorization?
One could argue that letting you determine your access to resources without actually trying to use them (and thus without causing audit records) is a form of hacking. Perhaps, but some IBM code does exactly that, and for what seems to be good cause. I don't recall the details, but it was discussed here in the last few years. You may be thinking of ISPF 3.4 and data set name hiding or may be thinking of ISPF 3.4 checking for ALTER access to the catalog. Following extracted from the CICS/TS RACF Security Guide: 2.7.6.2 Checking which transactions to offer a user You can use the QUERY SECURITY command to check whether a user is authorized to use a particular transaction before displaying the transaction code as part of an introductory menu. When you use the command for this purpose, you will probably want to avoid logging the checks for users who are not allowed to use certain transactions. To do this, use the NOLOG option. ...and the QUERY SECURITY command invokes a RACROUTE to perform this function. So CICS is documenting use of preemptive RACROUTE requests as reasonable design in presenting usable options on a user's menu. Randy Evans, Viaserv, Inc. -- 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: Newbie RACROUTE question: how to *test* authorization?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Randy Evans One could argue that letting you determine your access to resources without actually trying to use them (and thus without causing audit records) is a form of hacking. Perhaps, but some IBM code does exactly that, and for what seems to be good cause. I don't recall the details, but it was discussed here in the last few years. You may be thinking of ISPF 3.4 and data set name hiding or may be thinking of ISPF 3.4 checking for ALTER access to the catalog. Following extracted from the CICS/TS RACF Security Guide: 2.7.6.2 Checking which transactions to offer a user You can use the QUERY SECURITY command to check whether a user is authorized to use a particular transaction before displaying the transaction code as part of an introductory menu. When you use the command for this purpose, you will probably want to avoid logging the checks for users who are not allowed to use certain transactions. To do this, use the NOLOG option. ...and the QUERY SECURITY command invokes a RACROUTE to perform this function. So CICS is documenting use of preemptive RACROUTE requests as reasonable design in presenting usable options on a user's menu. I've heard that CICS issues RACROUTE REQUEST=FASTAUTH under the covers to do that. CICS also issues RACROUTE REQUEST=LIST,GLOBAL=YES during its startup for each of the CICS-related classes activated via the DFHSIT Xyyy parms, so RACLISTing of one sort or another may be a pre-req for FASTAUTH. -jc- -- 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: Newbie RACROUTE question: how to *test* authorization?
--snip--- Following extracted from the CICS/TS RACF Security Guide: 2.7.6.2 Checking which transactions to offer a user You can use the QUERY SECURITY command to check whether a user is authorized to use a particular transaction before displaying the transaction code as part of an introductory menu. When you use the command for this purpose, you will probably want to avoid logging the checks for users who are not allowed to use certain transactions. To do this, use the NOLOG option. ...and the QUERY SECURITY command invokes a RACROUTE to perform this function. So CICS is documenting use of preemptive RACROUTE requests as reasonable design in presenting usable options on a user's menu. --unsnip--- IIRC, under this particular set of circumstances, RACROUTE will do the equivalent of a FRACHECK, which does no logging. Has to do with the resource definitions for CICS transactions. -- 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: Newbie RACROUTE question: how to *test* authorization?
On Sat, 23 Feb 2008 10:07:24 -0600, Walt Farrell wrote: One could argue that letting you determine your access to resources without actually trying to use them (and thus without causing audit records) is a form of hacking. You're looking around trying to figure out what you can do, rather than simply doing your job. We have a JCL checker application that verifies dataset access for a JOB. Through routine use of this product, we end up with thousands of access warnings on our daily RACF reports. This is not a hacking attempt. If there were hacking attempts occuring, it would be tough to see them through the noise though. I'm going to try to see if I can have this product changed to use a non-logged access check. -- 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: Newbie RACROUTE question: how to *test* authorization?
On Mon, Feb 25, 2008 at 2:08 PM, Dave Kopischke [EMAIL PROTECTED] wrote: On Sat, 23 Feb 2008 10:07:24 -0600, Walt Farrell wrote: One could argue that letting you determine your access to resources without actually trying to use them (and thus without causing audit records) is a form of hacking. You're looking around trying to figure out what you can do, rather than simply doing your job. We have a JCL checker application that verifies dataset access for a JOB. Through routine use of this product, we end up with thousands of access warnings on our daily RACF reports. This is not a hacking attempt. If there were hacking attempts occuring, it would be tough to see them through the noise though. I'm going to try to see if I can have this product changed to use a non-logged access check. Another legitimate (IMO) use of this sort of function is a to automatically convert an ISPF Edit request to View in the event that the user does not have UPDATE access to the requested data set. This helps to reduce accidental violations. -- 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: Newbie RACROUTE question: how to *test* authorization?
One major difference. In CICS, the query security is for a subset of RACF information, and is already running in the proper environment, ie CICS, and is using the logged on userid's ACEE. You cannot issue a query security to see if another user has the authority, and you also cannot check for access to non-CICS resources. Because of things like PADS or WHEN() processing, it is hard to guarantee that you can get the same answer if the environment is different. Wayne Driscoll Product Developer [EMAIL PROTECTED] (Direct) (630) 663-0719 (Mobile) (630) 247-1632 -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Randy Evans Sent: Monday, February 25, 2008 9:05 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Newbie RACROUTE question: how to *test* authorization? One could argue that letting you determine your access to resources without actually trying to use them (and thus without causing audit records) is a form of hacking. Perhaps, but some IBM code does exactly that, and for what seems to be good cause. I don't recall the details, but it was discussed here in the last few years. You may be thinking of ISPF 3.4 and data set name hiding or may be thinking of ISPF 3.4 checking for ALTER access to the catalog. Following extracted from the CICS/TS RACF Security Guide: 2.7.6.2 Checking which transactions to offer a user You can use the QUERY SECURITY command to check whether a user is authorized to use a particular transaction before displaying the transaction code as part of an introductory menu. When you use the command for this purpose, you will probably want to avoid logging the checks for users who are not allowed to use certain transactions. To do this, use the NOLOG option. ...and the QUERY SECURITY command invokes a RACROUTE to perform this function. So CICS is documenting use of preemptive RACROUTE requests as reasonable design in presenting usable options on a user's menu. Randy Evans, Viaserv, Inc. -- 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: Newbie RACROUTE question: how to *test* authorization?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Wayne Driscoll One major difference. In CICS, the query security is for a subset of RACF information, and is already running in the proper environment, ie CICS, and is using the logged on userid's ACEE. You cannot issue a query security to see if another user has the authority, ... True. ... and you also cannot check for access to non-CICS resources. Check out the RESCLASS keyword on QUERY SECURITY: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DFHP4C00/1.16 8 RESCLASS(data-value) specifies an 8-character field identifying the name of a valid resource class, that could be non-CICS, in the ESM. The class name identified by RESCLASS is treated literally with no translation. -jc- -- 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: Newbie RACROUTE question: how to *test* authorization?
On Mon, 25 Feb 2008 13:08:53 -0600, Dave Kopischke wrote: We have a JCL checker application that verifies dataset access for a JOB. Through routine use of this product, we end up with thousands of access warnings on our daily RACF reports. This is not a hacking attempt. If there were hacking attempts occuring, it would be tough to see them through the noise though. I wonder that you get thousands of access warnings ... daily. Are your programmers commiting so many potential access errors in the course of coding their JCL? How many programmers does it take to do that? And my thanks to Randy Evans for reminding us that design of interactive systems imposes requirements that are not encountered in batch jobs. -- gil -- 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: Newbie RACROUTE question: how to *test* authorization?
In [EMAIL PROTECTED], on 02/22/2008 at 02:52 PM, Walt Farrell [EMAIL PROTECTED] said: Running APF-authorized you could specify LOG=NONE. However, in most cases I recommend simply letting the system make the appropriate checks Doesn't LOG=NONE allow that? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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: Newbie RACROUTE question: how to *test* authorization?
In [EMAIL PROTECTED], on 02/23/2008 at 10:07 AM, Walt Farrell [EMAIL PROTECTED] said: One could argue that letting you determine your access to resources without actually trying to use them (and thus without causing audit records) is a form of hacking. Perhaps, but some IBM code does exactly that, and for what seems to be good cause. I don't recall the details, but it was discussed here in the last few years. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html 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: Newbie RACROUTE question: how to *test* authorization?
On Sat, 23 Feb 2008 10:07:24 -0600, Walt Farrell wrote: One could argue that letting you determine your access to resources without actually trying to use them (and thus without causing audit records) is a form of hacking. You're looking around trying to figure out what you can do, rather than simply doing your job. I'm not sure why RACF allowed STATUS=ACCESS without APF authorization, but in hindsight I consider it to have been a mistake. However, changing it at this point would break an unpredictable number of applications. That may be the price of increased security awareness. Perhaps YA PARMLIB option to control it or enable logging negative responses? Should similar concerns apply to LISTDSD, mentioned elsewhere in this thread? Do sites similarly log, audit, and investigate storage protection exceptions? OTOH, I can readily imagine a utility that attempts an access but on failure proceeds with restricted function. As an example for Shmuel, see message GIM69158I, or perhaps IEB1099I. --gil -- 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: Newbie RACROUTE question: how to *test* authorization?
On Sat, 23 Feb 2008 19:01:19 -0500, Shmuel Metz (Seymour J.) [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], on 02/23/2008 at 10:07 AM, Walt Farrell [EMAIL PROTECTED] said: One could argue that letting you determine your access to resources without actually trying to use them (and thus without causing audit records) is a form of hacking. Perhaps, but some IBM code does exactly that, and for what seems to be good cause. I don't recall the details, but it was discussed here in the last few years. You may be thinking of ISPF 3.4 and data set name hiding or may be thinking of ISPF 3.4 checking for ALTER access to the catalog. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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: Newbie RACROUTE question: how to *test* authorization?
IBM-MAIN@BAMA.UA.EDU wrote: On Sat, 23 Feb 2008 10:07:24 -0600, Walt Farrell wrote: One could argue that letting you determine your access to resources without actually trying to use them (and thus without causing audit records) is a form of hacking. You're looking around trying to figure out what you can do, rather than simply doing your job. I'm not sure why RACF allowed STATUS=ACCESS without APF authorization, but in hindsight I consider it to have been a mistake. However, changing it at this point would break an unpredictable number of applications. That may be the price of increased security awareness. Perhaps YA PARMLIB option to control it or enable logging negative responses? Should similar concerns apply to LISTDSD, mentioned elsewhere in this thread? Do sites similarly log, audit, and investigate storage protection exceptions? OTOH, I can readily imagine a utility that attempts an access but on failure proceeds with restricted function. As an example for Shmuel, see message GIM69158I, or perhaps IEB1099I. --gil And YA email address, eh, Paul? Is this another manifestation of the merger finally taking place? Kind regards, -Steve Comstock The Trainer's Friend, Inc. 303-393-8716 http://www.trainersfriend.com z/OS Application development made easier * Our classes include + How things work + Programming examples with realistic applications + Starter / skeleton code + Complete working programs + Useful utilities and subroutines + Tips and techniques -- 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: Newbie RACROUTE question: how to *test* authorization?
I don't think you are fixing the problem correctly. Now I do apologize but if it was me I go MVS native and Forget about installing VM -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Sunday, February 24, 2008 10:42 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Newbie RACROUTE question: how to *test* authorization? On Sat, 23 Feb 2008 19:01:19 -0500, Shmuel Metz (Seymour J.) [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], on 02/23/2008 at 10:07 AM, Walt Farrell [EMAIL PROTECTED] said: One could argue that letting you determine your access to resources without actually trying to use them (and thus without causing audit records) is a form of hacking. Perhaps, but some IBM code does exactly that, and for what seems to be good cause. I don't recall the details, but it was discussed here in the last few years. You may be thinking of ISPF 3.4 and data set name hiding or may be thinking of ISPF 3.4 checking for ALTER access to the catalog. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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 __ Information from ESET NOD32 Antivirus, version of virus signature database 2898 (20080223) __ The message was checked by ESET NOD32 Antivirus. part000.txt - is OK http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 2898 (20080223) __ The message was checked by ESET NOD32 Antivirus. Email message - is OK Email message - is OK http://www.eset.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: Newbie RACROUTE question: how to *test* authorization?
I HAVENT WORKED IN THAT AREA FOR a while but I think possibly I can look the dump and fix it permanently -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Reza Fatemi Sent: Sunday, February 24, 2008 7:10 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Newbie RACROUTE question: how to *test* authorization? Importance: High I don't think you are fixing the problem correctly. Now I do apologize but if it was me I go MVS native and Forget about installing VM -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Sunday, February 24, 2008 10:42 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Newbie RACROUTE question: how to *test* authorization? On Sat, 23 Feb 2008 19:01:19 -0500, Shmuel Metz (Seymour J.) [EMAIL PROTECTED] wrote: In [EMAIL PROTECTED], on 02/23/2008 at 10:07 AM, Walt Farrell [EMAIL PROTECTED] said: One could argue that letting you determine your access to resources without actually trying to use them (and thus without causing audit records) is a form of hacking. Perhaps, but some IBM code does exactly that, and for what seems to be good cause. I don't recall the details, but it was discussed here in the last few years. You may be thinking of ISPF 3.4 and data set name hiding or may be thinking of ISPF 3.4 checking for ALTER access to the catalog. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.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 __ Information from ESET NOD32 Antivirus, version of virus signature database 2898 (20080223) __ The message was checked by ESET NOD32 Antivirus. part000.txt - is OK http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 2898 (20080223) __ The message was checked by ESET NOD32 Antivirus. Email message - is OK Email message - is OK http://www.eset.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 __ Information from ESET NOD32 Antivirus, version of virus signature database 2898 (20080223) __ The message was checked by ESET NOD32 Antivirus. part000.txt - is OK http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 2898 (20080223) __ The message was checked by ESET NOD32 Antivirus. Email message - is OK Email message - is OK http://www.eset.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: Newbie RACROUTE question: how to *test* authorization?
On Fri, 22 Feb 2008 14:43:03 -0600, David Eisenberg [EMAIL PROTECTED] wrote: Another way is to issue a RACROUTE REQUEST=EXTRACT LOG=NONE Am I correct when I say that both of these solutions require APF-authorization (or similar)? Might there be a way that would not require this? Yes, all the methods discussed so far would require APF authorization. One that would not (with RACF) is to specify STATUS=ACCESS. I wouldn't have thought that there would be a security issue with merely interrogating an authorization level, but perhaps I'm wrong... One could argue that letting you determine your access to resources without actually trying to use them (and thus without causing audit records) is a form of hacking. You're looking around trying to figure out what you can do, rather than simply doing your job. It may be clearer if you consider that perhaps *you* are not the one looking around, but perhaps you've unintentionally executed a trojan horse program of some sort, that is trying to figure out what damage it could do using your authorities. I'm not sure why RACF allowed STATUS=ACCESS without APF authorization, but in hindsight I consider it to have been a mistake. However, changing it at this point would break an unpredictable number of applications. By the way, I also would not recommend that you use this function. My advice in another message about letting the system do the checking still stands. -- Walt Farrell, CISSP IBM STSM, 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: Newbie RACROUTE question: how to *test* authorization?
On 23 Feb 2008 08:07:34 -0800, in bit.listserv.ibm-main (Message-ID:[EMAIL PROTECTED]) [EMAIL PROTECTED] (Walt Farrell) wrote: I wouldn't have thought that there would be a security issue with merely interrogating an authorization level, but perhaps I'm wrong... One could argue that letting you determine your access to resources without actually trying to use them (and thus without causing audit records) is a form of hacking. You're looking around trying to figure out what you can do, rather than simply doing your job. For your own userid, you can use LISTDSD or RLIST to check resource authorization without cutting audit records. But, unless you have sufficient RACF or APF authorization, you can't check the access *someone else* has to resources. -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur at intergate dot 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: SPAM: Re: Newbie RACROUTE question: how to *test* authorization?
---snip- My advice in another message about letting the system do the checking still stands. ---unsnip I strongly agree. Consider that a potential customer may WANT all the logging he can get, possibly weeding out dishonest employees, or at least preventing them from doing damage and revealing their presence. Other shops, like the ones I've been involved with, may want their own complete control. And auditors LOVE audit trails, the more complete the better. -- 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: Newbie RACROUTE question: how to *test* authorization?
For your own userid, you can use LISTDSD or RLIST to check resource authorization without cutting audit records. That would be perfect... is LISTDSD something I can do from within an assembler program? Or is there an assembler macro equivalent? All I really need to do is, from within an assembler application, invoke some function that will tell me whether or not the current userid is authorized via a given RACF profile to *read* a resource. The userid will always be either the person who is logged onto TSO or is the submitter of a batch job. It will never be anyone else. I guess I should have said that up front... sorry... David -- 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: Newbie RACROUTE question: how to *test* authorization?
All I really need to do is, from within an assembler application, invoke some function that will tell me whether or not the current userid is authorized via a given RACF profile to *read* a resource. The userid will always be either the person who is logged onto TSO or is the submitter of a batch job. It will never be anyone else. And of course (as I indicated in my original post), I need to be able to do this without producing a RACF violation if the user is not authorized to read the resource. I'll shut up now... David -- 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: Newbie RACROUTE question: how to *test* authorization?
You can call IRRSEQ00 (R_Admin) services within an assembler program to issue RACF commands like LISTDSD and RLIST and you don't need to be APFed for what you want to do. No audit records are cut and no messages to syslog for violations. The command results are sent back into a buffer that you need to parse to find the access level message. See http://tinyurl.com/29f4x9 for the manual, and if you wish, I can send you an assembler example on how to do this to get you started. George Fogg PS: IBM states that command output is not a programming interface. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Eisenberg Sent: Saturday, February 23, 2008 6:29 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Newbie RACROUTE question: how to *test* authorization? For your own userid, you can use LISTDSD or RLIST to check resource authorization without cutting audit records. That would be perfect... is LISTDSD something I can do from within an assembler program? Or is there an assembler macro equivalent? All I really need to do is, from within an assembler application, invoke some function that will tell me whether or not the current userid is authorized via a given RACF profile to *read* a resource. The userid will always be either the person who is logged onto TSO or is the submitter of a batch job. It will never be anyone else. I guess I should have said that up front... sorry... David -- 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: Newbie RACROUTE question: how to *test* authorization?
David Eisenberg wrote: Anyone, I'm just getting familiar with the RACROUTE macro. I have a working example of the macro with REQUEST=AUTH that generates a violation when appropriate. My question is: is there a way to interrogate RACF (presumably via the RACROUTE macro) to simply *ask* whether or not a particular user has read or write access to a dataset, but without actually issuing a violation if the user is unauthorized? All I want to do is get a yea or nay answer (via R15, I assume), then proceed accordingly and programmatically. I hope this makes sense... thank you! David LOG=NOFAIL on the macro call? -- Mark Jacobs Time Customer Service Tampa, FL The dogmas of the quiet past are inadequate to the stormy present. The occasion is piled high with difficulty, and we must rise to the occasion. We cannot escape history. We will be remembered in spite of ourselves. The fiery trial through which we pass will light us down in honor or dishonor, to the last generation. Abraham Lincoln -- 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: Newbie RACROUTE question: how to *test* authorization?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Jacobs Sent: Friday, February 22, 2008 1:16 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Newbie RACROUTE question: how to *test* authorization? David Eisenberg wrote: Anyone, I'm just getting familiar with the RACROUTE macro. I have a working example of the macro with REQUEST=AUTH that generates a violation when appropriate. My question is: is there a way to interrogate RACF (presumably via the RACROUTE macro) to simply *ask* whether or not a particular user has read or write access to a dataset, but without actually issuing a violation if the user is unauthorized? All I want to do is get a yea or nay answer (via R15, I assume), then proceed accordingly and programmatically. I hope this makes sense... thank you! David LOG=NOFAIL on the macro call? -- Mark Jacobs I think that LOG=NONE might be better. That way, successful access is not logged either (in the case where the resource or user is AUDIT'ed). I'd also use USER= to specify the userid for 3rd party access. -- 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: Newbie RACROUTE question: how to *test* authorization?
Another way is to issue a RACROUTE REQUEST=EXTRACT and specify the UACC and/or USERACS fields on the extract FIELDS parameter list. Refer to the RACROUTE Macro Reference appendix-B. That's what we did on last year when we developed the SAF Interface for CA Tape Encryption. (Of course, if I'm wrong I'll let Russ bail me out). Regards, Gary David Eisenberg wrote: Anyone, I'm just getting familiar with the RACROUTE macro. I have a working example of the macro with REQUEST=AUTH that generates a violation when appropriate. My question is: is there a way to interrogate RACF (presumably via the RACROUTE macro) to simply *ask* whether or not a particular user has read or write access to a dataset, but without actually issuing a violation if the user is unauthorized? All I want to do is get a yea or nay answer (via R15, I assume), then proceed accordingly and programmatically. I hope this makes sense... thank you! David LOG=NOFAIL on the macro call? -- Mark Jacobs I think that LOG=NONE might be better. That way, successful access is not logged either (in the case where the resource or user is AUDIT'ed). I'd also use USER= to specify the userid for 3rd party access. -- 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: Newbie RACROUTE question: how to *test* authorization?
Another way is to issue a RACROUTE REQUEST=EXTRACT LOG=NONE Am I correct when I say that both of these solutions require APF-authorization (or similar)? Might there be a way that would not require this? I wouldn't have thought that there would be a security issue with merely interrogating an authorization level, but perhaps I'm wrong... David -- 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: Newbie RACROUTE question: how to *test* authorization?
Gregory, Gary G wrote: Another way is to issue a RACROUTE REQUEST=EXTRACT and specify the UACC and/or USERACS fields on the extract FIELDS parameter list. Does it mean to check the profile, not the access authorities ? IMHO bad idea. Access can be granted i.e. due to OPERATIONS attribute or WARNING. Checking UACC and ACL changes the logic. RACF guys would hate it. My $0.02 -- 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.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- 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: Newbie RACROUTE question: how to *test* authorization?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Eisenberg Sent: Friday, February 22, 2008 2:43 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Newbie RACROUTE question: how to *test* authorization? Another way is to issue a RACROUTE REQUEST=EXTRACT LOG=NONE Am I correct when I say that both of these solutions require APF-authorization (or similar)? Might there be a way that would not require this? I wouldn't have thought that there would be a security issue with merely interrogating an authorization level, but perhaps I'm wrong... David Yes, almost any RACROUTE function requires APF authorization. It could be considered a security breach otherwise because if anybody could do it, they could possibly find which RACF ids to target in order to get the access that they want to specific resources, rather than attempting to crack random IDs and hope for access. -- 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: Newbie RACROUTE question: how to *test* authorization?
On Fri, 22 Feb 2008 15:21:29 -0500, Gregory, Gary G [EMAIL PROTECTED] wrote: Another way is to issue a RACROUTE REQUEST=EXTRACT and specify the UACC and/or USERACS fields on the extract FIELDS parameter list. Refer to the RACROUTE Macro Reference appendix-B. That's what we did on last year when we developed the SAF Interface for CA Tape Encryption. (Of course, if I'm wrong I'll let Russ bail me out). The obvious disadvantages of that approach, of course, are that it burdens you with processing groups to determine the users they contain, and of processing conditional access lists to see if they apply. And it bypasses GLOBAL processing, which an administrator may have decided to use to grant accesses. And you can get the wrong answer for general resource classes (if they're RACLISTed and you make the request the wrong way) or for data sets (if their generic profile is already in storage but the profile has changed on the database). But other than that, and anything else I've forgotten at the moment, and anything we add in the future, I suppose it's an approach you could use. I wouldn't, though. -- Walt Farrell, CISSP IBM STSM, 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: Newbie RACROUTE question: how to *test* authorization?
On Fri, 22 Feb 2008 13:09:26 -0600, David Eisenberg [EMAIL PROTECTED] wrote: I'm just getting familiar with the RACROUTE macro. I have a working example of the macro with REQUEST=AUTH that generates a violation when appropriate. My question is: is there a way to interrogate RACF (presumably via the RACROUTE macro) to simply *ask* whether or not a particular user has read or write access to a dataset, but without actually issuing a violation if the user is unauthorized? All I want to do is get a yea or nay answer (via R15, I assume), then proceed accordingly and programmatically. Running APF-authorized you could specify LOG=NONE. However, in most cases I recommend simply letting the system make the appropriate checks and, if necessary, trapping any ABENDs that result. Otherwise there are a lot of odd conditions you may need to deal with, and that can cause you to get the wrong answer and act incorrectly. You might think that the user will have access, and then the request might fail anyway. Or you might think the user does not have access, and refuse the action, when it would have worked if you had actually tried it. Of course, without knowing more about what your program does I can't say for that you'll have those problems. Still, I generally recommend just letting the system make the decisions. -- Walt Farrell, CISSP IBM STSM, 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: Newbie RACROUTE question: how to *test* authorization?
It's not something that we used to determine whether someone had authority but more of a logging mechanism. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: Friday, February 22, 2008 2:47 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: Newbie RACROUTE question: how to *test* authorization? Gregory, Gary G wrote: Another way is to issue a RACROUTE REQUEST=EXTRACT and specify the UACC and/or USERACS fields on the extract FIELDS parameter list. Does it mean to check the profile, not the access authorities ? IMHO bad idea. Access can be granted i.e. due to OPERATIONS attribute or WARNING. Checking UACC and ACL changes the logic. RACF guys would hate it. My $0.02 -- 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.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- 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
