David Uhden Collado <[email protected]> wrote: > 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.
I don't care about your concerns. > 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. That is being deleted in the next day or so.. > Rather than removing it entirely, could we retain it for explicitly > controlled execution paths, with clearer documentation of its > limitations? No.
