5 ms·

No. Having inheritance a default is fine. Not having an option to opt out when your program voluntarily tries to secure itself is terrible because it means few

No. Having inheritance a default is fine. Not having an option to opt out when your program voluntarily tries to secure itself is terrible because it means fewer programs can use it to secure themselves. A classic example would be an ssh server. You want to factor it into several components, one that talks to the network and a privileged (root) part that spawns the child processes with arbitrary uids. The latter part can reasonably pledge away a lot of its privileges but its children must run unrestricted (but often on unprivileged users).

jart 4y ago
This is a good example that really helps to explain things. SECCOMP's model of monotonically decreasing permissions seems the most intuitive. However with something like an SSH server I imagine the great fear is a remote exec compromise. pledge() fixes that, since after you call pledge, you can't create new PROT_EXEC memory. Plus OpenBSD enforces a W^X invariant so we can say for certain nothing like a pre-existing executable stack gets grandfathered in. So what they're doing seems reasonable to me. It's an added feature that our Linux polyfill can't offer. But that doesn't mean our pledge() doesn't work as advertised. We simply offer a subset of behaviors. It's not a disjoint paradigm that some people here have made it out to be.
staticassertion 4y ago
All that's required to emulate "no inheritance" is a broker.
- jart 4y ago
  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.
  - staticassertion 4y 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.
    - jart 4y 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 4y 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.
- the8472 4y ago
  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.
  - staticassertion 4y ago
    I wouldn't call sshd a broker, at least, it's not exclusively one.

jart 4y ago

This is a good example that really helps to explain things. SECCOMP's model of monotonically decreasing permissions seems the most intuitive. However with something like an SSH server I imagine the great fear is a remote exec compromise. pledge() fixes that, since after you call pledge, you can't create new PROT_EXEC memory. Plus OpenBSD enforces a W^X invariant so we can say for certain nothing like a pre-existing executable stack gets grandfathered in. So what they're doing seems reasonable to me. It's an added feature that our Linux polyfill can't offer. But that doesn't mean our pledge() doesn't work as advertised. We simply offer a subset of behaviors. It's not a disjoint paradigm that some people here have made it out to be.

staticassertion 4y ago

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

jart 4y ago
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.
- staticassertion 4y 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.
  - jart 4y 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 4y 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.
the8472 4y ago
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.
- staticassertion 4y ago
  I wouldn't call sshd a broker, at least, it's not exclusively one.