> Not requiring the cooperation of developers to opt-in, for starters.
True, meaningful in the general case, and completely irrelevant in this particular case, which started with specifically the question of OpenBSD applying the protection in question to its own base system. I actually agree that being able to externally impose a sandbox is super useful, but self-imposed restrictions are perfectly applicable in this usecase.
> You really think pledge and unveil are equivalent to sandboxing? Can you refer to any sandboxing solution or technologies that limit themselves to restricting syscalls and hiding file paths? Unveil is a lot more useful as a component in sandboxing, I'll give you that.
I think that pledge and unveil are a type of sandboxing, certainly. And... I'm struggling to think of any sandboxing tech that does anything but limit syscalls and filesystem access. After rereading https://github.com/containers/bubblewrap?tab=readme-ov-file#... a bit, I suppose there's a case for being able to change what a sandboxed process can see rather than only masking (ex. PID 1 is a different process inside and outside the sandbox), but that strikes me as a slight variation rather than a fundamental difference in what is or isn't a "sandbox" per se. Likewise, I could see an argument that OpenBSD's approach is coarser than it could be; ex. I think you could restrict a Linux process to keep your real user and be able to read files but not write them even though they're owned by your user and are 644, but that's more of a convenience thing than a true fundamental difference - an OpenBSD process could open files in read mode, keep the socket open, and then pledge away open() altogether which gives you the same outcome with more legwork.
> which started with specifically the question of OpenBSD applying the protection in question to its own base system.
Agreed, my answers did quickly go beyond the original point being claimed.
> I think that pledge and unveil are a type of sandboxing, certainly.
I think they are limitations and that's about it. They don't fit the metaphor of a sandbox IMO.
> but that strikes me as a slight variation rather than a fundamental difference in what is or isn't a "sandbox" per se.
Fundamentally I see a sandbox as something that is hard for the sandboxed application to escape, or even communicate out from except via limited well defined channels.
I don't think limiting syscalls alone satisfies that.
As a test, I think a robust sandbox should be able to apply to any program, no matter what it is doing.
Do you think pledge satisfies that? What about a complex piece of software that needs to use a number of syscalls that could be leveraged for an attack frequently, and so can't be meaningfully limited with pledge.
If that software has a vulnerability, the attacker now has access to the host system at least to the extent of the user the program was running under. That attacker certainly isn't sandboxed, they don't even have to escape a sandbox because there wasn't really one there, just 'concepts of a sandbox'.
True, meaningful in the general case, and completely irrelevant in this particular case, which started with specifically the question of OpenBSD applying the protection in question to its own base system. I actually agree that being able to externally impose a sandbox is super useful, but self-imposed restrictions are perfectly applicable in this usecase.
> You really think pledge and unveil are equivalent to sandboxing? Can you refer to any sandboxing solution or technologies that limit themselves to restricting syscalls and hiding file paths? Unveil is a lot more useful as a component in sandboxing, I'll give you that.
I think that pledge and unveil are a type of sandboxing, certainly. And... I'm struggling to think of any sandboxing tech that does anything but limit syscalls and filesystem access. After rereading https://github.com/containers/bubblewrap?tab=readme-ov-file#... a bit, I suppose there's a case for being able to change what a sandboxed process can see rather than only masking (ex. PID 1 is a different process inside and outside the sandbox), but that strikes me as a slight variation rather than a fundamental difference in what is or isn't a "sandbox" per se. Likewise, I could see an argument that OpenBSD's approach is coarser than it could be; ex. I think you could restrict a Linux process to keep your real user and be able to read files but not write them even though they're owned by your user and are 644, but that's more of a convenience thing than a true fundamental difference - an OpenBSD process could open files in read mode, keep the socket open, and then pledge away open() altogether which gives you the same outcome with more legwork.