bug#45198: 28.0.50; Sandbox mode

[Philipp Stephani <p.stephani2@gmail.com>]

Am Mo., 14. Dez. 2020 um 12:12 Uhr schrieb Mattias Engdegård <mattiase@acm.org>:
>
> > The sandboxing technologies I'm aware of are process-based (because Linux namespaces and kernel syscall filters are per-process), so a "start sandbox from here" function likely can't be implemented. The interface should rather be something like
>
> If you mean that the sandbox needs to be active from the very start of the process, I don't see why that has to be the case. It does not appear to be necessary for macOS, OpenBSD or FreeBSD, nor for at least some the Linux options I'm aware of.

Yes, it's not strictly required (as in, seccomp and unshare nominally
work at any point), though I think enabling sandboxing while user code
has already run can have confusing/unanticipated consequences. For
example, other threads might already be running in parallel, and they
would then suddenly be blocked from making some syscalls, potentially
in the middle of a critical section or similar. I'd expect that
there's lots of code around that doesn't expect syscalls to suddenly
start failing. Other sandboxing technologies like unsharing the user
namespace also don't work in multithreaded processes. Allowing
sandboxing (at least for now) only at process startup avoids such
issues and should be good enough for the given use case (Flymake
background compilation), since we need to start a new process anyway.

>
> Perhaps I misunderstood, and there may indeed be some desirable sandboxing methods that require from-exec sandboxing. It is often useful to allow for a set-up period prior to activating restrictions allowing for specific files to be opened and so on and can make the sandboxing itself simpler by being less selective.

That is true, though it would require more significant changes to
Emacs. For example, to achieve some amount of capability-based
security, you'd open files before sandboxing and then forbid the open
syscall, but that's not really possible with the current Emacs API
(which doesn't provide any access to open files).

>
> From-exec sandboxing also precludes using simple forking (without exec) as a cheap way to start the Emacs subprocess (if somewhat Unix-specific).
>

Even on Unix, a fork that's not immediately followed by an exec or
exit tends to not work any more. Lots of libraries nowadays assume
that the "weird in-between state" after a fork doesn't exist
permanently, and only a small number of async-signal-safe syscalls are
guaranteed to work between fork and exec.