| ▲ | qarl2 21 hours ago | ||||||||||||||||||||||
I don't know what you mean by "enforce W ^ X". You can't give shell access and then revoke special parts of it. This is not controversial. All your criticisms apply to all LLM harnesses - and everyone who genuinely cares about these things is using security on top of the harness, because OBVIOUSLY. Your complaints are misguided. | |||||||||||||||||||||||
| ▲ | wren6991 21 hours ago | parent [-] | ||||||||||||||||||||||
Here: https://en.wikipedia.org/wiki/W%5EX This doesn't require cooperation from the shell. If writable paths are non-executable, and executable paths are non-writable, then executing `cp $(which git) my-new-favourite-binary` doesn't grant you permission to run it. The part which does require cooperation (from outside of the shell, i.e. from the harness) is the ability to upgrade writable paths to executable, at the cost of writability and whatever other restrictions you place on the binaries generated by your agent. This kind of W^X invariant is widely deployed in every desktop operating system, and the type of W-X upgrade hook I described is used by every JIT engine. | |||||||||||||||||||||||
| |||||||||||||||||||||||