Re: TESTAUTH LISTPSW not displaying CC for TAR
My mistake I have to break on the instruction that Sets the CC Sent from my iPhone On Nov 2, 2013, at 11:58 PM, Tony Harminc t...@harminc.net wrote: On 2 November 2013 21:47, MichealButz michealb...@optonline.net wrote: [cleaned up messy, space-wasting quoting] I am running a program under TESTAUTH which executes the TAR instruction, after executing the inst under TESTAUTH I do a LISTPSW the CC is always 0 Well the DOC says in the ALET is 0 then a CC should be set at 8 XRXXXTIE KEY XMWP AS CC PROGMASK EA BA INSTR ADDR 01118 1101 00 00 0 1 00065EB6 I think you don't understand the mapping of condition codes in the PSW to masks in the various branch instructions. According to the doc the CC should be a 8 Resulting Condition Code: 0 Access-list-entry token (ALET) is hex 1 ALET designates the dispatchable-unit access list and does not cause exceptions in access register translation (ART) 2 ALET designates the primary-space access list and does not cause exceptions in ART 3 ALET is 0001 hex or causes exceptions in ART Hint: do you see a mention of CC 8 in what you just quoted? Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Security exposure of zXXP was Re: zIIP simulation
On 11/2/2013 7:34 PM, Peter Relson wrote: SRBs are the same level of security exposure that APF-authorized tasks are. So if an application is already APF-authorized, switching to enclave SRBs is not intrinsically more of a security exposure than already existed. It is true that SRBs are more likely to tend to be key 0 than authorized tasks, but that is not a security exposure. That is a greater potential for screwing up a system due to overlay of something critical exposure. And, the good ol' SPKA instruction helps tremendously here... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Interested in up to date open source software or low cost utilities?
Anyone used it on z/OS? On Oct 30, 2013 5:38 PM, Mike Schwab mike.a.sch...@gmail.com wrote: On Wed, Oct 30, 2013 at 8:38 AM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: deleted Also, isn't gcc available for z/OS? http://gccmvs.sourceforge.net/ -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: FACILITY Class profile BPX.DEFAULT.USER in zOS 2.1
Amen. On Oct 30, 2013 12:00 PM, John McKown john.archie.mck...@gmail.com wrote: IMO, use of UID(0) for a non-BCP component by a vendor or by IBM is simply an indication that the software designer is too damn lazy to determine what access they really need and simply refuse to spend the effort (and money) to determine which of the UNIXPRIV authorities might actually let them do what they need. Or just have the SUPERUSER privilege in order to switch into root for a short time to do something. IMO, it would be like saying that the program run by an STC needed to be put into the SCHEDxx member of PARMLIB to run non-cancelable and in PSW key 0 with a RACF id which had OPERATIONS authority. snip In one of my client's sysplexes non UID(0) UIDs are shared between a certain group of end users (1000s of them in some cases) and that also has to be remediated also. But that is an AIM issue only because that sysplex didn't use BPX.DEFAULT.USER. BPX.UNIQUE.USER would help, but it's a catch 22. BTW, this issue does affect ACF2 and Top Secret as well. Mark -- -- This is clearly another case of too many mad scientists, and not enough hunchbacks. Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Security exposure of zXXP was Re: zIIP simulation
I suspect we need an SRB that is non-authorized and can never get into an authorized state. I hate giving auditors information with which they can abuse us but this probably needs to be discussed. By making zIIP so cheap, IBM and customers are strongly encouraging us to offload as much work as possible onto zIIP. Products that never needed APF authorization may be forced to become APF authorized. Some of our code that we ran in unauthorized tasks will probably move to SRB's. JAVA is a good example. IBM created zAAP on zIIP in z/OS 1.11. I believe that zAAP is accessed through a TCB which is not running authorized. With zAAP on zIIP, they must be using SRB's. Some of that JAVA program must be running in SRB mode (unless only interpretation occurs on the zIIP and execution is in the TCB).. A hacker can potentially create JAVA code that runs in SRB mode to take advantage of the authorized state. Something as simple as overlaying storage could create a security exposure and give them access to the authorized state. Jon Perryman. - Original Message - From: Peter Relson rel...@us.ibm.com SRB's are a big security exposure so customers are unlikely to open them to their programmers. SRBs are the same level of security exposure that APF-authorized tasks are. So if an application is already APF-authorized, switching to enclave SRBs is not intrinsically more of a security exposure than already existed. It is true that SRBs are more likely to tend to be key 0 than authorized tasks, but that is not a security exposure. That is a greater potential for screwing up a system due to overlay of something critical exposure. Is the code that runs under the ZIP and ZAP process code that normally run without any privileges in a problem state? Only if the perpetrator is irresponsible. It is far from unheard of to have to take an application written to be unauthorized and make it authorized. But if anyone thinks it is as simple as changing the linkedit characteristic to AC=1 and placing it in an APF-authorized library, then they need to be re-educated (and quickly if they're the one responsible for the implementation). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Security exposure of zXXP was Re: zIIP simulation
I could almost wish that Mr. Perryman's conjectures were correct. They would greatly widen the market for strong assembly-language programming skills, which is much shrunken from what it once was; and that would be good for the platform. Alas, however, . . . John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Security exposure of zXXP was Re: zIIP simulation
SRB mode is only needed if you use IBM's supplied API to zIIP. WLM is the part of z/os that schedules the TCB/SRB to the a proccessor and there is a know-how to do this, and indead requires deep knowledge of mvs interfaces and assembler coding. THe SRBs scheduled on the zIIP (using IBM's supplied interfaces) are running in the same address space, so it minimize the risk. SRB mode is also disabled for IO, so you can't infect other libraries / files like a virus. ITschak On Sun, Nov 3, 2013 at 7:41 PM, Jon Perryman jperr...@pacbell.net wrote: I suspect we need an SRB that is non-authorized and can never get into an authorized state. I hate giving auditors information with which they can abuse us but this probably needs to be discussed. By making zIIP so cheap, IBM and customers are strongly encouraging us to offload as much work as possible onto zIIP. Products that never needed APF authorization may be forced to become APF authorized. Some of our code that we ran in unauthorized tasks will probably move to SRB's. JAVA is a good example. IBM created zAAP on zIIP in z/OS 1.11. I believe that zAAP is accessed through a TCB which is not running authorized. With zAAP on zIIP, they must be using SRB's. Some of that JAVA program must be running in SRB mode (unless only interpretation occurs on the zIIP and execution is in the TCB).. A hacker can potentially create JAVA code that runs in SRB mode to take advantage of the authorized state. Something as simple as overlaying storage could create a security exposure and give them access to the authorized state. Jon Perryman. - Original Message - From: Peter Relson rel...@us.ibm.com SRB's are a big security exposure so customers are unlikely to open them to their programmers. SRBs are the same level of security exposure that APF-authorized tasks are. So if an application is already APF-authorized, switching to enclave SRBs is not intrinsically more of a security exposure than already existed. It is true that SRBs are more likely to tend to be key 0 than authorized tasks, but that is not a security exposure. That is a greater potential for screwing up a system due to overlay of something critical exposure. Is the code that runs under the ZIP and ZAP process code that normally run without any privileges in a problem state? Only if the perpetrator is irresponsible. It is far from unheard of to have to take an application written to be unauthorized and make it authorized. But if anyone thinks it is as simple as changing the linkedit characteristic to AC=1 and placing it in an APF-authorized library, then they need to be re-educated (and quickly if they're the one responsible for the implementation). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Security exposure of zXXP was Re: zIIP simulation
Do vendor's have access to the WLM implementation that allows TCB's to run on a zIIP? Since JAVA was implemented starting with z/OS 1.11, I suspect they may use SRB's otherwise they could have easily retrofitted it to earlier versions. As for the risk, an SRB can use cross memory facilities. It can schedule an SRB to another address space and attach a subtask. These are all well documented, known and used. These alone would let you do file I/O and mimic any active user. Lesser know would be some of the key system addresses which can easily be replaced while running in key 0. This is exactly where a hacker would want to be in order to hide their tracks and do devious things without getting caught. Jon Perryman. From: Itschak Mugzach imugz...@gmail.com SRB mode is only needed if you use IBM's supplied API to zIIP. WLM is the part of z/os that schedules the TCB/SRB to the a proccessor and there is a know-how to do this, and indead requires deep knowledge of mvs interfaces and assembler coding. THe SRBs scheduled on the zIIP (using IBM's supplied interfaces) are running in the same address space, so it minimize the risk. SRB mode is also disabled for IO, so you can't infect other libraries / files like a virus. ITschak On Sun, Nov 3, 2013 at 7:41 PM, Jon Perryman jperr...@pacbell.net wrote: I suspect we need an SRB that is non-authorized and can never get into an authorized state. I hate giving auditors information with which they can abuse us but this probably needs to be discussed. By making zIIP so cheap, IBM and customers are strongly encouraging us to offload as much work as possible onto zIIP. Products that never needed APF authorization may be forced to become APF authorized. Some of our code that we ran in unauthorized tasks will probably move to SRB's. JAVA is a good example. IBM created zAAP on zIIP in z/OS 1.11. I believe that zAAP is accessed through a TCB which is not running authorized. With zAAP on zIIP, they must be using SRB's. Some of that JAVA program must be running in SRB mode (unless only interpretation occurs on the zIIP and execution is in the TCB).. A hacker can potentially create JAVA code that runs in SRB mode to take advantage of the authorized state. Something as simple as overlaying storage could create a security exposure and give them access to the authorized state. Jon Perryman. - Original Message - From: Peter Relson rel...@us.ibm.com SRB's are a big security exposure so customers are unlikely to open them to their programmers. SRBs are the same level of security exposure that APF-authorized tasks are. So if an application is already APF-authorized, switching to enclave SRBs is not intrinsically more of a security exposure than already existed. It is true that SRBs are more likely to tend to be key 0 than authorized tasks, but that is not a security exposure. That is a greater potential for screwing up a system due to overlay of something critical exposure. Is the code that runs under the ZIP and ZAP process code that normally run without any privileges in a problem state? Only if the perpetrator is irresponsible. It is far from unheard of to have to take an application written to be unauthorized and make it authorized. But if anyone thinks it is as simple as changing the linkedit characteristic to AC=1 and placing it in an APF-authorized library, then they need to be re-educated (and quickly if they're the one responsible for the implementation). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Security exposure of zXXP was Re: zIIP simulation
I will not comment on Mr. Perryman's suspicions, which are not arguments. I will limit myself to noting that 1) an SRB cannot attach a subtask and 2) a [different] SRB that it scheduled into another address space would also disabled for I/O. Peter Relson's point is the important one here. The use of these facilities by the unwashed certainly has great potential for bringing down z/OS. The security threat posed by an SRB executed on a cheap zIIP, zAAP, or the like is not, however, any greater in any way than the security threat of an SRB executed on an expensive standard CP. As Lewis Carroll put it in THOTS: Just the place for a Snark! I have said it twice: That alone should encourage the crew. Just the place for a Snark! I have said it thrice: What I tell you three times is true. --John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Security exposure of zXXP was Re: zIIP simulation
On 11/3/13, John Gilmore jwgli...@gmail.com wrote: I will not comment on Mr. Perryman's suspicions, which are not arguments. I will limit myself to noting that 1) an SRB cannot attach a subtask and 2) a [different] SRB that it scheduled into another address space would also disabled for I/O. Peter Relson's point is the important one here. The use of these facilities by the unwashed certainly has great potential for bringing down z/OS. The security threat posed by an SRB executed on a cheap zIIP, zAAP, or the like is not, however, any greater in any way than the security threat of an SRB executed on an expensive standard CP. As Lewis Carroll put it in THOTS: Just the place for a Snark! I have said it twice: That alone should encourage the crew. Just the place for a Snark! I have said it thrice: What I tell you three times is true. --John Gilmore, Ashland, MA 01721 - USA -- John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: BBC News - Russia: Hidden chips 'launch spam attacks from irons'
We have dome something similar in USB port. customers are usually protect from USB devices, but allow keyboard/mouse. We programmed a small cheap (bought off-shelve) packed into a usb stick that identifies it as a keyboard. We then was ables program the cheap to create a small bat file to get into personal data and, outlook (to copy mails and send data). a simple progra It was for demonstration only,of course. ITschak On Sun, Nov 3, 2013 at 9:24 PM, Jon Perryman jperr...@pacbell.net wrote: The BBC news article is at http://www.bbc.co.uk/news/blogs-news-from-elsewhere-24707337 It's definitely possible to imbed them into almost anything because they are so small. You would still need an Email server or hack into someones Email account. It also seems too expensive when you consider that you can easily get access through a coffee shop. If this is true, then just stop ironing your clothes to avoid the risk. ;) I couldn't resist. Jon Perryman. From: efinnell15 efinnel...@aol.com BBC News - Russia: Hidden chips 'launch spam attacks from irons' Just checking. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Interested in up to date open source software or low cost utilities?
In 4236639181988702.wa.paulgboulderaim@listserv.ua.edu, on 10/30/2013 at 10:16 AM, Paul Gilmartin paulgboul...@aim.com said: So the programmer codes in a regex /[abc]/, where '[' and ']' are radically locale-sensitive. Must PCRE query the locale to suss out what '[' means, That would be reasonable. or translate all input and output to a canonical character set? That would also require knowing the locale, or at least the character set. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: [slightly] off topic: SPFPRO on Win 8.1
In vmime.52711cc5.4ed2.933c6b6363ae3...@dms02.intranet.set-software.de, on 10/30/2013 at 03:50 PM, Michael Knigge michael.kni...@set-software.de said: Do not even think about trying THE (http://hessling-editor.sourceforge.net/). Okay, it supports Rexx, but it does not really feel like the editor under ISPF (ok, to be fair, it is a XEDIT-like editor that can be configured like the ISPF-editor - but not really well) It's hardly fair to judge THE by how well it simulates ISPF/PDF EDIT. Do you have any issues with its XEDIT compatibility? -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF statistics
In 2827497057068213.wa.paulgboulderaim@listserv.ua.edu, on 10/30/2013 at 03:34 PM, Paul Gilmartin paulgboul...@aim.com said: rarely+1. Now that I think of it, there are two uses of RECFM=U for non-load-module data that didn't qualify as rare; Wylbur compressed data and old SAS libraries; the latter was PS rather than PO. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Interesting? How _compilers_ are compromising application security
In 263145282.5266498.1383166791977.javamail.r...@comcast.net, on 10/30/2013 at 08:59 PM, DASDBILL2 dasdbi...@comcast.net said: PITA, yes, but not life-threateningly so. Consider the following: X = 0 IF X=1 THEN DC C'THIS IS A CONSTANT THAT IS NOW REACHABLE SO THE COMPILER WILL NOT DELETE IT IN ORDER TO OPTIMIZE THE LOAD MODULE. ENDIF A good compiler will recognize that as unreachable. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF statistics
There's a third and significant use of RECFM=U. Several IBM ESP programs provide SMF data for vendors in RECFM=U format, so those vendors who process those data on ASCII can directly read those files, since they contain the BDW and RDW and can be ftp'd as binary. If, instead, you attempt to ftp a VBS (or VB or V) file, PGM=FTP shows you it knows what that RECFM means, and then showing how smart it is, sends ONLY the data portion of each record without the BDW/RDWs. By creating RECFM=U copy (either by changing the DCB or by copying with IEBGENER) PGM=FTP cannot muck about and preserves the BDWs and RDWs. For years, MXG provided this PGM=IEBGENER example to copy the VBS dataset to one with RECFM=U: // EXEC PGM=IEBGENER //SYSUT1 DD DSN=YOUR.VB.FILE,DISP=SHR,RECFM=U,BLKSIZE=32760 //SYSUT2 DD DSN=YOUR.NEW.RECFMU,DISP=(,CATLG),RECFM=U, // BLKSIZE=32760,UNIT=SYSDA,SPACE=(CYL,(50,50)) //SYSIN DD DUMMY But very recently, Dan Kaberon showed how the existing VBS file can be changed to RECFM=U WITHOUT THE COST OF THE COPY: //JCLVBS2U EXEC PGM=IEBGENER //SYSIN DD DUMMY //SYSPRINT DD SYSOUT=* //SYSUT2 DD DSN=ZOS.VBS.FILE.TO.CHANGE, // DISP=MOD,DCB=RECFM=U //SYSUT1 DD DSN=NULLFILE,DCB=*.SYSUT2 The key is to use DISP=MOD and to copy NULLFILE which ONLY changes the DSCB attributes and does NOT touch the actual data in the original file. Barry -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Shmuel Metz (Seymour J.) Sent: Sunday, November 03, 2013 4:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: ISPF statistics In 2827497057068213.wa.paulgboulderaim@listserv.ua.edu, on 10/30/2013 at 03:34 PM, Paul Gilmartin paulgboul...@aim.com said: rarely+1. Now that I think of it, there are two uses of RECFM=U for non-load-module data that didn't qualify as rare; Wylbur compressed data and old SAS libraries; the latter was PS rather than PO. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ISPF statistics
In 20131031070844.6a4efbce75142c7b59b59...@gmx.net, on 10/31/2013 at 07:08 AM, nitz-...@gmx.net nitz-...@gmx.net said: No. For fixed and variable length records in a PO data set the user field of the directory entry IHAPDS points to the ISPF statistics, which can be 30 or 40 byte long. ISPF owns the format of the user data created by ISPF; it does not own the format of the user data created by, e.g., IEBUPDTE. Does anyone have an answer for my second question: How does the version in the pdf statistics get incremented (other than by some form of the VERSION command)? ISPF/PDF EDIT increments the version. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Security exposure of zXXP was Re: zIIP simulation
On 11/3/2013 10:25 AM, Itschak Mugzach wrote: THe SRBs scheduled on the zIIP (using IBM's supplied interfaces) are running in the same address space, so it minimize the risk. Not always. SRB mode is also disabled for IO, so you can't infect other libraries / files like a virus. Not sure what you're driving at here. It's true that zIIPs are disabled for I/O interrupts, but so are most CPs unless you have a boat load of I/O activity. How is that relevant? -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Security exposure of zXXP was Re: zIIP simulation
No one was asking for details on how to attach a task but since Mr. Gilmore requires a full explanation, the SRB schedules an IRB that does the attach. My point was that you can do anything with an SRB. Some of the hacks on Windows and Unix are far more complicated than this but someone always seems to abuse them. What makes this any different. Peter's comments are about inherent risk in a single SRB. Risk is assessed through probability which is more than a single occurrence. With zIIP, we must be running in thousands of times the workload to achieve the payback that customers see. Much more code executing under an SRB. Product support staff's that never looked at an SRB because it was easier just to pass it on to development. Training staff on code that should never be moved to an SRB because of security exposure (e.g. end user programming languages implemented within a product). Vendor products that never used an SRB will start using SRB's. Most of these SRB's will be running key 8 and will never issue modeset. Inadvertant errors are not a problem. In the past, we would never have end user code run in an SRB. With zIIP, a large portion of our code is now being consider SRB eligible. Some of that code run's under TCB's that never had authorization where end users could never abuse it will now be a potential exposure. Proverbial saying: can't see the forest for the tree's. Jon Perryman From: John Gilmore jwgli...@gmail.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Sunday, November 3, 2013 11:42 AM Subject: Re: Security exposure of zXXP was Re: zIIP simulation I will not comment on Mr. Perryman's suspicions, which are not arguments. I will limit myself to noting that 1) an SRB cannot attach a subtask and 2) a [different] SRB that it scheduled into another address space would also disabled for I/O. Peter Relson's point is the important one here. The use of these facilities by the unwashed certainly has great potential for bringing down z/OS. The security threat posed by an SRB executed on a cheap zIIP, zAAP, or the like is not, however, any greater in any way than the security threat of an SRB executed on an expensive standard CP. As Lewis Carroll put it in THOTS: Just the place for a Snark! I have said it twice: That alone should encourage the crew. Just the place for a Snark! I have said it thrice: What I tell you three times is true. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Security exposure of zXXP was Re: zIIP simulation
On Sun, 3 Nov 2013 14:42:18 -0500, John Gilmore wrote: The use of these facilities by the unwashed certainly has great potential for bringing down z/OS. Your implied faith in your coterie transcends mine I'm afraid - the pool of talent seems to be diminishing. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Interested in up to date open source software or low cost utilities?
I know a couple of load modules were compiled and tested on z/OS then the binary downloaded and run on MVS 3.8 too. On Sun, Nov 3, 2013 at 10:53 AM, Rob Schramm rob.schr...@gmail.com wrote: Anyone used it on z/OS? On Oct 30, 2013 5:38 PM, Mike Schwab mike.a.sch...@gmail.com wrote: On Wed, Oct 30, 2013 at 8:38 AM, Shmuel Metz (Seymour J.) shmuel+ibm-m...@patriot.net wrote: deleted Also, isn't gcc available for z/OS? http://gccmvs.sourceforge.net/ -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Security exposure of zXXP was Re: zIIP simulation
I agree that the pool of talent is being diminished by deaths, low recruitment because of poor perceived economic prospects, out migration for the same reason, and---among the young---a perception that the excitement is elsewhere. This issue is, however, separable from that of competence to work in the bowels of the operating system. I do now a little regret the use of the adjective 'unwashed'. I meant it metaphorically not literally. As a practical matter I should be entirely willing to work with [and downwind of] a competent but malodorous sysprog. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Security exposure of zXXP was Re: zIIP simulation
I think Itschak is saying that SRB's can't do I/O, therefore they can't write files to embed a virus or read confidential data. I think he's under the impression that SRB's can't get access to everything they desire. Jon Perryman. From: Ed Jaffe edja...@phoenixsoftware.com On 11/3/2013 10:25 AM, Itschak Mugzach wrote: SRB mode is also disabled for IO, so you can't infect other libraries / files like a virus. Not sure what you're driving at here. It's true that zIIPs are disabled for I/O interrupts, but so are most CPs unless you have a boat load of I/O activity. How is that relevant? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: ObamaCare Web Site Problems
On 3 Nov 2013 13:01:35 -0800, in bit.listserv.ibm-main you wrote: In 833950007-1383144348-cardhu_decombobulator_blackberry.rim.net-2146530692-@b25.c4.bise6.blackberry, on 10/30/2013 at 02:45 PM, Mike Liberatore vze2q...@verizon.net said: The thing find interesting is if the Affordable Care Act is so good then why was congress who passed the law were exempted ? Before asking why ask whether. As I understand the discussion in the Wall Street Journal, Congress and its staff were supposed to be moved to the exchanges but the Obama Administration has come up with a waiver. This whole thing is a moving target with plenty of room for people of all political stripes to cast rocks at opposition and keep everybody thoroughly confused. Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Is there currently a way to access MongoDB from z/OS LE languages?
Hi all While I may change my mind in the future, I've pretty much decided to abandon the project for now, for these reasons: 1. Mongo DB data is UTF-8 and not even ASCII. An EBCDIC version is thus irrelevant and not needed. This is different then the situation with the PCRE library where EBCDIC version is possible and useful in EBCDIC environment, and thus relevant. 2. Once the need for EBCDIC is ruled out, there is no real need for classic z/OS version. The C modules of the C driver could easily be compiled under USS and the only piece that might be needed is some COBOL copybooks and code to interface with the dll, resolve big and little endian conflicts and so on. This is a fairly easy task to do, but I sense that there is no specific need for it. As I've said, I may go back and do it some time in the future. 3. The most important obstacle is the fact that there is no descent development environment that could be reasonably and legally available to open source developers. This, combined with the hostility towards C in classic z/OS shops, curtails the ability of many potential users to actually build from source code and the ability of the project to distribute binaries. I will concentrate my open source efforts elsewhere ZA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Interesting? How _compilers_ are compromising application security
At 21:16 + on 10/30/2013, DASDBILL2 wrote about Re: Interesting? How _compilers_ are compromising applicati: At first, aggressive drivers drove faster than the posted speed limit. Then the police equipped themselves with radar guns to digitize the speed of cars. Interestingly, there have been cases where the attempt to use radar gun readings have been ruled inadmissible since there is no record of the readout. The gun has to print out a time stamped receipt that is attached to both the officer's and the driver's copies of the tickets. Otherwise the officer's testimony is not valid since the right to confront your accuser (ie: The Radar Gun) is denied to the driver since there is no proof of the reading. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Serialization without Enque
I sure missed that one with the locks. PLO CDS does exactly what is wanted. It does 2 CS's within the locked instruction. PLO CSDST on the other hand only does a single CS followed by 2 ST's. Since 3 separate load instructions (not under PLO control) are required when not in contiguous storage, there is not any method that will guarantee the 3 values are consistent with the others. A counter as suggested by Peter Relson won't help either for this same reason. I can't think of a situation where PLO CSDST is useful. Can anyone describe a situation where it is useful? Jon Perryman. From: Rob Scott rsc...@rocketsoftware.com I think the OP stated that his code could hold locks - in which case the latch services cannot be used. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
aggressive drivers was: Interesting? How _compilers_ are compromising application security
Germany has solved this by sending you a photo with you in the driver seat and shows the license plate / time date / your speed. The photo was really good night time photo for the distance. Officer's just set the radar gun at the side of the autobahn and just leave. Here, someone would probably steal it. Jon Perryman. From: Robert A. Rosenberg hal9...@panix.com At 21:16 + on 10/30/2013, DASDBILL2 wrote about Re: Interesting? How _compilers_ are compromising applicati: At first, aggressive drivers drove faster than the posted speed limit. Then the police equipped themselves with radar guns to digitize the speed of cars. Interestingly, there have been cases where the attempt to use radar gun readings have been ruled inadmissible since there is no record of the readout. The gun has to print out a time stamped receipt that is attached to both the officer's and the driver's copies of the tickets. Otherwise the officer's testimony is not valid since the right to confront your accuser (ie: The Radar Gun) is denied to the driver since there is no proof of the reading. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
numeric RACF ID and TSO
Hi Folks - I saw this discussion around 2008, but never saw any definitive resolution or prohibition so I just thought I'd check to see if anyone using RACF has managed to use TSO with an all numeric userid. I've played around a bit first with a couple of the TSO exits and managed to add an alphabetic to the Jobname to bypass the JES2 jobname limitation. Inside IKJEFLD1 though, I've had to flip on the Don't prompt bit otherwise the TSO/E screen processing syntax checks the userid. Unfortunately by setting Don't prompt I now needed to supply userid, password, procname and region size inside the exit. So it looks like I have to full-screen TPUT my own screen and process it myself. I have, with the help of some hardcoded values in the exit gotten logged on, so it is technically feasible, just painful. Has anyone discovered a simple, elegant, less cumbersome mechanism for getting a numeric user and TSO to coexist? Thanks kindly from the bottom side of the planet, Tom Sydney - IMPORTANT NOTICE : The information in this email is confidential and may also be privileged. If you are not the intended recipient, any use or dissemination of the information and any disclosure or copying of this email is unauthorised and strictly prohibited. If you have received this email in error, please promptly inform us by reply email or telephone. You should also delete this email and destroy any hard copies produced. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Security exposure of zXXP was Re: zIIP simulation
That's true. You can't infect files/load modulesqetc. ITschak On Mon, Nov 4, 2013 at 2:15 AM, Jon Perryman jperr...@pacbell.net wrote: I think Itschak is saying that SRB's can't do I/O, therefore they can't write files to embed a virus or read confidential data. I think he's under the impression that SRB's can't get access to everything they desire. Jon Perryman. From: Ed Jaffe edja...@phoenixsoftware.com On 11/3/2013 10:25 AM, Itschak Mugzach wrote: SRB mode is also disabled for IO, so you can't infect other libraries / files like a virus. Not sure what you're driving at here. It's true that zIIPs are disabled for I/O interrupts, but so are most CPs unless you have a boat load of I/O activity. How is that relevant? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: numeric RACF ID and TSO
Tom Rusnak wrote: I saw this discussion around 2008, but never saw any definitive resolution or prohibition so I just thought I'd check to see if anyone using RACF has managed to use TSO with an all numeric userid. This is WAD. Limits for TSO ids: A letter in first position as well as name length limit of 7. Just live with it. I've played around a bit first with a couple of the TSO exits and managed to add an alphabetic to the Jobname to bypass the JES2 jobname limitation. Just curious. What are you trying to achieve by having your TSO ids as all numeric? , so it is technically feasible, just painful. It is not technically feasible. [1] It should be painful. :-) Wait until you try using all numeric dataset names. Now it will hurts a lot. [2] Has anyone discovered a simple, elegant, less cumbersome mechanism for getting a numeric user and TSO to coexist? I don't think you will a less cumbersome way. At least for TSO. I know for some third party products you can logon using numbers as ids. Groete / Greetings Elardus Engelbrecht [1] - Why trying 1001 exits just to achive your goal? You will probably have to re-assemble all of them with each upgrades. [2] - Unless you use some sort of prefix. Think ISPF exit 16 amongst other exits for example. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: aggressive drivers was: Interesting? How _compilers_ are compromising application security
Jon Perryman wrote: Germany has solved this by sending you a photo with you in the driver seat and shows the license plate / time date / your speed. The photo was really good night time photo for the distance. Officer's just set the radar gun at the side of the autobahn and just leave. Here, someone would probably steal it. If my sources are correct, Germany is using a South African innovation http://www.truvelo.co.za/traffic/index.html Here in Sunny South Africa those fixed cameras are mounted high, very high, skyhigh on poles, otherwise they will be stolen/vandalized. ;-D And if the cops lose those laser or radar guns, they're in trouble of course. Not my problem. ;-) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
