> If a program has a bug such that it treats part of its input data as a branch > offset without validating it, > then it is useful to have the normal kind of storage not allow execution.
Yes, and to help prevent a bad guy from sending a z/OS program some sort of "message" -- perhaps a URL or SQL -- that is actually crafted as a series of malicious executable instructions, and then somehow inducing the program to branch to it. The program in question would not have to be privileged. The program might have permitted access to certain datasets or tables that it could be induced to modify maliciously. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Tony Harminc Sent: Monday, November 16, 2020 1:37 PM To: [email protected] Subject: Re: security with storage allocation under z.OS On Mon, 16 Nov 2020 at 12:24, Ze'ev Atlas <[email protected]> wrote: > > Hi allIn the 1970's I probably could have done some getmain, write some code > into that obtained memory and jump to that code. I assume that nowadays, this > would be impossible and there is some security model to prevent such a > security breach. Why do you call this a security breach? What is wrong with being able to write and execute your own code? If you can't do that, you don't have a computer, you have an appliance. Sort of like an iPhone... Yes, there have been architectures over the years that regard the ability to execute code as a privilege. But zArch (and predecessors) has never worked that way. What is the difference between executing that code you propose that does the GETMAIN and so on, and executing the code that you wrote into the area you obtained? What matters is what code can do with and to data, and that is controlled by mechanisms that don't depend on who wrote the code into storage. For that matter, what is the difference between building a sequence of zArch instructions and then executing them, and building a sequence of Java bytecodes or REXX instructions and executing *them*? So why is IBM adding the notion of no-execute storage to the architecture? Same reason as Intel and everyone else: to help prevent bugs in *privileged* code from being exploited by crafted data. If a program has a bug such that it treats part of its input data as a branch offset without validating it, then it is useful to have the normal kind of storage not allow execution. It just reduces the attack surface.
