On 2020-09-22 09:58, Ingo Schwarze wrote: > 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.
I generally agree with you. I do believe that there are a few exceptions, however, as I wrote in my reply to de Raadt. >> 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. My primary use-case is that I would like to port a Linux web app (the Rust Playground) to OpenBSD. The Rust Playground allows users to supply arbitrary source code, which is then compiled and executed. I have no control over the contents of said code, so I have no way to ensure that these programs will call pledge(2) themselves. Calling pledge(2) externally allows me to sandbox the untrusted binaries. >> 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. To be clear, I am only using execpromises because it is the only way I know of to solve my problem under OpenBSD. If there is a better replacement for execpromises, I will happily migrate to using it, but right now, I am not aware of any. Running each untrusted process under a separate user account requires at least part of the web application to run as root, which isn’t desirable. Using execpromises allows the web application to run as an unprivileged user. > Yours, > Ingo Sincerely, Demi
