How is this a security exposure for c but not ALC? I’m not a c programmer. Nor do I program with Java.
I would like to understand this. Regards, Steve Thompson --- [email protected] wrote: From: Seymour J Metz <[email protected]> To: [email protected] Subject: Re: security with storage allocation under z.OS Date: Tue, 17 Nov 2020 14:28:31 +0000 It's a security exposure in C that is alleviated by putting the stack and heap in nonexecutable storage. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List <[email protected]> on behalf of Tony Harminc <[email protected]> Sent: Monday, November 16, 2020 4: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. > Do you know where can I find information on the mainframe security model > under z/OS. There is a fair bit of information on what not to do when writing privileged programs. IBM has given sessions on this topic at SHARE and such. These are all how to write code according to rules identified in the very first statement of MVS System Integrity published around 1972. Tony H.
