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?
No comments:
Post a Comment