Hi Demi, Demi M. Obenour wrote on Mon, Sep 21, 2020 at 12:51:34PM -0400:
> The tool makes essential use of the execpromises argument > to pledge(2), so that it can sandbox the program it executes. This appears to conflict with the basic idea of pledge(2), which is for the *programmer* to first do simple preparatory work that requires full syscall access, then pledge(2) according to a precise understanding of what the program is supposed to do during normal operation. Usually, it is not possible to properly pledge(2) a program without designing it for pledge(2), sometimes called "hoisting". As a corollary, pledging a program from the outside, without changing the code that is compiled, usually does not provide significant benefit. > While I understand that this argument is slated for removal, > pledge(1) would not be possible without it. Exactly, so this is not likely to go anywhere. > pledge(1) is mainly intended for when the program being sandboxed > is either potentially malicious, Even in such cases, pledge(2) needs to be called from *within* the program. And that is what porters actually do. Two examples of programs that are very obviously malicious are firefox and chromium. Still, both call pledge(2) from within. > If there is interest, I would > also like to turn pledge(1) into a proper OpenBSD package at some > point, so that it can be installed using pkg_add(1). That might (potentially) meet resistance from porters because it might stand in the way of deleting the execpromises feature when the time comes. Yours, Ingo
