> At the same time, there have been some valid criticisms of pledge/unveil by capsicum people; IIRC something to do with its restrictions not persisting following an exec?
The validity of that criticism is so-so. It's a common complaint from people who are trying to build an externally imposed sandbox that dictates what a program can do.
But that's not what pledge and unveil are. They're more of an internally imposed set of constraints: the program just announces what it's going to do. After that, if it breaks the contract (due to a bug or malicious intervention), the system has license to kill it.
The program knows what it is going to do, so it can write the contract for itself. But it doesn't know what some other program is going to do, so it doesn't make sense for these restrictions to persist after exec. The program-to-be-exec'd should have its own pledges.
In reality it's even more complicated than that: programs often need to perform some "privileged" operations before they are ready to put on their straight jacket. It'd be very hard for program A to say that program B starts with privileges X, Y, Z, and then after instruction Q drops Y and Z. And program B might require more privileges than what A had when it called exec, so again it's just not going to work for this at all. If A's privileges were to persist, then it would have to have some way to elevate them or it'd never drop them in the first place. Both seem like a bad deal.
It's just a completely different mechanism, but people think sandbox sandbox sandbox and if that's all one can think of, pledge and unveil might seem like a terrible tool for that. They're not a tool for sandboxing untrusted programs.
It's also worth noting that you can pledge for an execed process using the second argument to pledge. This is for when you know what the child is expected to do on your behalf.
The validity of that criticism is so-so. It's a common complaint from people who are trying to build an externally imposed sandbox that dictates what a program can do.
But that's not what pledge and unveil are. They're more of an internally imposed set of constraints: the program just announces what it's going to do. After that, if it breaks the contract (due to a bug or malicious intervention), the system has license to kill it.
The program knows what it is going to do, so it can write the contract for itself. But it doesn't know what some other program is going to do, so it doesn't make sense for these restrictions to persist after exec. The program-to-be-exec'd should have its own pledges.
In reality it's even more complicated than that: programs often need to perform some "privileged" operations before they are ready to put on their straight jacket. It'd be very hard for program A to say that program B starts with privileges X, Y, Z, and then after instruction Q drops Y and Z. And program B might require more privileges than what A had when it called exec, so again it's just not going to work for this at all. If A's privileges were to persist, then it would have to have some way to elevate them or it'd never drop them in the first place. Both seem like a bad deal.
It's just a completely different mechanism, but people think sandbox sandbox sandbox and if that's all one can think of, pledge and unveil might seem like a terrible tool for that. They're not a tool for sandboxing untrusted programs.