← Back to context

Comment by staticassertion

4 years ago

All that's required to emulate "no inheritance" is a broker.

Yes but we can't always assume a broker is installed. For instance I distribute a lot of foss software. I don't want to have to ask my users to install and adopt these other tools in order to use my code. I don't want to have to ask people to do things like run my security daemon as root. What I like about this new pledge.com program is it doesn't need root. I could just incorporate it into a build process or automated tooling for instance, and it would just work, and wouldn't inconvenience anyone. The only thing it needs is a Linux Kernel from the last 12 years.

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

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

      1 reply →

But that's the issue. In the example I gave we already have a broker (the root process spawning ssh shells). But we want to restrict the broker too to make it more difficult to exploit. To do that we need to pledge without inheritance.