GSE (UK) Enterprise Security Working Group
Sent on behalf of Jamie Pease, Chairman GSE (UK) Enterprise Security Working Group Chairman. Ladies and Gentlemen, Just to remind you that the next meeting of the GSE Enterprise Security Working Group will take place on Wednesday 27th June in Central London. Full details including the agenda can be found at http://www.racf.gse.org.uk/future.html If you wish to attend the meeting please send me an email and I will add you to the list. Don't forget that you can earn CPEs for attending and a certificate of attendance will be issued to you to support your CPE claim. Regards _ Jamie Pease CISA, CISM, CISSP, MBCS CITP Certified IT Specialist, System z Security IBM Software Group Mobile: +44-7809-551709 (Mobex 37268263) e-mail: jamie_pe...@uk.ibm.commailto:jamie_pe...@uk.ibm.com _ Chairman of the GSE (UK) Enterprise Security Working Group http://www.racf.gse.org.uk/ Regards, _ Mark Wilson Technical Director RSM Partners Ltd z Specialists, Software Support __ This message was delivered by EPA Hosted Exchange and has been certified virus-free. For more information please visit http://www.epacloud.com/exchange __ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
GSE UK - Enterprise Security Working Group Meeting
Email sent on behalf of Jamie Pease Hi Folks, I'm pleased to announce that the next meeting of the GSE Enterprise Security Working Group will take place on Wednesday 27th June. Full details including the agenda can be found at http://www.racf.gse.org.uk/future.html If you wish to attend the meeting please send me an email and I will add you to the list. Regards _ Jamie Pease CISA, CISM, CISSP, MBCS CITP IT Specialist, System z Security IBM Software Group Mobile: +44-7809-551709 (Mobex 37268263) e-mail: jamie_pe...@uk.ibm.com _ Chairman of the GSE (UK) Enterprise Security Working Group http://www.racf.gse.org.uk/ Regards, _ Mark Wilson Technical Director RSM Partners Ltd z Specialists, Software Support Mobile +44 (0)7768 617006 Offices: The Courtyard, Buntsford Drive, Stoke Pound, Bromsgrove B60 3DJ Tel: 0870 0501004 Fax: 0870 0501006 Email: ma...@rsmpartners.com Web: www.rsmpartners.com GSE Information Large Systems Working Group Chairman www.lsx.gse.org.uk GSE UK Conference Manager www.gse.org.uk/tyc __ This message was delivered by EPA Hosted Exchange and has been certified virus-free. For more information please visit http://www.epacloud.com/exchange __ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
In offdd56d92.3c8dec60-on852579bf.006726f5-852579bf.0067b...@us.ibm.com, on 03/12/2012 at 02:52 PM, Peter Relson rel...@us.ibm.com said: The authorized code must be written to prevent such exposures. What does IGX00011 do and what are the safeguards? -- 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: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On Sun, Mar 11, 2012 at 8:07 AM, John Gilmore johnwgilmore0...@gmail.comwrote: Since this sort of thing is expected of me, I will note that we find ourselves between Scylla and Charybdis here. Chris Craddock's formulation was open to the exception that Peter Relson took: there is fetch-protected storage the contents of which its owner is entirely free to make available to others. Peter's exception is logically impeccable. It did, however, seem to me to be a very special one; and I observed that it was. I still prefer the ROT that the contents of protected storage should not be made available to the unauthorized (in any but very special circumstances, when they are known procedurally to be innocuous.). To repeat myself now, Peter is nonetheless correct in the abstract. There is a long intellectual tradition which has it that the production of just one black swan is an unanswerable refutation of the proposition that all swans are white. I can't quibble with Peter's exception. I was evidently not sufficiently clear. I had assumed it was self-evident to everyone that a privileged program is free to do what ever it wants with the contents of its own storage - including both disclosing and/or modifying that data - regardless of fetch protection. I was merely pointing out to a prior poster that a privileged program is required to honor key controlled protection in general and meeting that requirement is more rigorous than just not mindlessly storing in areas provided by a caller (regardless of the caller's key). -- This email might be from the artist formerly known as CC (or not) You be the judge. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
Some of the integrity examples have been tripping a bit over trying to define system integrity in terms of the behavior of authorized programs, when the statement is in terms of what an unauthorized program must not be allowed to do. For the PC FLIH intercept case, the requirement is that a malicious user must not be able to take advantage of this mechanism in order to get their own code running authorized. For the fetch-protection case, the requirement is that a malicious user must not be able to trick a service into copying arbitrary fetch protected system key storage into non-fetch protected storage viewable by the unauthorized caller. The authorized code must be written to prevent such exposures. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
this is true, but it is not interesting. (with respect to my pointing out some flaws in the examples) I respectfully disagree. When something is presented as a guideline or even perhaps a rule of thumb, that is one thing. When something is presented as a rule, that is a different thing. If it is stated that x is true when it is not, that ought to be challenged. I believe that that is where the examples fell. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
Since this sort of thing is expected of me, I will note that we find ourselves between Scylla and Charybdis here. Chris Craddock's formulation was open to the exception that Peter Relson took: there is fetch-protected storage the contents of which its owner is entirely free to make available to others. Peter's exception is logically impeccable. It did, however, seem to me to be a very special one; and I observed that it was. I still prefer the ROT that the contents of protected storage should not be made available to the unauthorized (in any but very special circumstances, when they are known procedurally to be innocuous.). To repeat myself now, Peter is nonetheless correct in the abstract. There is a long intellectual tradition which has it that the production of just one black swan is an unanswerable refutation of the proposition that all swans are white. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On 3/11/2012 9:07 AM, John Gilmore wrote: There is a long intellectual tradition which has it that the production of just one black swan is an unanswerable refutation of the proposition that all swans are white. I cringe at the word production - purportedly (google search came up empty) not too long ago in our nation's history it was common practice to paint sparrows for the purpose of selling them as parakeets. While I don't recall a proposition on swans, I was reminded of the Pejorative Calculus (Joel Cohen, On The Nature Of Mathematical Proofs, The Worm-Runner's Digest, Vol. III, No.3, December 1961), where Lemma I (all horses are the same color) is credited to Professor Lee M. Sonneborn, then at U. of Kansas. Gerhard Postpischil Bradford, VT -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
Swans, white and black, have a long history in scholastic and then mathematical logic, figuring too frequently in illustrations of modus ponens: All swans are white. A is a swan. Ergo, A is white. The heavy, unquestioning use of this scheme presumably reflects the fact that northern hemisphere swans, European and Japanese swans in particular, were/are white. All this changed when the southern hemisphere, Australian and New Zealand, black swan, Cygnus atratus, was discovered in the late 18th century. Black swan then came to have another, quite different connotation. It is used to describe putatively rare things when they are in fact found and sometimes even to derogate rareness, as in the recent heavy use of variants of Unscrupulous, greedy bankers are not black swans. Produce is used in logic as shorthand for provide an instance of in the sense of the existential quantifier, assert or show there is at least one S such that S is an x. Obtusely, I had not thought about the 'production of a black swan' in its other, literal or Marxist economic sense, accomplished say by painting a white swan black; but I agree that the idea is repellent. (We again have a significant, growing population of white swan pairs resident throughout the year in our glacial ponds/reservoirs here in Massachusetts west of Boston. They are very tolerant of people, and I should not want to see that change.) John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
I apologize in advance to Karl Schmitz if I have a bit of this not quite exact. Perhaps some Integrity Vulnerability examples will help clarify: 1)If your authorized program while executing in PSW key 0-7 stores into an address provided by an unauthorized caller then this is a violation of the IBM statement of integrity. The use of PSW key is imprecise. It's really while not using the user's key, whether by that being the PSW key or by using MVCK/MVCDK/MVCSK/etc.. But, more important, the (corrected) statement applies both to stores into and fetches from an address. Not just stores. Still, with the exception that if the address has been validated to be a block that the authorized program owns and that cannot change attributes while mid-stream and that is known not to be fetch-protected, maybe. There are any number of cases where unauthorized input identifies a system-key system block (which is verified as being a system block) and that block gets updated as a result of a service call by the system running in system key. 3)If your authorized program while executing in PSW Key 0-7 or supervisor state returns control to an unauthorized requester in an authorized state then this is a violation of the IBM statement of Integrity. By authorized state I mean PSW Key 0-7, Supervisor state, or now has the ability to MODESET. You really also need to add unintended if unauthorized refers only to key, state, and APF. This is allowed as long as it is done correctly, which includes limiting it to only the intended requestor(s). Getting that correct is the difficult part. And of course that's at heart of this whole thread. Whether done by a PC FLIH intercept returning via LPSW(E), or an SVC routine manipulating the RB, or a stacking PC manipulating the linkage stack, the concept is the same. 4)If your authorized program while executing in PSW Key 0-7 copies fetch protected storage to non-fetch protected storage then this is a violation of the IBM statement of integrity. This is not necessarily a violation of the IBM statement of integrity. It depends on whose data is being copied. I am allowed to put my own non-sensitive data into fetch-protected storage and copy it to non-fetch protected storage if I so choose. The requirement is that I not allow the unauthorized user to access something he should not be given access to. Fetch protection is just one tool in the bag of tricks. The owner of the data is typically the one that decides what the access limitations are to be. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
In response to Chris Craddock's stricture about the disclosure of the contents of fetch-protected storage Peter Relson wrote begin extract This is not necessarily a violation of the IBM statement of integrity. It depends on whose data is being copied. I am allowed to put my own non-sensitive data into fetch-protected storage and copy it to non-fetch protected storage if I so choose. The requirement is that I not allow the unauthorized user to access something he should not be given access to. Fetch protection is just one tool in the bag of tricks. The owner of the data is typically the one that decides what the access limitations are to be. end extract/ To borrow one of Chomsky's distinctions, this is true, but it is not interesting. I may of course do anything I like with something I myself put into fetch-protected storage. Moreover, I can know, locally and procedurally, when I can do so; but most of the time I am dealing with someone else's fetch-protected storage; and for it the only proper rule is non-disclosure to the unauthorized. An exact, entirely correct description of every action that constitutes a breach of integrity at some time T may just be achievable; but if it is achieved it will be obsolescent when it is achieved; and it will resemble a contract drawn up by an attorney not to inform but to protect a client from hostile litigation. It will not, that is, be at all helpful or even intelligible to any but the already well-informed. Integrity remains a crucial goal. Practices that clearly put it at risk must be avoided, and breaches must be closed as they are detected. (Disagreeable as this sounds, 1) we now learn chiefly from these breaches; and 2) there will be more of them.) ROTs simplify reality, and they thus always entail overkill, but they are useful to people who lack the experience to make subtle distinctions. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
In 4f58fe65.7030...@kr-inc.com, on 03/08/2012 at 12:45 PM, Ray Overby ray.ove...@kr-inc.com said: 1)If your authorized program while executing in PSW key 0-7 stores into an address provided by an unauthorized caller then this is a violation of the IBM statement of integrity. MVCDK -- 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: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On Mar 8, 2012, at 1:15 PM, Ray Overby ray.ove...@kr-inc.com wrote: Rob - How about: If your authorized program while executing in PSW Key 0-7 stores into an address provided by an unauthorized caller (as long as the store operation uses the execution PSW KEY) then this is a violation of the IBM statement of integrity. Not necessarily. The integrity statement would only be violated if the privileged program allowed the non-privileged program to circumvent key controlled access. To prevent this, the privileged program must use the non-privileged program's PSW key when passing any results back in areas provider by the caller (e.g. By using MVCDK and the caller's key) - however, the privileged program must also ensure that it does not inadvertently disclose the contents of fetch protected storage, regardless of how it moves the results back to the caller. In the latter case a black hat might cleverly cause a malformed privileged program to copy (say) contents of key zero fetch protected storage into plain old user key storage where the black hat could inspect it to his heart's content. So bottom line: using the caller's key to return results is a necessary, but not sufficient condition to maintain integrity. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On Tue, 6 Mar 2012 15:40:25 -0600, Tom Marchant wrote: By PCFLIH backdoor I mean a routine whose address replaced the address of the IBM supplied PCFLIH. That would be a hook or an intercept. Backdoor means something else entirely. You have your definition for 'backdoor', I have mine, Next. The backdoor routine received control every time a PC interrupt ITYM a program interruption. Yes. That is certainly not what the vendor routine being discussed is alleged to have done. It is alleged to return to the program that was interrupted in supervisor state. It is further alleged that it is relatively easy for any program to exploit this and to get put into supervisor state. I keep seeing that 'alleged' word. Doesn't anyone actually know what they did/do, and how did they do this magic without being APF authorized, and if they were APF authorized then they could by definition switch anyone or any task in the system to supervisor state so what does it matter at that point anyway; the battle is lost, get out your white flags and start waving. Now if they did this magic and they were NOT APF authorized, then we have a lot to talk about here. I have not seen the vendor code and cannot comment on what it does or does not do or how much security checking it does or does not perform before it does what it does. My defense was of the use of the technique of 'backdooring, hooking, intercepting, or whatever word you choose to use in whatever language you choose to use' when it is the appropriate technique. I would really hate to see IBM use this discussion as a justification for somehow making it impossible for a sharp systems programmer or vendor to use this technique when there are times that it is the only technique that will work. I guess it was that 'criminal' word in the subject line that set me off. As for what the vendor did, I am not offering any justification and if what you would like to organize with this discussion is a party where we all get together a roast a few vendors I will not only volunteer to bring some firewood I will also invite my CA and IBM marketing reps to come with me to the party! Gene Pate CSX Technology Enterprise Architecture - This email transmission and any accompanying attachments may contain CSX privileged and confidential information intended only for the use of the intended addressee. Any dissemination, distribution, copying or action taken in reliance on the contents of this email by anyone other than the intended recipient is strictly prohibited. If you have received this email in error please immediately delete it and notify sender at the above CSX email address. Sender and CSX accept no liability for any damage caused directly or indirectly by receipt of this email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On Thu, 8 Mar 2012 13:49:28 +, Pate, Gene wrote: You have your definition for 'backdoor', I have mine, Next. That is the root of your confusion. This thread is about a vendor creating a backdoor according to my definition. You are amazed at the uproar over this because you applied your definition of what a backdoor is without considering the description of what the backdoor was in the original discussion. if they were APF authorized then they could by definition switch anyone or any task in the system to supervisor state Yes, an APF authorized program can do that. It can also create a backdoor (my definition) that any task in the system can walk through and get into supervisor state. That is the objection that was raised, and it is a very different matter. Since your definition of a backdoor is simply an intercept of a system routine, what would you call it when an authorized program creates an interface that any program can use to put itself into supervisor state? Now if they did this magic and they were NOT APF authorized, then we have a lot to talk about here. Of course they were authorized to be able to install their intercept I have not seen the vendor code and cannot comment on what it does or does not do or how much security checking it does or does not perform before it does what it does. That was Ed's point too. Neither have I and it's the reason I said alleged. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
an APF authorized program can do that. It can also create a backdoor (my definition) that any task in the system can walk through and get into supervisor state. That is the objection that was raised, and it is a very different matter. I should be smarter than to wade into this one but is it not true, unfortunately, that an APF program can do ANYTHING it wants to do? Doing anything it wants to do would include granting privileges implicitly to other programs would it not? Further, there is no industry agreement -- witness this thread -- on what constitutes acceptable APF authorized program conduct. My the only technique that will work is someone else's criminal breach of security. It seems to me the problem here is, from a technological point of view, the all or nothing nature of APF authorization. IBM is moving away from that approach, but APF authorization as it is and was is going to be with us for a long time. From a non-technology point of view, we need some sort of industry agreement on what is good behavior in an authorized program. I am thinking of something like a standardized set of questions that a vendor could answer and have an officer certify: Mr./Ms. Customer, we are asking for APF authorization. I certify under penalty of fraud that our program uses APF authorization to do X, and Y, and Z but does not do A, and B, and C. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Tom Marchant Sent: Thursday, March 08, 2012 6:19 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Program FLIH backdoor - This is a criminal breach of security! On Thu, 8 Mar 2012 13:49:28 +, Pate, Gene wrote: You have your definition for 'backdoor', I have mine, Next. That is the root of your confusion. This thread is about a vendor creating a backdoor according to my definition. You are amazed at the uproar over this because you applied your definition of what a backdoor is without considering the description of what the backdoor was in the original discussion. if they were APF authorized then they could by definition switch anyone or any task in the system to supervisor state Yes, an APF authorized program can do that. It can also create a backdoor (my definition) that any task in the system can walk through and get into supervisor state. That is the objection that was raised, and it is a very different matter. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On 3/8/2012 6:40 AM, Charles Mills wrote: From a non-technology point of view, we need some sort of industry agreement on what is good behavior in an authorized program. I am thinking of something like a standardized set of questions that a vendor could answer and have an officer certify: Mr./Ms. Customer, we are asking for APF authorization. I certify under penalty of fraud that our program uses APF authorization to do X, and Y, and Z but does not do A, and B, and C. You have no integrity statement?? Wow! You might consider drafting one... Here is IBM's you can use as a template: http://www.ibm.com/systems/z/os/zos/features/racf/zos_integrity_statement.html -- 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: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
Not sure I get your drift. I am talking about the problem in the OP, not about me, and not about preventing programs from doing X and Y but rather about an agreement about what is legitimate and what is not, or as I said, one person's 'the only technique that will work' [a phrase one poster used] is someone else's 'criminal breach of security.' Failing that, a formal affirmation of we do X but we don't do Y. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Edward Jaffe Sent: Thursday, March 08, 2012 7:15 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Program FLIH backdoor - This is a criminal breach of security! On 3/8/2012 6:40 AM, Charles Mills wrote: From a non-technology point of view, we need some sort of industry agreement on what is good behavior in an authorized program. I am thinking of something like a standardized set of questions that a vendor could answer and have an officer certify: Mr./Ms. Customer, we are asking for APF authorization. I certify under penalty of fraud that our program uses APF authorization to do X, and Y, and Z but does not do A, and B, and C. You have no integrity statement?? Wow! You might consider drafting one... Here is IBM's you can use as a template: http://www.ibm.com/systems/z/os/zos/features/racf/zos_integrity_statement.ht ml -- 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: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
The IBM statement of Integrity or its equivalent is a standard that all authorized programs should conform with. See IBM statement of Integrity http://www-03.ibm.com/systems/z/os/zos/features/racf/zos_integrity_statement.html. If you look at z/OS V1R12.0 MVS Authorized Assembler Services Guide: 21.1.2 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a8b0/21.1.2?ACTION=MATCHESREQUEST=system+integrityTYPE=FUZZYSHELF=EZ2ZBK0KDT=20100629141054CASE=searchTopic=TOPICsearchText=TEXTsearchIndex=INDEXrank=RANKScrollTOP=FIRSTHIT#FIRSTHIT/you/ will see that IBM puts the responsibility on the installation for ensuring the integrity (i.e. - conforms to the IBM statement of Integrity) for any modifications or extensions to z/OS the installation makes. This would include any authorized code written/installed by the installation as well as any authorized code installed that is from ISVs. If the backdoor, intercept, or other authorized program violates the IBM statement of integrity then it is a problem that needs to be remediated. Ray Overby Key Resources, Inc. Ensuring System Integrity for z/Series^(TM) www.zassure.com (312)574-0007 On 3/8/2012 08:40 AM, Charles Mills wrote: an APF authorized program can do that. It can also create a backdoor (my definition) that any task in the system can walk through and get into supervisor state. That is the objection that was raised, and it is a very different matter. I should be smarter than to wade into this one but is it not true, unfortunately, that an APF program can do ANYTHING it wants to do? Doing anything it wants to do would include granting privileges implicitly to other programs would it not? Further, there is no industry agreement -- witness this thread -- on what constitutes acceptable APF authorized program conduct. My the only technique that will work is someone else's criminal breach of security. It seems to me the problem here is, from a technological point of view, the all or nothing nature of APF authorization. IBM is moving away from that approach, but APF authorization as it is and was is going to be with us for a long time. From a non-technology point of view, we need some sort of industry agreement on what is good behavior in an authorized program. I am thinking of something like a standardized set of questions that a vendor could answer and have an officer certify: Mr./Ms. Customer, we are asking for APF authorization. I certify under penalty of fraud that our program uses APF authorization to do X, and Y, and Z but does not do A, and B, and C. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Tom Marchant Sent: Thursday, March 08, 2012 6:19 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Program FLIH backdoor - This is a criminal breach of security! On Thu, 8 Mar 2012 13:49:28 +, Pate, Gene wrote: You have your definition for 'backdoor', I have mine, Next. That is the root of your confusion. This thread is about a vendor creating a backdoor according to my definition. You are amazed at the uproar over this because you applied your definition of what a backdoor is without considering the description of what the backdoor was in the original discussion. if they were APF authorized then they could by definition switch anyone or any task in the system to supervisor state Yes, an APF authorized program can do that. It can also create a backdoor (my definition) that any task in the system can walk through and get into supervisor state. That is the objection that was raised, and it is a very different matter. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
I will give it one more shot at trying to clarify what I mean. Witness this thread, reasonable people can disagree on what violates the statement of integrity means. One person's reasonable or only available technique is another person's violation. We could use some finer granularity. We could use a standard statement of does X but does not do Y. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ray Overby Sent: Thursday, March 08, 2012 8:45 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Program FLIH backdoor - This is a criminal breach of security! The IBM statement of Integrity or its equivalent is a standard that all authorized programs should conform with. See IBM statement of Integrity http://www-03.ibm.com/systems/z/os/zos/features/racf/zos_integrity_statemen t.html. If you look at z/OS V1R12.0 MVS Authorized Assembler Services Guide: 21.1.2 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a8b0/21.1.2? ACTION=MATCHESREQUEST=system+integrityTYPE=FUZZYSHELF=EZ2ZBK0KDT=2010062 9141054CASE=searchTopic=TOPICsearchText=TEXTsearchIndex=INDEXrank=RANK ScrollTOP=FIRSTHIT#FIRSTHIT/you/ will see that IBM puts the responsibility on the installation for ensuring the integrity (i.e. - conforms to the IBM statement of Integrity) for any modifications or extensions to z/OS the installation makes. This would include any authorized code written/installed by the installation as well as any authorized code installed that is from ISVs. If the backdoor, intercept, or other authorized program violates the IBM statement of integrity then it is a problem that needs to be remediated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
Charles - yes, it is somewhat ambiguous what violation of the IBM statement of integrity means. Perhaps some Integrity Vulnerability examples will help clarify: 1)If your authorized program while executing in PSW key 0-7 stores into an address provided by an unauthorized caller then this is a violation of the IBM statement of integrity. 2)If your authorized program while executing in PSW Key 0-7 or supervisor state branches to an address provided by an unauthorized requester then this is a violation of the IBM statement of Integrity. 3)If your authorized program while executing in PSW Key 0-7 or supervisor state returns control to an unauthorized requester in an authorized state then this is a violation of the IBM statement of Integrity. By authorized state I mean PSW Key 0-7, Supervisor state, or now has the ability to MODESET. 4)If your authorized program while executing in PSW Key 0-7 copies fetch protected storage to non-fetch protected storage then this is a violation of the IBM statement of integrity. The unauthorized requester in these case's would be any PSW Key 8 problem state program that is not currently enabled to MODESET prior to issuing a request to an authorized service. After the request completes the program now has new capabilities that were not available prior to the request such as: -The program could now be in an authorized state (psw key 0-7 or supervisor state) -The program could now have the ability to MODESET -The security credentials may have been dynamically elevated (i.e. - I now have RACF privileged attribute which I did not have before) -Some code provided by my program could have been executed in an authorized state (PSW Key 0-7 or Supervisor state). If you examine the before and after state around the invoking of the authorized service you generally see some form of elevated capabilities when a violation of the IBM statement of integrity occurs. Ray Overby Key Resources, Inc. Ensuring System Integrity for z/Series^(TM) www.zassure.com (312)574-0007 On 3/8/2012 11:20 AM, Charles Mills wrote: I will give it one more shot at trying to clarify what I mean. Witness this thread, reasonable people can disagree on what violates the statement of integrity means. One person's reasonable or only available technique is another person's violation. We could use some finer granularity. We could use a standard statement of does X but does not do Y. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ray Overby Sent: Thursday, March 08, 2012 8:45 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Program FLIH backdoor - This is a criminal breach of security! The IBM statement of Integrity or its equivalent is a standard that all authorized programs should conform with. See IBM statement of Integrity http://www-03.ibm.com/systems/z/os/zos/features/racf/zos_integrity_statemen t.html. If you look at z/OS V1R12.0 MVS Authorized Assembler Services Guide: 21.1.2 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a8b0/21.1.2? ACTION=MATCHESREQUEST=system+integrityTYPE=FUZZYSHELF=EZ2ZBK0KDT=2010062 9141054CASE=searchTopic=TOPICsearchText=TEXTsearchIndex=INDEXrank=RANK ScrollTOP=FIRSTHIT#FIRSTHIT/you/ will see that IBM puts the responsibility on the installation for ensuring the integrity (i.e. - conforms to the IBM statement of Integrity) for any modifications or extensions to z/OS the installation makes. This would include any authorized code written/installed by the installation as well as any authorized code installed that is from ISVs. If the backdoor, intercept, or other authorized program violates the IBM statement of integrity then it is a problem that needs to be remediated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
1)If your authorized program while executing in PSW key 0-7 stores into an address provided by an unauthorized caller then this is a violation of the IBM statement of integrity. Sorry - I disagree with this. It is quite OK for auth routines (eg PC-ss) to store into storage whose address is provided by the caller *AS LONG AS THE CALLER'S KEY IS USED* when moving the data. See the MVCDK instruction. Likewise any authorized routine should treat caller provided storage with suspicion and use MVCSK to copy any data from the caller and use trusted control block pointers rather than rely on caller contents. Rob Scott Lead Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ray Overby Sent: 08 March 2012 18:46 To: IBM-MAIN@bama.ua.edu Subject: Re: Program FLIH backdoor - This is a criminal breach of security! Charles - yes, it is somewhat ambiguous what violation of the IBM statement of integrity means. Perhaps some Integrity Vulnerability examples will help clarify: 1)If your authorized program while executing in PSW key 0-7 stores into an address provided by an unauthorized caller then this is a violation of the IBM statement of integrity. 2)If your authorized program while executing in PSW Key 0-7 or supervisor state branches to an address provided by an unauthorized requester then this is a violation of the IBM statement of Integrity. 3)If your authorized program while executing in PSW Key 0-7 or supervisor state returns control to an unauthorized requester in an authorized state then this is a violation of the IBM statement of Integrity. By authorized state I mean PSW Key 0-7, Supervisor state, or now has the ability to MODESET. 4)If your authorized program while executing in PSW Key 0-7 copies fetch protected storage to non-fetch protected storage then this is a violation of the IBM statement of integrity. The unauthorized requester in these case's would be any PSW Key 8 problem state program that is not currently enabled to MODESET prior to issuing a request to an authorized service. After the request completes the program now has new capabilities that were not available prior to the request such as: -The program could now be in an authorized state (psw key 0-7 or supervisor state) -The program could now have the ability to MODESET -The security credentials may have been dynamically elevated (i.e. - I now have RACF privileged attribute which I did not have before) -Some code provided by my program could have been executed in an authorized state (PSW Key 0-7 or Supervisor state). If you examine the before and after state around the invoking of the authorized service you generally see some form of elevated capabilities when a violation of the IBM statement of integrity occurs. Ray Overby Key Resources, Inc. Ensuring System Integrity for z/Series^(TM) www.zassure.com (312)574-0007 On 3/8/2012 11:20 AM, Charles Mills wrote: I will give it one more shot at trying to clarify what I mean. Witness this thread, reasonable people can disagree on what violates the statement of integrity means. One person's reasonable or only available technique is another person's violation. We could use some finer granularity. We could use a standard statement of does X but does not do Y. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ray Overby Sent: Thursday, March 08, 2012 8:45 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Program FLIH backdoor - This is a criminal breach of security! The IBM statement of Integrity or its equivalent is a standard that all authorized programs should conform with. See IBM statement of Integrity http://www-03.ibm.com/systems/z/os/zos/features/racf/zos_integrity_st atemen t.html. If you look at z/OS V1R12.0 MVS Authorized Assembler Services Guide: 21.1.2 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a8b0/21.1.2? ACTION=MATCHESREQUEST=system+integrityTYPE=FUZZYSHELF=EZ2ZBK0KDT=2 010062 9141054CASE=searchTopic=TOPICsearchText=TEXTsearchIndex=INDEXrank =RANK ScrollTOP=FIRSTHIT#FIRSTHIT/you/ will see that IBM puts the responsibility on the installation for ensuring the integrity (i.e. - conforms to the IBM statement of Integrity) for any modifications or extensions to z/OS the installation makes. This would include any authorized code written/installed by the installation as well as any authorized code installed that is from ISVs. If the backdoor, intercept, or other authorized program violates the IBM statement of integrity then it is a problem that needs to be remediated. -- For IBM-MAIN subscribe / signoff / archive access
Re: Program FLIH backdoor - This is a criminal breach of security!
Rob - How about: If your authorized program while executing in PSW Key 0-7 stores into an address provided by an unauthorized caller (as long as the store operation uses the execution PSW KEY) then this is a violation of the IBM statement of integrity. Ray Overby Key Resources, Inc. Ensuring System Integrity for z/Series^(TM) www.zassure.com (312)574-0007 On 3/8/2012 13:02 PM, Rob Scott wrote: 1)If your authorized program while executing in PSW key 0-7 stores into an address provided by an unauthorized caller then this is a violation of the IBM statement of integrity. Sorry - I disagree with this. It is quite OK for auth routines (eg PC-ss) to store into storage whose address is provided by the caller *AS LONG AS THE CALLER'S KEY IS USED* when moving the data. See the MVCDK instruction. Likewise any authorized routine should treat caller provided storage with suspicion and use MVCSK to copy any data from the caller and use trusted control block pointers rather than rely on caller contents. Rob Scott Lead Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ray Overby Sent: 08 March 2012 18:46 To: IBM-MAIN@bama.ua.edu Subject: Re: Program FLIH backdoor - This is a criminal breach of security! Charles - yes, it is somewhat ambiguous what violation of the IBM statement of integrity means. Perhaps some Integrity Vulnerability examples will help clarify: 1)If your authorized program while executing in PSW key 0-7 stores into an address provided by an unauthorized caller then this is a violation of the IBM statement of integrity. 2)If your authorized program while executing in PSW Key 0-7 or supervisor state branches to an address provided by an unauthorized requester then this is a violation of the IBM statement of Integrity. 3)If your authorized program while executing in PSW Key 0-7 or supervisor state returns control to an unauthorized requester in an authorized state then this is a violation of the IBM statement of Integrity. By authorized state I mean PSW Key 0-7, Supervisor state, or now has the ability to MODESET. 4)If your authorized program while executing in PSW Key 0-7 copies fetch protected storage to non-fetch protected storage then this is a violation of the IBM statement of integrity. The unauthorized requester in these case's would be any PSW Key 8 problem state program that is not currently enabled to MODESET prior to issuing a request to an authorized service. After the request completes the program now has new capabilities that were not available prior to the request such as: -The program could now be in an authorized state (psw key 0-7 or supervisor state) -The program could now have the ability to MODESET -The security credentials may have been dynamically elevated (i.e. - I now have RACF privileged attribute which I did not have before) -Some code provided by my program could have been executed in an authorized state (PSW Key 0-7 or Supervisor state). If you examine the before and after state around the invoking of the authorized service you generally see some form of elevated capabilities when a violation of the IBM statement of integrity occurs. Ray Overby Key Resources, Inc. Ensuring System Integrity for z/Series^(TM) www.zassure.com (312)574-0007 On 3/8/2012 11:20 AM, Charles Mills wrote: I will give it one more shot at trying to clarify what I mean. Witness this thread, reasonable people can disagree on what violates the statement of integrity means. One person's reasonable or only available technique is another person's violation. We could use some finer granularity. We could use a standard statement of does X but does not do Y. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ray Overby Sent: Thursday, March 08, 2012 8:45 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Program FLIH backdoor - This is a criminal breach of security! The IBM statement of Integrity or its equivalent is a standard that all authorized programs should conform with. See IBM statement of Integrity http://www-03.ibm.com/systems/z/os/zos/features/racf/zos_integrity_st atemen t.html. If you look at z/OS V1R12.0 MVS Authorized Assembler Services Guide: 21.1.2 http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/iea2a8b0/21.1.2? ACTION=MATCHESREQUEST=system+integrityTYPE=FUZZYSHELF=EZ2ZBK0KDT=2 010062 9141054CASE=searchTopic=TOPICsearchText=TEXTsearchIndex=INDEXrank =RANK ScrollTOP=FIRSTHIT#FIRSTHIT/you/ will see that IBM puts the responsibility on the installation for ensuring the integrity (i.e. - conforms to the IBM statement of Integrity) for any modifications or extensions to z/OS the installation makes. This would include any authorized code written/installed
Re: Program FLIH backdoor - This is a criminal breach of security!
How about : If your authorized program, while executing in PSW key 0-7 stores into an address provided by an unauthorized caller without using the caller's key then this is a violation of the IBM statement of integrity I am sure there are other people on IBM-Main who could make this more readable and accurate. Truth is that there are lots programs out there (public domain, in-house utilities) that just splat into caller storage using Key0 regardless of caller key. A good example of how to do it properly in Authorized Assembler Programming Guide would be my preferred start for re-education of the masses. Rob Scott Lead Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ray Overby Sent: 08 March 2012 19:15 To: IBM-MAIN@bama.ua.edu Subject: Re: Program FLIH backdoor - This is a criminal breach of security! Rob - How about: If your authorized program while executing in PSW Key 0-7 stores into an address provided by an unauthorized caller (as long as the store operation uses the execution PSW KEY) then this is a violation of the IBM statement of integrity. Ray Overby Key Resources, Inc. Ensuring System Integrity for z/Series^(TM) www.zassure.com (312)574-0007 On 3/8/2012 13:02 PM, Rob Scott wrote: 1)If your authorized program while executing in PSW key 0-7 stores into an address provided by an unauthorized caller then this is a violation of the IBM statement of integrity. Sorry - I disagree with this. It is quite OK for auth routines (eg PC-ss) to store into storage whose address is provided by the caller *AS LONG AS THE CALLER'S KEY IS USED* when moving the data. See the MVCDK instruction. Likewise any authorized routine should treat caller provided storage with suspicion and use MVCSK to copy any data from the caller and use trusted control block pointers rather than rely on caller contents. Rob Scott Lead Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.781.684.2305 Email: rsc...@rs.com Web: www.rocketsoftware.com -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ray Overby Sent: 08 March 2012 18:46 To: IBM-MAIN@bama.ua.edu Subject: Re: Program FLIH backdoor - This is a criminal breach of security! Charles - yes, it is somewhat ambiguous what violation of the IBM statement of integrity means. Perhaps some Integrity Vulnerability examples will help clarify: 1)If your authorized program while executing in PSW key 0-7 stores into an address provided by an unauthorized caller then this is a violation of the IBM statement of integrity. 2)If your authorized program while executing in PSW Key 0-7 or supervisor state branches to an address provided by an unauthorized requester then this is a violation of the IBM statement of Integrity. 3)If your authorized program while executing in PSW Key 0-7 or supervisor state returns control to an unauthorized requester in an authorized state then this is a violation of the IBM statement of Integrity. By authorized state I mean PSW Key 0-7, Supervisor state, or now has the ability to MODESET. 4)If your authorized program while executing in PSW Key 0-7 copies fetch protected storage to non-fetch protected storage then this is a violation of the IBM statement of integrity. The unauthorized requester in these case's would be any PSW Key 8 problem state program that is not currently enabled to MODESET prior to issuing a request to an authorized service. After the request completes the program now has new capabilities that were not available prior to the request such as: -The program could now be in an authorized state (psw key 0-7 or supervisor state) -The program could now have the ability to MODESET -The security credentials may have been dynamically elevated (i.e. - I now have RACF privileged attribute which I did not have before) -Some code provided by my program could have been executed in an authorized state (PSW Key 0-7 or Supervisor state). If you examine the before and after state around the invoking of the authorized service you generally see some form of elevated capabilities when a violation of the IBM statement of integrity occurs. Ray Overby Key Resources, Inc. Ensuring System Integrity for z/Series^(TM) www.zassure.com (312)574-0007 On 3/8/2012 11:20 AM, Charles Mills wrote: I will give it one more shot at trying to clarify what I mean. Witness this thread, reasonable people can disagree on what violates the statement of integrity means. One person's reasonable or only available technique is another person's violation. We could use some finer granularity. We could use a standard statement of does X but does not do Y
Re: Program FLIH backdoor - This is a criminal breach of security!
On 5 Mar 2012 23:38:50 -0800, in bit.listserv.ibm-main you wrote: On 3/5/2012 6:06 PM, Shmuel Metz (Seymour J.) wrote: In4f540cf5.3080...@phoenixsoftware.com, on 03/04/2012 at 04:46 PM, Edward Jaffeedja...@phoenixsoftware.com said: Look more closely. In the PLM that IBM doesn't publish? Peter? Could you comment on what IGX00011 does? To understand what it does study the two trace entries below (GTF is your friend): SVC CODE 109 ASCB 00F95200 CPU. PSW. 0785 806D 0C53B222 TCB. 00AC8300 R15. 000B R0.. R1.. 0001 GMT-03/06/2012 06:59:08.693767 LOC-03/05/2012 22:59:08.693767 SVCR CODE 109 ASCB 00F95200 CPU. PSW. 0714 806D 0C53B222 TCB. 00AC8300 R15. R0.. R1.. 0001 GMT-03/06/2012 06:59:08.693799 LOC-03/05/2012 22:59:08.693799 You need to look more closely at IGX00011. Hint: the secure implementation is not just in the SVC(ESR) routine itself but also in the caller What caller? It might not be the intended caller. Of course, I meant the intended caller. Unintended callers can't successfully use the service. How does the system verify that the caller is the intended caller versus an impostor? Clark Morris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
In 4f55be9e.7000...@phoenixsoftware.com, on 03/05/2012 at 11:37 PM, Edward Jaffe edja...@phoenixsoftware.com said: To understand what it does study the two trace entries below (GTF is your friend): That doesn't tell me what happens in between. Of course, I meant the intended caller. Code trumps intention. Unintended callers can't successfully use the service. What stops them. -- 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: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On 3/6/2012 7:40 AM, Clark Morris wrote: On 5 Mar 2012 23:38:50 -0800, in bit.listserv.ibm-main you wrote: To understand what it does study the two trace entries below (GTF is your friend): SVC CODE 109 ASCB 00F95200 CPU. PSW. 0785 806D 0C53B222 TCB. 00AC8300 R15. 000B R0.. R1.. 0001 GMT-03/06/2012 06:59:08.693767 LOC-03/05/2012 22:59:08.693767 SVCR CODE 109 ASCB 00F95200 CPU. PSW. 0714 806D 0C53B222 TCB. 00AC8300 R15. R0.. R1.. 0001 GMT-03/06/2012 06:59:08.693799 LOC-03/05/2012 22:59:08.693799 How does the system verify that the caller is the intended caller versus an impostor? Suffice to say that it does. My intent was not to explain the intricacies of this interface -- smart programmers can likely figure that out for themselves -- but rather to dispel the myth that such interfaces necessarily represent an exposure. This is IBM code!! The above notwithstanding, I don't think anyone at IBM or elsewhere would recommend this technique for brand new, 21st-century development. Making it secure is a tricky business that requires a deep understanding of system internals. There are much better interfaces available to modern developers on z/OS that guarantee integrity without having to work so hard. -- 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: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
Edward E. Jaffe wrote: begin extract The above notwithstanding, I don't think anyone at IBM or elsewhere would recommend this technique for brand new, 21st-century development. /end extract and I am very pleased to see that this is his view. My own, slightly different view of this interface is in a certain sense admiring; but it is also very like my view of Kama Sutra position 327,859: I see that you can do it that way, but why? Moreover, as I have had occasion to say here before, its cleverness seems to me to be misplaced or, better perhaps, too provocative. It implicitly poses a challenge of the self-congratulatory form: No impostor is clever enough to penetrate our defenses! This is unfortunate because there are able old-sense hackers who respond only to such challenges. (It is a good operational premise to assume, however improbably, that attackers are as smart as defenders.) John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
In 4f5638d5.6050...@phoenixsoftware.com, on 03/06/2012 at 08:18 AM, Edward Jaffe edja...@phoenixsoftware.com said: Suffice to say that it does. Perhaps; I'd have to examine the code to confirm that. Of course, if I examined the code and found a hole, I wouldn't give the details to anybody but IBM. -- 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: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
I am amazed at the uproar over this. Is there anything that a PCFLIH backdoor can accomplish that any AC=1 module in any APF authorized library cannot? Is there anyone else out there that is running any vendor code for which they have not done code reviews that is running AC=1 in any APF authorized library? Is there anyone else out there that is running any home grown code with an AC=1 in an APF authorized library for which they have not done code reviews? Is there anyone else out there that has libraries in the APF list that can be updated by anything other than there change control system that only allows modules that have been through code reviews to be installed in their APF authorized libraries? How you allow code to get into supervisor state is of no consequence once it is in supervisor state so, unless you have a pristine system where every load module library on the system is totally locked down and only the OS libraries supplied by IBM appear in the APF list, you have by definition accepted exposures to system integrity. Does your management understand just how exposed you have left all the company secrets? Using a PCFLIH backdoor is only one of many techniques that can be used to accomplish getting yourself into supervisor state and sometimes it is the right technique and sometimes it is not. Back in the late 70's I wrote a PCFLIH backdoor because it was not only the correct technique it was the only technique that would work. My company and its sister companies had many 168APs that did not have the MVS/SE hardware assist installed. At that time IBM wanted about $150K per system for the hardware upgrade and we already had plans to replace all of them over the next 3 years with 3033s so there was no money to upgrade them. I wrote an SE hardware emulator that would run on Ups, APs, and MPs and while you got a 15% performance increase with the hardware upgrade and MVS/SE we still got around 12% with my PCFLIH hardware emulator and we were able to move to MVS/SE 3 years sooner that we could have had we all had to wait until all the 168s were replaced. If there was any criminal activity involved in this entire affair I believe it was on IBM's part for trying to charge us $150K per system for a microcode upgrade to a bunch of outdated systems and not on the part any PCFLIH code that I wrote so I outright reject your assertion that a PCFLIH backdoor is any more criminal than running any AC=1 module in any APF authorized library that you as the systems programmer have not personally code reviewed before you allowed it to run on any system that you are responsible for! Gene Pate CSX Technology Enterprise Architecture - This email transmission and any accompanying attachments may contain CSX privileged and confidential information intended only for the use of the intended addressee. Any dissemination, distribution, copying or action taken in reliance on the contents of this email by anyone other than the intended recipient is strictly prohibited. If you have received this email in error please immediately delete it and notify sender at the above CSX email address. Sender and CSX accept no liability for any damage caused directly or indirectly by receipt of this email. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
I wrote an SE hardware emulator that would run on Ups, APs, and MPs and while you got a 15% performance increase with the hardware upgrade and MVS/SE we still got around 12% with my PCFLIH hardware emulator and we were able to move to MVS/SE 3 years sooner that we could have had we all had to wait until all the 168s were replaced. That's exactly what Amdahl's SE and SP Assist did. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On Mon, 5 Mar 2012 14:19:33 +, Pate, Gene wrote: I am amazed at the uproar over this. Is there anything that a PCFLIH backdoor can accomplish that any AC=1 module in any APF authorized library cannot? Is there anyone else out there that is running any vendor code for which they have not done code reviews that is running AC=1 in any APF authorized library? Is there anyone else out there that is running any home grown code with an AC=1 in an APF authorized library for which they have not done code reviews? Is there anyone else out there that has libraries in the APF list that can be updated by anything other than there change control system that only allows modules that have been through code reviews to be installed in their APF authorized libraries? How you allow code to get into supervisor state is of no consequence once it is in supervisor state so, unless you have a pristine system where every load module library on the system is totally locked down ... Not every. I believe IBM's SOI applies regardless of what mey be put in non-authorized load libraries. and only the OS libraries supplied by IBM appear in the APF list, you have by definition accepted exposures to system integrity. Does your management understand just how exposed you have left all the company secrets? Or, by your earlier paragraph, suitable review is performed for non-IBM code. And even then, IBM's SOI doesn't apply. But why do you trust IBM? Their code is OCO and difficult to review. I suppose it's possible if one signs the required NDAs and pays the charges. Is there any independent commercial body that so reviews and certifies IBM's code? And even indemnifies? For a price, of course. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On 03/05/2012 08:19 AM, Pate, Gene wrote: I am amazed at the uproar over this. Is there anything that a PCFLIH backdoor can accomplish that any AC=1 module in any APF authorized library cannot? Is there anyone else out there that is running any vendor code for which they have not done code reviews that is running AC=1 in any APF authorized library? Is there anyone else out there that is running any home grown code with an AC=1 in an APF authorized library for which they have not done code reviews? Is there anyone else out there that has libraries in the APF list that can be updated by anything other than there change control system that only allows modules that have been through code reviews to be installed in their APF authorized libraries? How you allow code to get into supervisor state is of no consequence once it is in supervisor state so, unless you have a pristine system where every load module library on the system is totally locked down and only the OS libraries supplied by IBM appear in the APF list, you have by definition accepted exposures to system integrity. Does your management understand just how exposed you have left all the company secrets? Using a PCFLIH backdoor is only one of many techniques that can be used to accomplish getting yourself into supervisor state and sometimes it is the right technique and sometimes it is not. Back in the late 70's I wrote a PCFLIH backdoor because it was not only the correct technique it was the only technique that would work. My company and its sister companies had many 168APs that did not have the MVS/SE hardware assist installed. At that time IBM wanted about $150K per system for the hardware upgrade and we already had plans to replace all of them over the next 3 years with 3033s so there was no money to upgrade them. I wrote an SE hardware emulator that would run on Ups, APs, and MPs and while you got a 15% performance increase with the hardware upgrade and MVS/SE we still got around 12% with my PCFLIH hardware emulator and we were able to move to MVS/SE 3 years sooner that we could have had we all had to wait until all the 168s were replaced. If there was any criminal activity involved in this entire affair I believe it was on IBM's part for trying to charge us $150K per system for a microcode upgrade to a bunch of outdated systems and not on the part any PCFLIH code that I wrote so I outright reject your assertion that a PCFLIH backdoor is any more criminal than running any AC=1 module in any APF authorized library that you as the systems programmer have not personally code reviewed before you allowed it to run on any system that you are responsible for! Gene Pate CSX Technology Enterprise Architecture ... While it is a given that a module running authorized can, if malicious or badly written, potentially do anything bad that could be done by a PCFLIH back door, it also would seem that as a general principle one would want to be able to limit the potential exposure from sensitive code as much as possible -- in other words, use the least-global interfaces that will suffice. Code reviews may be able to catch obvious malicious code, but the existence of corrective product SYSMODS attests to the continuing inability of reviews and testing to catch 100% of subtle errors and bugs. An authorized vendor module that is normally only invoked from vendor address spaces, if found to do bad things unintentionally, might at least be more likely to damage virtual storage and data associated with the vendor application; and not starting vendor address spaces or invoking the product could reasonably be expected to suppress use of the code. While someone familiar with the interface might attempt to invoke this code in a context for which it was not intended, this would have to be a deliberate act and not an accident. I think people tend to have a gut feeling that the exposure from a PCFLIH back door is much greater because this code has much greater potential to be invoked by any arbitrary address space and not just for those address spaces or events related to the vendor product. Users of the interface are in general unaware they are invoking the vendor code, and in the worst case scenario a code bug might render the system unusable even when the offending vendor product is not started or directly invoked. If sysprogs are unaware that such an interface is being used by a product, they would also be unlikely to know how to disable its use if it should become a problem. The generic suspicion toward a PCFLIH back door is probably not unlike the uproar several years back when another interface was used inappropriately that could have had serious negative impact far beyond the vendor product for which it was intended. It was revealed that CA was distributing in their products an SMP/E exit to automatically bypass ID errors to compensate for bad packaging of CA SYSMODs at the time. While
Re: Program FLIH backdoor - This is a criminal breach of security!
On Mon, 5 Mar 2012 14:19:33 + Pate, Gene gene_p...@csx.com wrote: :I am amazed at the uproar over this. Is there anything that a PCFLIH backdoor can accomplish that any AC=1 module in any APF authorized library cannot? No. The question is how is the PC-FLIH among the best choices to do this function. -- 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: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
Gene, All that an AC=1 module that is in an APF authorized module can do is to start running with the JSCBAUTH bit on if, and only if, it is invoked as a Job Step Task from the initiator, or other initiator-like process (z/OS UNIX Services, for instance). However, a PCFLIH backdoor can allow a problem state, non-system key program that is not running APF authorized to receive control in an authorized state simply by causing a program interrupt to occur. Now I don't know if this particular backdoor does this or not, but if it does (or worse, can be spoofed by a caller to do this) than it would constitute a violation of z/OS system integrity. === Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(AT)us.ibm.com === From: Pate, Gene gene_p...@csx.com To: IBM-MAIN@bama.ua.edu Date: 03/05/2012 08:30 AM Subject: Re: Program FLIH backdoor - This is a criminal breach of security! Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu I am amazed at the uproar over this. Is there anything that a PCFLIH backdoor can accomplish that any AC=1 module in any APF authorized library cannot? SNIP Gene Pate CSX Technology Enterprise Architecture -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
In 4f540e03.3070...@phoenixsoftware.com, on 03/04/2012 at 04:51 PM, Edward Jaffe edja...@phoenixsoftware.com said: For the record, I once knew of a developer who claimed to have found an MVS back door because he wanted to appear cool like a phone phreaking hacker, but he was full of B.S. I also know someone that actually *did* find a back door (through an EXCP appendage) and IBM closed it. BTDT,GTTS. I got some flack here because I asked IBM not to include the details in the public portion of the PMR. -- 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: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
In cf4c9114ed956d49a019f58166d918570a346...@tjaxp80093dag.csxt.ad.csx.com, on 03/05/2012 at 02:19 PM, Pate, Gene gene_p...@csx.com said: How you allow code to get into supervisor state is of no consequence once it is in supervisor state so, unless you have a pristine system where every load module library on the system is totally locked down and only the OS libraries supplied by IBM appear in the APF list, you have by definition accepted exposures to system integrity. It's not just how but who. Letting trusted code get into supervisor code is one thing; letting everybody that knows how do it is quite another. Back in the late 70's I wrote a PCFLIH backdoor What do you mean by backdoor? I don't believe that it is what others were referring to. -- 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: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
In 4f540cf5.3080...@phoenixsoftware.com, on 03/04/2012 at 04:46 PM, Edward Jaffe edja...@phoenixsoftware.com said: Look more closely. In the PLM that IBM doesn't publish? Peter? Could you comment on what IGX00011 does? You need to look more closely at IGX00011. Hint: the secure implementation is not just in the SVC(ESR) routine itself but also in the caller What caller? It might not be the intended caller. -- 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: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On 3/5/2012 6:06 PM, Shmuel Metz (Seymour J.) wrote: In4f540cf5.3080...@phoenixsoftware.com, on 03/04/2012 at 04:46 PM, Edward Jaffeedja...@phoenixsoftware.com said: Look more closely. In the PLM that IBM doesn't publish? Peter? Could you comment on what IGX00011 does? To understand what it does study the two trace entries below (GTF is your friend): SVC CODE 109 ASCB 00F95200 CPU. PSW. 0785 806D 0C53B222 TCB. 00AC8300 R15. 000B R0.. R1.. 0001 GMT-03/06/2012 06:59:08.693767 LOC-03/05/2012 22:59:08.693767 SVCR CODE 109 ASCB 00F95200 CPU. PSW. 0714 806D 0C53B222 TCB. 00AC8300 R15. R0.. R1.. 0001 GMT-03/06/2012 06:59:08.693799 LOC-03/05/2012 22:59:08.693799 You need to look more closely at IGX00011. Hint: the secure implementation is not just in the SVC(ESR) routine itself but also in the caller What caller? It might not be the intended caller. Of course, I meant the intended caller. Unintended callers can't successfully use the service. -- 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: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
I am sure that you could easily ask VAT Security... since the product offering is all about verifying the ability to subvert any interface to gain authorization. AFAIK VAT has already taken IBM for the trip to discover OS related vulnerabilities. Rob Schramm Senior Systems Consultant Imperium Group On Fri, Mar 2, 2012 at 1:00 PM, Edward Jaffe edja...@phoenixsoftware.comwrote: On 3/2/2012 9:09 AM, David Cole wrote: At 3/2/2012 10:25 AM, Edward Jaffe wrote: The real question is whether an unintended third party can use the code to become authorized. Yes. That absolutely is the real question. And absolutely, that is what Bill Fairchild's post asserts. So that absolutely is why I am concerned. The subject line of this thread started off (in the other list) as Program FLIH. Then, you renamed it to, Program FLIH backdoor - This is a criminal breach of security! Having concerns is one thing; making speculative accusations of criminal wrongdoing is quite another. Innocent until proven guilty is the American way; not the other way 'round. -- 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/ http://www.phoenixsoftware.com/ --**--**-- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
In 4f510ab8.2070...@phoenixsoftware.com, on 03/02/2012 at 10:00 AM, Edward Jaffe edja...@phoenixsoftware.com said: The subject line of this thread started off (in the other list) as Program FLIH. Then, you renamed it to, Program FLIH backdoor - This is a criminal breach of security! Having concerns is one thing; making speculative accusations of criminal wrongdoing is quite another. Speculative? Did you read what he quoted from Bill Fairchild's message? -- 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: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
In 4f50f9bf.10...@phoenixsoftware.com, on 03/02/2012 at 08:47 AM, Edward Jaffe edja...@phoenixsoftware.com said: A magic PFLIH technique is not substantially different, from an integrity standpoint, than a magic SVC except that the code gets control for EVERY interrupt ITYM every Program interrupt. The presence of SVC IGX00011 on z/OS systems *proves* that so-called magic SVCs that confer authority to their callers, The ESR's do notconfer authority to their callers, but rather invoke narrowly defined functions. The so-called magic SVC's return to their callers in a more privileged mode. are NOT considered an exposure when implemented correctly. I have yet to see one that was implemented correctly. -- 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: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On 3/4/2012 10:24 AM, Shmuel Metz (Seymour J.) wrote: The presence of SVC IGX00011 on z/OS systems *proves* that so-called magic SVCs that confer authority to their callers, The ESR's do notconfer authority to their callers, but rather invoke narrowly defined functions. The so-called magic SVC's return to their callers in a more privileged mode. Look more closely. That is exactly what IGX00011 does. It is called in problem state and returns in supervisor state. are NOT considered an exposure when implemented correctly. I have yet to see one that was implemented correctly. You need to look more closely at IGX00011. Hint: the secure implementation is not just in the SVC(ESR) routine itself but also in the caller which discards all information it had before the SVC(ESR) invocation, including base register contents, etc. and starts over with a clean slate. -- 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: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On 3/4/2012 10:28 AM, Shmuel Metz (Seymour J.) wrote: Speculative? Did you read what he quoted from Bill Fairchild's message? Yes. I read it before he quoted it. We don't even know the person's name or how long ago this happened (if at all). A lot can change in a decade. For the record, I once knew of a developer who claimed to have found an MVS back door because he wanted to appear cool like a phone phreaking hacker, but he was full of B.S. I also know someone that actually *did* find a back door (through an EXCP appendage) and IBM closed it. -- 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: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
John Gilmore wrote: even though, as I believe, the the offender's code itself commits no substantive offense it it is, I think, guilty of the admittedly much subtler offense of providing a template for others, who are bent on mischief, to use. If the PFLIH hook is (as it has been described earlier in these threads) a mechanism by which a non-authorized process can become authorized, then its very existence is a substantive offense in and of itself. It is not just a template, it doesn't just show the way. It *is* the way. I fervently hope that the existence of this thread has gotten the attention of the ISV who has created this obscenity and that it will commit immediate resources to purging this from its products. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 At 3/1/2012 04:54 PM, John Gilmore wrote: I don't want to put words in EJ's mouth; but if 'an exposure' were replaced by what I should call 'misuse' what he said is correct and not even controversial. I think there is an exposure, in the sense that this device lends itself very readily to abuse. I have seen no evidence that it has actually been misused in any but the tenuous sense that it adds clandestine overhead to the processing of every interrupt. The device itself has been much misused elsewhere. A number of viruses have, for example, used a Windows scheduled task---PC Health Data Collection is a favorite---to hijack PCs. Moreover, now that its use has been publicized here, the scheme it embodies---not, a fortiori, the offender's code itself---is all but certain to be used irresponsibly by others; even though, as I believe, the the offender's code itself commits no substantive offense it it is, I think, guilty of the admittedly much subtler offense of providing a template for others, who are bent on mischief, to use. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
At 3/1/2012 06:46 PM, Skip Robinson wrote: For years we ran a 'channel extender' product call RDS. It worked by front-endng FLIH for I/O interrupts to determine whether the I/O was to or from a supported device as defined to RDS. If not, the I/O was passed along for normal processing. If so, RDS redirected the I/O to its own network device for transmission (out); or written to the intended device (in). It sounds kludgy, but it worked amazingly well. The vendor was very forthright about the internals. We had occasional hardware problems with RDS, but I never once saw an OS failure caused by this technique. This sort of thing is best not done at home. This also is a example of a legitimate use of an intercept. It does not confer authority upon its caller. All it does is perform a service on behalf of a caller and which the caller itself does not have the authority to perform on its own. In this sense it is no different from any other system service (OPEN, WTO, GETMAIN, etc.) performed by the OS. JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
David Cole and I are, I think, in substantive agreement about the offensive character of this ISV's scheme. That said, the situation we confront would be much worse if this scheme had been used to do real mischief. It has not, and we can take some small comfort---It is only small comfort--- in that. There is an old notion that, shorn of any sexist connotations it may once have had, remains important. It is not enough that Caesar's wife be virtuous; she must also be seen to be virtuous. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On 3/2/2012 1:29 AM, David Cole wrote: If the PFLIH hook is (as it has been described earlier in these threads) a mechanism by which a non-authorized process can become authorized, then its very existence is a substantive offense in and of itself. It is not just a template, it doesn't just show the way. It *is* the way. A magic PFLIH technique is not substantially different, from an integrity standpoint, than a magic SVC except that the code gets control for EVERY interrupt and so has the potential to slow things down if not implemented efficiently. The presence of SVC IGX00011 on z/OS systems *proves* that so-called magic SVCs that confer authority to their callers, while arguably not a 21st-century best practice, are NOT considered an exposure when implemented correctly. (Those last three words are very important!) The real question is whether an unintended third party can use the code to become authorized. Unlike the magic SVCs of the past, I'm confident that IGX00011 cannot be exploited by unintended third parties. The same might very well be true of the PFLIH approach being discussed here, despite any speculation or hearsay to the contrary. -- 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: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
At 3/2/2012 10:25 AM, Edward Jaffe wrote: On 3/2/2012 1:29 AM, David Cole wrote: If the PFLIH hook is (as it has been described earlier in these threads) a mechanism by which a non-authorized process can become authorized, then its very existence is a substantive offense in and of itself. It is not just a template, it doesn't just show the way. It *is* the way. I keep coming back to IGX00011. It's presence on z/OS systems PROVES that the very existence of a magic SVC service, while arguably not a 21st-century best practice, is NOT considered an exposure or substantive offense when done correctly. (Those last three words are very important!) A magic PFLIH technique is not substantially different, from an integrity standpoint, than a magic SVC except that the code gets control for EVERY interrupt and so has the potential to slow things down if not implemented efficiently. The real question is whether an unintended third party can use the code to become authorized. Yes. That absolutely is the real question. And absolutely, that is what Bill Fairchild's post asserts. So that absolutely is why I am concerned. Unlike the magic SVCs of the past, I'm confident that IGX00011 cannot be exploited by unintended third parties. That is good to know. The same might very well be true of the PFLIH approach being discussed here, despite any third-party hearsay from Bill Fairchild's colleague claiming otherwise. Certainly, the hearsay could be wrong. And I do hope that it is wrong. But it is a better course to assume that the charge is right and raise awareness to the point where it will be investigated and PROVEN to be right or wrong... ... than it is to assume that the charge is wrong and just sit back and *hope* that nothing bad happens. In other words, I think that being noisy about this issue will have a more constructive result than being silent will. -- 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/ Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
On 3/2/2012 9:09 AM, David Cole wrote: At 3/2/2012 10:25 AM, Edward Jaffe wrote: The real question is whether an unintended third party can use the code to become authorized. Yes. That absolutely is the real question. And absolutely, that is what Bill Fairchild's post asserts. So that absolutely is why I am concerned. The subject line of this thread started off (in the other list) as Program FLIH. Then, you renamed it to, Program FLIH backdoor - This is a criminal breach of security! Having concerns is one thing; making speculative accusations of criminal wrongdoing is quite another. Innocent until proven guilty is the American way; not the other way 'round. -- 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: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
Ed, Let me quote to you what Bill Fairchild posted earlier on this thread: At 2/23/2012 05:42 PM, Bill Fairchild wrote: I found a similar (and maybe the same) vendor hook in 1996, disassembled the code, and discovered that one of its purposes was to put an unauthorized caller into various protect keys, supervisor state, etc., based on the contents of a register. I alerted the vendor that using a hook such as this was not the optimal way to get into some authorized state. Literally anyone could have disassembled the code enough to see how to exploit the hook and get an unauthorized program into supervisor state and key 0. The vendor made some changes shortly thereafter and claimed that the enhancement was now much better. [***===] I didn't have time to disassemble the new version and figure out how to hack into it, but a colleague of mine did and said it was still relatively easy to subvert. [===***] This vendor has many products which are typically installed in a system all at the same time, and many of their products make use of this program FLIH hook to do authorized things. That is the genesis of my very strong reaction to this thread. Certainly hooking xFLIH or SVCs or whatever is not, in and of itself, evil. However, then using said hook to grant your programs authority is where it all goes very very south! As Fairchild's colleague demonstrates, such backdoors generally can be subverted. That fact that we do not know that the code is still subvertable is no excuse for inaction. The threat, as described in this thread, is significant. Doing nothing is just burying one's head in the sand. Dave Cole REPLY TO: dbc...@colesoft.com ColeSoft Marketing WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 At 3/1/2012 11:52 AM, Edward Jaffe wrote: On 3/1/2012 6:52 AM, David Cole wrote: This is not just despicable, under today's law, it is actually criminal! Any vendor who does this could be (and should be) jailed in criminal courts and sued out of existence in civil courts. I do not know who is doing this, but I believe utmost pressure must be brought to bear upon that vendor so that it will commit every resource to removing the breach from its products. Just to clear: intercepting the FLIH does not itself constitute an exposure and, as far as state changes go, the checking and requirements could be complete enough to avoid any integrity problem. For example, the methodology could be similar to that employed by IBM's IGX00011 magic SVC and its intended caller. Unless someone can prove there really is an exposure, which to my knowledge has not been done, I suggest that passing such judgment is premature. -- 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: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
I don't want to put words in EJ's mouth; but if 'an exposure' were replaced by what I should call 'misuse' what he said is correct and not even controversial. I think there is an exposure, in the sense that this device lends itself very readily to abuse. I have seen no evidence that it has actually been misused in any but the tenuous sense that it adds clandestine overhead to the processing of every interrupt. The device itself has been much misused elsewhere. A number of viruses have, for example, used a Windows scheduled task---PC Health Data Collection is a favorite---to hijack PCs. Moreover, now that its use has been publicized here, the scheme it embodies---not, a fortiori, the offender's code itself---is all but certain to be used irresponsibly by others; even though, as I believe, the the offender's code itself commits no substantive offense it it is, I think, guilty of the admittedly much subtler offense of providing a template for others, who are bent on mischief, to use. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Program FLIH backdoor - This is a criminal breach of security!
For years we ran a 'channel extender' product call RDS. It worked by front-endng FLIH for I/O interrupts to determine whether the I/O was to or from a supported device as defined to RDS. If not, the I/O was passed along for normal processing. If so, RDS redirected the I/O to its own network device for transmission (out); or written to the intended device (in). It sounds kludgy, but it worked amazingly well. The vendor was very forthright about the internals. We had occasional hardware problems with RDS, but I never once saw an OS failure caused by this technique. This sort of thing is best not done at home. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: John Gilmore johnwgilmore0...@gmail.com To: IBM-MAIN@bama.ua.edu Date: 03/01/2012 01:56 PM Subject:Re: Program FLIH backdoor - This is a criminal breach of security! Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu I don't want to put words in EJ's mouth; but if 'an exposure' were replaced by what I should call 'misuse' what he said is correct and not even controversial. I think there is an exposure, in the sense that this device lends itself very readily to abuse. I have seen no evidence that it has actually been misused in any but the tenuous sense that it adds clandestine overhead to the processing of every interrupt. The device itself has been much misused elsewhere. A number of viruses have, for example, used a Windows scheduled task---PC Health Data Collection is a favorite---to hijack PCs. Moreover, now that its use has been publicized here, the scheme it embodies---not, a fortiori, the offender's code itself---is all but certain to be used irresponsibly by others; even though, as I believe, the the offender's code itself commits no substantive offense it it is, I think, guilty of the admittedly much subtler offense of providing a template for others, who are bent on mischief, to use. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Security resolutions article posted, and query for education/training tips
Thanks for tips for this, security resolutions: http://destinationz.org/Mainframe-Solution/Security/12-New-Years-Resolutions-to-Keep-Your-Mainframe.aspx ...and for great/abundant backup tips; that article to post soon. Next article will be on education/training -- mostly general tips, do's or don'ts. But this will be a relatively short piece so suggestions are best as brief nuggets rather than anecdotes. For extra credit, please address or cc me directly so I needn't pull answers from list digests. For this brief article, I likely can't include everything sent. But it will all be appreciated. (Yup, cross-posted to IBM-MAIN, VSE-L, IBMVM, and LINUX-390 for all to play!) Thanks! -- Gabriel Goldberg, Computers and Publishing, Inc. g...@gabegold.com 3401 Silver Maple Place, Falls Church, VA 22042 (703) 204-0433 LinkedIn: http://www.linkedin.com/in/gabegoldTwitter: GabeG0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Check out Symantec Recommends Disabling PcAnywhere and Waiting for Security P
_Symantec Recommends Disabling PcAnywhere and Waiting for Security Patches | PCWorld Business Center_ (http://www.pcworld.com/businesscenter/article/248782/symantec_recommends_disabling_pcanywhere_and_waiting_for_security_patc hes.html) I meant to send this earlier but was fighting another fire. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Enable security in ftp client
Thanks Chris and excuse my poor English. We'll search in the Redbooks and if it's necessary we'll post a message to RACF-L or IBMTCP-L. Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on scheduling security for TWS ad-hoc jobs
Obviously it's all possible. The work depend on what kind of operations are made before submit and if you want to have full control. I think that the best way is manage all under sw lifecycle and use a smart way to release object(input data or other thing) to prod before start. You can determine start of application using event trigger under mvs or unix to control in many ways your process. About authority(if you don't want to use sw lifecycle that may have another authorization level) you can define users to start particular application only or you can allow a user to write a particular file or give to him the authority to write into a particular folder(unix). About TWS you can decide to have runcycle dependent or unattended application or on demand. I don't think that this will help you because there are several way to accomplish your colleague's needs. Best regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Enable security in ftp client
Hello: We make a mistake with the ftp type. We want to configure the ftp server security and limit the users access by a RACF resource. We've reviewed the link Steps for setting up security for your FTP server. SIS1 is the system name and TCPIP is the tcpname. FTPD1 is the ftp daemon name and the USER ID associated is STCFTP. 1 .- SERVAUTH class is active 2 .- We define EZB.STACKACCESS.SIS1.TCPIP. UACC NONE. Access list - STCFTP READ; System programmers READ. If we activate this configuration only system programmer can execute FTP client but the remainder users can not. 3 .- We define OMVSAPPL resource in APPL class. We grant READ access to the same users (STCFTP and system programmers). 3 .- If the SAF class APPL is activated and you have a resource profile defined in that class that matches the job name of the address space that the FTP server starts when a user logs into FTP, a user ID should have READ access to that resource profile. - We haven't defined this profile. We suppose that it name is BPXAS. 4 .- Our ftp port is 21. It isn't protected with a RACF resource profile. Is it mandatory?. Regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Enable security in ftp client
Jorge Two general observations: 1. I appreciate this question covers three areas: (A) SAF products which include RACF of course, (B) FTP customisation and, in a vague way, (C) FTP use. That means that 3 lists could contribute: RACF-L for A, IBMTCP-L for B, IBM-MAIN and IBMTCP-L for C. On balance, given that this is a SAF user question rather than a question involving how a product implementing SAF works, this means A, in principle, doesn't apply and, since IBMTCP-L covers both B and C, you should really have posted your question in the IBMTCP-L list: For IBMTCP-L subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO IBMTCP-L I intended to say that in my last post but forgot! 2. I believe we are suffering from an peculiarity - when viewed from other cultural backgrounds - of the users of Latin languages in posing questions by voice inflection. Thus where an Englishman will say Hot today, isn't it?, an Italian could say Fa caldo oggi, non è vero? - I'm supporting my efforts with Google translate, by the way - but will omit the non è vero? by substituting voice inflection which obviously I can't reproduce.[1] I believe the spectre of a question mark hangs over each of your curiously numbered points. - So it seems that, rather than z/OS Communications Server IP Configuration Guide topic 2.3.4.1.4, Steps for setting up a port of entry for users of the FTP server, you are really interested in two sets of steps back, namely 2.3.4.1.2, Steps for setting up security for your FTP server. Note that I am answering only on the basis of what I read in the manual, I do not have any actual experience of having done any of this stuff. However rather than my trying to assist you, you can probably get the information you need from the set of redbooks, IBM z/OS V1Rxx Communications Server TCP/IP Implementation, where xx is the release number,[2] specifically Volume 2: Standard Applications and Volume 4: Security and Policy-Based Networking. Note that the chapter on FTP in Volume 2 has the title Basic FTP without security. However, SAF topics are discussed here. Additional SAF topics are discussed in Volume 4 in the section Protecting FTP within the chapter Protecting network resources. I checked on your SAF resource names in the redbooks as best I could and noted the following: - EZB.STACKACCESS is covered in Volume 4. Note that this concerns the userid permitted to start the FTP address space and is *not* related to FTP clients. - The token OMVSAPPL does not feature in either of the redbooks - which is something of a curiosity! I get the impression from the way that the topic is covered in section 2.3.4.1.2 that the userid in question is the same as for the EZB.STACKACCESS resource and hence is also *not* related to FTP clients. But I could be wrong. - As for authorising FTP clients, the first relevant section in Volume 4, Restrict certain users from logging into FTP server looks promising. Note that searching for the token BPXAS achieves hits in neither Volume 2 nor Volume 4. - You can find the section The PORT/PORTRANGE SAF keyword in Volume 4 covers the matter of protecting ports using EZB.PORTACCESS resources. As for being mandatory, I believe, in general, none of these SAF protections are mandatory. It all depends on how secure you want your system to be. However - I'm guessing a bit[3] - it may be that the SAF environment already established within your system can impose the requirement to activate certain SAF resources. - [1] An Irishman would say It's hot today, so it is! but that's another aspect of the topic! [2] Since I am including Volume 4, I have to mention that the latest complete set is for release 12. Release 12: Volume 1: http://www.redbooks.ibm.com/abstracts/sg247896.html Volume 2: http://www.redbooks.ibm.com/abstracts/sg247897.html Volume 3: http://www.redbooks.ibm.com/abstracts/sg247898.html Volume 4: http://www.redbooks.ibm.com/abstracts/sg247899.html Release 13: Volume 1: http://www.redbooks.ibm.com/redpieces/abstracts/sg247996.html Volume 2: http://www.redbooks.ibm.com/redpieces/abstracts/sg247997.html Volume 3: http://www.redbooks.ibm.com/redpieces/abstracts/sg247998.html [3] I'm guessing a bit because whenever during my consultancies I needed some SAF resources activated, I went to the appropriate desk, got in line, then got on my knees and handed a printout of the relevant section of the manual to the appropriate master of the universe in order to maximise my chances of having the work done - eventually! On one of my consultancies, the SAF product wasn't RACF, so the actually very charming master of the universe sighed audibly faced with the task of converting the RACF statements with which he was presented! - Chris Mason On Thu, 22 Dec 2011 04:18:00 -0600, Jorge Garcia jgarc...@mapfre.com wrote: Hello: We make a mistake with the ftp type. We want to configure
Re: Question on scheduling security for TWS ad-hoc jobs
Thanks Marco _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Marco Gianfranco Indaco Sent: Thursday, December 22, 2011 3:49 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Question on scheduling security for TWS ad-hoc jobs Obviously it's all possible. The work depend on what kind of operations are made before submit and if you want to have full control. I think that the best way is manage all under sw lifecycle and use a smart way to release object(input data or other thing) to prod before start. You can determine start of application using event trigger under mvs or unix to control in many ways your process. About authority(if you don't want to use sw lifecycle that may have another authorization level) you can define users to start particular application only or you can allow a user to write a particular file or give to him the authority to write into a particular folder(unix). About TWS you can decide to have runcycle dependent or unattended application or on demand. I don't think that this will help you because there are several way to accomplish your colleague's needs. Best regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Question on scheduling security for TWS ad-hoc jobs
One possibility is to have the scheduler trigger upon the creation of a dataset. The dataset could be real (as in the input data), or an empty dataset just for triggering. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jousma, David Sent: Wednesday, December 21, 2011 1:30 PM To: IBM-MAIN@bama.ua.edu Subject: Question on scheduling security for TWS ad-hoc jobs I am posting a question for a co-worker. We are looking for some real world feedback on how you may have solved the problem we are trying to solve. We use Tivoli workload scheduler on z/OS for about 80% of our standard/supported production batch workload. Operated in typical fashion by production control staff that monitor the schedule, problem resolution, etc. However, we have this remaining 20% of production batch that is currently NOT under TWS control that needs to be. It is under a homegrown process that usually involves end-users keying data, and then submitting the actual production job.We have a project to eliminate this process, and are looking for idea's. What we need to be able to do is to continue to do whatever manual process(data input, etc), and then most likely post some user requirement on the TWS job that would then allow that job to run on demand, but from TWS. The catch is that we need to be able to secure who has the authority to post a specific job. As far as we can tell, we don't see any granularity to secure specific TWS functions down to the job(application) level for a specific person. Thanks in advance for any suggestions. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN 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: INFO IBM-MAIN
Re: Question on scheduling security for TWS ad-hoc jobs
Dave: We had similar issues but we ran UCC7. I stayed away from the product (except when it was broken). Our UCC7 people managed to get your issue resolved, sorry I can't help with TIVOLI. One issue I think you also need to address is responsibility of how you handle when the user schedules the job and it bombs this is a sticky wicket in most shops. Ed On Dec 22, 2011, at 12:16 PM, Hal Merritt wrote: One possibility is to have the scheduler trigger upon the creation of a dataset. The dataset could be real (as in the input data), or an empty dataset just for triggering. -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Jousma, David Sent: Wednesday, December 21, 2011 1:30 PM To: IBM-MAIN@bama.ua.edu Subject: Question on scheduling security for TWS ad-hoc jobs I am posting a question for a co-worker. We are looking for some real world feedback on how you may have solved the problem we are trying to solve. We use Tivoli workload scheduler on z/OS for about 80% of our standard/supported production batch workload. Operated in typical fashion by production control staff that monitor the schedule, problem resolution, etc. However, we have this remaining 20% of production batch that is currently NOT under TWS control that needs to be. It is under a homegrown process that usually involves end-users keying data, and then submitting the actual production job.We have a project to eliminate this process, and are looking for idea's. What we need to be able to do is to continue to do whatever manual process(data input, etc), and then most likely post some user requirement on the TWS job that would then allow that job to run on demand, but from TWS. The catch is that we need to be able to secure who has the authority to post a specific job. As far as we can tell, we don't see any granularity to secure specific TWS functions down to the job(application) level for a specific person. Thanks in advance for any suggestions. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN 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: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Enable security in ftp client
Hello: We want to enable a security for ftp client in our production system. We don't grant access to any user for execute ftp client again our production system. We've searched a RACF resource for limit the access to ftp client in RACF system programmers guide and RACF security administrator guide, but we don't find anything. We don't want to use the exit for limit the access (if that's possible). We prefer to use the RACF for security administration. Regards Jorge García Juanino Técnico de Sistemas Z/Os DGTP Departamento de Técnica de Sistemas MAPFRE C/ Llodio nº 2 2ª Planta 28034 Madrid Tfno: 91 581 27 34/ 618 33 35 59 Fax: 91 581 24 01 jgarc...@mapfre.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Enable security in ftp client
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Jorge Garcia Hello: We want to enable a security for ftp client in our production system. We don't grant access to any user for execute ftp client again our production system. We've searched a RACF resource for limit the access to ftp client in RACF system programmers guide and RACF security administrator guide, but we don't find anything. We don't want to use the exit for limit the access (if that's possible). We prefer to use the RACF for security administration. Start here: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B391/2.3 The discussion on securing FTP starts at 2.3.4.1. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Enable security in ftp client
On Wed, 21 Dec 2011 10:41:09 -0600, Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Jorge Garcia We want to enable a security for ftp client in our production system. We don't grant access to any user for execute ftp client again our production system. We've searched a RACF resource for limit the access to ftp client in RACF system programmers guide and RACF security administrator guide, but we don't find anything. We don't want to use the exit for limit the access (if that's possible). We prefer to use the RACF for security administration. Start here: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1B391/2.3 The discussion on securing FTP starts at 2.3.4.1. Why bother with securing the FTP client? A determined and competent sockets programmer can bypass anything you do in the FTP client. Your only recourse is a firewall. The section you cite concerns securing the FTP server, not the FTP client. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Question on scheduling security for TWS ad-hoc jobs
I am posting a question for a co-worker. We are looking for some real world feedback on how you may have solved the problem we are trying to solve. We use Tivoli workload scheduler on z/OS for about 80% of our standard/supported production batch workload. Operated in typical fashion by production control staff that monitor the schedule, problem resolution, etc. However, we have this remaining 20% of production batch that is currently NOT under TWS control that needs to be. It is under a homegrown process that usually involves end-users keying data, and then submitting the actual production job.We have a project to eliminate this process, and are looking for idea's. What we need to be able to do is to continue to do whatever manual process(data input, etc), and then most likely post some user requirement on the TWS job that would then allow that job to run on demand, but from TWS. The catch is that we need to be able to secure who has the authority to post a specific job. As far as we can tell, we don't see any granularity to secure specific TWS functions down to the job(application) level for a specific person. Thanks in advance for any suggestions. _ Dave Jousma Assistant Vice President, Mainframe Services david.jou...@53.com 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 This e-mail transmission contains information that is confidential and may be privileged. It is intended only for the addressee(s) named above. If you receive this e-mail in error, please do not read, copy or disseminate it in any manner. If you are not the intended recipient, any disclosure, copying, distribution or use of the contents of this information is prohibited. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please erase it from your computer system. Your assistance in correcting this error is appreciated. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Enable security in ftp client
On Wed, 21 Dec 2011 10:00:51 -0600, Jorge Garcia jgarc...@mapfre.com wrote: We want to enable a security for ftp client in our production system. We don't grant access to any user for execute ftp client again our production system. We've searched a RACF resource for limit the access to ftp client in RACF system programmers guide and RACF security administrator guide, but we don't find anything. We don't want to use the exit for limit the access (if that's possible). We prefer to use the RACF for security administration. You would find information about securing the FTP client, if there is any to be found, in the Communications Server books that describe FTP. But I'm curious what you're trying to protect, inbound to the host, or outbound? And I'm curious why you think securing the FTP client will really protect anything? -- Walt Farrell IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Re: Enable security in ftp client
Jorge I'm assuming you want to limit access to the FTP server by means of the IP address of the FTP client - or the IP address range from which an FTP client's IP address will be selected. If this isn't so, please explain what you want with some more clarity. If this is so, read on. I guess this is going to be a big surprise for Walt Farrell[1] and maybe Paul Gilmartin! You need to read up the following in the z/OS Communications Server IP Configuration Guide manual and the section really does refer to FTP *client* access to your FTP server. It is indeed one of the subsections in the part of the manual to which John Chase[2] directed you - definitely a surprise for Paul Gilmartin[3]!: 2.3.4.1.4 Steps for setting up a port of entry for users of the FTP server http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b3b0/2.3.4.1.4 It all looks quite well written and easy to follow. You need also to take care of the PORTOFENTRY4 statement for the FTP server as documented in the z/OS Communications Server IP Configuration Reference manual - assuming you are using IPv4 rather than IPv6[1]: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b4b0/18.97 Spot the stupid mistake! It's clear the development authors who wrote this statement up have never been required to write up anything to do with the so-called TN3270E server program! - [1] The access control for FTP clients is *required* for IPv6, it's not some curiosity! [2] Actually I wonder if John Chase realised how close he was to answering what I *think* you want. He just needed to go down one more level! [3] Who should now be thinking what sauce will flavour the next hat he should oblige himself to eat! - Chris Mason On Wed, 21 Dec 2011 10:00:51 -0600, Jorge Garcia jgarc...@mapfre.com wrote: Hello: We want to enable a security for ftp client in our production system. We don't grant access to any user for execute ftp client again our production system. We've searched a RACF resource for limit the access to ftp client in RACF system programmers guide and RACF security administrator guide, but we don't find anything. We don't want to use the exit for limit the access (if that's possible). We prefer to use the RACF for security administration. Regards Jorge García Juanino -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN
Security Group
Hi. How to find the security group my id resides from TSO? Regards Ron -- 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: Security Group
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Ron Thomas Hi. How to find the security group my id resides from TSO? LU your ID and look for DEFAULT-GROUP. (LU is the abbreviation for LISTUSER.) -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: Security Group
How to find the security group my id resides from TSO? Regards Ron, RACF, ACF2, or Top Secret Security Product? Or are you asking about SDSF Groups? What are you doing that you need to know the security group? Lizette -- 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: Security Group
Thanks John , it worked! I needed to see where my id resides as currently some datasets i lost read access. Regards Ron -- 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: Security Group
On Thu, 15 Dec 2011 08:40:08 -0600, Ron Thomas ron5...@gmail.com wrote: Hi. How to find the security group my id resides from TSO? Regards Ron If RACF, you should be able to list your own USERID - TSO LU userid Or run this exec: /* REXX */ ASCB = C2d(Storage(224,4)) /* point to ASCB*/ ASXB = C2d(Storage(D2x(ASCB+108),4)) /* point to ASXB*/ ACEE = C2d(Storage(D2x(ASXB+200),4)) /* point to ACEE*/ USER = Storage(D2x(ACEE+21),8) /* point to USERID */ GROUP= Storage(D2x(ACEE+30),8) /* point to GROUP */ Say 'The USERID in the ACEE is:' USER Say 'The GROUP in the ACEE is:' GROUP Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS mailto:m...@mzelden.com Mark's MVS Utilities: http://www.mzelden.com/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: Security Group
-Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ron Thomas Sent: Thursday, December 15, 2011 8:40 AM To: IBM-MAIN@bama.ua.edu Subject: Security Group Hi. How to find the security group my id resides from TSO? Regards Ron There is no such thing. There are RACF userids which can do security work. They have attributes such as SPECIAL or AUDITOR set on the RACF id. They can do RACF functions, but that is based on those attributes as well as the proper PERMITs to specific RACF profiles in various classes. Or perhaps I misunderstand what you are meaning by security group. RACF has security labels. It also has GROUPS. But I don't know of any way for a regular user to do some sort of report to show them what authorities they have. It should be documented somewhere what you are allowed to do and how to do it. If it isn't, and needs to be, then talk to your manager. If you're just going on a fishing expedition to see what you can mess around with, then I wouldn't talk to management about it. They might not react favorably. RACF is extensively documented here: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/Shelves/ichzbkc0 -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM -- 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: Security Certificate error message at IBMLINK
Hi Skip, Policy here is that we are not to accept any invalid certs, so I can't ignore it . 'Course I had to go on through to SR so that I could open a ticket. It's open to level 2 now. It seems that the date on the cetificate may not valid. Perhaps I will hear more tomorrow. Thanks, Linda - Original Message - From: Skip Robinson jo.skip.robin...@sce.com To: IBM-MAIN@bama.ua.edu Sent: Monday, September 26, 2011 8:47:06 PM Subject: Re: Security Certificate error message at IBMLINK This bump in the road has not impeded my business, merely added an extra 'never mind' maneuver. Of course it looks inept, but if I wanted superficial beauty, I'd be a Mac-fly. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Clark Morris cfmpub...@ns.sympatico.ca To: IBM-MAIN@bama.ua.edu Date: 09/26/2011 05:28 PM Subject: Re: Security Certificate error message at IBMLINK Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu On 26 Sep 2011 13:56:27 -0700, in bit.listserv.ibm-main you wrote: Thanks Skip, I appreciate it. They just closed my SR for the third time and I'm getting plenty steamed Amazing how unreliable IBMLINK, the support function for the 24/7 mainframe seems to be. Is it hosted on z? Should it be hosted on z? An interested shareholder wants to know. Clark Morris Linda - Original Message - From: Skip Robinson jo.skip.robin...@sce.com To: IBM-MAIN@bama.ua.edu Sent: Monday, September 26, 2011 1:50:38 PM Subject: Re: Security Certificate error message at IBMLINK I've been getting the message since yesterday Sunday. Everyone here is. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Linda Mooney linda.lst...@comcast.net To: IBM-MAIN@bama.ua.edu Date: 09/26/2011 01:48 PM Subject: Re: Security Certificate error message at IBMLINK Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Hi Mike, And they're telling me that it ain't so, that I must be doing something to cause it. They even closed my SR twice today. Thanks, Linda - Original Message - From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Monday, September 26, 2011 1:42:46 PM Subject: Re: Security Certificate error message at IBMLINK The digital certificate expiring has been reported to IBM. On Mon, Sep 26, 2011 at 3:32 PM, Linda Mooney linda.lst...@comcast.net wrote: Yipes! let me try this again. I don't know what happened. Greetings! Anybody else getting the following message trying to access IBMLINK this today? All was well yesterday, but this today - The security certificate presented by this website has expired or is not yet valid. Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Click here to close this webpage. Continue to this website (not recommended). Thanks, Linda -- 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: Security Certificate error message at IBMLINK
On Mon, 26 Sep 2011 21:27:48 -0300 Clark Morris wrote: Amazing how unreliable IBMLINK, the support function for the 24/7 mainframe seems to be. Is it hosted on z? Should it be hosted on z? Unfortunately the platform, even a good one, isn't going to resolve inherent frailties like those mentioned by Phil yesterday. Shane ... -- 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: Security Certificate error message at IBMLINK
I also opened a Feedback PMR# 40016,499,000 in IBMLink. I would encourage everyone who is seeing this to put in a Feedback using IBMLink Feedback or SR till this is resolved. This is basic certificate management off the rails. An SSL certificate expired for 3 days is still being served to customers to validate the web interface. I don't see this as any inherent problem in IBMLink, RETAIN or the application just a process failure that an expired certificate was not replaced on the web site with an updated one prior to expiration. As an aside IMHO most of IBMLink is not needed 24x7 just the bits that support problem determination and resolution ETR (now is 24x7 via SR), SIS, and SRD (now is pretty high availability also using ShopzSeries). Would I pay more for SoftwareExcel to have the remainder of the IBMLink applications 24x7 probably not... and it doesn't matter where they are hosted as long as they provide the desired function with appropriate availability. Best Regards, Sam Knutson, GEICO System z Team Leader mailto:sknut...@geico.com (office) 301.986.3574 (cell) 301.996.1318 Think big, act bold, start simple, grow fast... -Original Message- On Mon, 26 Sep 2011 21:27:48 -0300 Clark Morris wrote: Amazing how unreliable IBMLINK, the support function for the 24/7 mainframe seems to be. Is it hosted on z? Should it be hosted on z? This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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: Security Certificate error message at IBMLINK
Yes. It's back to normal today. -jc- -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Linda Mooney Sent: Monday, September 26, 2011 3:32 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Security Certificate error message at IBMLINK Yipes! let me try this again. I don't know what happened. Greetings! Anybody else getting the following message trying to access IBMLINK this today? All was well yesterday, but this today - The security certificate presented by this website has expired or is not yet valid. Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Click here to close this webpage. Continue to this website (not recommended). Thanks, Linda - Original Message - From: zMan zedgarhoo...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Monday, September 26, 2011 1:27:59 PM Subject: Re: Security Certificate error message at IBMLINK Am I the only one for whom this didn't unencode? On Mon, Sep 26, 2011 at 4:24 PM, Linda Mooney linda.lst...@comcast.net wrote: Content-Transfer-Encoding: base64 Content-Type: text/plain; charset=utf-8 CgpHcmVldGluZ3MhIAoKCgpBbnlib2R5IGVsc2UgZ2V0dGluZyB0aGUgZm9sbG93aW5nIG1lc3Nh Z2UgdHJ5aW5nIHRvIGFjY2VzcyBJQk1MSU5LIHRoaXMgdG9kYXk/wqAgQWxsIHdhcyB3ZWxsIHll c3RlcmRheSwgYnV0IHRoaXPCoHRvZGF5IC0gCgoKClRoZSBzZWN1cml0eSBjZXJ0aWZpY2F0ZSBw cmVzZW50ZWQgYnkgdGhpcyB3ZWJzaXRlIGhhcyBleHBpcmVkIG9yIGlzwqDCoCAKbm90IHlldCB2 YWxpZC7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgClNlY3VyaXR5IGNlcnRpZmljYXRl IHByb2JsZW1zIG1heSBpbmRpY2F0ZSBhbiBhdHRlbXB0IHRvIGZvb2wgeW91IG9ywqDCoMKgIApp bnRlcmNlcHQgYW55IGRhdGEgeW91IHNlbmQgdG8gdGhlIHNlcnZlci7CoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIArCoCBXZSByZWNvbW1l bmQgdGhhdCB5b3UgY2xvc2UgdGhpcyB3ZWJwYWdlIGFuZCBkbyBub3QgY29udGludWUgdG8gdGhp c8KgIAp3ZWJzaXRlLsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAKwqAgQ2xpY2sgaGVyZSB0byBjbG9zZSB0aGlzIHdl YnBhZ2UuwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIArCoCBDb250aW51ZSB0byB0aGlzIHdlYnNpdGUgKG5vdCBy ZWNvbW1lbmRlZCkuwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCAKCgoKVGhhbmtzLCAKCgoKTGluZGEgCgo= --=_Part_30742_484754870.1317068640967 DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpGb3IgSUJNLU1BSU4gc3Vic2NyaWJlIC8gc2lnbm9mZiAvIGFyY2hp dmUgYWNjZXNzIGluc3RydWN0aW9ucywNCnNlbmQgZW1haWwgdG8gbGlzdHNlcnZAYmFtYS51YS5l ZHUgd2l0aCB0aGUgbWVzc2FnZTogR0VUIElCTS1NQUlOIElORk8NClNlYXJjaCB0aGUgYXJjaGl2 ZXMgYXQgaHR0cDovL2JhbWEudWEuZWR1L2FyY2hpdmVzL2libS1tYWluLmh0bWwNCg== -- zMan -- I've got a mainframe and I'm not afraid to use it -- 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 -- 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: Security Certificate error message at IBMLINK
What URL are you using? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Linda Mooney Sent: Monday, September 26, 2011 3:48 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Security Certificate error message at IBMLINK Hi Mike, And they're telling me that it ain't so, that I must be doing something to cause it. They even closed my SR twice today. Thanks, Linda - Original Message - From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Monday, September 26, 2011 1:42:46 PM Subject: Re: Security Certificate error message at IBMLINK The digital certificate expiring has been reported to IBM. On Mon, Sep 26, 2011 at 3:32 PM, Linda Mooney linda.lst...@comcast.net wrote: Yipes! let me try this again. I don't know what happened. Greetings! Anybody else getting the following message trying to access IBMLINK this today? All was well yesterday, but this today - The security certificate presented by this website has expired or is not yet valid. Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Click here to close this webpage. Continue to this website (not recommended). Thanks, Linda -- 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...@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 == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- 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: Security Certificate error message at IBMLINK
Advice from the IBMLink feedback apparently they did correct something. Cleared cache and cookies as instructed and exited the browser (IE) completely and a valid non-expired certificate is now being served. https://www.ibm.com/ibmlink Best Regards, Sam Knutson -NARAYANAN, SREENATH A-5700URSF0 -L789/IBMLNK-P2S2-11/09/27-13:58- Hi Sam, Only few users are facing this issue. Please clear the Cache and cookies on your internet browser and give a try. Let us know if the problem pers its.Also let us know if it happens on IE or Mozilla Firefox. Regards, IBM Link Helpdesk -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ward, Mike S Sent: Tuesday, September 27, 2011 10:00 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Security Certificate error message at IBMLINK What URL are you using? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Linda Mooney Sent: Monday, September 26, 2011 3:48 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Security Certificate error message at IBMLINK Hi Mike, And they're telling me that it ain't so, that I must be doing something to cause it. They even closed my SR twice today. Thanks, Linda - Original Message - From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Monday, September 26, 2011 1:42:46 PM Subject: Re: Security Certificate error message at IBMLINK The digital certificate expiring has been reported to IBM. On Mon, Sep 26, 2011 at 3:32 PM, Linda Mooney linda.lst...@comcast.net wrote: Yipes! let me try this again. I don't know what happened. Greetings! Anybody else getting the following message trying to access IBMLINK this today? All was well yesterday, but this today - The security certificate presented by this website has expired or is not yet valid. Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Click here to close this webpage. Continue to this website (not recommended). Thanks, Linda -- 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...@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 == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- 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 This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- 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: Security Certificate error message at IBMLINK
Skip, Sigh macs are even more security concuss and we get a similar message that is hard to ignore. 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: Security Certificate error message at IBMLINK
Hi Mike, I usually use www.ibmlink.ibm.com support asked me to try www.ibm.com/ibmlink so I did and it didn't make any difference. Tryed after I got home on a fresh boot, no diff. This morning, no expired cert and I don't have to log in. I type the URL and it takes me right in! Not good. Linda - Original Message - From: Mike S Ward mw...@ssfcu.org To: IBM-MAIN@bama.ua.edu Sent: Tuesday, September 27, 2011 6:59:34 AM Subject: Re: Security Certificate error message at IBMLINK What URL are you using? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Linda Mooney Sent: Monday, September 26, 2011 3:48 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Security Certificate error message at IBMLINK Hi Mike, And they're telling me that it ain't so, that I must be doing something to cause it. They even closed my SR twice today. Thanks, Linda - Original Message - From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Monday, September 26, 2011 1:42:46 PM Subject: Re: Security Certificate error message at IBMLINK The digital certificate expiring has been reported to IBM. On Mon, Sep 26, 2011 at 3:32 PM, Linda Mooney linda.lst...@comcast.net wrote: Yipes! let me try this again. I don't know what happened. Greetings! Anybody else getting the following message trying to access IBMLINK this today? All was well yesterday, but this today - The security certificate presented by this website has expired or is not yet valid. Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Click here to close this webpage. Continue to this website (not recommended). Thanks, Linda -- 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...@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 == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- 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: Security Certificate error message at IBMLINK
Hi Sam, No more expired browesr - yeah! But now it's skipping the sign-on page and taking me directly to the ServiceLink screen. No updates have been made to my SR yet. Weird, it hasn't done that before. Are you having to sign in? Thanks, Linda - Original Message - From: Sam Knutson sknut...@geico.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, September 27, 2011 7:40:09 AM Subject: Re: Security Certificate error message at IBMLINK Advice from the IBMLink feedback apparently they did correct something. Cleared cache and cookies as instructed and exited the browser (IE) completely and a valid non-expired certificate is now being served. https://www.ibm.com/ibmlink Best Regards, Sam Knutson -NARAYANAN, SREENATH A-5700URSF0 -L789/IBMLNK-P2S2-11/09/27-13:58- Hi Sam, Only few users are facing this issue. Please clear the Cache and cookies on your internet browser and give a try. Let us know if the problem pers its.Also let us know if it happens on IE or Mozilla Firefox. Regards, IBM Link Helpdesk -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ward, Mike S Sent: Tuesday, September 27, 2011 10:00 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Security Certificate error message at IBMLINK What URL are you using? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Linda Mooney Sent: Monday, September 26, 2011 3:48 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Security Certificate error message at IBMLINK Hi Mike, And they're telling me that it ain't so, that I must be doing something to cause it. They even closed my SR twice today. Thanks, Linda - Original Message - From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Monday, September 26, 2011 1:42:46 PM Subject: Re: Security Certificate error message at IBMLINK The digital certificate expiring has been reported to IBM. On Mon, Sep 26, 2011 at 3:32 PM, Linda Mooney linda.lst...@comcast.net wrote: Yipes! let me try this again. I don't know what happened. Greetings! Anybody else getting the following message trying to access IBMLINK this today? All was well yesterday, but this today - The security certificate presented by this website has expired or is not yet valid. Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Click here to close this webpage. Continue to this website (not recommended). Thanks, Linda -- 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...@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 == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- 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 This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message
Re: Security Certificate error message at IBMLINK
The expired cetificate is back. I was gone for a while. :-( Anybody else? Linda - Original Message - From: Linda Mooney linda.lst...@comcast.net To: IBM-MAIN@bama.ua.edu Sent: Tuesday, September 27, 2011 10:29:16 AM Subject: Re: Security Certificate error message at IBMLINK Hi Sam, No more expired browesr - yeah! But now it's skipping the sign-on page and taking me directly to the ServiceLink screen. No updates have been made to my SR yet. Weird, it hasn't done that before. Are you having to sign in? Thanks, Linda - Original Message - From: Sam Knutson sknut...@geico.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, September 27, 2011 7:40:09 AM Subject: Re: Security Certificate error message at IBMLINK Advice from the IBMLink feedback apparently they did correct something. Cleared cache and cookies as instructed and exited the browser (IE) completely and a valid non-expired certificate is now being served. https://www.ibm.com/ibmlink Best Regards, Sam Knutson -NARAYANAN, SREENATH A-5700URSF0 -L789/IBMLNK-P2S2-11/09/27-13:58- Hi Sam, Only few users are facing this issue. Please clear the Cache and cookies on your internet browser and give a try. Let us know if the problem pers its.Also let us know if it happens on IE or Mozilla Firefox. Regards, IBM Link Helpdesk -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ward, Mike S Sent: Tuesday, September 27, 2011 10:00 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Security Certificate error message at IBMLINK What URL are you using? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Linda Mooney Sent: Monday, September 26, 2011 3:48 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Security Certificate error message at IBMLINK Hi Mike, And they're telling me that it ain't so, that I must be doing something to cause it. They even closed my SR twice today. Thanks, Linda - Original Message - From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Monday, September 26, 2011 1:42:46 PM Subject: Re: Security Certificate error message at IBMLINK The digital certificate expiring has been reported to IBM. On Mon, Sep 26, 2011 at 3:32 PM, Linda Mooney linda.lst...@comcast.net wrote: Yipes! let me try this again. I don't know what happened. Greetings! Anybody else getting the following message trying to access IBMLINK this today? All was well yesterday, but this today - The security certificate presented by this website has expired or is not yet valid. Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Click here to close this webpage. Continue to this website (not recommended). Thanks, Linda -- 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...@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 == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- 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 This email/fax message is for the sole use of the intended recipient(s) and may
Re: Security Certificate error message at IBMLINK
It's back. Got it this afternoon accessing ShopzSeries. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Linda Mooney linda.lst...@comcast.net To: IBM-MAIN@bama.ua.edu Date: 09/27/2011 03:11 PM Subject:Re: Security Certificate error message at IBMLINK Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu The expired cetificate is back. I was gone for a while. :-( Anybody else? Linda - Original Message - From: Linda Mooney linda.lst...@comcast.net To: IBM-MAIN@bama.ua.edu Sent: Tuesday, September 27, 2011 10:29:16 AM Subject: Re: Security Certificate error message at IBMLINK Hi Sam, No more expired browesr - yeah! But now it's skipping the sign-on page and taking me directly to the ServiceLink screen. No updates have been made to my SR yet. Weird, it hasn't done that before. Are you having to sign in? Thanks, Linda - Original Message - From: Sam Knutson sknut...@geico.com To: IBM-MAIN@bama.ua.edu Sent: Tuesday, September 27, 2011 7:40:09 AM Subject: Re: Security Certificate error message at IBMLINK Advice from the IBMLink feedback apparently they did correct something. Cleared cache and cookies as instructed and exited the browser (IE) completely and a valid non-expired certificate is now being served. https://www.ibm.com/ibmlink Best Regards, Sam Knutson -NARAYANAN, SREENATH A-5700URSF0 -L789/IBMLNK-P2S2-11/09/27-13:58- Hi Sam, Only few users are facing this issue. Please clear the Cache and cookies on your internet browser and give a try. Let us know if the problem pers its.Also let us know if it happens on IE or Mozilla Firefox. Regards, IBM Link Helpdesk -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Ward, Mike S Sent: Tuesday, September 27, 2011 10:00 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Security Certificate error message at IBMLINK What URL are you using? -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@bama.ua.edu] On Behalf Of Linda Mooney Sent: Monday, September 26, 2011 3:48 PM To: IBM-MAIN@bama.ua.edu Subject: Re: Security Certificate error message at IBMLINK Hi Mike, And they're telling me that it ain't so, that I must be doing something to cause it. They even closed my SR twice today. Thanks, Linda - Original Message - From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Monday, September 26, 2011 1:42:46 PM Subject: Re: Security Certificate error message at IBMLINK The digital certificate expiring has been reported to IBM. On Mon, Sep 26, 2011 at 3:32 PM, Linda Mooney linda.lst...@comcast.net wrote: Yipes! let me try this again. I don't know what happened. Greetings! Anybody else getting the following message trying to access IBMLINK this today? All was well yesterday, but this today - The security certificate presented by this website has expired or is not yet valid. Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Click here to close this webpage. Continue to this website (not recommended). Thanks, Linda -- Mike A Schwab, Springfield IL USA -- 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
Security Certificate error message at IBMLINK
��z{S���}�ĝ� �xjǺ�*'���O*^��m��Z�w!j�
Re: Security Certificate error message at IBMLINK
Am I the only one for whom this didn't unencode? On Mon, Sep 26, 2011 at 4:24 PM, Linda Mooney linda.lst...@comcast.net wrote: Content-Transfer-Encoding: base64 Content-Type: text/plain; charset=utf-8 CgpHcmVldGluZ3MhIAoKCgpBbnlib2R5IGVsc2UgZ2V0dGluZyB0aGUgZm9sbG93aW5nIG1lc3Nh Z2UgdHJ5aW5nIHRvIGFjY2VzcyBJQk1MSU5LIHRoaXMgdG9kYXk/wqAgQWxsIHdhcyB3ZWxsIHll c3RlcmRheSwgYnV0IHRoaXPCoHRvZGF5IC0gCgoKClRoZSBzZWN1cml0eSBjZXJ0aWZpY2F0ZSBw cmVzZW50ZWQgYnkgdGhpcyB3ZWJzaXRlIGhhcyBleHBpcmVkIG9yIGlzwqDCoCAKbm90IHlldCB2 YWxpZC7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgClNlY3VyaXR5IGNlcnRpZmljYXRl IHByb2JsZW1zIG1heSBpbmRpY2F0ZSBhbiBhdHRlbXB0IHRvIGZvb2wgeW91IG9ywqDCoMKgIApp bnRlcmNlcHQgYW55IGRhdGEgeW91IHNlbmQgdG8gdGhlIHNlcnZlci7CoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIArCoCBXZSByZWNvbW1l bmQgdGhhdCB5b3UgY2xvc2UgdGhpcyB3ZWJwYWdlIGFuZCBkbyBub3QgY29udGludWUgdG8gdGhp c8KgIAp3ZWJzaXRlLsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAKwqAgQ2xpY2sgaGVyZSB0byBjbG9zZSB0aGlzIHdl YnBhZ2UuwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIArCoCBDb250aW51ZSB0byB0aGlzIHdlYnNpdGUgKG5vdCBy ZWNvbW1lbmRlZCkuwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCAKCgoKVGhhbmtzLCAKCgoKTGluZGEgCgo= --=_Part_30742_484754870.1317068640967 DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpGb3IgSUJNLU1BSU4gc3Vic2NyaWJlIC8gc2lnbm9mZiAvIGFyY2hp dmUgYWNjZXNzIGluc3RydWN0aW9ucywNCnNlbmQgZW1haWwgdG8gbGlzdHNlcnZAYmFtYS51YS5l ZHUgd2l0aCB0aGUgbWVzc2FnZTogR0VUIElCTS1NQUlOIElORk8NClNlYXJjaCB0aGUgYXJjaGl2 ZXMgYXQgaHR0cDovL2JhbWEudWEuZWR1L2FyY2hpdmVzL2libS1tYWluLmh0bWwNCg== -- zMan -- I've got a mainframe and I'm not afraid to use it -- 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: Security Certificate error message at IBMLINK
Yipes! let me try this again. I don't know what happened. Greetings! Anybody else getting the following message trying to access IBMLINK this today? All was well yesterday, but this today - The security certificate presented by this website has expired or is not yet valid. Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Click here to close this webpage. Continue to this website (not recommended). Thanks, Linda - Original Message - From: zMan zedgarhoo...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Monday, September 26, 2011 1:27:59 PM Subject: Re: Security Certificate error message at IBMLINK Am I the only one for whom this didn't unencode? On Mon, Sep 26, 2011 at 4:24 PM, Linda Mooney linda.lst...@comcast.net wrote: Content-Transfer-Encoding: base64 Content-Type: text/plain; charset=utf-8 CgpHcmVldGluZ3MhIAoKCgpBbnlib2R5IGVsc2UgZ2V0dGluZyB0aGUgZm9sbG93aW5nIG1lc3Nh Z2UgdHJ5aW5nIHRvIGFjY2VzcyBJQk1MSU5LIHRoaXMgdG9kYXk/wqAgQWxsIHdhcyB3ZWxsIHll c3RlcmRheSwgYnV0IHRoaXPCoHRvZGF5IC0gCgoKClRoZSBzZWN1cml0eSBjZXJ0aWZpY2F0ZSBw cmVzZW50ZWQgYnkgdGhpcyB3ZWJzaXRlIGhhcyBleHBpcmVkIG9yIGlzwqDCoCAKbm90IHlldCB2 YWxpZC7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqAgCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgClNlY3VyaXR5IGNlcnRpZmljYXRl IHByb2JsZW1zIG1heSBpbmRpY2F0ZSBhbiBhdHRlbXB0IHRvIGZvb2wgeW91IG9ywqDCoMKgIApp bnRlcmNlcHQgYW55IGRhdGEgeW91IHNlbmQgdG8gdGhlIHNlcnZlci7CoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIArCoCBXZSByZWNvbW1l bmQgdGhhdCB5b3UgY2xvc2UgdGhpcyB3ZWJwYWdlIGFuZCBkbyBub3QgY29udGludWUgdG8gdGhp c8KgIAp3ZWJzaXRlLsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAKwqAgQ2xpY2sgaGVyZSB0byBjbG9zZSB0aGlzIHdl YnBhZ2UuwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgIArCoCBDb250aW51ZSB0byB0aGlzIHdlYnNpdGUgKG5vdCBy ZWNvbW1lbmRlZCkuwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoCAKCgoKVGhhbmtzLCAKCgoKTGluZGEgCgo= --=_Part_30742_484754870.1317068640967 DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpGb3IgSUJNLU1BSU4gc3Vic2NyaWJlIC8gc2lnbm9mZiAvIGFyY2hp dmUgYWNjZXNzIGluc3RydWN0aW9ucywNCnNlbmQgZW1haWwgdG8gbGlzdHNlcnZAYmFtYS51YS5l ZHUgd2l0aCB0aGUgbWVzc2FnZTogR0VUIElCTS1NQUlOIElORk8NClNlYXJjaCB0aGUgYXJjaGl2 ZXMgYXQgaHR0cDovL2JhbWEudWEuZWR1L2FyY2hpdmVzL2libS1tYWluLmh0bWwNCg== -- zMan -- I've got a mainframe and I'm not afraid to use it -- 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: Security Certificate error message at IBMLINK
The digital certificate expiring has been reported to IBM. On Mon, Sep 26, 2011 at 3:32 PM, Linda Mooney linda.lst...@comcast.net wrote: Yipes! let me try this again. I don't know what happened. Greetings! Anybody else getting the following message trying to access IBMLINK this today? All was well yesterday, but this today - The security certificate presented by this website has expired or is not yet valid. Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Click here to close this webpage. Continue to this website (not recommended). Thanks, Linda -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Security Certificate error message at IBMLINK
Hi Mike, And they're telling me that it ain't so, that I must be doing something to cause it. They even closed my SR twice today. Thanks, Linda - Original Message - From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Monday, September 26, 2011 1:42:46 PM Subject: Re: Security Certificate error message at IBMLINK The digital certificate expiring has been reported to IBM. On Mon, Sep 26, 2011 at 3:32 PM, Linda Mooney linda.lst...@comcast.net wrote: Yipes! let me try this again. I don't know what happened. Greetings! Anybody else getting the following message trying to access IBMLINK this today? All was well yesterday, but this today - The security certificate presented by this website has expired or is not yet valid. Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Click here to close this webpage. Continue to this website (not recommended). Thanks, Linda -- 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...@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: Security Certificate error message at IBMLINK
I've been getting the message since yesterday Sunday. Everyone here is. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Linda Mooney linda.lst...@comcast.net To: IBM-MAIN@bama.ua.edu Date: 09/26/2011 01:48 PM Subject:Re: Security Certificate error message at IBMLINK Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Hi Mike, And they're telling me that it ain't so, that I must be doing something to cause it. They even closed my SR twice today. Thanks, Linda - Original Message - From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Monday, September 26, 2011 1:42:46 PM Subject: Re: Security Certificate error message at IBMLINK The digital certificate expiring has been reported to IBM. On Mon, Sep 26, 2011 at 3:32 PM, Linda Mooney linda.lst...@comcast.net wrote: Yipes! let me try this again. I don't know what happened. Greetings! Anybody else getting the following message trying to access IBMLINK this today? All was well yesterday, but this today - The security certificate presented by this website has expired or is not yet valid. Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Click here to close this webpage. Continue to this website (not recommended). Thanks, Linda -- 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...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Security Certificate error message at IBMLINK
Thanks Skip, I appreciate it. The just closed my SR for the third time and I'm getting plenty steamed Linda - Original Message - From: Skip Robinson jo.skip.robin...@sce.com To: IBM-MAIN@bama.ua.edu Sent: Monday, September 26, 2011 1:50:38 PM Subject: Re: Security Certificate error message at IBMLINK I've been getting the message since yesterday Sunday. Everyone here is. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Linda Mooney linda.lst...@comcast.net To: IBM-MAIN@bama.ua.edu Date: 09/26/2011 01:48 PM Subject: Re: Security Certificate error message at IBMLINK Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Hi Mike, And they're telling me that it ain't so, that I must be doing something to cause it. They even closed my SR twice today. Thanks, Linda - Original Message - From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Monday, September 26, 2011 1:42:46 PM Subject: Re: Security Certificate error message at IBMLINK The digital certificate expiring has been reported to IBM. On Mon, Sep 26, 2011 at 3:32 PM, Linda Mooney linda.lst...@comcast.net wrote: Yipes! let me try this again. I don't know what happened. Greetings! Anybody else getting the following message trying to access IBMLINK this today? All was well yesterday, but this today - The security certificate presented by this website has expired or is not yet valid. Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Click here to close this webpage. Continue to this website (not recommended). Thanks, Linda -- 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...@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: Security Certificate error message at IBMLINK
On 26 Sep 2011 13:56:27 -0700, in bit.listserv.ibm-main you wrote: Thanks Skip, I appreciate it. The just closed my SR for the third time and I'm getting plenty steamed Amazing how unreliable IBMLINK, the support function for the 24/7 mainframe seems to be. Is it hosted on z? Should it be hosted on z? An interested shareholder wants to know. Clark Morris Linda - Original Message - From: Skip Robinson jo.skip.robin...@sce.com To: IBM-MAIN@bama.ua.edu Sent: Monday, September 26, 2011 1:50:38 PM Subject: Re: Security Certificate error message at IBMLINK I've been getting the message since yesterday Sunday. Everyone here is. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Linda Mooney linda.lst...@comcast.net To: IBM-MAIN@bama.ua.edu Date: 09/26/2011 01:48 PM Subject: Re: Security Certificate error message at IBMLINK Sent by: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Hi Mike, And they're telling me that it ain't so, that I must be doing something to cause it. They even closed my SR twice today. Thanks, Linda - Original Message - From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Monday, September 26, 2011 1:42:46 PM Subject: Re: Security Certificate error message at IBMLINK The digital certificate expiring has been reported to IBM. On Mon, Sep 26, 2011 at 3:32 PM, Linda Mooney linda.lst...@comcast.net wrote: Yipes! let me try this again. I don't know what happened. Greetings! Anybody else getting the following message trying to access IBMLINK this today? All was well yesterday, but this today - The security certificate presented by this website has expired or is not yet valid. Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Click here to close this webpage. Continue to this website (not recommended). Thanks, Linda -- 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: Security Certificate error message at IBMLINK
This bump in the road has not impeded my business, merely added an extra 'never mind' maneuver. Of course it looks inept, but if I wanted superficial beauty, I'd be a Mac-fly. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Clark Morris cfmpub...@ns.sympatico.ca To: IBM-MAIN@bama.ua.edu Date: 09/26/2011 05:28 PM Subject:Re: Security Certificate error message at IBMLINK Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu On 26 Sep 2011 13:56:27 -0700, in bit.listserv.ibm-main you wrote: Thanks Skip, I appreciate it. The just closed my SR for the third time and I'm getting plenty steamed Amazing how unreliable IBMLINK, the support function for the 24/7 mainframe seems to be. Is it hosted on z? Should it be hosted on z? An interested shareholder wants to know. Clark Morris Linda - Original Message - From: Skip Robinson jo.skip.robin...@sce.com To: IBM-MAIN@bama.ua.edu Sent: Monday, September 26, 2011 1:50:38 PM Subject: Re: Security Certificate error message at IBMLINK I've been getting the message since yesterday Sunday. Everyone here is. . . JO.Skip Robinson SCE Infrastructure Technology Services Electric Dragon Team Paddler SHARE MVS Program Co-Manager 626-302-7535 Office 323-715-0595 Mobile jo.skip.robin...@sce.com From: Linda Mooney linda.lst...@comcast.net To: IBM-MAIN@bama.ua.edu Date: 09/26/2011 01:48 PM Subject:Re: Security Certificate error message at IBMLINK Sent by:IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Hi Mike, And they're telling me that it ain't so, that I must be doing something to cause it. They even closed my SR twice today. Thanks, Linda - Original Message - From: Mike Schwab mike.a.sch...@gmail.com To: IBM-MAIN@bama.ua.edu Sent: Monday, September 26, 2011 1:42:46 PM Subject: Re: Security Certificate error message at IBMLINK The digital certificate expiring has been reported to IBM. On Mon, Sep 26, 2011 at 3:32 PM, Linda Mooney linda.lst...@comcast.net wrote: Yipes! let me try this again. I don't know what happened. Greetings! Anybody else getting the following message trying to access IBMLINK this today? All was well yesterday, but this today - The security certificate presented by this website has expired or is not yet valid. Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Click here to close this webpage. Continue to this website (not recommended). Thanks, Linda -- 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: Security is fun in the PC world....
On Mon, 22 Aug 2011 11:27:08 -0400 Shmuel Metz (Seymour J.) wrote: or even computer science back then, There were CS departments in the late 1960's. But they weren't all offering degrees - even into the 70's. I had to do a Science degree majoring in Applied Mathematics and Computer Science at Adelaide - at the time considered one of the top tier unis in this country. I meandered through the grounds a few months back - CompSci looked scarily similar. I suspect (pray) the CDC 6400 has however moved on. Shane ... -- 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: Security is fun in the PC world....
On 23/08/2011 4:04 PM, Shane wrote: On Mon, 22 Aug 2011 11:27:08 -0400 Shmuel Metz (Seymour J.) wrote: or even computer science back then, There were CS departments in the late 1960's. But they weren't all offering degrees - even into the 70's. I had to do a Science degree majoring in Applied Mathematics and Computer Science at Adelaide - at the time considered one of the top tier unis in this country. I meandered through the grounds a few months back - CompSci looked scarily similar. I suspect (pray) the CDC 6400 has however moved on. Wow! At least UWA could afford a PDP-11 ;-) Shane ... -- 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: Security is fun in the PC world....
In 025301cc6134$b9c39ca0$2d4ad5e0$@us, on 08/22/2011 at 08:33 PM, Jim Thomas j...@thethomasresidence.us said: Don't know about the first HTTP server Mainframe, at CERN as I recall. -- 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: Security is fun in the PC world....
In 4e539fcf.2020...@gmail.com, on 08/23/2011 at 08:40 PM, David Crayford dcrayf...@gmail.com said: Wow! At least UWA could afford a PDP-11 ;-) The CDC was a mainframe, and fairly fast for its day; basically a 6600 without all of the parallelism. A much more powerful machine that the DEC PDP-11. -- 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: Security is fun in the PC world....
LOL .. Nah mate .. too lazy to want to do some hard work. Kind Regards Jim Thomas 617-233-4130 (mobile) 636-294-1014(res) j...@thethomasresidence.us (Email) -Original Message- From: Shmuel (Seymour J.) Metz [mailto:shmuel+ibm-m...@patriot.net] Sent: Tuesday, August 23, 2011 1:14 PM To: j...@thethomasresidence.us Subject: Re: Security is fun in the PC world Offlist In 025101cc6133$02b0a860$0811f920$@us, on 08/22/2011 at 08:21 PM, Jim Thomas j...@thethomasresidence.us said: Thank you ... but that was a couple of years ago ... besides .. lawyers are just as bad as 'management'. He may be an SOB but he's *my* SOB. Or do you mean that he's a rooster and clucks defiance? -- 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) - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1392 / Virus Database: 1520/3853 - Release Date: 08/23/11 -- 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: Security is fun in the PC world....
They were running some very large MVS data centers across the country -Original Message- From: Gerhard Postpischil [mailto:gerh...@valley.net] Sent: Saturday, August 20, 2011 11:26 AM To: IBM-MAIN@bama.ua.edu Subject: Re: Security is fun in the PC world On 8/20/2011 9:37 AM, zMan wrote: In case it's escaped you: http://www.lmgtfy.com/?q=%22kevin+mitnick%22 1.3M hits. Heavily covered by popular and trade press. Hardly obscure. While I don't know about the others, MCI in the late seventies was definitely running IBM systems (MVT up to 1978, pre-RACF; I don't know what they ran once they got their own computer center in DC). Gerhard Postpischil Bradford, VT -- 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
