Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Just curious here. Are there any shops that let people (ie programmers) install applications that are SMP/e based? I was (and still am) preaching that vendors do SMP/e installs and fix's. I find it strange that IBM would essentially not allow application types to install and maintain products with SMP/e. There by throwing out vendors work of putting in product packaging. Now vendors can say IBM doesn't allow SMP/e installs so we do not have to. Now CA (and other vendors) will no longer need to do SMP/e packaging. I would think at a minimum IBM would fix immediately any system integrity issues as in all reality SMP/e is an application program and doing (at the most) IEBCOPY work that does need APF authorization. A LONG time ago IBM gave up the fight with APF IEBCOPY by allowing it to run authorized via parmlib specification. That fight mind you took 20+ years (that I can remember), I hope this SMP/e issue will be resolved long before this. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Edward Jaffe Mark Zelden wrote: Not if you define only 1 profile as GIM.*. I suspect that will suffice for at least 95% of the shops out there. We've already discussed the unlikelihood of shops desiring to do something more granular like giving a certain set of users RECEIVE only (even though it could be done). That's exactly what we did last week: defined GIM.** with UACC(READ). For your kind of shop that's probably entirely appropriate. We defined GIM.** with UACC(NONE) and permitted our sysprog group to it with READ. It will probably stay that way until somebody figures out exactly what the risk is or was (or somebody in the know spills all the beans). -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Okay, my RACF is a little rusty, but isn't there a difference between a profile define as 'GIM.*' and one defined as 'GIM.**'? The IBM APAR advises to rdefine GIM.* (and echoed by Mark Z), but JC and Ed Jaffe are advising GIM.**. Thanks in advance, Greg Shirey Ben E. Keith Co. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Chase, John Sent: Friday, May 14, 2010 6:36 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use -Original Message- From: IBM Mainframe Discussion List On Behalf Of Edward Jaffe Mark Zelden wrote: Not if you define only 1 profile as GIM.*. I suspect that will suffice for at least 95% of the shops out there. We've already discussed the unlikelihood of shops desiring to do something more granular like giving a certain set of users RECEIVE only (even though it could be done). That's exactly what we did last week: defined GIM.** with UACC(READ). For your kind of shop that's probably entirely appropriate. We defined GIM.** with UACC(NONE) and permitted our sysprog group to it with READ. It will probably stay that way until somebody figures out exactly what the risk is or was (or somebody in the know spills all the beans). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Greg Shirey pisze: Okay, my RACF is a little rusty, but isn't there a difference between a profile define as 'GIM.*' and one defined as 'GIM.**'? The IBM APAR advises to rdefine GIM.* (and echoed by Mark Z), but JC and Ed Jaffe are advising GIM.**. Actually no. However you shouldn't define both, because only one will be picked. Explanation: GIM.* covers GIM.somethin.even.with.dots, but not GIM itself (3-letter long string, not additional qualifiers. GIM.** covers GIM.somethin.even.with.dots as well as GIM itself. It has no practical meaning because there is no such resource used by SMP/E - all resource names are multi-qualifier ones. -- 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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Greg Shirey wrote: Okay, my RACF is a little rusty, but isn't there a difference between a profile define as 'GIM.*' and one defined as 'GIM.**'? The IBM APAR advises to rdefine GIM.* (and echoed by Mark Z), but JC and Ed Jaffe are advising GIM.**. The profile you create depends upon whether your shop uses the Enhanced Generic Naming feature. See: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ichza4a1/A.3.2 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ichza4a1/A.3.3 -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Edward Jaffe wrote: The profile you create depends upon whether your shop uses the Enhanced Generic Naming feature. See: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ichza4a1/A.3.2 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ichza4a1/A.3.3 I just read these sections closely and see that it says EGN applies only to resources in the DATASET class. If true, for resources in other classes a trailing * and ** should have identical meanings. I would still rather use the EGN syntax for all resources in all classes to avoid confusion. -- Edward E Jaffe Chief Technology Officer Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Edward Jaffe Greg Shirey wrote: Okay, my RACF is a little rusty, but isn't there a difference between a profile define as 'GIM.*' and one defined as 'GIM.**'? The IBM APAR advises to rdefine GIM.* (and echoed by Mark Z), but JC and Ed Jaffe are advising GIM.**. The profile you create depends upon whether your shop uses the Enhanced Generic Naming feature. See: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ichza4a1/A.3. 2 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ichza4a1/A.3. 3 Yabbut EGN pertains only to dataset profiles. For general resource profiles it's almost but not quite six of one and a half-dozen of the other. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Edward Jaffe pisze: Edward Jaffe wrote: The profile you create depends upon whether your shop uses the Enhanced Generic Naming feature. See: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ichza4a1/A.3.2 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/ichza4a1/A.3.3 I just read these sections closely and see that it says EGN applies only to resources in the DATASET class. If true, for resources in other classes a trailing * and ** should have identical meanings. I would still rather use the EGN syntax for all resources in all classes to avoid confusion. As I wrote, the * and **, even trailing one have *almost* identical meaning. BTW: Main difference between EGN in DATASET class and general resource naming is: a) not limitation to 8 characters qualifiers, b) dot can be part of string *almost* as well as other allowed characters. Almost, because profiles like COS.*.*.* do treat first few dots in other way. BTW2: If you want to be sure how the profile works and what is covered by it, you can try the following: RDEF FACILITY $ME.anything-you-want-to-try and then RL FACI $ME.any.resoucre.to.check. -- 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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Wed, 14 Apr 2010 09:46:01 -0500, Walt Farrell wfarr...@us.ibm.com wrote: What is important is that you understand that you are at risk if you do not carefully control who can run those SMP/E functions, and that your users who can run those functions must be very trusted users. And that's why we have the new APAR IO12263. I might point out for those who have not applied this enhancement, that the examples within APAR IO12263 are not complete. Below is what they indicate are protected in the APAR: quote These functions, and the corresponding SAF FACILITY class resources that SMP/E checks, are as follows: Function:Resource name: RECEIVE command GIM.CMD.RECEIVE APPLY commandGIM.CMD.APPLY ACCEPT command GIM.CMD.ACCEPT RESTORE command GIM.CMD.RESTORE REJECT command GIM.CMD.REJECT LINK command GIM.CMD.LINK CLEANUP command GIM.CMD.CLEANUP Program GIMZIP GIM.PGM.GIMZIP Program GIMUNZIP GIM.PGM.GIMUNZIP Program GIMIAP GIM.PGM.GIMIAP /quote SET and REPORT also need command profiles, even though they were indicated earlier in the APAR. I am sure there are others that I have not found yet. From earlier in the APAR: quote The functions being controlled are all the SMP/E commands processed by program GIMSMP (for example, SET, RECEIVE, APPLY, ACCEPT UCLIN, LIST, REPORT, etc.), the GIMZIP and GIMUNZIP service routines, and the GIMIAP copy utility invocation program. /quote Just a heads up that those planning on applying this enhancement, that more will be needed. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Thu, 13 May 2010 09:36:23 -0500, Patrick Lyon ptl...@midamerican.com wrote: On Wed, 14 Apr 2010 09:46:01 -0500, Walt Farrell wfarr...@us.ibm.com wrote: What is important is that you understand that you are at risk if you do not carefully control who can run those SMP/E functions, and that your users who can run those functions must be very trusted users. And that's why we have the new APAR IO12263. I might point out for those who have not applied this enhancement, that the examples within APAR IO12263 are not complete. Below is what they indicate are protected in the APAR: quote These functions, and the corresponding SAF FACILITY class resources that SMP/E checks, are as follows: Function:Resource name: RECEIVE command GIM.CMD.RECEIVE APPLY commandGIM.CMD.APPLY ACCEPT command GIM.CMD.ACCEPT RESTORE command GIM.CMD.RESTORE REJECT command GIM.CMD.REJECT LINK command GIM.CMD.LINK CLEANUP command GIM.CMD.CLEANUP Program GIMZIP GIM.PGM.GIMZIP Program GIMUNZIP GIM.PGM.GIMUNZIP Program GIMIAP GIM.PGM.GIMIAP /quote SET and REPORT also need command profiles, even though they were indicated earlier in the APAR. I am sure there are others that I have not found yet. From earlier in the APAR: quote The functions being controlled are all the SMP/E commands processed by program GIMSMP (for example, SET, RECEIVE, APPLY, ACCEPT UCLIN, LIST, REPORT, etc.), the GIMZIP and GIMUNZIP service routines, and the GIMIAP copy utility invocation program. /quote Just a heads up that those planning on applying this enhancement, that more will be needed. Not if you define only 1 profile as GIM.*. I suspect that will suffice for at least 95% of the shops out there. We've already discussed the unlikelihood of shops desiring to do something more granular like giving a certain set of users RECEIVE only (even though it could be done). Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Thu, 13 May 2010 10:31:39 -0500 Mark Zelden mzel...@flash.net wrote: :On Thu, 13 May 2010 09:36:23 -0500, Patrick Lyon ptl...@midamerican.com wrote: :On Wed, 14 Apr 2010 09:46:01 -0500, Walt Farrell wfarr...@us.ibm.com :wrote: :What is important is that you understand that you are at risk if you do not :carefully control who can run those SMP/E functions, and that your users :who :can run those functions must be very trusted users. And that's why we have :the new APAR IO12263. :I might point out for those who have not applied this enhancement, that the :examples within APAR IO12263 are not complete. Below is what they indicate :are protected in the APAR: :quote :These functions, and the corresponding SAF FACILITY class :resources that SMP/E checks, are as follows: : Function:Resource name: : RECEIVE command GIM.CMD.RECEIVE : APPLY commandGIM.CMD.APPLY : ACCEPT command GIM.CMD.ACCEPT : RESTORE command GIM.CMD.RESTORE : REJECT command GIM.CMD.REJECT : LINK command GIM.CMD.LINK : CLEANUP command GIM.CMD.CLEANUP : Program GIMZIP GIM.PGM.GIMZIP : Program GIMUNZIP GIM.PGM.GIMUNZIP : Program GIMIAP GIM.PGM.GIMIAP :/quote :SET and REPORT also need command profiles, even though they were :indicated earlier in the APAR. I am sure there are others that I have not :found yet. From earlier in the APAR: :quote :The functions being controlled are all the SMP/E commands processed by :program GIMSMP (for example, SET, RECEIVE, APPLY, ACCEPT :UCLIN, LIST, REPORT, etc.), the GIMZIP and GIMUNZIP :service routines, and the GIMIAP copy utility invocation :program. :/quote :Just a heads up that those planning on applying this enhancement, that more :will be needed. :Not if you define only 1 profile as GIM.*. I suspect that will suffice for :at least 95% of the shops out there. We've already discussed the :unlikelihood of shops desiring to do something more granular like :giving a certain set of users RECEIVE only (even though it could be done). I would be surprised if anyone makes the effort for it to be granular until IBM 'fesses up on the exposure. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Thu, 13 May 2010 18:40:10 +0300, Binyamin Dissen bdis...@dissensoftware.com wrote: :Not if you define only 1 profile as GIM.*. I suspect that will suffice for :at least 95% of the shops out there. We've already discussed the :unlikelihood of shops desiring to do something more granular like :giving a certain set of users RECEIVE only (even though it could be done). I would be surprised if anyone makes the effort for it to be granular until IBM 'fesses up on the exposure. I suspect there is at least 1 client who knows the exposure. :-) But they still probably aren't interested in making the access granular. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Thu, 13 May 2010 09:36:23 -0500, Patrick Lyon ptl...@midamerican.com wrote: I might point out for those who have not applied this enhancement, that the examples within APAR IO12263 are not complete. Below is what they indicate are protected in the APAR: quote These functions, and the corresponding SAF FACILITY class resources that SMP/E checks, are as follows: Function:Resource name: RECEIVE command GIM.CMD.RECEIVE APPLY commandGIM.CMD.APPLY ACCEPT command GIM.CMD.ACCEPT RESTORE command GIM.CMD.RESTORE REJECT command GIM.CMD.REJECT LINK command GIM.CMD.LINK CLEANUP command GIM.CMD.CLEANUP Program GIMZIP GIM.PGM.GIMZIP Program GIMUNZIP GIM.PGM.GIMUNZIP Program GIMIAP GIM.PGM.GIMIAP /quote Sorry, but you've only quoted part of the APAR text. Start a bit earlier, please: quote HOWEVER, OF ALL THE FUNCTIONS DESCRIBED ABOVE, SEVERAL NEED TO BE CONTROLLED VERY CAREFULLY. Users who are granted access to these resources have the potential to undermine system security regardless of any data set protections you may have in place. Therefore, they should be as trusted, for example, as users who have authority to update APF authorized libraries. /quote And then it goes into your quote, which intentionally describes only those dangerous functions that you must control carefully. But yes, you must supply some security definition and make a decision even about the non-dangerous functions such a SET and REPORT, but for those it's fine to let everyone use them. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Thu, 13 May 2010 10:31:39 -0500, Mark Zelden mzel...@flash.net wrote: Not if you define only 1 profile as GIM.*. I suspect that will suffice for at least 95% of the shops out there. We've already discussed the unlikelihood of shops desiring to do something more granular like giving a certain set of users RECEIVE only (even though it could be done). Mark I say 'potato', you say 'potatoe'. :) I see your point, but I'm still defining discrete profiles here, and we are a small shop. Only two sysprogs with one working manager. We have a few scheduled jobs that kick off that do SMP/E work, like REPORT and RECEIVE. I guess my fear is of someone getting SURROGAT to that ID and could wreak havoc, which of course, is unlikely, but possible. So that ID only gets those attributes. rant All this said - what is the point of putting a restriction on SET? I mean, if you can SET to any zone you want, what is the point of it? I can see where you could put it down to the GLOBAL level for just RECEIVE's and such, and I also realize the managing nightmare of maintaining a profile for all of your zones[1], but do you not have to pretty much do a SET to do *anything* in SMP/E? [1] I realize that you could also put a generic profile of GIM.COMMAND.SET.*, if that capability was included. /rant off -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Thu, 13 May 2010 11:15:43 -0500, Patrick Lyon ptl...@midamerican.com wrote: On Thu, 13 May 2010 10:31:39 -0500, Mark Zelden mzel...@flash.net wrote: Not if you define only 1 profile as GIM.*. I suspect that will suffice for at least 95% of the shops out there. We've already discussed the unlikelihood of shops desiring to do something more granular like giving a certain set of users RECEIVE only (even though it could be done). Mark I say 'potato', you say 'potatoe'. :) I see your point, but I'm still defining discrete profiles here, and we are a small shop. Only two sysprogs with one working manager. We have a few scheduled jobs that kick off that do SMP/E work, like REPORT and RECEIVE. I guess my fear is of someone getting SURROGAT to that ID and could wreak havoc, which of course, is unlikely, but possible. So that ID only gets those attributes. It's your shop and RACF to maintain, but you still only need the generic profile and whichever ones you need to control more granularly. Do you define every possible profile under STGADMIN for example just because many exist? Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Thu, 13 May 2010 11:15:31 -0500, Walt Farrell wfarr...@us.ibm.com wrote: Walt said: Sorry, but you've only quoted part of the APAR text. Start a bit earlier, please: Ok, here is the entire quote: quote HOWEVER, OF ALL THE FUNCTIONS DESCRIBED ABOVE, SEVERAL NEED TO BE CONTROLLED VERY CAREFULLY. Users who are granted access to these resources have the potential to undermine system security regardless of any data set protections you may have in place. Therefore, they should be as trusted, for example, as users who have authority to update APF authorized libraries. These functions, and the corresponding SAF FACILITY class resources that SMP/E checks, are as follows: Function:Resource name: RECEIVE command GIM.CMD.RECEIVE APPLY commandGIM.CMD.APPLY ACCEPT command GIM.CMD.ACCEPT RESTORE command GIM.CMD.RESTORE REJECT command GIM.CMD.REJECT LINK command GIM.CMD.LINK CLEANUP command GIM.CMD.CLEANUP Program GIMZIP GIM.PGM.GIMZIP Program GIMUNZIP GIM.PGM.GIMUNZIP Program GIMIAP GIM.PGM.GIMIAP /quote My apologies. I guess I did not follow along the storyline very well. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Thu, 13 May 2010 11:33:36 -0500, Mark Zelden mzel...@flash.net wrote: Do you define every possible profile under STGADMIN for example just because many exist? Well of course not, that would be too much work. :) Should it be reviewed and addressed? Absolutely. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On 05/13/10 12:50, Patrick Lyon wrote: On Thu, 13 May 2010 11:33:36 -0500, Mark Zeldenmzel...@flash.net wrote: Do you define every possible profile under STGADMIN for example just because many exist? Well of course not, that would be too much work. :) Should it be reviewed and addressed? Absolutely. All the STGADMIN profiles and what they protect are well documented and therefor easy to setup correctly. The new GIM profiles while well understood no one outside of IBM knows what the exposure is which makes setting them up correctly almost impossible. I'm disappointed with IBM on how they handled this situation. In essence IBM didn't fix the integrity problem they just performed a CYA action by giving the installation the ability and responsibility to us to protect ourselves against a potential integrity exposure that we don't have any knowledge about. -- Mark Jacobs Time Customer Service Tampa, FL It is impossible to make anything foolproof, because fools are so ingenious. -- Robert Heinlein -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Thu, 13 May 2010 11:15:31 -0500, Walt Farrell wrote: But yes, you must supply some security definition and make a decision even about the non-dangerous functions such a SET and REPORT, but for those it's fine to let everyone use them. It's hard to avoid the surmise that: o There is an underlying integrity hazard in SMP/E that was not part of the intent of the design. o This hazard was discovered or reported fairly recently. (This describes a bug as opposed to a feature o IBM is unable or unwilling to repair that underlying hazard, possibly because either: - a proper repair is too resource intensive, or - a logical consequence of specified and commited facilities yields the hazard. Beyond that, it's implausible that read-only operations such as LIST and REPORT, or simple utilities such as GIMZIP embody the hazard, and easy to suspect that IBM is providing a smoke screen to distract [fe]malefactors. If so, Walt has somewhat blown away the smokescreen. Would he go so far as to say that with proper RACF data set protection there is no integrity hazard in granting UACC(READ) to SET and REPORT? (What use is SET by itself?) Mark Z. suspects there is at least one client who knows the details of the exposure. Is Mark presuming the problem was reported by a client rather than discovered by IBM as Jim M. obliquely boasted on April 3: of course, we would love to show off how clever we were in discovering an exposure? A proper repair would be even cleverer. And one contributor to ISPF-L remains in adamant denial: ..., bottom-line is if a real exposure was found by IBM, IBM delivered a proactive fix before you or I knew about it. On the evidence, I'm skeptical. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
IBM didn't fix the integrity problem they just performed a CYA action I wholeheartedly agree. In general, IBM's policy of correcting the exploit, and not telling you what it is, is a good one. But, acknowledging there is one and giving you a 'fix' that you have to implement, without telling you what/how to implement, is (at best) wrong-headed or (at worst) butt covering. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Thu, 13 May 2010 12:32:57 -0500, Paul Gilmartin paulgboul...@aim.com wrote: If so, Walt has somewhat blown away the smokescreen. Would he go so far as to say that with proper RACF data set protection there is no integrity hazard in granting UACC(READ) to SET and REPORT? We have already documented which functions are dangerous and need to be tightly controlled. SET and REPORT are not in that documented list of dangerous functions, and therefore (by the obvious conclusion) do not need to be tightly controlled for any reason related to System Integrity. -- Walt Farrell, CISSP IBM STSM, z/O Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Of course you would craft your profiles to suit your situation and preferences. However, coding each one is a PITA to manage and grant access. Not to mention an opportunity for a keying error. Personally, I'd go for a resource GIM.** granted to sysprogs to make sure they have all the juice they could ever want/need. Then I'd code exception profiles for those functions needing the granularity. For example, I could add a profile GIM.CMD.RECEIVE and grant access to both sysprogs and the production batch ID. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Patrick Lyon Sent: Thursday, May 13, 2010 11:16 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use ..snip I say 'potato', you say 'potatoe'. :) I see your point, but I'm still defining discrete profiles here, and we are a small shop. Only two sysprogs with one working manager. We have a few scheduled jobs that kick off that do SMP/E work, like REPORT and RECEIVE. I guess my fear is of someone getting SURROGAT to that ID and could wreak havoc, which of course, is unlikely, but possible. So that ID only gets those attributes. ..snip NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Mark Zelden wrote: Not if you define only 1 profile as GIM.*. I suspect that will suffice for at least 95% of the shops out there. We've already discussed the unlikelihood of shops desiring to do something more granular like giving a certain set of users RECEIVE only (even though it could be done). That's exactly what we did last week: defined GIM.** with UACC(READ). -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On 14 Apr 2010 12:13:53 -0700, in bit.listserv.ibm-main you wrote: On Wed, 14 Apr 2010 16:01:52 -0300 Clark Morris cfmpub...@ns.sympatico.ca wrote: :Also given the problem found with SMP/E, I would hope that IBM and :other vendors are checking to see if there are similar exposures in :other utilities and services. Only possible if IBM tells what the exposure is. Making the drastic assumption that the various groups WITHIN IBM can communicate on the exposure, then IBM can check to see if there are similar exposures in other functions. In terms of the third party vendor, it gets to be tricky. I would assume that at least CA would have to be made aware of the type of exposure. Who is responsible if a similar hole in Vendor x system type software is exploited because of a presumed underlying hole in IBM software and a SOX, data compromise or other bad event occurs? If I understand this thing correctly, the effect of this APAR is to restrict the exploitation of this hole, intentionally or inadvertently, to authorized people. That might mean we should restrict SMP access so as to exclude people who have a talent for finding flaws without looking for them. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
W dniu 2010-04-14 21:22, Don Williams pisze: CA-Endevor is an APF-authorized product that can install and maintain software. Is that similar enough such that it needs to be examined? I have no idea. However, if you don't know what the exposure is, it will be darn hard to evaluate it. I don't know Endeavor, but I know Serena Changeman. While it is also for code management, I wouldn't call it similar to SMP/E in any way. For me it's like comparison between IEBGENER and ADRDSSU. -- 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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Many years ago I worked for a company that had Endevor (before CA purchased it and changed the name to CA-Endevor). Endevor tracks the relationships between source, object, load modules/objects. When a change is made, it will calculate what needs to be re-compiled, re-linked, etc. and do it. It does require APF authorization. It invokes compilers, linkers, etc. to update protected libraries. Conceptually this is similar to SMP. Of course, that does not mean that CA-Endevor is susceptible to the same exposure. However, I think that it might be prudent to consider reviewing CA-Endevor for the possibility. I'm not familiar with Changeman, but I guess that they are competing products. Does Changeman have features similar to SMP? Should it be reviewed? Some people may call me Chick Little. Don Williams -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of R.S. Sent: Thursday, April 15, 2010 3:18 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use W dniu 2010-04-14 21:22, Don Williams pisze: CA-Endevor is an APF-authorized product that can install and maintain software. Is that similar enough such that it needs to be examined? I have no idea. However, if you don't know what the exposure is, it will be darn hard to evaluate it. I don't know Endeavor, but I know Serena Changeman. While it is also for code management, I wouldn't call it similar to SMP/E in any way. For me it's like comparison between IEBGENER and ADRDSSU. -- 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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Thu, 15 Apr 2010 11:57:43 -0400, Don Williams wrote: Many years ago I worked for a company that had Endevor (before CA purchased it and changed the name to CA-Endevor). Endevor tracks the relationships between source, object, load modules/objects. When a change is made, it will calculate what needs to be re-compiled, re-linked, etc. and do it. It does require APF authorization. It invokes compilers, linkers, etc. to update protected libraries. Conceptually this is similar to SMP. Of course, that does not mean that CA-Endevor is susceptible to the same exposure. However, I think that it might be prudent to consider reviewing CA-Endevor for the possibility. I'm not familiar with Changeman, but I guess that they are competing products. Does Changeman have features similar to SMP? Should it be reviewed? Some people may call me Chick Little. Reviewed by whom? Will IBM make the pertinent information available (presumably under NDA)? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Reviewed by whom? Will IBM make the pertinent information available (presumably under NDA)? Inquiring minds want to know... Should a competing software vendor with proprietary code be willing to let IBM review their source code, etc.? Should IBM be willing to let a third-party software vendor know how to exploit an exposure in IBM code? ... Chicken Little does not know which came first, the chicken or the egg. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Thu, 15 Apr 2010 14:41:01 -0400, Don Williams wrote: Reviewed by whom? Will IBM make the pertinent information available (presumably under NDA)? Inquiring minds want to know... Should a competing software vendor with proprietary code be willing to let IBM review their source code, etc.? Should IBM be willing to let a third-party software vendor know how to exploit an exposure in IBM code? ... There should be no cause for concern as long as the information is made available only to persons ... as trusted, for example, as users who have authority to update APF authorized libraries. Chicken Little does not know which came first, the chicken or the egg. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
I'm sorry; I'm obviously missing your point. Companies work to prevent disclosing their proprietary code to others. Therefore, I think it would be difficult to get IBM and third-party software vendors to open up their proprietary code for review. An NDA with a non-trust-worthy person is close to worthless. Software vendors do not want to give competitors access to their proprietary code, not even with a NDA. Most vendors do not want to give their customers access to their proprietary code, or only with a NDA. Don Williams -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Thursday, April 15, 2010 4:48 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use On Thu, 15 Apr 2010 14:41:01 -0400, Don Williams wrote: Reviewed by whom? Will IBM make the pertinent information available (presumably under NDA)? Inquiring minds want to know... Should a competing software vendor with proprietary code be willing to let IBM review their source code, etc.? Should IBM be willing to let a third-party software vendor know how to exploit an exposure in IBM code? ... There should be no cause for concern as long as the information is made available only to persons ... as trusted, for example, as users who have authority to update APF authorized libraries. Chicken Little does not know which came first, the chicken or the egg. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Tue, 13 Apr 2010 18:35:25 -0400, Thompson, Steve wrote: After some discussion here in the office, we are wondering why SMP/E would be allowed to subvert the protections on data sets I'm not so sure that it does. Consider this: It does not require update authority to SYS1.LINKLIB to RECEIVE a PTF that, when applied, will update a module in LINKLIB. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Wed, 14 Apr 2010 08:58:55 -0500 Tom Marchant m42tom-ibmm...@yahoo.com wrote: :On Tue, 13 Apr 2010 18:35:25 -0400, Thompson, Steve wrote: :After some discussion here in the office, we are wondering why SMP/E :would be allowed to subvert the protections on data sets :I'm not so sure that it does. :Consider this: It does not require update authority to SYS1.LINKLIB to :RECEIVE a PTF that, when applied, will update a module in LINKLIB. Obviously one protects the PTS and CSI as well. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Tue, 13 Apr 2010 23:25:12 +0300, Binyamin Dissen bdis...@dissensoftware.com wrote: On Tue, 13 Apr 2010 16:12:19 -0400 Don Williams donb...@gmail.com wrote: :Sorry, SMP does not bypass security. The user has to be smart and know what :to do, but no security is bypassed or violated. If the user cannot update the libraries, all that granting access to these resources is allowing the APPLY to abend with a S913 in place of being rejected due to lack of permission. How does allowing access to the SMP functions allow the potential to undermine system security --- wait for it --- regardless of any data set protections you may have in place. In the original discussion, it was speculated that IBM obviously did not understand that one should protect the data sets rather than trying to protect the program or functions. And that therefore anyone who did have proper data set protections is safe. In most cases that is true. In this case it is not (that's why there is an exposure, and that's why we had the System Integrity APAR IO11698 and its PTF(s).). Some of you are trying to guess what the exposure is, or speculating about what it may be. We will not participate in such speculation or confirm anything about it. What is important is that you understand that you are at risk if you do not carefully control who can run those SMP/E functions, and that your users who can run those functions must be very trusted users. And that's why we have the new APAR IO12263. Note, by the way, that the official IBM statement on all of this is in the APARs, not my emails on this topic. I am merely trying to help some of you understand those statements since there still seems to be some confusion. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Tue, 13 Apr 2010 14:02:08 -0500, Walt Farrell wrote: On Tue, 13 Apr 2010 21:36:16 +0300, Binyamin Dissen wrote: Now that IS scary. It seems to imply that SMP bypasses data set security. No, it does not imply that. You may, of course, infer that, but you'd be wrong :) Hmmm. At a casual glance you seem to be saying that Binyamin's conclusion is contrary to fact. Misdirection. On more careful reading, all you're saying is that Binyamin's process of inference is invalid. You're a master of Minsk-Pinsk reasoning. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
W dniu 2010-04-14 16:46, Walt Farrell pisze: [...] In the original discussion, it was speculated that IBM obviously did not understand that one should protect the data sets rather than trying to protect the program or functions. And that therefore anyone who did have proper data set protections is safe. In most cases that is true. In this case it is not (that's why there is an exposure, and that's why we had the System Integrity APAR IO11698 and its PTF(s).). Some of you are trying to guess what the exposure is, or speculating about what it may be. We will not participate in such speculation or confirm anything about it. What is important is that you understand that you are at risk if you do not carefully control who can run those SMP/E functions, and that your users who can run those functions must be very trusted users. And that's why we have the new APAR IO12263. Note, by the way, that the official IBM statement on all of this is in the APARs, not my emails on this topic. I am merely trying to help some of you understand those statements since there still seems to be some confusion. Now I feel a little bit scared. So dataset protection can be bypassed. It is OK for programs which: a) have APF atuhorization and b) use the authorization in safely controlled manner, vide ADRDDSU and STGADMIN.ADR.STGADMIN profiles. Ad a) If a program does not require APF to bypass dataset (or other) protection then it's not the issue with the program itself, it is security hole in the system! Walt, can you confirm that the APAR issue wouldn't happened without APF authorization for SMPE? -- 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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On 13 Apr 2010 15:36:51 -0700, in bit.listserv.ibm-main you wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Walt Farrell Sent: Tuesday, April 13, 2010 9:44 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use On Tue, 6 Apr 2010 10:39:22 -0500, Walt Farrell wfarr...@us.ibm.com wrote: SNIPPAGE Quoting from IO12263: quote ...However, of all the functions described above, several need to be controlled very carefully. *Users who are granted access to these resources have the potential to undermine system security regardless of any data set protections you may have in place.* Therefore, they should be as trusted, for example, as users who have authority to update APF authorized libraries. ... [Emphasis and coloring mine] SNIPPAGE After some discussion here in the office, we are wondering why SMP/E would be allowed to subvert the protections on data sets (see the bold in the above quote). The discussion came down to this sample: If one only has READ authority to SYS1.LPALIB [or pick one of your favorites for this example], why should SMP/E allow a USERMOD (or one's own cobbled PTF) to that library? Can SYS1.LPALIB on volume 123456 have a different RACF profile than SYS1.LPALIB on volume 987654? If not, this raises some interesting questions. Also given the problem found with SMP/E, I would hope that IBM and other vendors are checking to see if there are similar exposures in other utilities and services. Now, if the underlying security product (NOT RACF) allows this access when SMP/E asks, those of us discussing this [here in our offices] don't think this is an IBM integrity issue. And given that we are an ISV, we know we will have to inform our L1/2 persons to be aware of the SMP/E error messages that will come out and the questions that will come their way as a result. Regards, Steve Thompson -- Opinions expressed by this poster do not necessarily reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
W dniu 2010-04-14 21:01, Clark Morris pisze: [...] Can SYS1.LPALIB on volume 123456 have a different RACF profile than SYS1.LPALIB on volume 987654? If not, this raises some interesting questions. Yes, it can. See discrete profiles. However I don't see any gotcha here. In many cases updates to LPALIB are done on the copy, from another system (another security). Also given the problem found with SMP/E, I would hope that IBM and other vendors are checking to see if there are similar exposures in other utilities and services. What utilities or services are similar to SMP/E? Different tools, but similar exposures? Well, since we don't know the exposure it is really hard to guess whether the exposure does take place in other tools, isn't it? The only we could say is: there are not many tools similar to SMP/E, so possible exposures are not likely to happen. -- 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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Wed, 14 Apr 2010 16:01:52 -0300 Clark Morris cfmpub...@ns.sympatico.ca wrote: :Also given the problem found with SMP/E, I would hope that IBM and :other vendors are checking to see if there are similar exposures in :other utilities and services. Only possible if IBM tells what the exposure is. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
CA-Endevor is an APF-authorized product that can install and maintain software. Is that similar enough such that it needs to be examined? I have no idea. However, if you don't know what the exposure is, it will be darn hard to evaluate it. Don Williams -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of R.S. Sent: Wednesday, April 14, 2010 3:12 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use W dniu 2010-04-14 21:01, Clark Morris pisze: [...] Can SYS1.LPALIB on volume 123456 have a different RACF profile than SYS1.LPALIB on volume 987654? If not, this raises some interesting questions. Yes, it can. See discrete profiles. However I don't see any gotcha here. In many cases updates to LPALIB are done on the copy, from another system (another security). Also given the problem found with SMP/E, I would hope that IBM and other vendors are checking to see if there are similar exposures in other utilities and services. What utilities or services are similar to SMP/E? Different tools, but similar exposures? Well, since we don't know the exposure it is really hard to guess whether the exposure does take place in other tools, isn't it? The only we could say is: there are not many tools similar to SMP/E, so possible exposures are not likely to happen. -- 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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Wow. IT SOX auditors are going to have a field day with this. I can hardly wait to do my next SOX audit. On Wed, Apr 14, 2010 at 3:22 PM, Don Williams donb...@gmail.com wrote: CA-Endevor is an APF-authorized product that can install and maintain software. Is that similar enough such that it needs to be examined? I have no idea. However, if you don't know what the exposure is, it will be darn hard to evaluate it. Don Williams -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of R.S. Sent: Wednesday, April 14, 2010 3:12 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use W dniu 2010-04-14 21:01, Clark Morris pisze: [...] Can SYS1.LPALIB on volume 123456 have a different RACF profile than SYS1.LPALIB on volume 987654? If not, this raises some interesting questions. Yes, it can. See discrete profiles. However I don't see any gotcha here. In many cases updates to LPALIB are done on the copy, from another system (another security). Also given the problem found with SMP/E, I would hope that IBM and other vendors are checking to see if there are similar exposures in other utilities and services. What utilities or services are similar to SMP/E? Different tools, but similar exposures? Well, since we don't know the exposure it is really hard to guess whether the exposure does take place in other tools, isn't it? The only we could say is: there are not many tools similar to SMP/E, so possible exposures are not likely to happen. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl 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.2009 r. kapita zak adowy BRE Banku SA (w ca ci wp acony) wynosi 118.763.528 z otych. W zwi zku z realizacj warunkowego podwy szenia kapita u zak adowego, na podstawie uchwa y XXI WZ z dnia 16 marca 2008r., oraz uchwa y XVI NWZ z dnia 27 pa dziernika 2008r., mo e ulec podwy szeniu do kwoty 123.763.528 z . Akcje w podwy szonym kapitale zak adowym BRE Banku SA b w ca ci op acone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- George Henke (C) 845 401 5614 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Hi Clark, One way to give you volumes specific RACF protection! Use an EXIT. ++SRC (ICHRCX01) DISTLIB(AOSBN). ** * ICHRCX01 TITLE 'ICHRCX01 - RACF - RACHECK PRE-PROCESSING EXIT' SPACE 3 ** * *** *** *** MODULE - ICHRCX01 *** *** *** *** *** *** For active SYSRES set (IPL volume set) *** *** *** *** Protect Any Sysres volume xx - Alter dataset *** *** profile to $RES.dsname before calling RACF *** *** *** *** For active IPL Sysres volume xx in SS lpar only *** *** Alter dataset profile to $RES.dsname before calling RACF *** *** *** *** For nonactive IPL Sysres volume xx in SS lpar only *** *** Alter dataset profile to $Rxxdd.dsname before calling RACF *** *** *** *** *** *** RETURN CODES: Register 15 *** *** 0 - Exit routine processing is complete, normal *** *** RACHECK SVC processing is to continue. *** *** *** *** FUNCTION *** *** This exit prefixes dataset profiles with $RES if*** *** the dataset resides on SYSRES volumes. *** *** *** *** *** ** * My version of the exit validates the dataset volumes serial with the active IPL volume name...if it matches (the match depends on some local standard) then the RACF dataset resource name is modifiedthe text '$RES.' is inserted as a prefix. So now all IPL volume set datasets can be protected via $RES.** In the SysMaint systems, sysname=SSxx, the RACF resource gets modified with a prefix related the the volumes set name... eg.. $RBXA.** for the SBXRA1,2,3 volume set. So it is easy to protect active sysres volume sets...and to protect non-active target sysres volume sets separately. On Wed, 14 Apr 2010 16:01:52 -0300, Clark Morris cfmpub...@ns.sympatico.ca wrote: snip The discussion came down to this sample: If one only has READ authority to SYS1.LPALIB [or pick one of your favorites for this example], why should SMP/E allow a USERMOD (or one's own cobbled PTF) to that library? Can SYS1.LPALIB on volume 123456 have a different RACF profile than SYS1.LPALIB on volume 987654? If not, this raises some interesting questions. snip Regards Bruce Hewson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Tue, 6 Apr 2010 10:39:22 -0500, Walt Farrell wfarr...@us.ibm.com wrote: There is a legitimate integrity exposure involved, and the APAR is properly classified as such. We perhaps should have said a bit more in the documentation. We're considering whether we can do so, and what we can say that will convey the magnitude of our concern (though merely the fact that we did this via an APAR with mandatory migration actions should serve as a indication that we have serious concerns and there is a legitimate problem to address). Things having quieted down significantly on this topic, I almost hesitate to reopen this discussion. However, I did say we would consider whether we could say any more, and we've done that. APAR IO12263 is open and contains the additional information that we can make available. Quoting from IO12263: quote The documentation provided with APAR IO11698 is incomplete and does not provide sufficient guidance in how to implement the System Authorization Facility (SAF) controls introduced in the APAR. The function supplied by IO11698 is not broken and no modifications are planned, however, the complete documentation provided with IO11698 should have been as follows: [some information from original documentation omitted from this message for brevity; see the APAR if you're interested] However, of all the functions described above, several need to be controlled very carefully. Users who are granted access to these resources have the potential to undermine system security regardless of any data set protections you may have in place. Therefore, they should be as trusted, for example, as users who have authority to update APF authorized libraries. These functions, and the corresponding SAF FACILITY class resources that SMP/E checks, are as follows: Function:Resource name: RECEIVE commandGIM.CMD.RECEIVE APPLY commandGIM.CMD.APPLY ACCEPT command GIM.CMD.ACCEPT RESTORE command GIM.CMD.RESTORE REJECT command GIM.CMD.REJECT LINK command GIM.CMD.LINK CLEANUP command GIM.CMD.CLEANUP Program GIMZIPGIM.PGM.GIMZIP Program GIMUNZIP GIM.PGM.GIMUNZIP Program GIMIAPGIM.PGM.GIMIAP /quote In addition to a ++HOLD for DOC, the PTF for IO12263 will also have a ++HOLD for ACTION suggesting that anyone who applied the prior PTF and granted broad access to SMP/E functions should review those access authorities based on this new documentation. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Tue, 13 Apr 2010 09:43:46 -0500 Walt Farrell wfarr...@us.ibm.com wrote: :Users who are :granted access to these resources have the potential to :undermine system security regardless of any data set protections :you may have in place. Now that IS scary. It seems to imply that SMP bypasses data set security. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Tue, 13 Apr 2010 21:36:16 +0300, Binyamin Dissen bdis...@dissensoftware.com wrote: On Tue, 13 Apr 2010 09:43:46 -0500 Walt Farrell wfarr...@us.ibm.com wrote: :Users who are :granted access to these resources have the potential to :undermine system security regardless of any data set protections :you may have in place. Now that IS scary. It seems to imply that SMP bypasses data set security. No, it does not imply that. You may, of course, infer that, but you'd be wrong :) And we will not describe any details of the actual exposure. The important thing to take away from it is that you need to carefully review who should have the ability to use those functions. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Walt Farrell wrote: Binyamin Dissen wrote: :Users who are granted access to these resources have the potential to undermine system security regardless of any data set protections you may have in place. Now that IS scary. It seems to imply that SMP bypasses data set security. No, it does not imply that. You may, of course, infer that, but you'd be wrong :) It is the CALLER of RACF, for example in this case, SMP/E, which may or may not bypass data set security! Think, for example, DFDSS which bypass normal checks if you have access to ADMINISTRATOR keyword on some of its commands via some STGADMIN profiles in class FACILITY. Only the CALLER which calls RACF may 'bypass' RACF or data set security. It is up to them to follow RACF answer or not and then honouring RACF answer. The software calls RACF (if designed to do this) and then decides to honors RACF results (of course, if designed to do so) and then follow it own designed way. Nothing scary, only common practise. ;-D RACF itself cannot stop or allow accesses. It is the caller to allow/deny access. Actually in this case, SMP/E does not have any access beside normal accesses to datasets. So any software decides (if designed) to do a RACROUTE call. Then that software decide to honor any contents in Register 15 passed back by this call. It seemed to me that SMP/E designers added some more RACF calls in their new version of SMP/E. That is what this APAR is about. And we will not describe any details of the actual exposure. Of course. (and no one can argue (or has any courage) with Walt Farrell! ;-D ) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Of course. (and no one can argue (or has any courage) with Walt Farrell! It's hard to argue when one doesn't know what the problem was and how the solution was implemented. Of course that won't stop the folks on this list. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
W dniu 2010-04-13 21:32, Elardus Engelbrecht pisze: Walt Farrell wrote: Binyamin Dissen wrote: :Users who are granted access to these resources have the potential to undermine system security regardless of any data set protections you may have in place. Now that IS scary. It seems to imply that SMP bypasses data set security. No, it does not imply that. You may, of course, infer that, but you'd be wrong :) It is the CALLER of RACF, for example in this case, SMP/E, which may or may not bypass data set security! Think, for example, DFDSS which bypass normal checks if you have access to ADMINISTRATOR keyword on some of its commands via some STGADMIN profiles in class FACILITY. Bad example. Or rather good example but proves different opinion. DSS do bypass normal dataset check, but it's NOT resource manager for DATASET class. -- 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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Sorry, SMP does not bypass security. The user has to be smart and know what to do, but no security is bypassed or violated. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Binyamin Dissen Sent: Tuesday, April 13, 2010 2:36 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use On Tue, 13 Apr 2010 09:43:46 -0500 Walt Farrell wfarr...@us.ibm.com wrote: :Users who are :granted access to these resources have the potential to :undermine system security regardless of any data set protections :you may have in place. Now that IS scary. It seems to imply that SMP bypasses data set security. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Tue, 13 Apr 2010 16:12:19 -0400 Don Williams donb...@gmail.com wrote: :Sorry, SMP does not bypass security. The user has to be smart and know what :to do, but no security is bypassed or violated. If the user cannot update the libraries, all that granting access to these resources is allowing the APPLY to abend with a S913 in place of being rejected due to lack of permission. How does allowing access to the SMP functions allow the potential to undermine system security --- wait for it --- regardless of any data set protections you may have in place. ?? If I have all the libraries protected - how can SMP alter them? : -Original Message- : From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On : Behalf Of Binyamin Dissen : Sent: Tuesday, April 13, 2010 2:36 PM : To: IBM-MAIN@bama.ua.edu : Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition : required for any SMP/E use : On Tue, 13 Apr 2010 09:43:46 -0500 Walt Farrell wfarr...@us.ibm.com : wrote: : :Users who are : :granted access to these resources have the potential to : :undermine system security regardless of any data set protections : :you may have in place. : Now that IS scary. It seems to imply that SMP bypasses data set : security. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
W dniu 2010-04-13 22:25, Binyamin Dissen pisze: On Tue, 13 Apr 2010 16:12:19 -0400 Don Williamsdonb...@gmail.com wrote: :Sorry, SMP does not bypass security. The user has to be smart and know what :to do, but no security is bypassed or violated. If the user cannot update the libraries, all that granting access to these resources is allowing the APPLY to abend with a S913 in place of being rejected due to lack of permission. How does allowing access to the SMP functions allow the potential to undermine system security --- wait for it --- regardless of any data set protections you may have in place. ?? If I have all the libraries protected - how can SMP alter them? Possible explanation: language nuances. Maybe decription could be more accurate, maybe your understanding of the description is not the only correct. -- 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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
IBM has not told me what the problem is, but I think I have a fairly good guess. Given what I have said earlier, I'm surprised that I'm saying this, but in this case the details of how to take advantage of this security hole is probably best left unstated. SMP is may not be the only program susceptible to this style of attack. Therefore closing the hole via SMP may not complete fix the problem. Don Williams -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Binyamin Dissen Sent: Tuesday, April 13, 2010 4:25 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use On Tue, 13 Apr 2010 16:12:19 -0400 Don Williams donb...@gmail.com wrote: :Sorry, SMP does not bypass security. The user has to be smart and know what :to do, but no security is bypassed or violated. If the user cannot update the libraries, all that granting access to these resources is allowing the APPLY to abend with a S913 in place of being rejected due to lack of permission. How does allowing access to the SMP functions allow the potential to undermine system security --- wait for it --- regardless of any data set protections you may have in place. ?? If I have all the libraries protected - how can SMP alter them? : -Original Message- : From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On : Behalf Of Binyamin Dissen : Sent: Tuesday, April 13, 2010 2:36 PM : To: IBM-MAIN@bama.ua.edu : Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition : required for any SMP/E use : On Tue, 13 Apr 2010 09:43:46 -0500 Walt Farrell wfarr...@us.ibm.com : wrote: : :Users who are : :granted access to these resources have the potential to : :undermine system security regardless of any data set protections : :you may have in place. : Now that IS scary. It seems to imply that SMP bypasses data set : security. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Tue, 13 Apr 2010 23:25:12 +0300, Binyamin Dissen bdis...@dissensoftware.com wrote: On Tue, 13 Apr 2010 16:12:19 -0400 Don Williams donb...@gmail.com wrote: :Sorry, SMP does not bypass security. The user has to be smart and know what :to do, but no security is bypassed or violated. If the user cannot update the libraries, all that granting access to these resources is allowing the APPLY to abend with a S913 in place of being rejected due to lack of permission. How does allowing access to the SMP functions allow the potential to undermine system security --- wait for it --- regardless of any data set protections you may have in place. ?? If I have all the libraries protected - how can SMP alter them? We can guess all day. If you really want to know, set up some test scenarios and see what you come up with.My thought was that this could be related to something with z/OS unix, but if you aren't running the job under UID=0, then you need BPX.SUPERUSER for SMP/E to be able to do it's thing when you don't have the authority on your userid. So if you already have BPX.SUPERUSER, what more could SMP/E be giving you without this APAR? Not sure... haven't thought about it too much... but there could be something. BPX.SUPERUSER doesn't do everything for you in z/OS unix land. Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:mzel...@flash.net Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html Systems Programming expert at http://expertanswercenter.techtarget.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Walt Farrell Sent: Tuesday, April 13, 2010 9:44 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use On Tue, 6 Apr 2010 10:39:22 -0500, Walt Farrell wfarr...@us.ibm.com wrote: SNIPPAGE Quoting from IO12263: quote ...However, of all the functions described above, several need to be controlled very carefully. *Users who are granted access to these resources have the potential to undermine system security regardless of any data set protections you may have in place.* Therefore, they should be as trusted, for example, as users who have authority to update APF authorized libraries. ... [Emphasis and coloring mine] SNIPPAGE After some discussion here in the office, we are wondering why SMP/E would be allowed to subvert the protections on data sets (see the bold in the above quote). The discussion came down to this sample: If one only has READ authority to SYS1.LPALIB [or pick one of your favorites for this example], why should SMP/E allow a USERMOD (or one's own cobbled PTF) to that library? Now, if the underlying security product (NOT RACF) allows this access when SMP/E asks, those of us discussing this [here in our offices] don't think this is an IBM integrity issue. And given that we are an ISV, we know we will have to inform our L1/2 persons to be aware of the SMP/E error messages that will come out and the questions that will come their way as a result. Regards, Steve Thompson -- Opinions expressed by this poster do not necessarily reflect those of poster's employer -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Clark Morris pisze: [...] The second is the question of APF authorization. I believe that one of the longer term goals should be to remove the need for APF authorization from all utilities where at all possible. Agreed, 100%. However there APF for *trusted* programs is nothing bad. I strongly believe IBM that IEBCOPY does not have any backdoors and is not dangerous. I also trust IBM when they say run JES2 TRUSTED (in terms of STARTED class). I would not give APF or TRUSTED for consultant's homegrown tool. It is worth to remember that APF does not mean that program is dangeours and powerful. No, that means that program is allowed to be powerful and dangerous. In other words - if we trust the code of the program (backdoor and error free) then APF is not a problem. -- 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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Wed, 7 Apr 2010 15:42:31 -0300, Clark Morris wrote: The second is the question of APF authorization. I believe that one of the longer term goals should be to remove the need for APF authorization from all utilities where at all possible. The requirement that IEBCOPY be APF authorized probably should have been removed 20 - 30 years ago since a competitive product seems to be able to do without it. ... That provokes a very interesting sequence of questions: o Is that competitive product interface and data compatible with IEBCOPY? o If so, can it be used as a substitute for IEBCOPY with SMP/E? o If so, can SMP/E be run without APF authority (provided the user sidesteps the S99WTDSN entanglement)? o If so, can the installation specify UACC(READ) for all the SMP/E facility classes with confidence that there is no threat to system integrity? If the answers are respectively yes, yes, yes, no, then there is a gaping security hole that needs to be plugged. No unauthorized program, regardless of the provenance of the code (IBM, customer, ISV, or any mixture) should pose a threat to system integrity. (Isn't that IBM's policy position?) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Paul Gilmartin pisze: On Wed, 7 Apr 2010 15:42:31 -0300, Clark Morris wrote: The second is the question of APF authorization. I believe that one of the longer term goals should be to remove the need for APF authorization from all utilities where at all possible. The requirement that IEBCOPY be APF authorized probably should have been removed 20 - 30 years ago since a competitive product seems to be able to do without it. ... That provokes a very interesting sequence of questions: o Is that competitive product interface and data compatible with IEBCOPY? o If so, can it be used as a substitute for IEBCOPY with SMP/E? o If so, can SMP/E be run without APF authority (provided the user sidesteps the S99WTDSN entanglement)? o If so, can the installation specify UACC(READ) for all the SMP/E facility classes with confidence that there is no threat to system integrity? If the answers are respectively yes, yes, yes, no, then there is a gaping security hole that needs to be plugged. No unauthorized program, regardless of the provenance of the code (IBM, customer, ISV, or any mixture) should pose a threat to system integrity. (Isn't that IBM's policy position?) Do we know that the APAR is related to APF authorization of GIMSMP? Why do we consider IEBCOPY? Is IEBCOPY engaged in any way in the APAR? Do we know that? BTW: I know that APF program cannot call other program out of APF library. However in this case we consider the opposite scenario: Can non-APF program call APF-one? If so, then GIMSPE may be unathorized with no changes to IEBCOPY authorization. Is my assumption correct? BTW2: I can imagine APAR classified as integrity for unauthorized program and this does not break any integrity statement. Just matter of integrity definition. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.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.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Thu, 8 Apr 2010 15:17:03 +0200, R.S. wrote: ... No unauthorized program, regardless of the provenance of the code (IBM, customer, ISV, or any mixture) should pose a threat to system integrity. (Isn't that IBM's policy position?) Do we know that the APAR is related to APF authorization of GIMSMP? Why do we consider IEBCOPY? Is IEBCOPY engaged in any way in the APAR? Do we know that? All irrelevant (see last paragraph below). But, empirically, I have run SMP/E unauthorized (inadvertently or experimentally) The problems I encountered concerned IEBCOPY and S99WTDSN. There might be others. BTW: I know that APF program cannot call other program out of APF library. However in this case we consider the opposite scenario: Can non-APF program call APF-one? If so, then GIMSPE may be unathorized with no changes to IEBCOPY authorization. Is my assumption correct? In that case, the otherwise authorized program executes unauthorized. My experience (see above) confirms this. BTW2: I can imagine APAR classified as integrity for unauthorized program and this does not break any integrity statement. Just matter of integrity definition. Essentially, we agree. My understanding of IBM's integrity statement (not verbatim) is that no unauthorized program can attain superviser state, key 0, or otherwise escalate its privileges. So, yes, if an unauthorized program does this, it's pretty automatically cause for an integrity APAR for an unauthorized program. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Wed, 7 Apr 2010 22:49:03 +, Ted MacNEIL wrote: Customer: How do we configure this to plug the hole? IBM: For system integrity reasons, we can't tell you. Customer: What would happen if we configure it incorrectly? IBM: For system integrity reasons, we can't tell you. Customer: Can you at least tell us what function(s) we should protect? IBM: For system integrity reasons, we can't tell you. Your rant is a bit over the top, Ted. Did you bother to read Information APAR II14489 that Kurt Quackenbush posted? -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Wed, 7 Apr 2010 18:36:15 -0400, Don Williams donb...@gmail.com wrote: APF authorization or superuser authority is the keys to kingdom. Any program granted those privileges must be very carefully designed, written, and tested, and tested, and with paranoia. If there were granular types of authorization, it seems that you to should be able only grant a program the authority it needs to get its job done. Of course, it could too granular so that you're spending all your time trying to figure out what needs to be granted. However, somewhere between those two extremes there is bound to be a good compromise. Pinch me, I must be dreaming. It seems to be true that there are selected functions (or sub-functions) that it would be safe to allow in some way other than by granting full APF authorization. However, in the research we did it was not clear how to grant them to programs, rather than to the users running those programs. Nor was it clear: (a) how to do so in a way that did not impose undue administrative burdens; (b) how to allow vendors to describe to system administrators which granular authorities their programs would need; (c) How to allow the administrators to discover which granular authorities any particular program might need. Additionally, it is not clear whether the set of functions/sub-functions for which we could allow granular authorization is large enough to actually allow removal of AC(1) from a significant number of programs. The real issue, I believe, is that there is a (so far) relatively small set of functions amenable to granular authorization and a much larger set of functions for which usage, even if authorized in a granular manner, could allow privilege escalation and eventual acquisition of full authorization. So at the moment and for the foreseeable future it must remain only a nice dream, I'm afraid. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
W dniu 2010-04-08 15:33, Paul Gilmartin pisze: [...] My understanding of IBM's integrity statement (not verbatim) is that no unauthorized program can attain superviser state, key 0, or otherwise escalate its privileges. So, yes, if an unauthorized program does this, it's pretty automatically cause for an integrity APAR for an unauthorized program. My understanding is the same, however I disagree with the secon sentence. IMHO if any unauthorized program is able to escalate its privileges then integrity APAR should be issued for *operating system*, not the program itself. Otherwise you don't try to fix security hole, you only try to stop (one of) the hole explorers. I smell Windows... ;-) BTW: This is far off topic. I mean original thread, but it's still about z/OS. Regards -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.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.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Thu, 8 Apr 2010 20:30:17 +0200, R.S. wrote: My understanding is the same, however I disagree with the secon sentence. IMHO if any unauthorized program is able to escalate its privileges then integrity APAR should be issued for *operating system*, not the program itself. Otherwise you don't try to fix security hole, you only try to stop (one of) the hole explorers. I smell Windows... ;-) I stand corrected. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
In !!aaayaih+nruo4exaufaxntnnphscxbiaephwmypgbwtikhrmpaur2woba...@gmail.com, on 04/06/2010 at 10:21 PM, Don Williams donb...@gmail.com said: The possibility of disclosure may make some people reluctant. I'd see that as a serious minus. It is unlikely that an integrity hole is so obscure, that only one person will discover it. I'd like for the first person to discover it to report it. If good guys find it first, then the hole has a chance to be closed before the bad guys can capitalize on it. Not if the good guys are unwilling to report it. unless there is a new law that requires that all integrity fixes be applied, Or unless the old legal doctrine of due diligence effectively compels it. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
-Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Thursday, April 08, 2010 4:32 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use In !!AAAYAIH+nruO4exAufAxNTnNpHSCxBIAEPhwMYPgBwtIkHr mpaur2woba...@gmail.com, on 04/06/2010 at 10:21 PM, Don Williams donb...@gmail.com said: The possibility of disclosure may make some people reluctant. I'd see that as a serious minus. I agree, they should report problem; but the consensus seems to be that some people may not report them. It is unlikely that an integrity hole is so obscure, that only one person will discover it. I'd like for the first person to discover it to report it. So would I. If good guys find it first, then the hole has a chance to be closed before the bad guys can capitalize on it. Not if the good guys are unwilling to report it. Hmm. If they are unwilling to report it, should we consider them one of the good guys? unless there is a new law that requires that all integrity fixes be applied, Or unless the old legal doctrine of due diligence effectively compels it. Yes, if due diligence happened more often, the world would be a better place. -- 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...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Don Williams pisze: [...] A fair number of years ago I submitted a DCR suggesting that customers should have an optional facility to control access to APF libraries. I don't remember the details I suggested. Well, what control did you suggest, at least in general? I ask, because there are CSVAPF. profiles (CSV*.** in general) in the FACILITY class. For 10+ years. Of course we still have regular DATASET control along with AUDIT(ALL) - to trace activities of persons who have authorization. Perhaps it was CLASS(FACILITY) 'APF.data-set-name' or maybe a new class CLASS(APFLIB) 'data-set-name'. Looks quite similar to CSVAPF.libname CL(FACILITY). In either case, the profile would apply to all APF libraries, in addition to their normal RACF profiles. APF libraries would have some protection, even if they had no regular data set profile. A profile like CLASS(APFLIB) ** UACC(READ) would prevent updates to all APF libraries, but allow execution. DATASET profiles already provide such control. UPDATE allows changes, while read allows read and execution. Why do you think that something else is needed? Just curious. BTW: (this only my observation, YMMV) I noticed that CSV*.** profiles are rarely used (never used in fact). Maybe the reason is that APF/LNKLST/LPA changes are done by sysprogs, and in fact RACF admin has no reason to ask why when a sysprog wants to change any of the lists. The answer would be because it's my job, I'm installing ABC product. -- 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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Over the years, in multiple shops, I have come across multiple sysprogs that have created new APF libraries. As you say, it is needed to perform their job. However, ensuring that those libraries were appropriately protected may not have been their job (perhaps it should have been, but that is a different issue). After many months or years, it was discovered that those APF libraries did not have appropriate protection. One can argue that company had poor procedures, or not enough staff, etc. which should be addressed, or you could provide a facility to mitigate the situation. The mere fact that a library is APF authorized implies that you probably only what highly trusted people updating it. If you could put your highly trusted people on the access list of just one profile that protected all APF libraries that would help reduce the human error factor or the don't care factor. It does mean higher overhead, but protecting APF libraries is important. Of course, if you have good procedures that are always followed, you don't need this kind of feature. Human error (and it's not my job) is really hard to eliminate. The new hire who does not know or understand your naming standard can introduce a hole. CSVAPF protects who can change the APF list. That is different from protecting the content of the APF libraries. What I had suggested was method to allow you to protect (with a single profile) all currently APF authorized libraries from unauthorized update or access regardless of its name, volume, etc. In other words, even if you had DATASET ALTER authority to a APF library, you could not update it unless you also had UPDATE to the special APF profile. Of course, this added protection does not apply while the libraries are not in the APF list or from another system with a different APF list. Obviously my suggestion was not bullet proof and had a few holes. I think the RACF administrator can and should ask about new APF libraries. Not whether the library is needed, but whether it is appropriately protected. Don Williams -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of R.S. Sent: Wednesday, April 07, 2010 2:42 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use Don Williams pisze: [...] A fair number of years ago I submitted a DCR suggesting that customers should have an optional facility to control access to APF libraries. I don't remember the details I suggested. Well, what control did you suggest, at least in general? I ask, because there are CSVAPF. profiles (CSV*.** in general) in the FACILITY class. For 10+ years. Of course we still have regular DATASET control along with AUDIT(ALL) - to trace activities of persons who have authorization. Perhaps it was CLASS(FACILITY) 'APF.data-set-name' or maybe a new class CLASS(APFLIB) 'data-set-name'. Looks quite similar to CSVAPF.libname CL(FACILITY). In either case, the profile would apply to all APF libraries, in addition to their normal RACF profiles. APF libraries would have some protection, even if they had no regular data set profile. A profile like CLASS(APFLIB) ** UACC(READ) would prevent updates to all APF libraries, but allow execution. DATASET profiles already provide such control. UPDATE allows changes, while read allows read and execution. Why do you think that something else is needed? Just curious. BTW: (this only my observation, YMMV) I noticed that CSV*.** profiles are rarely used (never used in fact). Maybe the reason is that APF/LNKLST/LPA changes are done by sysprogs, and in fact RACF admin has no reason to ask why when a sysprog wants to change any of the lists. The answer would be because it's my job, I'm installing ABC product. -- 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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
No single DATASET profile is not a problem, the problem is to automatically update the list of APF libraries in RACF. In fact, you propose additional check for updating APF libraries just because the are APFed. Some kind of wizard (no irony) checking APF attrib dynamically. The same job can be done manually by simple DSMON report which lists all the APF libraries. I would not pay for such change. It could be also costly in terms of CPU and I/O. Last, but not leat it does not exhaust possible holes - there are LNKLST (usually run auth), LPA, exits, etc. Those objects lists are easily available by a command and can be compared to RACF protection. BTW: RACF admin shouldn't be dumb command issuer. He's resonsibility is to define/change the profiles as well as document the changes, as well as understand the changes (to know what is ABC.DEF.APFLOAD, etc.). In many cases RACF admin creates security policy (maybe he shouldn't but he does), and decides who should have access to APF, LPA, etc. -- 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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
I definitely agree with your points. The security admin staff should be sharp smart people. However, I have worked for more than one company whose security admin staff where nothing more than dumb command issuers. They might have run DSMON once or twice in an audit cycle (which could be several years). Those companies did not allocate resources to hire smart security people or to educate the people they had. I've also worked with incredibly smart RACF people. They don't need or want my suggestion. Like you, they would not want to pay for such a feature in money, CPU, or IO. My suggestion was for the below average security dept which I have encounter all too often. However, I still believe that someone, someday will design a security feature to automatically provide better protection for all the system libraries, APF, Linklist, etc. for the below average. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of R.S. Sent: Wednesday, April 07, 2010 10:10 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use No single DATASET profile is not a problem, the problem is to automatically update the list of APF libraries in RACF. In fact, you propose additional check for updating APF libraries just because the are APFed. Some kind of wizard (no irony) checking APF attrib dynamically. The same job can be done manually by simple DSMON report which lists all the APF libraries. I would not pay for such change. It could be also costly in terms of CPU and I/O. Last, but not leat it does not exhaust possible holes - there are LNKLST (usually run auth), LPA, exits, etc. Those objects lists are easily available by a command and can be compared to RACF protection. BTW: RACF admin shouldn't be dumb command issuer. He's resonsibility is to define/change the profiles as well as document the changes, as well as understand the changes (to know what is ABC.DEF.APFLOAD, etc.). In many cases RACF admin creates security policy (maybe he shouldn't but he does), and decides who should have access to APF, LPA, etc. -- Radoslaw Skorupka Lodz, Poland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On 6 Apr 2010 08:39:36 -0700, in bit.listserv.ibm-main you wrote: On Tue, 6 Apr 2010 13:28:11 +0200, R.S. r.skoru...@bremultibank.com.pl wrote: Of course in every case we should know the meaning of the profiles and I believe that the GIM.** profiles will be documented. It does not contradict with the APAR statement - the risk details can be still obscured. BTW: I bet the case is very bizarre case and it does not affect majority of us, BUT the APAR officially falls into category integrity and gets all the attributes of secrecy. I consider it as SPE (Small Programming Enhancement) with disputable qualification. Sorry, Radoslaw, but while the implementation may have happened to provide a functional enhancement that some of you will find useful, we would not have released an APAR that -requires- those migration actions if it were merely an enhancement. We might have introduced such improved function via an APAR, but it would have been optional (e.g., if you want to control function x you can define this profile, not if you want to allow the program to continue working at all you must define a profile). We do not lightly make such changes mandatory and force migration actions on our users in the service stream. There is a legitimate integrity exposure involved, and the APAR is properly classified as such. We perhaps should have said a bit more in the documentation. We're considering whether we can do so, and what we can say that will convey the magnitude of our concern (though merely the fact that we did this via an APAR with mandatory migration actions should serve as a indication that we have serious concerns and there is a legitimate problem to address). After watching this thread, I have a couple of comments. The first is that when something like this is introduced, the APAR should give some clue as to how and why people are to use this new function/feature. The discussion shows that far better systems programmers than I are confused about the new function and profile. If people don't implement the change properly so as to achieve the intended goal of the change, it could be worse than useless. At the very least there should be a list of recommended practices. The second is the question of APF authorization. I believe that one of the longer term goals should be to remove the need for APF authorization from all utilities where at all possible. The requirement that IEBCOPY be APF authorized probably should have been removed 20 - 30 years ago since a competitive product seems to be able to do without it. Should IDCAMS need to be APF authorized in order to function. Is IEBCOPY the only reason that SMP/E needs to be APF authorized? If not, can changes be made to eliminate the need? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Wed, 7 Apr 2010 15:42:31 -0300, Clark Morris wrote: The second is the question of APF authorization. I believe that one of the longer term goals should be to remove the need for APF authorization from all utilities where at all possible. The requirement that IEBCOPY be APF authorized probably should have been removed 20 - 30 years ago since a competitive product seems to be able to do without it. Should IDCAMS need to be APF authorized in order to function. Is IEBCOPY the only reason that SMP/E needs to be APF authorized? If not, can changes be made to eliminate the need? No. There's also S99WTDSN. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
APF authorization or superuser authority is the keys to kingdom. Any program granted those privileges must be very carefully designed, written, and tested, and tested, and with paranoia. If there were granular types of authorization, it seems that you to should be able only grant a program the authority it needs to get its job done. Of course, it could too granular so that you're spending all your time trying to figure out what needs to be granted. However, somewhere between those two extremes there is bound to be a good compromise. Pinch me, I must be dreaming. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Paul Gilmartin Sent: Wednesday, April 07, 2010 2:56 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use On Wed, 7 Apr 2010 15:42:31 -0300, Clark Morris wrote: The second is the question of APF authorization. I believe that one of the longer term goals should be to remove the need for APF authorization from all utilities where at all possible. The requirement that IEBCOPY be APF authorized probably should have been removed 20 - 30 years ago since a competitive product seems to be able to do without it. Should IDCAMS need to be APF authorized in order to function. Is IEBCOPY the only reason that SMP/E needs to be APF authorized? If not, can changes be made to eliminate the need? No. There's also S99WTDSN. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
If people don't implement the change properly so as to achieve the intended goal of the change, it could be worse than useless. That's my concern: IBM: We've closed a security hole with a new SAF Facility. Customer: Good! What was the hole? IBM: For system integrity reasons, we can't tell you. Customer: How do we configure this to plug the hole? IBM: For system integrity reasons, we can't tell you. Customer: What would happen if we configure it incorrectly? IBM: For system integrity reasons, we can't tell you. Customer: Can you at least tell us what function(s) we should protect? IBM: For system integrity reasons, we can't tell you. Customer: What use is this modification? IBM: For system integrity reasons, we can't tell you. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Paul Gilmartin pisze: [...] But note that there are no permissions peculiar to AMASPZAP; all needed security is provided by protecting data sets and VTOCs. What can you do with AMASPZAP? You can ...ZAP data. This is powerful utility, but quite limited in terms of functions. You modify data and that's why data is protected. BTW: DASDVOL profile had to be used, because standard DATASET control was not able to control some resources. Another example would be ICKDSF. In this case you also protect resources FIRST. DASDVOL class profiles are checked. However you can further control use of specific commands/functions like ANALYZE or INSPECT. Sometimes it is enough to use different access levels (READ, UPDATE, CONTROL), but sometimes is it more flexible to use another class for the functions. In case of ICKDSF it is FACILITY class and profiles STGADMIN.ICK.function. For DITTO it is FACILITY class and profiles DITTO.** (more complex than ICKDSF example). Those FACILITY profiles are *addition* to regular data protection. They do not replace data profiles (DATASET, DASDVOL, etc.) but complement the security, provide better granularity. Maybe such granularity is excessive and rarely used - but it doesn't hurt to have it and not use it (today). Of course in every case we should know the meaning of the profiles and I believe that the GIM.** profiles will be documented. It does not contradict with the APAR statement - the risk details can be still obscured. BTW: I bet the case is very bizarre case and it does not affect majority of us, BUT the APAR officially falls into category integrity and gets all the attributes of secrecy. I consider it as SPE (Small Programming Enhancement) with disputable qualification. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.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.2009 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 118.763.528 złotych. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwały XXI WZ z dnia 16 marca 2008r., oraz uchwały XVI NWZ z dnia 27 października 2008r., może ulec podwyższeniu do kwoty 123.763.528 zł. Akcje w podwyższonym kapitale zakładowym BRE Banku SA będą w całości opłacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Binyamin Dissen pisze: [...] :Won't prevent them from modifying the RECEIVEd code, though... That :needs PADS. Of course there's also the code signing approach. You would need signing, as they can modify the code before the receive or receive completely bogus stuff. Unless he downloads the stuff directly from IBM and he is not authorized to make any changes in network (to cheat the source) and he has to leave the output, and he is just an operator who only can order the job without any change in the job text. BTW: Sometimes good enough is enough good. -- 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.2009 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale zakadowym BRE Banku SA bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Tue, 6 Apr 2010 13:28:11 +0200, R.S. r.skoru...@bremultibank.com.pl wrote: Of course in every case we should know the meaning of the profiles and I believe that the GIM.** profiles will be documented. It does not contradict with the APAR statement - the risk details can be still obscured. BTW: I bet the case is very bizarre case and it does not affect majority of us, BUT the APAR officially falls into category integrity and gets all the attributes of secrecy. I consider it as SPE (Small Programming Enhancement) with disputable qualification. Sorry, Radoslaw, but while the implementation may have happened to provide a functional enhancement that some of you will find useful, we would not have released an APAR that -requires- those migration actions if it were merely an enhancement. We might have introduced such improved function via an APAR, but it would have been optional (e.g., if you want to control function x you can define this profile, not if you want to allow the program to continue working at all you must define a profile). We do not lightly make such changes mandatory and force migration actions on our users in the service stream. There is a legitimate integrity exposure involved, and the APAR is properly classified as such. We perhaps should have said a bit more in the documentation. We're considering whether we can do so, and what we can say that will convey the magnitude of our concern (though merely the fact that we did this via an APAR with mandatory migration actions should serve as a indication that we have serious concerns and there is a legitimate problem to address). -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
It is obvious that SMP/E is in the business of executing SYSMOD installation instructions. SMP/E is an APF authorized/superuser program, therefore it is a tempting attack surface. Since SMP/E is privileged, it must be carefully designed and controlled in order to avoid arbitrary code execution. Regardless of how much review and testing SMP/E undergoes and it could have still have a security hole, known or unknown; therefore it is only prudent to restrict who can use it. Of course, any APF authorized/superuser program could be a tempting attack surface. Obviously, they should be thoroughly reviewed and tested before allowing public access. If their design or function has the possibility of arbitrary code execution, their use should be restricted to trusted users. A fair number of years ago I submitted a DCR suggesting that customers should have an optional facility to control access to APF libraries. I don't remember the details I suggested. Perhaps it was CLASS(FACILITY) 'APF.data-set-name' or maybe a new class CLASS(APFLIB) 'data-set-name'. In either case, the profile would apply to all APF libraries, in addition to their normal RACF profiles. APF libraries would have some protection, even if they had no regular data set profile. A profile like CLASS(APFLIB) ** UACC(READ) would prevent updates to all APF libraries, but allow execution. -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Walt Farrell Sent: Tuesday, April 06, 2010 11:39 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use On Tue, 6 Apr 2010 13:28:11 +0200, R.S. r.skoru...@bremultibank.com.pl wrote: Of course in every case we should know the meaning of the profiles and I believe that the GIM.** profiles will be documented. It does not contradict with the APAR statement - the risk details can be still obscured. BTW: I bet the case is very bizarre case and it does not affect majority of us, BUT the APAR officially falls into category integrity and gets all the attributes of secrecy. I consider it as SPE (Small Programming Enhancement) with disputable qualification. Sorry, Radoslaw, but while the implementation may have happened to provide a functional enhancement that some of you will find useful, we would not have released an APAR that -requires- those migration actions if it were merely an enhancement. We might have introduced such improved function via an APAR, but it would have been optional (e.g., if you want to control function x you can define this profile, not if you want to allow the program to continue working at all you must define a profile). We do not lightly make such changes mandatory and force migration actions on our users in the service stream. There is a legitimate integrity exposure involved, and the APAR is properly classified as such. We perhaps should have said a bit more in the documentation. We're considering whether we can do so, and what we can say that will convey the magnitude of our concern (though merely the fact that we did this via an APAR with mandatory migration actions should serve as a indication that we have serious concerns and there is a legitimate problem to address). -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Tue, 6 Apr 2010 10:39:22 -0500, Walt Farrell wrote: Sorry, Radoslaw, but while the implementation may have happened to provide a functional enhancement that some of you will find useful, we would not have released an APAR that -requires- those migration actions if it were merely an enhancement. We might have introduced such improved function via an APAR, but it would have been optional (e.g., if you want to control function x you can define this profile, not if you want to allow the program to continue working at all you must define a profile). We do not lightly make such changes mandatory and force migration actions on our users in the service stream. That was my surmise; apparently others felt only gratitude at the perceived functional enhancement. There is a legitimate integrity exposure involved, and the APAR is properly classified as such. We perhaps should have said a bit more in the documentation. We're considering whether we can do so, and what we can say that will convey the magnitude of our concern (though merely the fact that we did this via an APAR with mandatory migration actions should serve as a indication that we have serious concerns and there is a legitimate problem to address). It might be well to emphasize (if such is the case) that ordinary RACF data set protections do not suffice to cover the integrity exposure. But I would hope for a genuine fix in the future: one that provides sufficient internal robustness that data set protections will suffice, as was the (incorrect) perception prior to IO11698. Even if this is contingent on an enhancement to IEBCOPY such that it, and thus GIMSMP, might run unauthorized. Hmmm. Nowadays, IEBCOPY can do considerable work unauthorized, particularly if it manipulates only PDSEs. Might a statement be appropriate that if the user runs GIMSMP unauthorized (STEPLIB could do it), the exposure is mitigated? For example, I believe that if I omit the WAIT option I can use the UCLIN command with GIMSMP unauthorized. Should there be a profile allowing all users to use the UCLIN command provided that GIMSMP is unauthorized? (If an unauthorized program can threaten integrity, there's a defect more drastic than has been suggested in this thread so far.) S99WTDSN? That's the only cause of failures other than IEBCOPY when I've inadvertently run GIMSMP unauthorized. Could that be handled by a new facility class resource allowing selected programs to set S99WTDSN even when invoked unauthorized? Would this require DYNALLOC to issue SAF calls to query authorization? Is allocation able to issue SAF calls? I've read the APAR fix comments and ++HOLD: o There are numerous references to the section above titled 'Authorizing Use of SMP/E Commands and Services'. There is no such titled section above nor anywhere else in the APAR fix. o I see: To allow current SMP/E users to continue executing SMP/E functions, you must define the appropriate facility class resources in the active security manager and grant all userids that should be allowed to invoke the protected SMP/E functions read access to those resources. The key word is should. Let's remember that. And: although not recommended by IBM, it is possible to define the profiles with UACC(READ) and AUDIT(ALL(READ)) to help identify and log all userids that currently invoke SMP/E functions and will require eventual definition in the profiles' access list. After sufficient analysis has occurred and the access list has been updated, then profiles should be changed to UACC(NONE). OK. That tells what IBM doesn't recommend. What _does_ IBM recommend as a technique to identify users who should be allowed to invoke the protected SMP/E functions? Should that be all current SMP/E users? We have a development shop, like Bob Shannon's. To date, current SMP/E users means all programmers able to create data sets and run batch jobs that modify those data sets. To date, we have relied only on data set protection. Apparently data set protection no longer suffices (never did; only we didn't know it). What should be our new criteria? In the currently popular phrase, might SMP/E misuse allow premature termination or execution of arbitrary code, with possible leverage to escalation of privileges, regardless of data set protection? (This is typical of integrity flaws, once exploited.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
In !!AAAYAIH+nruO4exAufAxNTnNpHSCxBIAECA1rFVV8e9NiM0/vbx0tayba...@gmail.com, on 04/05/2010 at 10:54 PM, Don Williams donb...@gmail.com said: I agree that the discussion between the reporter and developer should be secret, at least until the developer provides a solution or refuses. But that's not the question I was trying to comment on. I was more interested in the disclosure that IBM (or software vendor) has with their customers. If the vendor discloses it then the conversation between the reporter and the developer *isn't* private. That may lead to a reluctance to report integrity exposures at all. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
In 745658b07912254e8d4b05c7d8a53b111a597...@surfsd21.cnasurety.net, on 04/05/2010 at 01:51 PM, Pommier, Rex R. rex.pomm...@cnasurety.com said: The operations staff needs to run these via their own IDs to satisfy auditing requirements. That sounds like you need new auditors. The operators should be using their ids to submit jobs that they don't control and that run under an appropriate user id; the job scheduler should maintain an audit trail showing who submitted the jobs. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
In 4bb8d145.6080...@ync.net, on 04/04/2010 at 12:49 PM, Rick Fochtman rfocht...@ync.net said: I'm not sure that I'd be quite as open about it, but I understand the sentiment. I'd be more like to attack IBM's inaction or apparent lack of concern by escalating the problem within the IBM corporate structure. I haven't had to do either in decades; they seem to take integrity seriously these days. Other types of problems, or other vendors, are separate issues. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
The possibility of disclosure may make some people reluctant. I'm not reluctant and I'm fairly sure there are other people smarter than me who are not reluctant. It is unlikely that an integrity hole is so obscure, that only one person will discover it. So it is race between the good guys and the bad guys. Both groups have smart people, so there is no guarantee which group will win. If the bad guys find it first, then they get to take advantage of it until the hole is closed. If good guys find it first, then the hole has a chance to be closed before the bad guys can capitalize on it. Of course, the vendor has to get their customers to apply the fix. Unless the fix is obviously completely painless and fool-proof, some customers may be reluctant to apply them. The vendor may need to disclose details in order to convince them; unless there is a new law that requires that all integrity fixes be applied, no questions asked. Don Williams -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Shmuel Metz (Seymour J.) Sent: Tuesday, April 06, 2010 10:30 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use In !!AAAYAIH+nruO4exAufAxNTnNpHSCxBIAECA1rFVV8e9NiM0/VBX0 tayba...@gmail.com, on 04/05/2010 at 10:54 PM, Don Williams donb...@gmail.com said: I agree that the discussion between the reporter and developer should be secret, at least until the developer provides a solution or refuses. But that's not the question I was trying to comment on. I was more interested in the disclosure that IBM (or software vendor) has with their customers. If the vendor discloses it then the conversation between the reporter and the developer *isn't* private. That may lead to a reluctance to report integrity exposures at all. -- 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...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
From: Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net To: IBM-MAIN@bama.ua.edu Sent: Sun, April 4, 2010 10:27:46 AM Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use In 553635.9909...@web54605.mail.re2.yahoo.com, on 04/03/2010 at 09:48 AM, Ed Gould ps2...@yahoo.com said: We had a *REALLY* good applications programmer that simply bypassed any and all protections we had, Every time that I've seen anything similar it's been lax security code, not a bug in the system. I'm not saying that there weren't security exposures in the pre-DFP pre-SP days, but they were harder to exploit than, e.g., default passwords, magic SVC's. As I said before No magic SVC's the RACF system was not lax as we were always bombarded with we should be able to do We never did find how he managed to do it. He would not admit to doing it. As I mentioned before the most I saw logrec entries from his ID and a dump once in a while. As I said before we could see stuff wrong but needed proof it was his doing just because one bit was on (o off) wasn't proof (at least that was what we were told). Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
---snip--- We had a *REALLY* good applications programmer that simply bypassed any and all protections we had, -unsnip--- I've found some really serious holes in vendor SVC code. One example was a serious breach in the IDMS SVC, which I learned about from a security auditor. The hard way. Some vendors ASSUME that their code is inviolable, without proper testing or safeguards. WAKE UP, FOLKS. Presence can and usually does generate abuse. Rick -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Ted, How's this for a near-real-time scenario. We have a relatively slow internet pipe. We don't have an automated job scheduler and management wants to have the operations staff perform receive-from-network commands in the middle of the night while the internet pipe is less taxed. Operations runs these jobs on a weekly basis to keep our SMP/E environments current on received maintenance. The operations staff needs to run these via their own IDs to satisfy auditing requirements. Based on this, the operations staff needs update access to the SMP/E datasets/libraries to be able to perform the RECEIVE tasks. However, we definitely do NOT want them running anything except the RECEIVE tasks. They are authorized to put stuff into the SMPPTS but they cannot run REJECT commands (because they might grab something that is in the process of being installed. So they need access to the RECEIVE command but nothing else. Just protecting the datasets won't give us that granularity. Rex -Original Message- From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf Of Ted MacNEIL Sent: Sunday, April 04, 2010 12:31 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use The length of granularity is optional based on one's shop's philosophy. That's what I'm trying to understand. What philisophical basis is there for the granularity smaller than read or write? That's where I'm lost. I've worked in many shops, and the SYSPROGs were responsible for products, not SMP/E functions. They had access to all of them, not restricted to a subset. Everybody in tech support/operations had at least READ, and it was all controlled at the dataset level. The need for more granular control still escapes me. And, unless IBM relents, we'll never know the reasons. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
So they need access to the RECEIVE command but nothing else. Just protecting the datasets won't give us that granularity. See! That wasn't so hard! Thank you. The last time I was involved, directly, in maintenance SMP/E wasn't spelled the same way (SMP) and receivefromnetwork didn't exist. All I needed was an answer (without personal attacks), so now I'll go way (regarding this issue). - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Mon, 5 Apr 2010 20:11:33 + Ted MacNEIL eamacn...@yahoo.ca wrote: :So they need access to the RECEIVE command but nothing else. Just protecting the datasets won't give us that :granularity. :See! That wasn't so hard! You do not give them access to the target or distribution libraries. That would prevent APPLY/ACCEPT. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Ted, a slight variation on that theme had already been presented on the list (twice, I think). Ted MacNEIL eamacn...@yahoo.ca 4/5/2010 4:11 PM So they need access to the RECEIVE command but nothing else. Just protecting the datasets won't give us that granularity. See! That wasn't so hard! Thank you. The last time I was involved, directly, in maintenance SMP/E wasn't spelled the same way (SMP) and receivefromnetwork didn't exist. All I needed was an answer (without personal attacks), so now I'll go way (regarding this issue). - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On 5 April 2010 16:22, Binyamin Dissen bdis...@dissensoftware.com wrote: On Mon, 5 Apr 2010 20:11:33 + Ted MacNEIL eamacn...@yahoo.ca wrote: :So they need access to the RECEIVE command but nothing else. Just protecting the datasets won't give us that granularity. :See! That wasn't so hard! You do not give them access to the target or distribution libraries. That would prevent APPLY/ACCEPT. Won't prevent them from modifying the RECEIVEd code, though... That needs PADS. Of course there's also the code signing approach. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Mon, 5 Apr 2010 16:37:20 -0400 Tony Harminc t...@harminc.net wrote: :On 5 April 2010 16:22, Binyamin Dissen bdis...@dissensoftware.com wrote: : On Mon, 5 Apr 2010 20:11:33 + Ted MacNEIL eamacn...@yahoo.ca wrote: : :So they need access to the RECEIVE command but nothing else. Just protecting the datasets won't give us that granularity. : :See! That wasn't so hard! : You do not give them access to the target or distribution libraries. : That would prevent APPLY/ACCEPT. :Won't prevent them from modifying the RECEIVEd code, though... That :needs PADS. Of course there's also the code signing approach. You would need signing, as they can modify the code before the receive or receive completely bogus stuff. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
You do not give them access to the target or distribution libraries. That would prevent APPLY/ACCEPT. But you would give the same people update access to the PTS and CSI? Wouldn't that just make it possible for a determined person to create or modify a PTF so that the authorized person can implement it for them? For example, it would be fairly simple for a trained person to modify SMP input for a HIPER PTF to add JCLIN and a new CSECT that replaces almost any SVC on the system. They receive it to the PTS, the systems programmer installs the modified PTF, and unknowingly implements whatever security hole the originator wants. For me, the SMP libraries are at most read only for anyone except the systems programmers. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Wow, what a long thread about what I think is a relatively minor issue. IBM does not provide all that nice and detailed HOLDDATA for it to be ignored. Of course, I would have to assume that there may be many sysprogs out there who use SMP/E in cookbook fashion rather than really understanding what they're using. The ACCEPT/RESTORE commands as a case in point if I go by past posts having to do with it. I would also have to assume that integrity APARs slip in all the time, but unnoticed, if they require no action by the user. I think this one is a very useful improvement to SMP/E functionality irregardless of the integrity issue IBM is concerned with - what's the big deal? Guy Gardoit z/OS Systems Programming On Sat, Apr 3, 2010 at 7:48 PM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net shmuel%2bibm-m...@patriot.net wrote: Shouldn't you read the unresolved HOLDDATA before applying any PTF. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Mon, 5 Apr 2010 15:43:18 -0500 Martin Kline martin.kl...@yrcw.com wrote: :You do not give them access to the target or distribution libraries. :That would prevent APPLY/ACCEPT. :But you would give the same people update access to the PTS and CSI? :Wouldn't that just make it possible for a determined person to create or :modify a PTF so that the authorized person can implement it for them? :For example, it would be fairly simple for a trained person to modify SMP input :for a HIPER PTF to add JCLIN and a new CSECT that replaces almost any SVC :on the system. They receive it to the PTS, the systems programmer installs :the modified PTF, and unknowingly implements whatever security hole the :originator wants. If he has access to the PTS or the RELFILEs he can do that already. Explain how granular access to SMP adds to security of the above datasets. :For me, the SMP libraries are at most read only for anyone except the systems :programmers. Agree. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Mon, 5 Apr 2010 13:51:27 -0500, Pommier, Rex R. wrote: How's this for a near-real-time scenario. ... They are authorized to put stuff into the SMPPTS but they cannot run REJECT commands (because they might grab something that is in the process of being installed. So they need access to the RECEIVE command but nothing else. Just protecting the datasets won't give us that granularity. OTOH, consider a relatively small shop where one systems programmer (or a few) do all the maintenance: RECEIVE, REJECT, APPLY, RESTORE, UCLIN. Only they have write access to the SMP/E CSI and associated data sets. Everyone has read access in order to do LIST commands and browse. The security administrator is satisfied with this protection of the data sets. Is it then satisfactory to permit UACC(READ) on all the SMP/E facilities? If not, why not? What else must the security administrator consider? I'd still like to see an answer from an IBM representative. I'm still extremely puzzled that this facility, which appears to be an enhancement, is issued as a HIPER integrity APAR. It seems that there's something IBM isn't telling us. But, then, Jim and Walt have already told us that they're not telling us. Repeating, the operant question is, what, besides the protection of the data sets must the security administrator consider? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
Ted, a slight variation on that theme had already been presented on the list (twice, I think). If you say so. I didn't get it, if it is the case. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
That's not the question. Is it to his advantage for the discussion to be private, between the reporter and the developer? The only situations in which I would go public with a security hole are when it is a generic problem affected a whole community of developers or when the developers refuse to fix it. I agree that the discussion between the reporter and developer should be secret, at least until the developer provides a solution or refuses. But that's not the question I was trying to comment on. I was more interested in the disclosure that IBM (or software vendor) has with their customers. How do they convince their customers to apply the fix, upgrade their software, etc. I used to believe that non-disclosure was a good strategy and customers would blindly apply all integrity APARs. Here are just a few points to consider. 1. Some sites may believe that obscurity of flaws is sufficient protection. That plan works most of time; or rather until a clever attacker comes along. So as long as the flaw seems obscure, they feel safe. However, what seems obscure to one person, may be obvious to another. 2. Some sites don't fix things, if they aren't broke. Applying fixes takes time and effort and frequently introduces other problems. They want to avoid unnecessary effort. So they'll wait to fix the problem when it occurs in their environment. Or someone shows strong evidence that it is likely to. In other words, just saying that it is a security issue is not enough to convince them. 3. Some sites ignore security because it costs too much or is too hard to maintain, esp. when they have little at stake. For example, a service provider may have an exclusion or waiver of liability in the fine print of their contracts. Their customers may have concerns, but they agree to the risks when they sign the contract. 4. No one has a fool-proof method to separate the good guys from bad guys. Or in other words, IBM cannot discuss security issues with only the good guys, because they can't be sure whether they are talking to the good, the bad, or just the ugly. Open discussion reduces the effectiveness of security by obscurity. Open discussion may provide the strong evidence needed to show that security is broken. Open discussion may force security issues to be heeded, even when they have little at stake. Open discussion does not care whether or not the parties involved are good guys or bad guys. Of course, these points have faults, too; but so far, I'm leaning toward them anyway. Don Williams -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
From: Binyamin Dissen bdis...@dissensoftware.com To: IBM-MAIN@bama.ua.edu Sent: Sat, April 3, 2010 3:28:36 PM Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use On Sat, 3 Apr 2010 09:48:03 -0700 Ed Gould ps2...@yahoo.com wrote: :We had a *REALLY* good applications programmer that simply bypassed any and all protections we had, RACF, expiration dates, :password protection, doing cross address space snooping and alterations. In short he was a nightmare. Before going to upper management we decided we had to have proof what he was doing . We decided the only possible way to monitor him was with GTF. He was able to bypass even GTF recording for him, he was that good. He either had an SVC or has/had update access to an APF library with a special program. If the guy was good it would be difficult to catch, but it can be done. A SADUMP would have all the data needed. Sorry he had neither. It took him a month as we kept seeing dumps being taken and logrec entries and all sorts of interesting items. The dumps were of little help (at least the ones I looked at) you could see certain items not being correct but nothing that said he did it. You could get an inference that he did but inference is not usable in court. The scary part was when he got into cross memory alterations as we were never quite sure what he was aiming for. The ability to alter GTF tracing on the fly was extremely unnerving. We were an early (not ESP) for SAM-e and we had probably our fair share of bugs. We seemed to be using GTF quite a but for the SAMe bugs and we found every once in a while trace entries *GONE* so we had to recreate it again. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
On Sat, 3 Apr 2010 23:16:46 -0700 Ed Gould ps2...@yahoo.com wrote: : :From: Binyamin Dissen bdis...@dissensoftware.com :To: IBM-MAIN@bama.ua.edu :Sent: Sat, April 3, 2010 3:28:36 PM :Subject: Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use :On Sat, 3 Apr 2010 09:48:03 -0700 Ed Gould ps2...@yahoo.com wrote: ::We had a *REALLY* good applications programmer that simply bypassed any and all protections we had, RACF, expiration dates, ::password protection, doing cross address space snooping and alterations. In short he was a nightmare. Before going to upper management we decided we had to have proof what he was doing . We decided the only possible way to monitor him was with GTF. He was able to bypass even GTF recording for him, he was that good. :He either had an SVC or has/had update access to an APF library with a special :program. If the guy was good it would be difficult to catch, but it can be :done. A SADUMP would have all the data needed. :Sorry he had neither. It took him a month as we kept seeing dumps being taken and logrec entries and all sorts of interesting items. :The dumps were of little help (at least the ones I looked at) you could see certain items not being correct but nothing that said he did it. You could get an inference that he did but inference is not usable in court. That is why I said an SADUMP. Hit stop and IPL it. No code in memory will affect it (unless, of course, he also changed SADUMP - which would be very visible.) :The scary part was when he got into cross memory alterations as we were never quite sure what he was aiming for. The ability to alter GTF tracing on the fly was extremely unnerving. We were an early (not ESP) for SAM-e and we had probably our fair share of bugs. We seemed to be using GTF quite a but for the SAMe bugs and we found every once in a while trace entries *GONE* so we had to recreate it again. You needed better forensic SYSPROGs. -- Binyamin Dissen bdis...@dissensoftware.com http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
In 4bb6037b.6020...@phoenixsoftware.com, on 04/02/2010 at 07:47 AM, Edward Jaffe edja...@phoenixsoftware.com said: Ever tried to invoke IEBCOPY from a REXX? Works fine[1] under TSO; IRXJCL is another matter. [1] Assuming that it's in the TSO authorized program table. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
In listserv%201004021117302976.0...@bama.ua.edu, on 04/02/2010 at 11:17 AM, Paul Gilmartin paulgboul...@aim.com said: I've long wondered about this. Does this mean, in turn, that all utilities GIMSMP invokes (IEBCOPY, Binder, Assembler, et al.) must likewise be authorized? No. It is my understanding that an authorized program ABENDs if it attempts to ATTACH an unauthorized subtask. There's no[1] such thing. ATTACH does not check for AC(1) except when RSAPF=YES is specified by a privileged program. There is, however, a test for authorized libraries. [1] Unless you're talking about creating a new job step with its own JSCB. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
In d7d6aecb6747954693308258067007800fca74f...@exchange.calpers.ca.gov, on 04/02/2010 at 03:29 PM, Starr, Alan alan_st...@calpers.ca.gov said: I had always thought that NODSI was applied at ALLOCation time to determine whether or not a SYSDSN ENQ is to be issued. It is. It has nothing to do with SAF checking. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Heads Up: APAR IO11698 - New SAF FACILITY class definition required for any SMP/E use
In listserv%201004012321240716.1...@bama.ua.edu, on 04/01/2010 at 11:21 PM, Brian Peterson brian.peterson.ibm.m...@comcast.net said: Please note that you won't see APAR IO11698 itself in IBMLink Are you sure? My understand is that an integrity APAR can be displayed in IBMlink but that the sensitive details are not include in the public APAR text. If you do not define this FACILITY class prior to installing the SMP/E PTF on your system, Shouldn't you read the unresolved HOLDDATA before applying any PTF. -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
