On 2020-09-22 10:58, Theo de Raadt wrote: >> I actually agree with this. Designing a program with pledge in >> mind is always better. However, that requires that the program be >> trusted, and there still may be some corner cases in which I can >> tighten down the pledge more than the program itself can. > > I disagree. I don't believe you can correctly produce security, because > the pledge operation puts the program into an unexpected non-POSIX > operational environment, and will introduce new potential error conditions > the program does not expect.
In my use-case, the program’s correct functionality is less important than ensuring that the program cannot break out. >> So I can sandbox ftp(1) more than ftp(1) can reasonably sandbox itself. > > I very strongly disagree. At best the pledge/unveil-wrapper will work in > a specific one-time configuration, and not be generalizable. Indeed it is not generalizable. > We do not want users to be experimenting with things they don't understand, > more precisely, things they cannot understand because this high-level pledge > command is changing big underlying conditions. > >> To be fair, one could argue that ftp(1) should have a command-line >> option that enables these lockdown options and disables the features >> unsupported under this mode. > > Disagree. This is not supposed to be user visible. That’s why I posted the lockdown patch to remove the exec pledge when it isn’t required. >> That isn't actually not the main use case for pledge(1), >> at least for me. The main use-case is to sandbox untrusted, >> potentially malicious executables. > > That is propostrous. > > You think it's a good idea to throw untrusted programs into an > environment they were not designed... Personally, I would prefer to run something like https://play.rust-lang.org under the hardened OpenBSD kernel than under Linux. However, without a way to sandbox these binaries, it can't be done. >> I do not know any way to >> implement something like the Rust Playground securely on OpenBSD >> without using execpromises, at least without requiring at least part >> of the application to run as root. With execpromises, sandboxing >> untrusted executables is trivial. That's what pledge(1) is for. > > No it is not trivial! You are running code in *NON-POSIX MODES*. I know. In my use-case, POSIX conformance is not necessary. Rust works just fine on Windows, for example. >> In my main use-case, I know what pledges I am willing to allow >> untrusted code to have. If it tries to do something that the >> sandbox doesn't allow, it *should* fail. I expect that some >> functionality *will* break. That's okay in my application. > > But you are wrong. There are non-terminating situations in unveil > and pledge, where a program which doesn't test for unexpected error > returns or specific errno's, as this is NOT A CORRECT POSIX ENVIRONEMT, > will go down a wrong path and do the wrong thing. In many cases, these are throwaway programs, often used to share snippets. In others, I would be fine with picking up the pieces myself if things break. What I am NOT fine with is having to run a web application as root, or give it access to doas(1). I am also not wedded to execpromises at all. If there is a better alternative, I would be more than happy to use it. I am just not aware of one. Sincerely, Demi
