Re: Dynalloc (was Macro processor)

On Wed, 27 Dec 2017 08:22:33 -0500, Tom Marchant wrote: >It is even more difficult for RACF to answer the question if the data >set may only be accessed by certain programs. Excellent point, Tom, and an even better example than mine. Thanks. -- Walt

Re: Dynalloc (was Macro processor)

On Sun, 24 Dec 2017 15:58:10 -0500, Walt Farrell wrote: >RACF is not allowing an ENQ on a DSN, because RACF has no idea >that an ENQ is being done. If anyone were to control that, it would >be data set allocation, who would have to invoke RACF to ask if >the user would have authority to

Re: Dynalloc (was Macro processor)

24, 2017 2:17 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Dynalloc (was Macro processor) EXTERNAL: This email originated from outside of Broadridge. Do not click any links or open any attachments unless you trust the sender and know the content is safe. On 2017-12-24, at 11:01:38, Far

Re: Dynalloc (was Macro processor)

Walt, you wrote, "Therefore, RACF is not allowing an ENQ on a DSN, because RACF has no idea that an ENQ is being done." and it occurs to me to point out that, likewise, ENQ is not preventing access to a DSN because ENQ has no idea that a dsn is being accessed (which, of course, is different

Re: Dynalloc (was Macro processor)

Think like a security admin instead of programmer. You are right that dynalloc is not a problem but to a security admin, it is an exposure. Exposures combine to become a problem.  Here are some examples (UNRELATED to dynalloc) that may help to clarify. 1. Don't you have customers that refuse to

Re: Dynalloc (was Macro processor)

On Sun, 24 Dec 2017 05:38:48 +, Jon Perryman wrote: >Keven, As I said before, I wanted to know why it's not considered an exposure >now. Why do you assume it was ever considered an exposure? -- Walt

Re: Dynalloc (was Macro processor)

On Sun, 24 Dec 2017 12:17:22 -0700, Paul Gilmartin wrote: >On 2017-12-24, at 11:01:38, Farley, Peter x23353 wrote: >> >> If truly a DOS attempt, then this would be followed the next day by >> promotion to the street for the responsible programmer and reprimands for >>

Re: Dynalloc (was Macro processor)

: Sunday, December 24, 2017 9:33 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Dynalloc (was Macro processor) On 2017-12-24, at 00:10:58, Farley, Peter x23353 wrote: > > ... Without necessary access rights, allocation is a useless tool for malfeasance of any kind. > Ummm..

Re: Dynalloc (was Macro processor)

On 2017-12-24, at 11:01:38, Farley, Peter x23353 wrote: > > If truly a DOS attempt, then this would be followed the next day by promotion > to the street for the responsible programmer and reprimands for the code > reviewer(s) for missing such a trick. > But the DoS could be inadvertent, by a

AW: Dynalloc (was Macro processor)

Farley, Peter x23353 Gesendet: Sonntag, 24. Dezember 2017 19:02 An: ASSEMBLER-LIST@LISTSERV.UGA.EDU Betreff: Re: Dynalloc (was Macro processor) OK, possibly for 5 minutes or so. Mainframe operations personnel are trained, in my experience, to prioritize such issues in order to keep the batch stream

Re: Dynalloc (was Macro processor)

. Peter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Sunday, December 24, 2017 9:33 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Dynalloc (was Macro processor) On 2017-12-24, at 00:10:58, Farley, Peter

Re: Dynalloc (was Macro processor)

On 2017-12-24, at 00:10:58, Farley, Peter x23353 wrote: > > ... Without necessary access rights, allocation is a useless tool for > malfeasance of any kind. > Ummm... Denial of Service? -- gil

Re: Dynalloc (was Macro processor)

The argument that dynalloc is the problem strikes me as somewhat dubious. It was suggested that you need to restrict dynalloc because an allocated data set is a way to capture data that the user is already authorized to access. That is not the "problem" statement; a data set might contribute to

Re: Dynalloc (was Macro processor)

n Behalf Of Jon Perryman Sent: Sunday, December 24, 2017 12:39 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Dynalloc (was Macro processor) EXTERNAL: This email originated from outside of Broadridge. Do not click any links or open any attachments unless you trust the sender and know the

Re: Dynalloc (was Macro processor)

o:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Jon Perryman Sent: Sunday, December 24, 2017 12:39 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Dynalloc (was Macro processor) EXTERNAL: This email originated from outside of Broadridge. Do not click any links or open any attachments unless you

Re: Dynalloc (was Macro processor)

question? Peter -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Jon Perryman Sent: Sunday, December 24, 2017 12:39 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Dynalloc (was Macro processor) EXTERNAL: This email originated

Re: Dynalloc (was Macro processor)

Keven, As I said before, I wanted to know why it's not considered an exposure now. I'm not interested in convincing anyone it's an exposure because it won't help to answer my question.  Jon.     On Saturday, December 23, 2017 8:48 PM, Keven Hall wrote:Jon,It seems to me that

Re: Dynalloc (was Macro processor)

Jon,It seems to me that what you’re saying is that if one works in a badly run z/OS shop with unprotected UserIDs and unscrupulous employees who share their user credentials then that might result in a security exposure.  In

Re: Dynalloc (was Macro processor)

Proper separation from user departments is usually not a problem from the IT perspective. User departments generally run in CICS or IMS which is very controlled (unless in VSE I think). Instead, this would most likely be an IT person where they maintain programs. You sound very confident and

Re: Dynalloc (was Macro processor)

Am I missing something or are the arguments for disabling dynamic allocation nearly a clone of the old arguments for restricting AMASPZAP?

Re: Dynalloc (was Macro processor)

On Sat, 23 Dec 2017, at 19:42, Jon Perryman wrote: > Naming conventions only go so far in securing departmental data because > of exceptions. For instance, there is departmental overlap such as > payroll and general ledger. But if there's proper separation between production ids (which run the

Re: Dynalloc (was Macro processor)

Naming conventions only go so far in securing departmental data because of exceptions. For instance, there is departmental overlap such as payroll and general ledger. As for "Production being executed by a user", forgive me if I implied that. I was specifically saying production being executed

Re: Dynalloc (was Macro processor)

On Sat, 23 Dec 2017, at 18:40, Jon Perryman wrote: > I only wanted to know why dynalloc is no longer considered an exposure. > When these people did the risk analysis for dynalloc on MVS, what made > them decide why it's not an exposure and does not need to be a > controlled resource? Maybe

Re: Dynalloc (was Macro processor)

I was going from a court ruling but David Stokes noted a whitepaper that confirms my suspicions in the court ruling. Target does not have z/OS nor dynalloc (by name). However Unix is by design dynalloc all the time. Jon On Saturday, December 23, 2017 9:09 AM, Walt Farrell

Re: Dynalloc (was Macro processor)

I only wanted to know why dynalloc is no longer considered an exposure. When these people did the risk analysis for dynalloc on MVS, what made them decide why it's not an exposure and does not need to be a controlled resource? Thanks, Jon. On Saturday, December 23, 2017 8:40 AM, Ed Jaffe

Re: Dynalloc (was Macro processor)

On 2017-12-23, at 10:09:47, Walt Farrell wrote: > On Fri, 22 Dec 2017 21:26:07 +, Jon Perryman wrote: > >> Charles broke the cardinal rule in security ( never say never ). Viruses >> rely on dynalloc. This vulnerability was used against Target where they >> >were recently fined $18 million

Re: Dynalloc (was Macro processor)

On Sat, 23 Dec 2017, at 16:18, Jon Perryman wrote: > Most security breaches need multiple exploits on MVS. Often, eliminating > a single exploit is enough to to stop that particular breach. > SAF (RACF) secures resources but there will be always be exposures (e.g. > A security admin can't

AW: Dynalloc (was Macro processor)

] Im Auftrag von Walt Farrell Gesendet: Samstag, 23. Dezember 2017 18:10 An: ASSEMBLER-LIST@LISTSERV.UGA.EDU Betreff: Re: Dynalloc (was Macro processor) On Fri, 22 Dec 2017 21:26:07 +, Jon Perryman <jperr...@pacbell.net> wrote: >Charles broke the cardinal rule in security ( never

Re: Dynalloc (was Macro processor)

On Fri, 22 Dec 2017 21:26:07 +, Jon Perryman wrote: >Charles broke the cardinal rule in security ( never say never ). Viruses rely >on dynalloc. This vulnerability was used against Target where they >were >recently fined $18 million and lost millions in revenues for

Re: AW: Dynalloc (was Macro processor)

I'm not saying that it comes down to dynalloc. Security never comes down to a single exploitation. Think about alcatraz which despite all the extreme security measures still had an escape. I'm sayiing that dynalloc is not controlled by security admins and there are simple scenario's to exploit

Re: Dynalloc (was Macro processor)

On 12/23/2017 8:18 AM, Jon Perryman wrote: People are clever and will find ways to abuse things if they are motivated. Dynalloc can easily be exploited. It's not exploited because no one has been motivated to exploit it. Security risks are big news in this century and there have been some

Re: Dynalloc (was Macro processor)

This started as me being surprised that Cobol and PL/I now support Dynalloc because of the security risks. I satisfied that it exists and for whatever reason, it is no longer considered a security exposure. My apologies for allowing this to drag into a discussion about security theory in this

AW: Dynalloc (was Macro processor)

>>How can RACF stop someone when they have a legitimate need It can't of course. That's why the Target attack (like most others) essentially revolved around a bit of social engineering and getting access to a privileged account. Along with poor malware detection, lack of network segregation

Re: Dynalloc (was Macro processor)

On 2017-12-22, at 17:37:52, Jon Perryman wrote: > How can RACF stop someone when they have a legitimate need to update > something like clists? Or do we keep making the processes so complicated that > more people jump to Unix where they have complete freedom and control. > Security is a

FW: Dynalloc (was Macro processor)

Apologies, I accidentally sent this reply so Jon directly instead of to the list. Peter -Original Message- From: Farley, Peter x23353 Sent: Friday, December 22, 2017 7:34 PM To: 'Jon Perryman' Subject: RE: Dynalloc (was Macro processor) Jon, I think our confusion (or at least my

Re: Dynalloc (was Macro processor)

How can RACF stop someone when they have a legitimate need to update something like clists? Or do we keep making the processes so complicated that more people jump to Unix where they have complete freedom and control. Security is a balancing act of risk versus cost. Jon. On Friday,

Re: Dynalloc (was Macro processor)

Again with the motivated reasoning. Give me any fact that it's unrelated. Give me any fact that I'm wrong. Of course it's based on dynamic allocation. In a permanent allocation situation (like JCL, CICS or possibly IMS), you are defining datasets that can be used at that time. From a security

Re: Dynalloc (was Macro processor)

On 2017-12-22, at 14:26:07, Jon Perryman wrote: > Charles broke the cardinal rule in security ( never say never ). Viruses rely > on dynalloc. This vulnerability was used against Target where they were > recently fined $18 million and lost millions in revenues for their data > breach. > In

Re: Dynalloc (was Macro processor)

Subject: Dynalloc (was Macro processor) Charles broke the cardinal rule in security ( never say never ). Viruses rely on dynalloc. This vulnerability was used against Target where they were recently fined $18 million and lost millions in revenues for their data breach. In MVS, many of the dynalloc

Dynalloc (was Macro processor)

Charles broke the cardinal rule in security ( never say never ). Viruses rely on dynalloc. This vulnerability was used against Target where they were recently fined $18 million and lost millions in revenues for their data breach.  In MVS, many of the dynalloc exposures don't exist but there are

Re: [EXTERNAL] Re: Macro processor

rbrick, Frank <frank.swarbr...@efirstbank.com> Sent: Thursday, December 21, 2017 5:29 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: [EXTERNAL] Re: Macro processor Doesn't RACF or other access control protect this data equally? -Original Message- From: IBM Mainframe As

Re: [EXTERNAL] Re: Macro processor

ABSOLUTELY!  CharlesSent from a mobile; please excuse the brevity. Original message From: "Swarbrick, Frank" <frank.swarbr...@efirstbank.com> Date: 12/21/17 5:29 PM (GMT-05:00) To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: [EXTERNAL] Re: Macro process

Re: [EXTERNAL] Re: Macro processor

: Macro processor Thanks for pointing out dynalloc in Cobol. A few decades since I actually looked at these languages. In fact, The only LE programming language I've used is C. Do you know if companies allow the use of this feature in production? For those that don't, how do they protect

Re: Macro processor

: Thursday, December 21, 2017 1:40 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Macro processor Thanks for pointing out dynalloc in Cobol. A few decades since I actually looked at these languages. In fact, The only LE programming language I've used is C. Do you know if companies allow the use

Re: Macro processor

On Thursday, December 21, 2017 10:47 AM, John McKown wrote: > The programmers that I work with would most likely do a "deer > in the headlights" act if I tried to talk to the about dynamic allocation >in COBOL with them. They're not stupid, but they just do

Re: Macro processor

On Thu, Dec 21, 2017 at 12:39 PM, Jon Perryman wrote: > Thanks for pointing out dynalloc in Cobol. A few decades since I actually > looked at these languages. In fact, The only LE programming language I've > used is C. > Do you know if companies allow the use of this

Re: Macro processor

Thanks for pointing out dynalloc in Cobol. A few decades since I actually looked at these languages. In fact, The only LE programming language I've used is C. Do you know if companies allow the use of this feature in production? For those that don't, how do they protect themselves against

Re: Macro processor

On Thu, Dec 21, 2017 at 11:31 AM, Jon Perryman wrote: > > Paul wrote: did C have dynamic allocation in FOPEN before MVS UNIX. > Thanks John for pointing out that LE supports dynalloc. It's been many > years since I've looked at application programming in MVS. > > Paul

Re: Macro processor

> Paul wrote: did C have dynamic allocation in FOPEN before MVS UNIX. Thanks John for pointing out that LE supports dynalloc. It's been many years since I've looked at application programming in MVS.  > Paul wrote: Please explain dynalloc security exposure in programming > languages. In the past

Re: Who'da Thunk about COBOL here? [was Re: Macro processor]

59b-dmarc-requ...@listserv.uga.edu> Sent: Wednesday, December 20, 2017 1:19 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Who'da Thunk about COBOL here? [was Re: Macro processor] On 2017-12-20, at 11:17:03, Seymour J Metz wrote: > True, but how many shops these days have uncataloged

Re: Who'da Thunk about COBOL here? [was Re: Macro processor]

On 2017-12-20, at 11:17:03, Seymour J Metz wrote: > True, but how many shops these days have uncataloged DASD datasets? > Not all data sets are DASD. -- gil

Re: Who'da Thunk about COBOL here? [was Re: Macro processor]

marc-requ...@listserv.uga.edu> Sent: Wednesday, December 20, 2017 1:13 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Who'da Thunk about COBOL here? [was Re: Macro processor] On 2017-12-20, at 10:54:17, Seymour J Metz wrote: > The volumes are irrelevant. > Volume must be specified un

Re: Who'da Thunk about COBOL here? [was Re: Macro processor]

On 2017-12-20, at 10:54:17, Seymour J Metz wrote: > The volumes are irrelevant. > Volume must be specified unless the data sets are catalogued. -- gil

Re: Who'da Thunk about COBOL here? [was Re: Macro processor]

t: Wednesday, December 20, 2017 11:30 AM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: Who'da Thunk about COBOL here? [was Re: Macro processor] On 2017-12-20, at 06:15:40, John McKown wrote: >> >> ps. Sure hope it allows one to build concatenations... Gonna be a lot of >> expe

Re: Who'da Thunk about COBOL here? [was Re: Macro processor]

On 2017-12-20, at 09:34:06, John McKown wrote: >> >> Only with BPXWDYN can I allocate a mixed concatenation of Classic >> data sets and UNIX files/directories. COBOL ASSIGN? > > ​Nope - I just double checked the documentation previously posted. The > COBOL dynamic allocation via the ASSIGN can

Re: Who'da Thunk about COBOL here? [was Re: Macro processor]

On Wed, Dec 20, 2017 at 10:30 AM, Paul Gilmartin < 0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > On 2017-12-20, at 06:15:40, John McKown wrote: > >> > >> ps. Sure hope it allows one to build concatenations... Gonna be a lot of > >> experimenting with this. > > > > ​Glad to be of

Re: Who'da Thunk about COBOL here? [was Re: Macro processor]

On 2017-12-20, at 06:15:40, John McKown wrote: >> >> ps. Sure hope it allows one to build concatenations... Gonna be a lot of >> experimenting with this. > > ​Glad to be of service. I have never tried to allocate a concatenation > using the ASSIGN. But it is simple with BPXWDYN.​ > TSO

Re: Who'da Thunk about COBOL here? [was Re: Macro processor]

On 12/20/2017 08:15 AM, John McKown wrote: On Wed, Dec 20, 2017 at 6:59 AM, Steve Thompson wrote: Now, I might be able to solve a problem with an ALC module that was written and last touched about 1988 under MVS/SP1. Making this particular module LE friendly, RENT,

Re: Who'da Thunk about COBOL here? [was Re: Macro processor]

On Wed, Dec 20, 2017 at 6:59 AM, Steve Thompson wrote: > On 12/20/2017 06:13 AM, John McKown wrote: > > >> ​Which "production" languages would that be? Enterprise COBOL and PL/I >> _both_ support dynamic allocation of files. >> >> COBOL ref: >>

Who'da Thunk about COBOL here? [was Re: Macro processor]

On 12/20/2017 06:13 AM, John McKown wrote: ​Which "production" languages would that be? Enterprise COBOL and PL/I _both_ support dynamic allocation of files. COBOL ref: https://www.ibm.com/support/knowledgecenter/en/SS6SG3_6.2.0/com.ibm.cobol62.ent.doc/PGandLR/ref/rliosass.html Thank you

Re: Macro processor

On Tue, Dec 19, 2017 at 9:51 PM, Jon Perryman wrote: > > I wrote: TSO has the alloc command which can easily be > used in clists. > It exists because of MVS UNIX. > MVS UNIX has nothing to do with TSO ALLOC. When I moved the C FOPEN text, > I forgot to delete the MVS UNIX

Re: Macro processor

On 2017-12-19, at 20:51:23, Jon Perryman wrote: >> I wrote: TSO has the alloc command which can easily be > used in clists. It >> exists because of MVS UNIX. > MVS UNIX has nothing to do with TSO ALLOC. When I moved the C FOPEN text, I > forgot to delete the MVS UNIX senstence. It's FOPEN

Re: Macro processor

> I wrote: TSO has the alloc command which can easily be > used in clists. It > exists because of  MVS UNIX. MVS UNIX has nothing to do with TSO ALLOC. When I moved the C FOPEN text, I forgot to delete the MVS UNIX senstence. It's FOPEN dynamic alloc only exists because of MVS Unix and is

Re: Macro processor

Sorry for taking  so long to respond. A little too busy. >John Ehrman  wrote: I agree that PL/I's macro preprocessor is indeed powerful; >but it and > all other macro facilities I know of lack a key feature of >HLASM's  > conditional assembly and macro facility:   John is being modest by hugely