>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.

Reply via email to