Well, it falls afoul of compilers. JIT compilation does it in memory, but a regular compiler breaks the same rules on disk - it writes a file that is executable.
But even if we were writing binaries by hand, the editor that wrote them would still be breaking the same rules. There's no getting around it. The stuff that creates executables has to break those rules.
You just want a very limited set of things that are able to do that. Even in JIT, the JIT portion of the runtime should be able to write executable pages of memory, and the rest should not be able to.
But how do you enforce that? Aye, there's the rub...
> Well, it falls afoul of compilers. JIT compilation does it in memory, but a regular compiler breaks the same rules on disk - it writes a file that is executable.
Now you got me thinking. That's avoidable on linux - you can use SELinux to disallow the compiler process to execute it's own output. You might be able to ensure that a process is able to execute the compiler xor it's output, but I'm not sure about that. I know the first one because I've spent a weekend writing an SELinux module for our application servers, which don't need to execute anything after a certain startup procedure. But let me tell you, java + SELinux is not for the faint of heart, because the executed binary is shared.
> But even if we were writing binaries by hand, the editor that wrote them would still be breaking the same rules. There's no getting around it. The stuff that creates executables has to break those rules.
> You just want a very limited set of things that are able to do that.
I call that trust management for myself. For example, from a systems perspective, my configuration management is a large security issue. It downloads binaries either via a package management or via HTTPs, validates them and runs them. It has to download and run them, because that's the definition of 'provisioning a server'. And it doesn't matter if the binaries are pre-baked via docker / packer, or if chef/puppet install them in VMs on the fly, the entity 'config management' just grows larger.
As such, we have to trust our configuration management, because we have to trust something, because we can't enforce security at this point.
You can do this with an out of process JIT. Basically the JIT process has the code mapped as read/write and maps it into the runtime process as read/execute. Then you can use OS capabilities to prevent the runtime process from creating its own executable pages (on Windows you can do this by enabling ACG).
