No that's a linux thing. The OpenBSD way is to do things that could be abused later early and then drop privs to prevent abuse. How is some program going to know what other programs you use will need? How is the dynamic linker of the later program supposed to deal?
> The OpenBSD way is to do things that could be abused later early and then drop privs to prevent abuse.
That is the approach if you can't regain privileges. In the OpenBSD way it is literally the opposite of waht you propose.
> How is some program going to know what other programs you use will need?
It doesn't? Same issue on linux/openbsd in that regard, with some aspects a bit different due to libc.
> How is the dynamic linker of the later program supposed to deal?
It obviously doesn't, again, same thing on Linux and OpenBSD. It also won't help you to be able to regain privileges via exec if the issue is a shared library.
Allowing for privileges to not propagate is a cool feature that allows you to shell out to a binary that you can't write to (otherwise it's pointless) and have that binary manage its own permissions. That's sometimes important, and Apparmor supports that sort of thing (with child profiles).
But it's also a big footgun that can easily allow a full sandbox bypass.
You can implement the child profile concept easily enough with a privileged broker anyway.
Oh yeah, is this not a clear bypss? Write an executable file to disk and then... execute it. As far as I know that is all that's required to completely bypass pledge?
I assume/ hope this is something you can control with better filesystem controls?
