David Uhden Collado <daviduhden@gmail.com> wrote: > 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. This actually is the best example of them all. execpromises is only used in one program in base. I struggled to find one. It barely works. And what lesson did you take from it? You consider using this feature in the largest piece of software. You are out of your mind.
Friday, October 16, 2026
Re: [IMPROVEMENT] Add native sandbox support to devel/codex
Theo de Raadt wrote: >> 2. The helper translates the profile into unveil(2) filesystem >> restrictions and pledge(2) syscall restrictions, locks the unveil >> configuration, and executes the requested program. > > Upon execve, unveil and pledge are disabled. > > atomic_clearbits_int(&pr->ps_flags, PS_PLEDGE); > p->p_pledge = 0; > pr->ps_pledge = 0; > /* Clear our unveil paths out so the child starts afresh */ > unveil_destroy(pr); > pr->ps_uvdone = 0; > } > > pledge execpromises do continue, but I'm probably going to delete > that subsystem soon because the only way to use it is with "error", > and the errors introduced into unready programs are a bizzare non-POSIX > enviroment, meaning these errors produce fractal error cascade. I > am 99% sure I am going to disable or delete execpromises. > > > > unveil and pledge are not "sandbox technologies". > > You did not test. My concern is that removing execpromises would eliminate the existing mechanism for carrying pledge restrictions across execve(), including legitimate cases where the executed program's behavior is known and controlled. ldd(1) already demonstrates such a use case. I realize it is a special case, but it establishes that the mechanism can be useful when applied carefully. Rather than removing it entirely, could we retain it for explicitly controlled execution paths, with clearer documentation of its limitations?
Subscribe to:
Posts (Atom)