>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. >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. 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 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... But I argue the behavioral changes (especially relating the unveil not seeing files, or the subtle behaviour of pledge around "stat", or lockeds objects being left lingering when the program terminates unexpected, are *USER HOSTILE*, and we don't want to help people using this excessively sharp tool cutting their hands off and coming to misc@ to tell us long stories which summarize to "I am using pledge wrong and I don't understand the failure modes" >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*. >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. That is the opposite of sandboxing.
