Theo de Raadt wrote:
I have not seen *ANY SAFE WAY TO USE THIS* with execpromises:
error Rather than killing the process upon violation, indicate
error with ENOSYS.
Also when pledge() is called with higher promises or
execpromises, those changes will be ignored and return
success. This is useful when a parent enforces
execpromises but an execve'd child has a different idea.
The combination is trash. It is a serious delusion that arbitrary
programs will fail cleanly. What actually happens is the invariant
failures become attack surface.
I agree that returning ENOSYS for arbitrary pledge violations can break
program invariants and introduce attack surface. I am not arguing that
the "error" promise is safe for arbitrary programs.
However, I think this is an argument against "error" and its interaction
with execpromises, rather than necessarily against execpromises itself.
For example, ldd uses:
pledge("stdio rpath exec", "stdio rpath");
It does not use "error". Violations terminate the process instead of
allowing execution to continue with potentially broken invariants.
Would it be reasonable to remove or restrict "error" while retaining
fail-closed execpromises for carefully controlled execution paths?
