If by “it” you mean MVS DynAlloc then the reason it’s not
considered to be a potential security exposure now is pretty much the same
reason for it never having been, namely that it cannot be used to circumvent
system security.
Keven
Get Outlook for iOS
On Sun, Dec 24, 2017 at 1:11 AM -0600, "Farley, Peter x23353"
<peter.far...@broadridge.com> 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: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 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 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.
