Re: Intercept USS calls
In article 2861860432296333.wa.wernerzmindsltd@listserv.ua.edu you wrote: Thanks, Tony, the SMF option I tried, unfortunately the records for open/close of USS files are not written in all cases. Don, the service stubs are loaded at USS startup and reside always at the same offset like published in the document you pointed out. I.E. BPX1OPN - 156 Thats the way you can find it with Assembler. But it is possible to call them or even the BPX4xxx (64 bit) straight from the CSSLIB? I'm not completely sure about it. The stubs in CSSLIB just do the same thing as one would do in assembler. You can step through the calls with ASMIDF to verify. -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Intercept USS calls
Thanks, Tony, the SMF option I tried, unfortunately the records for open/close of USS files are not written in all cases. Don, the service stubs are loaded at USS startup and reside always at the same offset like published in the document you pointed out. I.E. BPX1OPN - 156 Thats the way you can find it with Assembler. But it is possible to call them or even the BPX4xxx (64 bit) straight from the CSSLIB? I'm not completely sure about it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Intercept USS calls
On 17 December 2013 14:38, Don Poitras poit...@pobox.com wrote: I don't see why someone couldn't install their own table in place of the pointed to by the CVT. See http://pic.dhe.ibm.com/infocenter/zos/v2r1/index.jsp?topic=%2Fcom.ibm.zos.v2r1.bpxb100%2Fbpx2cr_Example.htm Sure - I agree that that's not hard. But, as with SVC screening, you have to eventually pass control on to the real routine (or conceivably fail the call or implement a different version yourself). If all you want to do is log the calls, well it's probably not too hard, though you might have to be aware of the caller's environment. If you want to do all this without introducing security or integrity exposures, you may have to analyze each call you want to capture. It may also be the case that some software just knows the PC numbers for certain routines, and doesn't go through the CSR table at all. Not a good practice, but I'd be surprised if it doesn't exist. And who knows what recovery and repair there may be in the UNIX kernel, or if those tables are dynamically updated as a matter of routine. This would be fun to experiment with on your own private LPAR or zPDT, and I'm not saying it can't or even shouldn't be done, but is anyone really going to install such a change into their production systems? That's why I said it falls into the not for the faint of heart category. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Intercept USS calls
In article CAArMM9RSgenhOi792=dhsbsd1ztdfrypygoodzdoawbeu2f...@mail.gmail.com you wrote: On 17 December 2013 13:36, Werner Zieleznik wer...@zmindsltd.com wrote: Does somebody know how to intercept z/OS USS calls? I managed to intercept several SVC's for audit reasons. Now I would like to to do the same for USS calls. The kernel calls are PCs. IBM has rejected (or required a business case for, which comes very close) a number of requests for something analogous to SVC Screening for PCs. These were generally not in a UNIX context, but e.g. to allow front-ending of STORAGE OBTAIN. It's conceivable that you could front-end the entire UNIX PC set, but this would fall into the not for the faint of heart category of schemes that come up here from time to time. There are a few UNIX exits that might cover some of what you want, but as for a general UNIX audit facility you may have to reply on SMF records and the like. Tony H. I don't see why someone couldn't install their own table in place of the pointed to by the CVT. See http://pic.dhe.ibm.com/infocenter/zos/v2r1/index.jsp?topic=%2Fcom.ibm.zos.v2r1.bpxb100%2Fbpx2cr_Example.htm -- Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive sas...@sas.com (919) 531-5637Cary, NC 27513 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Intercept USS calls
Modifying the CVT to perform intercepts is definitely very easy but also extremely risky. Modifying the CVT affects the entire system. All it takes is the mishandling of a single caller, particularly one critical to an address space and all hell breaks loose. I tried it once. I modified the PC number in the SVT for a key system PC. A simple programming error caused system wide havoc. I'll never do anything that has global system affects again. Any intercept must be designed to provide isolation, at least for testing. On the other hand, PCs are managed at the address space level by Z/Architecture. So provided you have the capabilities to create the necessary PC data structures required by the hardware in real, fixed storage, you can intercept PC calls. It takes a lot of code and definitely not recommended for faint of heart. Once a PC intercept is created, its simple to pass the call to the original PC routine by simply branch entering the original code with the state set by the PC call. You already have the stacked entry . If you require both a front and back end intercept, this can easily be accomplished by creating bypass PC definitions that mimic the original Pc definition. But from experience, unless you're willing to write and debug a lot of code, I'd get what I need from SMF. Kenneth From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Tuesday, December 17, 2013 2:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Intercept USS calls On 17 December 2013 14:38, Don Poitras poit...@pobox.com wrote: I don't see why someone couldn't install their own table in place of the pointed to by the CVT. See http://pic.dhe.ibm.com/infocenter/zos/v2r1/index.jsp?topic=%2Fcom.ibm. zos.v2r1.bpxb100%2Fbpx2cr_Example.htm Sure - I agree that that's not hard. But, as with SVC screening, you have to eventually pass control on to the real routine (or conceivably fail the call or implement a different version yourself). If all you want to do is log the calls, well it's probably not too hard, though you might have to be aware of the caller's environment. If you want to do all this without introducing security or integrity exposures, you may have to analyze each call you want to capture. It may also be the case that some software just knows the PC numbers for certain routines, and doesn't go through the CSR table at all. Not a good practice, but I'd be surprised if it doesn't exist. And who knows what recovery and repair there may be in the UNIX kernel, or if those tables are dynamically updated as a matter of routine. This would be fun to experiment with on your own private LPAR or zPDT, and I'm not saying it can't or even shouldn't be done, but is anyone really going to install such a change into their production systems? That's why I said it falls into the not for the faint of heart category. Tony H. -- 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: Intercept USS calls
On 17 December 2013 13:36, Werner Zieleznik wer...@zmindsltd.com wrote: Does somebody know how to intercept z/OS USS calls? I managed to intercept several SVC's for audit reasons. Now I would like to to do the same for USS calls. The kernel calls are PCs. IBM has rejected (or required a business case for, which comes very close) a number of requests for something analogous to SVC Screening for PCs. These were generally not in a UNIX context, but e.g. to allow front-ending of STORAGE OBTAIN. It's conceivable that you could front-end the entire UNIX PC set, but this would fall into the not for the faint of heart category of schemes that come up here from time to time. There are a few UNIX exits that might cover some of what you want, but as for a general UNIX audit facility you may have to reply on SMF records and the like. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Intercept USS calls
Hi, Does somebody know how to intercept z/OS USS calls? I managed to intercept several SVC's for audit reasons. Now I would like to to do the same for USS calls. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Intercept USS calls
There at least one prior thread on USS files and SMF exits. Need IEFU83/84/85 to make sure you have captured file close. Unless you know of a situation for USS file close that is not covered by the IEFu83/84/85? Rob Schramm p.s. and for those picking nits.. USS in this case is unix system services... not the first one. shields up *groan* May Chris Mason send us a message from the beyond to correct me. Rob Schramm Senior Systems Consultant Imperium Group On Tue, Dec 17, 2013 at 4:28 PM, Kenneth Wilkerson redb...@austin.rr.comwrote: Modifying the CVT to perform intercepts is definitely very easy but also extremely risky. Modifying the CVT affects the entire system. All it takes is the mishandling of a single caller, particularly one critical to an address space and all hell breaks loose. I tried it once. I modified the PC number in the SVT for a key system PC. A simple programming error caused system wide havoc. I'll never do anything that has global system affects again. Any intercept must be designed to provide isolation, at least for testing. On the other hand, PCs are managed at the address space level by Z/Architecture. So provided you have the capabilities to create the necessary PC data structures required by the hardware in real, fixed storage, you can intercept PC calls. It takes a lot of code and definitely not recommended for faint of heart. Once a PC intercept is created, its simple to pass the call to the original PC routine by simply branch entering the original code with the state set by the PC call. You already have the stacked entry . If you require both a front and back end intercept, this can easily be accomplished by creating bypass PC definitions that mimic the original Pc definition. But from experience, unless you're willing to write and debug a lot of code, I'd get what I need from SMF. Kenneth From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Tuesday, December 17, 2013 2:25 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Intercept USS calls On 17 December 2013 14:38, Don Poitras poit...@pobox.com wrote: I don't see why someone couldn't install their own table in place of the pointed to by the CVT. See http://pic.dhe.ibm.com/infocenter/zos/v2r1/index.jsp?topic=%2Fcom.ibm. zos.v2r1.bpxb100%2Fbpx2cr_Example.htm Sure - I agree that that's not hard. But, as with SVC screening, you have to eventually pass control on to the real routine (or conceivably fail the call or implement a different version yourself). If all you want to do is log the calls, well it's probably not too hard, though you might have to be aware of the caller's environment. If you want to do all this without introducing security or integrity exposures, you may have to analyze each call you want to capture. It may also be the case that some software just knows the PC numbers for certain routines, and doesn't go through the CSR table at all. Not a good practice, but I'd be surprised if it doesn't exist. And who knows what recovery and repair there may be in the UNIX kernel, or if those tables are dynamically updated as a matter of routine. This would be fun to experiment with on your own private LPAR or zPDT, and I'm not saying it can't or even shouldn't be done, but is anyone really going to install such a change into their production systems? That's why I said it falls into the not for the faint of heart category. Tony H. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Intercept USS calls
It's days from Friday, but I can't resist. The NSA can intercept calls to US(S) or anywhere else. You don't even have to ask. . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Rob Schramm rob.schr...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 12/17/2013 07:01 PM Subject:Re: Intercept USS calls Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU There at least one prior thread on USS files and SMF exits. Need IEFU83/84/85 to make sure you have captured file close. major snippage -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Intercept USS calls
On 12/17/2013 9:03 PM, Skip Robinson wrote: It's days from Friday, but I can't resist. The NSA can intercept calls to US(S) or anywhere else. You don't even have to ask. OK, also off topic (and off color?): driving to an audition today saw a bumper sticker that really overloads the USS acronymn: Universal Semen Sales 'struth! -Steve Comstock . . JO.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Rob Schramm rob.schr...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU, Date: 12/17/2013 07:01 PM Subject:Re: Intercept USS calls Sent by:IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU There at least one prior thread on USS files and SMF exits. Need IEFU83/84/85 to make sure you have captured file close. major snippage -- 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: Intercept USS calls
Would the following functionality help? http://pic.dhe.ibm.com/infocenter/zos/v2r1/index.jsp?topic=%2Fcom.ibm.zos.v2r1.icha800%2Fomvsaud.htm Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
