This is a good point. My initial thought is that the developers would know best what features their application needs? Furthermore, it's work that every user benefits from, rather than requiring an IT professional to reconfigure for each use case.
What do you see as the downsides?
Legacy software, new security issues which has not yet been patched. As the operator you have no way to isolate the application, you just have to wait for the developer for both mitigation and bug-fixes.
In the real world I don't see that making much of a difference. Many sandbox solutions aren't really being used anyway, legacy software can go on it's own VM and network. Micro-segmentation of networks are in style for those types of companies anyway.
Pledge and Unveil seems like more pragmatic solutions to me, but they do require a certain level of care and engagement from the developers. If you don't have that, then things like SELinux, AppArmor or some type of sandbox that can be applied by the operator can help prevent an attacker from getting a foothold on a server or VM.
If it’s open source then it can be patched in bsd packages manager.
Most usage of pledge is here rather than being upstreamed.
> Furthermore, it's work that every user benefits from, rather than requiring an IT professional to reconfigure for each use case.
A distro could distribute, say, bubblewrap configs that automatically sandbox packages and every user could likewise benefit from that.
> What do you see as the downsides?
I think you're right that devs are best placed to lock down their own code, but if you don't have developer buy-in (or if they just don't want to make the effort or aren't available) then externally-imposed sandboxes are a lot easier for distro maintainers or end users to add after the fact than trying to patch the actual program source to do pledge+unveil or such.