Re: RMM Tape Dataset Protection (was: discrete profiles for tape protection.)
Bob, You do now have a very good understanding of how RMM is working with RACF to secure and validate tape volumes and data sets. As far as I can see, if you do not have TAPEVOL active - you lose any ability to control the use of BLP. This BLP authorization is only performed today if TAPEVOL is active and also you need ICHBLP in FACILITY class to be defined. - IEHINITT relies on TAPEVOL profiles to check authorization for tape which contain a VOL1 label. - used with TVTOCs RACF will check all data sets on the volume not just the one you are opening. If you are happy to be running without the above abilities, and are happy that the validation rmm does helps further secure access to data on tape ... then that is good. In z/OS V1R8 the new tape authorization support specifically addresses those items in the list above; - direct calls for ICHBLP from OPEN - support for authorization checking other files on the volume - allows TAPEVOL to be active as well if you wish, but only used for applications such as IEHINITT that issue RACROUTE in TAPEVOL class. Mike WoodRMM Development -- 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: RMM Tape Dataset Protection (was: discrete profiles for tape protection.)
Mike, This tread has prompted me to reread the RMM manuals to see where I may have misinterpreted them. Based on this review and comments from Russell and you, here is what I now understand. RMM will itself match the dsname and tape requested by the user against the list of dsnames contained on the tape in its control dataset and reject the request if the full dsname specified by the user doesn't match the full dsname on the list. So in this manner, RMM protects against a user trying to access a tape dataset by falsifying the name. If a RACF TAPEVOL profile with TVTOC is defined, RACF will also validate the dsname for the requested tape and check for the flag indicating a discrete profile. Further, it is necessary for RMM OPMODE to be set to PROTECT for this protection to be fully functional. The RMM option REJECT ANYUSE(*) requires all tapes to be defined to RMM before they can be used, blocking the use of undefined tapes (e.g., foreign tapes), and thereby ensuring the dsname validation is comprehensive. In addition, to bypass this check, the user must have READ (for input) or UPDATE (for output) to FACILITY class profile STGADMIN.EDG.IGNORE.TAPE.volser which is checked when EXPDT=98000 specified, and use of the exit EDGUX100 is required to implement this functionality. All this being true, the use of TAPEVOL profiles with TVTOCs does not seem necessary unless you want to use discrete profiles for a tape dataset or you want to grant access to tapes at the volume level, both of which are rarely done. This would make me shy away from using TPRACF(P) or (A) so as not to have to deal with the TAPEVOL profiles. Are there other security-related reasons why someone would want to maintain these profiles? Thanks, Bob -Original Message- From: Mike Wood [mailto:[EMAIL PROTECTED] Sent: Monday, March 13, 2006 5:06 AM To: IBM-MAIN@BAMA.UA.EDU; Robert Hansel Subject: Re: discrete profiles for tape protection. Bob, To build on to what Russell has said.. In rmm you force all tapes to be rmm managed by including REJECT ANYUSE(*) in parmlib. Now to bypass rmm control you need authorized to have tapes ignored by rmm; very few usres would have that ability. By default rmm forces full 44 character dsname validation for all files on a tape it is managing; you do not need to rely on RACF TVTOC to get that. With a tape management system set up correctly you should be able to use generic DATASET profiles for full tape data set protection. Mike Wood RMM Development On Sat, 11 Mar 2006 15:57:12 -0500, Robert S. Hansel (RSH) [EMAIL PROTECTED] wrote: Mike, Your comments about running without TAPEVOL and/or TVTOC raises the following issue. It is my understanding that with RMM the only way to protect against unauthorized access to a tape dataset by taking inappropriate advantage of tape label containing just the last 17 characters of the dsname (e.g., opening PAY.PROD.MASTER.FILE by calling it MYID.PROD.MASTER.FILE) is by implementing RACF TAPEVOL profiles with TVTOC and setting RMM option TPRACF to either (P) or (A). This causes RACF to keep track of the full dsnames on a given tape and guard against someone falsifying the name. Does RMM have other features or functionality that prevents misnaming tape datasets without involving TAPEVOL TVTOCs? Is yes, can you help me find the reference where it is described? Thanks, Bob -- 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: discrete profiles for tape protection.
John, The function performed by the RMM TPRACF options depends on how you have RACF set up. If you were to inactivate TAPEVOL class rmm stops creating and deleting TAPEVOL profiles for you. With z/OS 1.8 we provide another option for TPRACF that will stop creation of profiles but enable deletion; supporting the gradual migration from TAPEVOL class to use of DATASET/TAPEDSN. Mike Wood RMM Development On Thu, 9 Mar 2006 16:33:35 -0600, John Benik [EMAIL PROTECTED] wrote: you were exactly right TPRACF(A). It sounds like the only way to avoid this is to not use Tapevol any longer, is there something else I should change the TPRACF(A) to? -- 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: discrete profiles for tape protection.
Not to speak for Mike, but as Mike said in his previous email the ability to have generic rules protect individual datasets in place of discrete rules is fine as long as you have a tape management system (any tape management system). To take that one step further however, I would also say as long as you have a tape management system AND have rules in place to prevent un-authorized bypassing of the tape management system you are nearly as safe with generic rules as with discrete profiles. And all tape management systems (CA's, IBM's, BMC's and ASG's) have some ability to protect who can use EXPDT=98000 to bypass the tape management system (that is one thing we all do agree on). So, if you are controlling who can or cannot bypass the tape management system; then unless you have given that user the ability to bypass the tape management system the trick of changing the HLQ will not work (the tape management system would reject the tape since the DSN in the JCL does not match its full-44-character dsname). Russell Witt CA-1 Level-2 Support Manager -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Robert S. Hansel (RSH) Sent: Saturday, March 11, 2006 2:57 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: discrete profiles for tape protection. Mike, Your comments about running without TAPEVOL and/or TVTOC raises the following issue. It is my understanding that with RMM the only way to protect against unauthorized access to a tape dataset by taking inappropriate advantage of tape label containing just the last 17 characters of the dsname (e.g., opening PAY.PROD.MASTER.FILE by calling it MYID.PROD.MASTER.FILE) is by implementing RACF TAPEVOL profiles with TVTOC and setting RMM option TPRACF to either (P) or (A). This causes RACF to keep track of the full dsnames on a given tape and guard against someone falsifying the name. Does RMM have other features or functionality that prevents misnaming tape datasets without involving TAPEVOL TVTOCs? Is yes, can you help me find the reference where it is described? Thanks, Bob -- 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: discrete profiles for tape protection.
Mike, Your comments about running without TAPEVOL and/or TVTOC raises the following issue. It is my understanding that with RMM the only way to protect against unauthorized access to a tape dataset by taking inappropriate advantage of tape label containing just the last 17 characters of the dsname (e.g., opening PAY.PROD.MASTER.FILE by calling it MYID.PROD.MASTER.FILE) is by implementing RACF TAPEVOL profiles with TVTOC and setting RMM option TPRACF to either (P) or (A). This causes RACF to keep track of the full dsnames on a given tape and guard against someone falsifying the name. Does RMM have other features or functionality that prevents misnaming tape datasets without involving TAPEVOL TVTOCs? Is yes, can you help me find the reference where it is described? Thanks, Bob Robert S. Hansel | 2006 RACF Training RACF Specialist| Intro Basic Admin - Cinci., OH - JUN 6-7 RSH Consulting, Inc. | Audit for Results- Boston, MA - MAY 23-24 www.rshconsulting.com | Advanced Admin *NEW* - Boston, MA - MAY 2-4 617-969-8211 | See our website for details registration form -Original Message- Date:Thu, 9 Mar 2006 13:17:19 -0600 From:Mike Wood [EMAIL PROTECTED] Subject: Re: discrete profiles for tape protection. John, You do not give any details about your setup of rmm and RACF, but I would guess that you are using rmm parmlib option TPRACF(P) or TPRACF(A). It is very likely that it is rmm creating the TVTOC and the first data set gets added either by OPEN issuing RACROUTE in DATASET class or by rmm when the data set is closed. You could consider larger logical volumes sizes since VTS now supports this option, or you have to avoid the problem by not using both TAPEVOL class and the TAPEDSN option. Many people do use TAPEDSN without TAPEVOL. As long as you have tape management, and you do, you can consider running without TVTOCs, and most likely this means not using TAPEVOL. There are other considerations such as BLP and use of ustilities such as IEHINITT. Limitations such as this are just some of the reasons why we have previewed new tape data set security options in z/OS 1.8. http://www- 03.ibm.com/servers/eserver/zseries/zos/overview/zosnew18_preview.html Mike WoodRMM Development -- 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: discrete profiles for tape protection.
I'm not sure if my question on this went out or not. Through many trials I was finally able to get a job to abend after writing virtual tapes. The only way I was able to do this however was to use a file that was on tape already and it was using the fat tape 200gb. So I'm not sure if the error I'm seeing is because it was on tape already or if it's something in RACF. When I do a racf list of the tape vol it does not look like we are using discrete profiles, but it does look like we have TVTOC on. I'm just looking for insight on how we could possibly get around this, as our direction is to go to virtual tape with almost all tape files. 21.09.22 JOB31505 IEC029I 937- 40,IFG0552B,TSUAW6OZ,CRETREMT,DD01O,,xx,TSUAW6O.VSM.MULTI.GT42 21.09.22 JOB31505 IEA995I SYMPTOM DUMP OUTPUT 713 713 SYSTEM COMPLETION CODE=0C1 REASON CODE=0001 713 TIME=21.09.22 SEQ=02515 CPU= ASID=0032 This is a section of the RACF list for the input tape volume. The only difference is that there are different user IDs for the virtual tape creation and also it spans across 42 volumes, abend occurs on the 43rd volume. Which would lead me to believe that we would need to set NOTVTOC for all virtual. I no longer believe this is a discrete profile issue, but willing to listen to any possible explanation. TVTOC INFORMATION FOR DATASET CREATION DATE FILE SEQUENCE (DAY) (YEAR) DISCRETE PROFILE - - 0001 061 06 NO -- 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: discrete profiles for tape protection.
On 3/9/2006 8:25 AM, John Benik wrote: I'm not sure if my question on this went out or not. Through many trials I was finally able to get a job to abend after writing virtual tapes. The only way I was able to do this however was to use a file that was on tape already and it was using the fat tape 200gb. So I'm not sure if the error I'm seeing is because it was on tape already or if it's something in RACF. When I do a racf list of the tape vol it does not look like we are using discrete profiles, but it does look like we have TVTOC on. I'm just looking for insight on how we could possibly get around this, as our direction is to go to virtual tape with almost all tape files. ...snipped... You cannot use TVTOCs in the TAPEVOL profiles for tapes if the data sets on those tapes will span more than 42 volumes. So you will need to specify NOTVTOC for those TAPEVOL profiles. I might wonder whether you should be using TAPEVOL profiles at all, but I will confess I know very little about virtual tapes. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: discrete profiles for tape protection.
John, You do not give any details about your setup of rmm and RACF, but I would guess that you are using rmm parmlib option TPRACF(P) or TPRACF(A). It is very likely that it is rmm creating the TVTOC and the first data set gets added either by OPEN issuing RACROUTE in DATASET class or by rmm when the data set is closed. You could consider larger logical volumes sizes since VTS now supports this option, or you have to avoid the problem by not using both TAPEVOL class and the TAPEDSN option. Many people do use TAPEDSN without TAPEVOL. As long as you have tape management, and you do, you can consider running without TVTOCs, and most likely this means not using TAPEVOL. There are other considerations such as BLP and use of ustilities such as IEHINITT. Limitations such as this are just some of the reasons why we have previewed new tape data set security options in z/OS 1.8. http://www- 03.ibm.com/servers/eserver/zseries/zos/overview/zosnew18_preview.html Mike WoodRMM Development -- 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: discrete profiles for tape protection.
you were exactly right TPRACF(A). It sounds like the only way to avoid this is to not use Tapevol any longer, is there something else I should change the TPRACF(A) to? -- 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: discrete profiles for tape protection.
On 2/26/2006 1:12 PM, John Benik wrote: We have recently begun a tapecopy process from IBM VTS's to STK VSM's. We have run into a few files that on the IBM side exceeded the max vol count for discrete profiles, but when trying to copy them to STK there is an issue and the discrete profile only allows them to go 42 volumes. On the IBM side some of these went to 90 volumes. When I questioned our outsourcer about this, they said they seemed to remember something being setup special for the IBM Vts's. I had our security department look at this and they stated that the tapevol profiles are the same. Since we are an RMM shop is this something that we would have to control in RMM? Also are discrete profiles something we should be using or can we eliminate them and still be protected in our tape environment? It is likely that you defined the original TAPEVOL profiles using the NOTVTOC operand on the RDEFINE TAPEVOL command. Walt Farrell, CISSP z/OS Security Design, IBM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
discrete profiles for tape protection.
We have recently begun a tapecopy process from IBM VTS's to STK VSM's. We have run into a few files that on the IBM side exceeded the max vol count for discrete profiles, but when trying to copy them to STK there is an issue and the discrete profile only allows them to go 42 volumes. On the IBM side some of these went to 90 volumes. When I questioned our outsourcer about this, they said they seemed to remember something being setup special for the IBM Vts's. I had our security department look at this and they stated that the tapevol profiles are the same. Since we are an RMM shop is this something that we would have to control in RMM? Also are discrete profiles something we should be using or can we eliminate them and still be protected in our tape environment? -- 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: discrete profiles for tape protection.
Since the 42-volume limit for a discrete tape dataset profile, I doubt that the tape management system could over-ride this. You may have been given some special usermod to RACF to disable the abend that occurs when the 42-volume limit is reached, and simply allow more volumes to be created. But such a usermod would have worked regardless of the tape library. If you have an existing 90-volume dataset with a discrete tape dataset profile I would list that profile and ask IBM how it is supported. As to the question of discrete dataset and/or volume profiles; I have always thought them obsolete since support for generic profiles was introduced. As long as you have a tape management system that is secure and does the full 44-character DSN checking (they all do); you are as secure with generic profiles as with discrete profiles. If you have a unique environment were discrete profiles are necessary (each dataset has a unique set of access's); then I would believe you also have discrete dataset profiles for all your disk datasets as well. Why treat them differently. The only exception that is reasonable would be to allow discrete tape-volume (TAPEVOL) profiles for foreign tapes when you do not have a tape management system that will allow you to completely protect your in-house tapes and allow more open-access for foreign tapes (the issue with running with TAPEDSN and handling foreign tapes, which has been discussed many times before). But then you must remember to delete the TAPEVOL profile when finished and make sure that the foreign volser does not match any in-house volsers. Russell Witt CA-1 Level-2 Support Manager -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of John Benik Sent: Sunday, February 26, 2006 12:12 PM To: IBM-MAIN@BAMA.UA.EDU Subject: discrete profiles for tape protection. We have recently begun a tapecopy process from IBM VTS's to STK VSM's. We have run into a few files that on the IBM side exceeded the max vol count for discrete profiles, but when trying to copy them to STK there is an issue and the discrete profile only allows them to go 42 volumes. On the IBM side some of these went to 90 volumes. When I questioned our outsourcer about this, they said they seemed to remember something being setup special for the IBM Vts's. I had our security department look at this and they stated that the tapevol profiles are the same. Since we are an RMM shop is this something that we would have to control in RMM? Also are discrete profiles something we should be using or can we eliminate them and still be protected in our tape environment? -- 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: discrete profiles for tape protection.
Hi, The DFSMSrmm observation I feel might be worth considering, as per the z/OS V1R7.0 DFSMSrmm Implementation and Customization Guide (dgt2c840) manual. Section 11.9.1 Recommendations for Using RACF Tape Profile Processing states: 1. The maximum number of entries for data sets that a TVTOC can contain is 500. Attention: Processing that creates large numbers of TVTOC entries and large access lists, for example, could result in an attempt to exceed the maximum profile size. 2. The maximum number of volumes that any data set on the tape with an entry in the TVTOC can span is 42. 3. The maximum number of volumes that any data set on tape without a| TVTOC can span is limited only by the maximum profile size. Basically this all relates to TAPEVOL and TAPEDSN usage with either the DFSMSrmm options TPRACF(P) or TPRACF(A). I dont really understand why there is different behaviour for IBM VTS versus StorageTek VSM, but I wonder whether there might be some legacy exit code in the form of ADSP or PROTECT=YES which might be VTS dependant? Ultimately I guess you might want to review your installations TAPEDSN and TAPEVOL settings and decide on what they might be. Regards, UK Mikey. On Sun, 26 Feb 2006 12:12:28 -0600, John Benik [EMAIL PROTECTED] wrote: We have recently begun a tapecopy process from IBM VTS's to STK VSM's. We have run into a few files that on the IBM side exceeded the max vol count for discrete profiles, but when trying to copy them to STK there is an issue and the discrete profile only allows them to go 42 volumes. On the IBM side some of these went to 90 volumes. When I questioned our outsourcer about this, they said they seemed to remember something being setup special for the IBM Vts's. I had our security department look at this and they stated that the tapevol profiles are the same. Since we are an RMM shop is this something that we would have to control in RMM? Also are discrete profiles something we should be using or can we eliminate them and still be protected in our tape environment? -- 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
