bug#45198: 28.0.50; Sandbox mode

[Stefan Monnier <monnier@iro.umontreal.ca>]

> 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
>
> (defun run-in-sandbox (form)
>   (eql 0 (call-process "bwrap" ... "emacs" "--quick" "--batch" (format
> "--eval=%S" form))))
>
> (Maybe with some async variant and the opportunity to return some
> result, like emacs-async.)

Thanks.  We definitely want some output, otherwise there's no point in
running `form`, right?

Also, I think the async option is the most important one.  How 'bout:

    (sandbox-start FUNCTION)

    Lunch a sandboxed Emacs subprocess running FUNCTION.
    Returns a process object.
    FUNCTION is called with no arguments and it can use `sandbox-read`
    to read the data sent to the process object via `process-send-string`,
    and `sandbox-reply` to send back a reply to the parent process
    (which will receive it via its `process-filter`).
    The sandboxed process has read access to all the local files
    but no write access to them, nor any access to the network or
    the display.

WDYT?

>> - I suspect we'll still want to use the extra "manual" checks I put in
>>   my code (so as to get clean ELisp errors when bumping against the
>>   walls of the sandbox, and because of the added in-depth security).
> That's reasonable, though I'm worried that it will give users a false
> sense of security.

That would only be the case if we don't additionally use process-level
isolation, right?

>> - This will need someone else doing the implementation.
> Looks like we already have a volunteer for macOS.
> For Linux, this shouldn't be that difficult either. The sandbox needs
> to install a mount namespace that only allows read access to Emacs's
> installation directory plus any input file and write access to known
> output files, and enable syscall filters that forbid everything except
> a list of known-safe syscalls (especially exec). I can take a stab at
> that, but I can't promise anything ;-)

Looking forward to it.


        Stefan