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
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 eventua
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
ubject: AW: Dynalloc (was Macro processor)
Is that like the evil mastermind who kills his best people as soon as they fail
in any way? If only real life were so simple.
And Merry Christmas (or Festive Season).
-Ursprüngliche Nachricht-
Von: IBM Mainframe Assembler List [mailto:ASSEMBLER-L
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 from
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
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
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
>> the code reviewer(s) for
: 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...
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
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
.
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
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
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
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 content
is safe.
K
] 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 trust the sender and know
your 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 origi
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 what you’re s
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 tha
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 it'
Am I missing something or are the arguments for disabling dynamic allocation
nearly a clone of the old arguments for restricting AMASPZAP?
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
p
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 b
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 it'
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
wrote:
On Fri
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
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
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 possib
] 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 wrote:
>Charles broke the cardinal rule in security ( never say never ). Viruses rely
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 their data
>breach.
C
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 i
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
*o
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 gr
>>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 and
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 balanci
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 a
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, Decembe
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 st
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 MVS
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
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 e
ember 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 Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On
Behalf Of Jon Per
ABSOLUTELY!
CharlesSent from a mobile; please excuse the brevity.
Original message From: "Swarbrick, Frank"
Date: 12/21/17 5:29 PM (GMT-05:00) To:
ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: [EXTERNAL] Re: Macro processor
Doesn't RACF or other access
L] 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
: 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 th
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 things the tried &
> true way.
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 feature in production? For
>
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 intent
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 wrote: Please explain dynall
> 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
;
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 DASD datasets?
>
Not all d
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
;
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 unless the data sets are catalogued.
-- gil
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
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
>> experimenting with this.
>
> Glad to b
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 b
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 servic
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 ALLOCATE
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, AMODE(31), and G3 friendly
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:
>> https://www.ibm.com/support/knowledgecenter/en/SS6S
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 for
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 senstence. It's FOPEN d
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 dynam
> 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 consid
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
65 matches
Mail list logo
