Comment by staticassertion

4 years ago

You can package the broker yourself and launch it before you pledge.

Keep in mind that if you can:

1. write to a file 2. Make that file executable (or write to an already-executable file, or an executable that provides scripting/ code exec natively)

And you have the `exec` capability, the sandbox is trivial to bypass in the face of code execution in the pledge'd process.

2 comments

staticassertion

jart 4 years ago

Yes that's true. It's something that I considered. I was reluctant at first to restrict changing the executable bit since OpenBSD lets this happen:

    int main(int argc, char *argv[]) {
      CHECK_NE(-1, pledge("stdio rpath wpath cpath exec", 0));
      CHECK_NE(-1, open("/tmp/doge.exe", O_CREAT | O_WRONLY | O_TRUNC, 0755));
      return 0;
    }

But if other people are noticing it too, then I think I might change the tool to simply disallow creating new executables. Since that makes more sense to me. But naturally would make even more sense for OpenBSD.

staticassertion 4 years ago

The bypass is so significant that I kind of wouldn't bother. To me I think that it's probably best to just assume that this tpe of sandboxing is not capable of resisting an attacker with code execution, which is fine. It could instead be for things like path traversal attacks in web servers, or other design flaws that would allow "tricking" the application into performing actions you don't want.
I mean it's probably a good idea to close the trivial version of the bypass by disallowing setting exec on files (although you need to check the path because you may want to set it on a directory), but if you can execute `chmod`, write to the i-node directly, write to any other executable, write to your own executable, etc, that's just a full bypass.