Am 04.03.26 um 05:41 schrieb Theo de Raadt:

The only way to do what you are talking about here is to dumb it down to
the least capable subsystem.  But that will make it much, much, much
less ineffective than a pristine solution.  At that point the word
'sandboxing becomes approximately as valuable as it has been for for a
while.  The bar should be high, but it is low.  But the word sandboxing is
always satisfied by performing the minimum.  "Oh we sandboxed it".  The
problem is the community understanding that a minimum sandbox is still
considered a sandbox.

The idea is not to provide a "sandbox" just to be able to check a checkmark, but to provide an actual security boundary.

By abstraction, I don't mean a race to the bottom for the lowest common denominator (which is no sandboxing at all), but rather an abstraction over pledge+unveil that can also be made to work with Landlock (and maybe Capsicum). So it would deny everything by default and also allow no file system paths by default, except for those explicitly allowed.

This way, the least common denominator doesn't mean allowing - it means denying. So, if, for example (and this is fictitious) Landlock has no way to allow what pledge("ps") does, you just won't be able to get a list of processes in your sandboxed process. Some OS-specific promises could also be added to make the user fully aware that this only works on that specific OS - and will fail on any other OS.

And yes, this means there are plenty of sandbox systems out there that will plainly not be supported because they don't have "deny everything by default", making them IMHO useless anyway.

If you're interested in this and would like to tear it apart once I got to it, let me know and I'll send you a link once it's there :).

--
Jonathan

Reply via email to