Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
:: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Paul Gilmartin :: Sent: Monday, April 14, 2014 8:51 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED) :: :: On Wed, 9 Apr 2014 14:27:28 +, Storr, Lon A CTR USARMY HRC (US) :: wrote: :: :: When a dataset is deleted, it is scratched and its DSCB in the VTOC is :: freed. Hence, as far as I know, the dataset's data can only be accessed :: in one of two ways: :: :: Pedantry: have no DSCB? Is there not in fact a DSCB describing such :: an extent? Perhaps a Format 5, or thereabouts? Only for non-indexed volumes. If the volume is indexed, the free space details are kept in the index, not the VTOC. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
W dniu 2014-04-15 11:11, retired mainframer pisze: :: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Paul Gilmartin :: Sent: Monday, April 14, 2014 8:51 PM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED) :: :: On Wed, 9 Apr 2014 14:27:28 +, Storr, Lon A CTR USARMY HRC (US) :: wrote: :: :: When a dataset is deleted, it is scratched and its DSCB in the VTOC is :: freed. Hence, as far as I know, the dataset's data can only be accessed :: in one of two ways: :: :: Pedantry: have no DSCB? Is there not in fact a DSCB describing such :: an extent? Perhaps a Format 5, or thereabouts? Only for non-indexed volumes. If the volume is indexed, the free space details are kept in the index, not the VTOC. Nevermind, the question was about free space, regardless of the wording used to descirbe it. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
If you deleted a dataset and the DASD is thin provisioned, it will recycle the tracks when the VTOC is updated, and the records are gone. If you deleted a dataset and RACF has Secure erase, the tracks are erased before the VTOC is updated. If you deleted a dataset and another dataset has allocated and written on those tracks, the data is destroyed when overwritten. If you deleted a dataset, and the three ways to destroy the data have not occurred, then you use Absolute Track allocation to re-allocate those tracks and read them. The DCB must match, along with directory entries. On Mon, Apr 14, 2014 at 10:50 PM, Paul Gilmartin paulgboul...@aim.com wrote: On Wed, 9 Apr 2014 14:27:28 +, Storr, Lon A CTR USARMY HRC (US) wrote: When a dataset is deleted, it is scratched and its DSCB in the VTOC is freed. Hence, as far as I know, the dataset's data can only be accessed in one of two ways: Pedantry: have no DSCB? Is there not in fact a DSCB describing such an extent? Perhaps a Format 5, or thereabouts? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
On Tue, 15 Apr 2014 11:33:39 -0500, Mike Schwab wrote: If you deleted a dataset, and the three ways to destroy the data have not occurred, then you use Absolute Track allocation to re-allocate those tracks and read them. The DCB must match, along with directory entries. FSVO match. Nearly anything ought to be readable with RECFM=U. Keys make it more complicated, but there are (used to be?) CCWs for this (backup utilites need them). An assembler program can read beyond end-of-file (to wit the utilities for recovering deleted PDS members). PDSE, HFS, and zFS are harder yet, in part because of ab$ence of documentation. I thought no DCB information as such is retained for a deleted data set. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
On Wed, 9 Apr 2014 14:27:28 +, Storr, Lon A CTR USARMY HRC (US) wrote: When a dataset is deleted, it is scratched and its DSCB in the VTOC is freed. Hence, as far as I know, the dataset's data can only be accessed in one of two ways: Pedantry: have no DSCB? Is there not in fact a DSCB describing such an extent? Perhaps a Format 5, or thereabouts? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
On 4/9/2014 2:49 PM, R.S. wrote: IMHO remote access to the DASD box does not include access to data on disks. Yes, CE can switch off the machine, but not access data. Do you know any confirmed case where CE access to data was given with remote (or even local) access? While I can't speak to current controllers, I had a long discussion with the Hitachi C.E. about the capabilities. However, we never had a security breach, and had a policy of having a systems programmer watch C.E.s at work (running diagnostics). Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
In 53459a09.8020...@bremultibank.com.pl, on 04/09/2014 at 09:05 PM, R.S. r.skoru...@bremultibank.com.pl said: There are several tools which allows user to read free disk space. ADRDSSU, AMASPZAP, DITTO are few of them. However those tools require some special authorization, all of the tools I mentioned are controlled by RACF CL(FACILITY) profiles (and can be blocked at all using PROGRAM class) - so I wouldn't worry about them. BTW: those tools should be reasonably controlled for other reasons Lack of training? Lack of change control for production libraries? Management that doesn't understand that those tools won't give a user access to any data that he doesn't already have? Awkward syntax? I don't know of any legitimate reason to restrict access to the unauthorized functions of those programs. -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
3) allocate a new data set and be sure that the DSORG is _not_ specified either in the JCL or via the DATACLAS, or that it is DA. This tells DADSM to _not_ write an EOF or anything else in the newly allocate disk space. If you need to inspect some specific tracks, _and the disk is not SMS managed_, then use ABSTR allocation. Once allocated, you can use BSAM or BDAM to read the data as RECFM=U to simply read the uninterpreted blocks of data (physical blocks). Or, once allocated, you can use ADRDSSU to DUMP the tracks in HEX format. Again, you are simply fishing and hoping to see something interesting. Back, long ago, I have a manager who did this for _every_ disk volume we ever installed just because he was curious. This was in the 3350 days. In today's environment where the back end is usually RAID 5, I would say the likelihood of someone getting one of the array drives, inspecting it, and finding proprietary information of any use is very unlikely. But if you have credit card data, or HIPAA data then it _might_ be a good idea for CYA. On Wed, Apr 9, 2014 at 9:27 AM, Storr, Lon A CTR USARMY HRC (US) lon.a.storr@mail.mil wrote: Classification: UNCLASSIFIED Caveats: NONE Hello List, Due to an audit requirement, we shall be enabling the ERASE function provided by RACF. We know better than to resist this mandate but it did make me wonder about the purpose of this feature. When a dataset is deleted, it is scratched and its DSCB in the VTOC is freed. Hence, as far as I know, the dataset's data can only be accessed in one of two ways: 1) Via a utility like AMASPZAP that accepts CCHHR addresses 2) Via a program that uses EXCPVR (or SSCH) In case #2, the program must be authorized in some way (i.e. key 0-7, supervisor state or APF-authorized). In case #1, most installations (including us) use program protection to restrict users of these utilities. A user would have to be authorized in some way (i.e. key 0-7, supervisor state or APF-authorized) to bypass that protection. It therefore seems to me that a user must have the ability to become authorized in some way to access areas of DASD (in which a deleted dataset resided) by CCHHR. A user who has become authorized in some way can also access any live (undeleted) dataset. Why then are we worried that a user who can access any live dataset in the system may attempt to access a deleted dataset? If the aforementioned is true and complete, the ERASE functionality doesn't appear to have any practical purpose other than to slow down the scratch process. So, I assume that I'm missing something. Can someone please identify the flaw in my logic? Can a non-authorized user gain access to these scratched areas of DASD? Thanks, Alan Classification: UNCLASSIFIED Caveats: NONE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: NONE Thank you John. I had overlooked both of those mechanisms. Using ADRDSSU doesn't worry me because it's program protected but there does not appear to be an easy way to protect usage of the ABSTR keyword in JCL. Best regards, Alan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of John McKown Sent: Wednesday, April 09, 2014 10:41 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED) 3) allocate a new data set and be sure that the DSORG is _not_ specified either in the JCL or via the DATACLAS, or that it is DA. This tells DADSM to _not_ write an EOF or anything else in the newly allocate disk space. If you need to inspect some specific tracks, _and the disk is not SMS managed_, then use ABSTR allocation. Once allocated, you can use BSAM or BDAM to read the data as RECFM=U to simply read the uninterpreted blocks of data (physical blocks). Or, once allocated, you can use ADRDSSU to DUMP the tracks in HEX format. Again, you are simply fishing and hoping to see something interesting. Back, long ago, I have a manager who did this for _every_ disk volume we ever installed just because he was curious. This was in the 3350 days. In today's environment where the back end is usually RAID 5, I would say the likelihood of someone getting one of the array drives, inspecting it, and finding proprietary information of any use is very unlikely. But if you have credit card data, or HIPAA data then it _might_ be a good idea for CYA. On Wed, Apr 9, 2014 at 9:27 AM, Storr, Lon A CTR USARMY HRC (US) lon.a.storr@mail.mil wrote: Classification: UNCLASSIFIED Caveats: NONE Hello List, Due to an audit requirement, we shall be enabling the ERASE function provided by RACF. We know better than to resist this mandate but it did make me wonder about the purpose of this feature. When a dataset is deleted, it is scratched and its DSCB in the VTOC is freed. Hence, as far as I know, the dataset's data can only be accessed in one of two ways: 1) Via a utility like AMASPZAP that accepts CCHHR addresses 2) Via a program that uses EXCPVR (or SSCH) In case #2, the program must be authorized in some way (i.e. key 0-7, supervisor state or APF-authorized). In case #1, most installations (including us) use program protection to restrict users of these utilities. A user would have to be authorized in some way (i.e. key 0-7, supervisor state or APF-authorized) to bypass that protection. It therefore seems to me that a user must have the ability to become authorized in some way to access areas of DASD (in which a deleted dataset resided) by CCHHR. A user who has become authorized in some way can also access any live (undeleted) dataset. Why then are we worried that a user who can access any live dataset in the system may attempt to access a deleted dataset? If the aforementioned is true and complete, the ERASE functionality doesn't appear to have any practical purpose other than to slow down the scratch process. So, I assume that I'm missing something. Can someone please identify the flaw in my logic? Can a non-authorized user gain access to these scratched areas of DASD? Thanks, Alan Classification: UNCLASSIFIED Caveats: NONE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Classification: UNCLASSIFIED Caveats: NONE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
On 4/9/2014 10:27 AM, Storr, Lon A CTR USARMY HRC (US) wrote: Can someone please identify the flaw in my logic? Can a non-authorized user gain access to these scratched areas of DASD? I'd add 4) - many modern control units have diagnostic capability that allows unrestricted hardware access to the drives. If yours do, you'll need physical access controls. I first ran into this when we got our first string of Hitachi 3380s. The C.E. wanted a telephone line so he could service the units remotely; I had to educate management that that would allow uncontrolled access to customer data. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
John McKown wrote: 3) allocate a new data set and be sure that the DSORG is _not_ specified either in the JCL or via the DATACLAS, or that it is DA. This tells DADSM to _not_ write an EOF or anything else in the newly allocate disk space. If you need to inspect some specific tracks, _and the disk is not SMS managed_, then use ABSTR allocation. Once allocated, you can use BSAM or BDAM to read the data as RECFM=U to simply read the uninterpreted blocks of data (physical blocks). Or, once allocated, you can use ADRDSSU to DUMP the tracks in HEX format. DITTO (and possibly IDCAMS PRINT) is another friend for such data scavenging/fishing. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: NONE Thanks Gerhard, this is another consideration of which I was unaware. It is certainly significant but I believe that this function would also permit access to live datasets. Hence, the issue is not specific to ERASE. Regards, Alan -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Postpischil Sent: Wednesday, April 09, 2014 10:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED) On 4/9/2014 10:27 AM, Storr, Lon A CTR USARMY HRC (US) wrote: Can someone please identify the flaw in my logic? Can a non-authorized user gain access to these scratched areas of DASD? I'd add 4) - many modern control units have diagnostic capability that allows unrestricted hardware access to the drives. If yours do, you'll need physical access controls. I first ran into this when we got our first string of Hitachi 3380s. The C.E. wanted a telephone line so he could service the units remotely; I had to educate management that that would allow uncontrolled access to customer data. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Classification: UNCLASSIFIED Caveats: NONE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
In a previous instance of my career, I was a member of a team that tested a security product, not RACF and had to verify that the space was ERASED and this was done by using SPACE with it's ABSTR format and SMS was not as popular as it is today. To request specific tracks: SPACE= (ABSTR,(primary-qty,address [,directory]) Request for Specific Tracks For an SMS-managed data set (one with an assigned storage class), do not code ABSTR. ABSTR Requests that the data set be allocated at the specified location on the volume. primary-qty Specifies the number of tracks to be allocated to the data set. The volume must have enough available space for the primary quantity. If it does not, the system terminates the job step. address Specifies the track number of the first track to be allocated. Count the first track of the first cylinder on the volume as 0. Count through the tracks on each cylinder until you reach the track on which you want the data set to start. address Specifies the track number of the first track to be allocated. Count the first track of the first cylinder on the volume as 0. Count through the tracks on each cylinder until you reach the track on which you want the data set to start. The absolute track address must be a decimal number equal to or less than 65535. Note: Do not request track 0. Al Nims Systems Admin/Programmer 3 Information Technology University of Florida (352) 273-1298 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Gerhard Postpischil Sent: Wednesday, April 09, 2014 10:53 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED) On 4/9/2014 10:27 AM, Storr, Lon A CTR USARMY HRC (US) wrote: Can someone please identify the flaw in my logic? Can a non-authorized user gain access to these scratched areas of DASD? I'd add 4) - many modern control units have diagnostic capability that allows unrestricted hardware access to the drives. If yours do, you'll need physical access controls. I first ran into this when we got our first string of Hitachi 3380s. The C.E. wanted a telephone line so he could service the units remotely; I had to educate management that that would allow uncontrolled access to customer data. Gerhard Postpischil Bradford, Vermont -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
On Wed, 9 Apr 2014 14:27:28 +, Storr, Lon A CTR USARMY HRC (US) wrote: ... most installations (including us) use program protection to restrict users of these utilities. Protecting AMASPZAP and ADRDSSU is, in my opinion, not a good way to protect data from them. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
Tom Marchant wrote: ... most installations (including us) use program protection to restrict users of these utilities. Protecting AMASPZAP and ADRDSSU is, in my opinion, not a good way to protect data from them. Agreed. Protect the resource (data), not the method (program). If you still want to limit usage of programs and their functions beside program protection, consider these too: - For ADRDSSU the relevant STGADMIN.whatever profiles in RACF FACILITY class. - DITTO for example has FACILITY class profiles for its functions. Of course, protect your datasets + catalogs. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
:: -Original Message- :: From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :: Behalf Of Storr, Lon A CTR USARMY HRC (US) :: Sent: Wednesday, April 09, 2014 7:27 AM :: To: IBM-MAIN@LISTSERV.UA.EDU :: Subject: Accessing DASD areas that have no DSCB (UNCLASSIFIED) :: :: Classification: UNCLASSIFIED :: Caveats: NONE :: :: Hello List, :: :: Due to an audit requirement, we shall be enabling the ERASE function :: provided by RACF. We know better than to resist this mandate but it did :: make me wonder about the purpose of this feature. :: :: When a dataset is deleted, it is scratched and its DSCB in the VTOC is :: freed. Hence, as far as I know, the dataset's data can only be accessed :: in one of two ways: :: :: 1) Via a utility like AMASPZAP that accepts CCHHR addresses :: 2) Via a program that uses EXCPVR (or SSCH) :: :: In case #2, the program must be authorized in some way (i.e. key 0-7, :: supervisor state or APF-authorized). :: :: In case #1, most installations (including us) use program protection to :: restrict users of these utilities. A user would have to be authorized in :: some way (i.e. key 0-7, supervisor state or APF-authorized) to bypass :: that protection. :: :: It therefore seems to me that a user must have the ability to become :: authorized in some way to access areas of DASD (in which a deleted :: dataset resided) by CCHHR. A user who has become authorized in some way :: can also access any live (undeleted) dataset. Why then are we worried :: that a user who can access any live dataset in the system may attempt to :: access a deleted dataset? :: :: If the aforementioned is true and complete, the ERASE functionality :: doesn't appear to have any practical purpose other than to slow down the :: scratch process. So, I assume that I'm missing something. :: :: Can someone please identify the flaw in my logic? Can a non-authorized :: user gain access to these scratched areas of DASD? As others have noted, there are multiple ways to gain access to previously occupied tracks. But there still can be a practical result from using ERASE. When you initialize a volume, do so without the SMS parameter. Then allocate one or more datasets to completely fill the volume. Delete the dataset(s) and let ERASE zero all the tracks. If necessary, CONVERT the volume to SMS. Make the volume available to users. From that point on, all unused space on the volume should always be zeroed. Note that this is not foolproof. On at least one old STK DASD system, when data is written to a CKD track, the hardware automatically remapped that track to a different FBA address. While a read always returned the current data, the old data was still physically present if anyone could figure out how to get to it. I don't know if any modern DASD systems do something similar. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
On Wed, 9 Apr 2014 11:06:22 -0500, Elardus Engelbrecht wrote: Tom Marchant wrote: ... most installations (including us) use program protection to restrict users of these utilities. Protecting AMASPZAP and ADRDSSU is, in my opinion, not a good way to protect data from them. Agreed. Protect the resource (data), not the method (program). ... Of course, protect your datasets + catalogs. I generally agree. However, any APF-authorized program has a risk of bugs. Consider the horrible thing that was done to SMP/E a few years ago because of a newly recognized security flaw. Is there any way to limit authorized invocation of a utility to selected users and allow all others to invoke it unauthorized? Of course a copy could be installed in a non-authorized library. (Several years ago, I discovered that SMP/E worked pretty well unauthorized as long as I avoided functions that invoke IEBCOPY (I know), ahd used NOWAIT on all my DDDEFs. Don't know about AMASPZAP; skeptical about ADRDSSU. But I disagree strongly with those who will probably argue here that only storage administrators have justifiable use for ADRDSSU. Elitism.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
On Wed, Apr 9, 2014 at 11:44 AM, Paul Gilmartin paulgboul...@aim.comwrote: snip Is there any way to limit authorized invocation of a utility to selected users and allow all others to invoke it unauthorized? Of course a copy could be installed in a non-authorized library. At present, there is no way to have a single copy of a program run with APF authorization based simply on a RACF profile. As I understand it, the program loader in the initiator will set the APF auth bit if (1) the program from the EXEC PGM= is marked AC(1), and (2) it is loaded from an authorized library. (Several years ago, I discovered that SMP/E worked pretty well unauthorized as long as I avoided functions that invoke IEBCOPY (I know), ahd used NOWAIT on all my DDDEFs. Don't know about AMASPZAP; skeptical about ADRDSSU. But I disagree strongly with those who will probably argue here that only storage administrators have justifiable use for ADRDSSU. Elitism.) I don't mind _anybody_ using a program _which they know how to use_. ADRDSSU is generally not one of those. Unfortunately, around here, I sometimes wonder about the COBOL compiler too. -- gil -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
Paul Gilmartin wrote: But I disagree strongly with those who will probably argue here that only storage administrators have justifiable use for ADRDSSU. I'm on your side. My DB2 colleagues and users want ENQ toleration to be, well, tolerated in ADRDSSU. DB2 v10 generates a COPY job which needs FACILITY class profile STGADMIN.ADR.COPY.TOLERATE.ENQF. Before creation of that profile, I explained the risk of that (wearing my storage admin hat). Go figure. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
On Wed, 9 Apr 2014 11:52:07 -0500, John McKown wrote: I don't mind _anybody_ using a program _which they know how to use_. ADRDSSU is generally not one of those. Unfortunately, around here, I sometimes wonder about the COBOL compiler too. Be careful. That view can too easily lead to elitist stereotyping. The storage administrator might believe, No one but a storage administrator could acquire the skills necessary to use ADRDSSU! And, White men can't jump; we don't even let them try out! I wasn't thinking of volume restore; I was only experimenting with ADRDSSU as an alternative to TSO TRANSMIT for data interchange. And I was somewhat dismayed to learn that ADRDSSU RESTORE with RENAME requires READ authority to the original data set name. I understand the rationale for this, but it paints with too broad a brush; READ authority to the archive and WRITE authority to the new data set name should suffice. What if the original data set name doesn't even exist on the receiving system, and UACC=NONE? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
Am 09.04.2014 16:53, schrieb Gerhard Postpischil: I'd add 4) - many modern control units have diagnostic capability that allows unrestricted hardware access to the drives. If yours do, you'll need physical access controls. I first ran into this when we got our first string of Hitachi 3380s. The C.E. wanted a telephone line so he could service the units remotely; I had to educate management that that would allow uncontrolled access to customer data. True but not only related to the ERASE function. It applies to deleted as well as non-deleted data. -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
W dniu 2014-04-09 16:53, Gerhard Postpischil pisze: On 4/9/2014 10:27 AM, Storr, Lon A CTR USARMY HRC (US) wrote: Can someone please identify the flaw in my logic? Can a non-authorized user gain access to these scratched areas of DASD? I'd add 4) - many modern control units have diagnostic capability that allows unrestricted hardware access to the drives. If yours do, you'll need physical access controls. I first ran into this when we got our first string of Hitachi 3380s. The C.E. wanted a telephone line so he could service the units remotely; I had to educate management that that would allow uncontrolled access to customer data. IMHO remote access to the DASD box does not include access to data on disks. Yes, CE can switch off the machine, but not access data. Do you know any confirmed case where CE access to data was given with remote (or even local) access? -- Radoslaw Skorupka Lodz, Poland --- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.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.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
W dniu 2014-04-09 18:06, Elardus Engelbrecht pisze: Tom Marchant wrote: ... most installations (including us) use program protection to restrict users of these utilities. Protecting AMASPZAP and ADRDSSU is, in my opinion, not a good way to protect data from them. Agreed. Protect the resource (data), not the method (program). If you still want to limit usage of programs and their functions beside program protection, consider these too: - For ADRDSSU the relevant STGADMIN.whatever profiles in RACF FACILITY class. - DITTO for example has FACILITY class profiles for its functions. Objection, you honour! We don't talk about regular programs, it's about APF-authorized tools. From the other hand the tools give better granularity than 0/1 - that's why the profiles you mentioned exist. So one can use APF-authorized power-tool like SPZAP, but only against TEST%% volumes, but not PROD%% ones. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2014 r. kapitał zakładowy mBanku S.A. (w całości wpłacony) wynosi 168.696.052 złote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Accessing DASD areas that have no DSCB (UNCLASSIFIED)
Alan, There are several tools which allows user to read free disk space. ADRDSSU, AMASPZAP, DITTO are few of them. However those tools require some special authorization, all of the tools I mentioned are controlled by RACF CL(FACILITY) profiles (and can be blocked at all using PROGRAM class) - so I wouldn't worry about them. BTW: those tools should be reasonably controlled for other reasons The problem is it can be AFAIK possible to read the disk space using IEBGENER (assuming user created a dataset on the interesting tracks). This possibility is reduced/blocked for SMS-managed disks. Of course the best method to protect obituary data is to erase it. The best method to erase the data is to use ERASE in RACF (IMHO preferred) or VSAM (limited to VSAM). Of course ERASE is not free, it takes considerable resources. HTH -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.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.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
