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