Thanks Peter. This is much closer to what I was asking.
Specifically, are cobol programmers allowed to specify DSN in production cobol
programs? Either way, are companies reviewing cobol programs for abuse where
the DSN is in the cobol source? I realize that several shops do reviews but is
this now a standard practice? I only ask because 20 year's ago, code reviews
were not very strict at some shops. Back then, some shops did not require code
reviews and those that did require it often allowed you to make corrections
after the code review without a second review. There always seemed to be a way
to sneak small changes.
Cited in the Target breach were some process failures. E.g. Ignoring warnings
that were supposed to be reviewed. Are MVS personel more dedicated to their
internal processes than their Unix counterparts?
By the way, I'm talking about a well configured SAF environment and not
violating any SAF rules.
Thanks, Jon.
On Saturday, December 23, 2017 11:11 PM, "Farley, Peter x23353"
<[email protected]> wrote:
Jon,
Dynalloc is not an exposure in a properly configured z/OS SAF environment.
Most large shops I have worked at don't allow application programmers (who are
the ones most likely to have the skills to perpetrate a security breach and the
necessary inside knowledge of process and procedure) to even execute a SAF LIST
function, let alone modify any SAF rule, even for their own user ID datasets.
No SAF rule violations are unmonitored or uncaught, even accidental ones. The
mainframe security team are usually very vigilant in my experience.
In a properly configured z/OS SAF environment there is no way for any
programmer or other non-trusted employee to violate any SAF rules. Dynalloc
only allows allocation of a file, not read or write or update access to that
file (or database table, etc.). Without necessary access rights, allocation is
a useless tool for malfeasance of any kind.
OTOH dynalloc is a very useful programming tool for the use cases that require
access to files whose names are known only at run time from dynamic and
appropriately process-controlled input. I am on an application team who are
responsible for one such program.
Does that answer your question?
Peter
-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]] On
Behalf Of Jon Perryman
Sent: Sunday, December 24, 2017 12:39 AM
To: [email protected]
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.
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 <[email protected]>
wrote: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
that regard z/OS is like any other system out there. Ultimately Your arguments
fail to convince me of the existence of any actual vulnerabilities in z/OS
itself.Keven
On Sat, 23 Dec 2017, at 18:40, Jon Perryman wrote:
> I only wanted to know why dynalloc is no longer considered an exposure.
This message and any attachments are intended only for the use of the addressee
and may contain information that is privileged and confidential. If the reader
of the message is not the intended recipient or an authorized representative of
the intended recipient, you are hereby notified that any dissemination of this
communication is strictly prohibited. If you have received this communication
in error, please notify us immediately by e-mail and delete the message and any
attachments from your system.
