I think in linux you could already do this if you wanted to.
unprivileged user namespace + mount namespace -> mount some tmpfs, bind-mount (optionally read-only or noexec), pivot_root and you got an isolated view of the filesystem. You could write a wrapper around that which provides a streamlined API in the fashion of unveil.
It's what sandboxes and containers runtimes do. Instead it could also be made into a security library which processes could use as part of their startup sequence.
Basically, the linux building-blocks (seccomp, namespaces, privileges) are more low-level and you need to assemble pledge/unveil-like abstractions from them. But I am not aware of any established library that does that in a convenient fashion.
The difference between pledge and seccomp, or unveil and namespaces, is that pledge and unveil limitations are not inherited.
Intuitively you would think that makes them less secure. But inheritance means that it becomes impossible to use system utilities. On OpenBSD /bin/sh is pledge'd; you could never do the same thing using seccomp because it would make the shell useless. At best you'd dynamically seccomp a single shell session according to a particular task, and you'd have to do it from the invoking process. Unsurprisingly, nobody bothers doing this.
So it's impossible to emulate pledge, and impractical to emulate unveil, on Linux. At this point, almost every program on OpenBSD uses pledge. No configuration. No option switches. It's done. Everything works like before, except now the security risk of bugs in all that code are substantially mitigated.
All the criticisms of pledge and unveil miss the basic point of these interfaces--to be easily useable by developers and easily used in all programs, not as low-level primitives to be used to write libraries to be used to write tools to be used by sysadmins for sandboxing services.
in linux, systemd can do that when starting a service. the config is in a unit file, not a library
probably better, as such code is likely to be very unportable. even if you standardise the calls in a library, on linux the right paths will probably vary between distributions and architectures
Pledge and unveil allow you to do privileged setup within the process, e.g. obtaining a bunch of file descriptors, or doing other things that need caps, then holding onto them and then dropping those privs.
That's not possible with an external container/sandbox launcher, you need to interleave it with the control flow.
Seccomp&co are too low-level. Jail launchers are too coarse.
unprivileged user namespace + mount namespace -> mount some tmpfs, bind-mount (optionally read-only or noexec), pivot_root and you got an isolated view of the filesystem. You could write a wrapper around that which provides a streamlined API in the fashion of unveil.
It's what sandboxes and containers runtimes do. Instead it could also be made into a security library which processes could use as part of their startup sequence.
Basically, the linux building-blocks (seccomp, namespaces, privileges) are more low-level and you need to assemble pledge/unveil-like abstractions from them. But I am not aware of any established library that does that in a convenient fashion.