5 ms·

I increasingly find myself looking at pledge... https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2 It's objectively the right model, if my assu

I increasingly find myself looking at pledge... https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2 It's objectively the right model, if my assumptions are wrong, the program fails. I like that. Maybe it could be taken further... to lie to the app and report back about it's sandbox... or halt and log it's image.

cyphar 8y ago
As a complete aside, I'm happy that they added "execpromises" to pledge. It was one of the main things that really concerned me about its usage as a sandboxing system (seccomp I think is still more powerful but I will be the first to admit it's ridiculously complicated to get right).
- tux1968 8y ago
  Wonder how hard it would be to provide a Pledge API which simply passes through to seccomp.
  - ori_b 8y ago
    It's possible, but it's fairly hard. You'd need a second process to supervise the seccomp'ed process, watching the paths that it accesses with ptrace, and allows/disallows the actions based on inspection of the process state. The problem is that seccomp, as far as I'm aware, does not provide you with easy access to the actual arguments of system calls if they are not pointers. The actual pointed-at values of the arguments are required for emulating pledge.
    - Ua2Reemo 8y ago
      Yeah, the seccomp limitation that it can't deref pointer arguments makes things a lot less elegant than pledge. But at least unveil can be implemented via mount namespaces.
    - cyphar 8y ago
      The need for ptrace is soon going to change with the new seccomp userspace notification API (still undergoing review) which allows a userspace process to get notifications when seccomp is tripped and decide what the return code of the syscall is (you can also give it an fd which is copied to the process unix socket style). This would allow you to use process_vm_{read,write}v without the need to mess around with PTRACE_SEIZE. The main usecase for this is container runtimes (emulating privileged operations like auto-loading of kernel modules), but it could also be used for this an a whole host of other really neat features. (Huge shout-outs to Tycho Anderson for working on this for quite a while!)
pcwalton 8y ago
pledge is objectively the wrong model, because it's an ad-hoc set of fixed-function rules. By contrast, Linux seccomp-bpf allows much more flexibility, because you can actually write an arbitrary program to implement whatever sandboxing policy you want. In fact, your wish list highlights the problems of pledge precisely. You can implement "pretend to succeed" and "dump core for inspection by a trusted supervisor", but only on Linux with seccomp-bpf, not with pledge.
- ori_b 8y ago
  It's objectively the right model, because it's simple enough to implement that the vast majority of OpenBSD is pledged, including many ports like Firefox. The vast majority of other systems do not have the equivalent, in spite of having mechanisms that are in theory more powerful than pledge. Flexible sandboxes don't help if your programs don't run in them.
  - kbenson 8y ago
    Maybe it's objectively the right model for right now, and the wrong model for tomorrow, which would make you both right. It's hard to get programmers and packagers to add new OS specific features, at least until most OS's support from variant of that feature, and then they either bite the bullet or they use from library to abstract it. Pledge is simple, and that helps people adopt it and start using it. When most operating systems are providing something equivalent and most programs are making some use of it, it then becomes a selling point to do it better, because the status quo has moved. At that point, pledge might not compare well, unless it has evolved.
    - ori_b 8y ago
      > Maybe it's objectively the right model for right now, and the wrong model for tomorrow. I'm using my computer right now. And pledge is evolving over time, as we gain experience in what real programs need by implementing protection for them.
      - 8y ago

cyphar 8y ago

As a complete aside, I'm happy that they added "execpromises" to pledge. It was one of the main things that really concerned me about its usage as a sandboxing system (seccomp I think is still more powerful but I will be the first to admit it's ridiculously complicated to get right).

tux1968 8y ago
Wonder how hard it would be to provide a Pledge API which simply passes through to seccomp.
- ori_b 8y ago
  It's possible, but it's fairly hard. You'd need a second process to supervise the seccomp'ed process, watching the paths that it accesses with ptrace, and allows/disallows the actions based on inspection of the process state. The problem is that seccomp, as far as I'm aware, does not provide you with easy access to the actual arguments of system calls if they are not pointers. The actual pointed-at values of the arguments are required for emulating pledge.
  - Ua2Reemo 8y ago
    Yeah, the seccomp limitation that it can't deref pointer arguments makes things a lot less elegant than pledge. But at least unveil can be implemented via mount namespaces.
  - cyphar 8y ago
    The need for ptrace is soon going to change with the new seccomp userspace notification API (still undergoing review) which allows a userspace process to get notifications when seccomp is tripped and decide what the return code of the syscall is (you can also give it an fd which is copied to the process unix socket style). This would allow you to use process_vm_{read,write}v without the need to mess around with PTRACE_SEIZE. The main usecase for this is container runtimes (emulating privileged operations like auto-loading of kernel modules), but it could also be used for this an a whole host of other really neat features. (Huge shout-outs to Tycho Anderson for working on this for quite a while!)

pcwalton 8y ago

pledge is objectively the wrong model, because it's an ad-hoc set of fixed-function rules. By contrast, Linux seccomp-bpf allows much more flexibility, because you can actually write an arbitrary program to implement whatever sandboxing policy you want. In fact, your wish list highlights the problems of pledge precisely. You can implement "pretend to succeed" and "dump core for inspection by a trusted supervisor", but only on Linux with seccomp-bpf, not with pledge.

ori_b 8y ago
It's objectively the right model, because it's simple enough to implement that the vast majority of OpenBSD is pledged, including many ports like Firefox. The vast majority of other systems do not have the equivalent, in spite of having mechanisms that are in theory more powerful than pledge. Flexible sandboxes don't help if your programs don't run in them.
- kbenson 8y ago
  Maybe it's objectively the right model for right now, and the wrong model for tomorrow, which would make you both right. It's hard to get programmers and packagers to add new OS specific features, at least until most OS's support from variant of that feature, and then they either bite the bullet or they use from library to abstract it. Pledge is simple, and that helps people adopt it and start using it. When most operating systems are providing something equivalent and most programs are making some use of it, it then becomes a selling point to do it better, because the status quo has moved. At that point, pledge might not compare well, unless it has evolved.
  - ori_b 8y ago
    > Maybe it's objectively the right model for right now, and the wrong model for tomorrow. I'm using my computer right now. And pledge is evolving over time, as we gain experience in what real programs need by implementing protection for them.
    - 8y ago