>My primary use-case is that I would like to port a Linux web app >(the Rust Playground) to OpenBSD. The Rust Playground allows >users to supply arbitrary source code, which is then compiled >and executed. I have no control over the contents of said code, >so I have no way to ensure that these programs will call pledge(2) >themselves. Calling pledge(2) externally allows me to sandbox the >untrusted binaries.
No it does not. You keep using that vague word "sandbox", the word has become pointless because it allows people to handwave away concerns about "what happens when the software hits the boundaries". In a real backyard sandbox when the toy truck falls outside the box onto the grass it's no big deal, but in the tech-space sandbox means bolting on "security" without investing in actual "security". I'll give it one more shot. pledge is not a virtual machine. It is a deliberately designed collection of POSIX subsets. Every subset you can generate is non-complaint with POSIX. You have no idea if the correctly-operating program won't hit one of those behavioral changes, and then it is performing unintended behaviour. The addition of unveil and pledge enforcement has violated the assumptions of the original program. At a very fundamental level the program will misbehave because you are putting it into an incorrect execution environment. The "containment method" WILL introduce changes in program behaviour. Let me be clear, the process you are engaging in is not ENGINEERING. It is much closer to moving sand with plastic Tonka trucks. >To be clear, I am only using execpromises because it is the only way >I know of to solve my problem under OpenBSD. I thought there were good usage cases for execpromises when I designed it, but I've been unable to find them. I was hoping people would not abuse it, but here we are. You are blindly accepting downsides which you cannot see. That is why I intend to delete execpromises.
