There are typically separate development and production (virtual) machines (or partitions). With assembler, C\CPP, COBOL, etc. there is a prerequisite compile of the source code to object modules on the development machine under the control of a software change management (DevOps) tool followed by a subsequent deployment to production of the generated executables. The complier is not available on the production machines thereby protecting the production machines from the introduction of unauthorized executables.

With Python and JAVA since v11 the interpreter automatically compiles the source code at run time. That ability of the interpreter to automatically compile is convenient, but it is also insecure since that interpreter must be available on the production machine. On the z mainframe many people with an account on the production partition(s) have an OMVS segment and therefore a UNIX home directory where they can place files that they can edit, save, and execute. That makes it easy for them to bypass software change controls by introducing new or modified JAVA and Python programs on the production machines that they can then execute from source code.  Cython can convert Python to C\C++ but it appears that Cython requires LINUX and not everyone installs LINUX.

Question: Are there practical ways for those who want their production machines to be properly secured, and who do not have LINUX, to implement JAVA and Python while still ensuring the integrity of the software change management process is protected? 

Discussion: Wouldn't it better overall if either the interpreter only executes compiled byte code (as was the case for JAVA v8) or if there were two separate interpreters one of which only executes compiled byte code, so that a less secure source code interpreter would not need to be deployed on the production partitions?

------------------------------
Mathew Goldstein
------------------------------

Hey Matthew, the way to secure your environment is through using proper security controls and logging (ex: using unix groups, RACF), giving the user access to only features that they require access to. For example, if the user doesn't have access to either Python or Java, there are many other ways they can still run code on the mainframe such as shell scripts or writing assembler. 

For Python on z/OS, you can compile your code to bytecode before running it, and Cython is also available via the Python AI Toolkit for IBM z/OS. But as long as a given user has write access to these scripts or binaries, they can be modified. Being a compiled binary does not protect it from being changed, only makes it more difficult. But this is the fundamental nature of Python - that its an interpreted language, not compiled. 

Regarding "Being a compiled binary does not protect it from being changed, only makes it more difficult."

For the JAVA and Python interpreters, providing an option to turn off the automatic compile is all that is needed since both can be compiled on the development machine prior to deploying the compiled byte code to the production machine. IBM (or the vendor supplying IBM with the interpreters) could do this, customers cannot reasonably be expected to modify the interpreter that way.

The "Least Privilege" security control is not about making it impossible for anyone to do anything wrong. It is about reducing the security weakness exposures. You appear to be basing your argument on a false dichotomy of an all or nothing choice between an impossible to achieve perfection or doing nothing. The ZAP program, like the compilers (including the high-level assembler) and the software change management tools (including SMPE) should not be available for use on a production platform or at least should require completing a procedure with management oversight for obtaining temporary use. The goal is for initial installs/maintenance of COTS products, and updates of in-house software, to occur exclusively on the development platform, testing to also occur on a pre-production platform, and finally deploy to production, without installs or updates occurring on the production platform. Shutting down the shell scripts and REXX execs would be more difficult yet doing that would also improve security. Each and every individual obstacle that makes it more difficult to do installs/maintenance/updates directly on the production platform improves the security of the production platform, therefore implementing such obstacles is a proper goal.  At least for in-house software, it would be abnormal to directly update the binary, enough so that merely being caught having done that on a production machine would by itself be justification for locking out, or even firing, the person responsible for doing that.

------------------------------
Mathew Goldstein
------------------------------