Everything I've read about pledge and unveil really admire the approach and the results but it didn't seem to have a big impact outside of OpenBSD. It took ~20 years for OpenBSD's CSPRNG to be re-implemented everywhere else maybe we're operating on a similar timeline here.
Maybe I'm not getting something here, but I find the pledge/unveil approach confusing.
Why should I expect a program to set allowed syscalls/filesystem paths? Why would I trust that it will set itself the right permissions? What is allowed should be set externally from the program, similarly how I can map filesystem volumes and add capabilities to a Docker container [1].
I'm not familiar with BSD and I only used it a couple times out of curiosity. What am I missing?
The threat vector is not that you don't trust the program, pledge/unveil is completely unsuitable for that. but that you worry the program will be compromised while it is running.
so the observation is that programs tend to have a startup state where they need access to files and a run state where they don't. so pledge/unveil is a mechanism for a program to inform the os that it no longer needs access to files/syscalls and any future access should be considered a hostile takeover. please kill me.
> Why should I expect a program to set allowed syscalls/filesystem paths? Why would I trust that it will set itself the right permissions?
Because the admin or owner will know FAR less about what a complex program needs at all times, and when it will be safe to drop privs. A database might be tested for a week and then it has a special snapshot thing done for the monthly backup and you did not foresee this, whereas the coders would know what perms are needed in order to do these dumps. Hence, you can't set perms just once before starting, and as a user of said software, you can't expect to just make a quick test and then design a fully working harness for it either.
