[sroerick]

There's an interesting distinction here where one approach is to build sandboxes that limit exposure, while the other is just allowing the program to be more secure.

One approach is "Trust No Code" and the other is "Trusted code should run safely".

the first one sounds better on paper, but leads to a very complicated system. That said, I haven't worked with jails much or other forms of sandboxing. It just seems to me that to make software function you need escape hatches, and the more of those you have, well, now you're back to plugging exploits with a more complicated system.

It was interesting to me to hear that even though OpenBSD had designed their software to limit permissions even before pledge and unveil were released - upon release they found that a shocking amount of their software actually wasn't following their own rules.

[grebc]

I definitely lean to the “trusted code should run safely” because it’s just simpler in general.

At what point do you trust the system? And if you don’t trust any of it what are you trying to accomplish?

Re OpenBSD: I think it just shows we’re all human(fallible) at the end of the day :)

[josephg]

> Re OpenBSD: I think it just shows we’re all human(fallible) at the end of the day :)

Yeah. Its yet another reminder that "being really careful" isn't an adequate security policy. Attackers only need to find 1 bug. Defenders need to protect everything. In large systems, you need defence in depth. Pledge? Yeah. NX? Yeah. Process isolation between subsystems? Yeah lets have that too. Static verification? Love it. Rust's borrow checker? Sure. We need it all.