GNU bug report logs - #45198
28.0.50; Sandbox mode

Previous Next

Full log

Message #38 received at 45198 <at> debbugs.gnu.org (full text, mbox):

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Bastien <bzg <at> gnu.org>, 45198 <at> debbugs.gnu.org,
 João Távora <joaotavora <at> gmail.com>
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Date: Sun, 13 Dec 2020 19:13:35 +0100

Am So., 13. Dez. 2020 um 18:57 Uhr schrieb Stefan Monnier
<monnier <at> iro.umontreal.ca>:
>
> > I don't think such an approach can work. It assumes perfect knowledge
> > about anything that might be problematic, and also assumes that all
> > future changes to Emacs take the sandbox question into account.
> > Especially the latter point seems unrealistic, and this looks like a
> > security incident waiting to happen.
>
> That's true for the implementation side.
> How 'bout the ELisp API side?
>
> > Sandboxing is good, but it should happen using an allowlist and
> > established technology, such as firejail/bubblewrap/Google sandboxed
> > API/...

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.)

>
> I'm all for it, *but*:
> - 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.

> - 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 ;-)

> - The ELisp-level API should not depend on the specific implementation
>   too much, since none of those established technologies sound like
>   things that'll still be maintained 10 years from now.

Yes, I'd imagine the API to be something like

;; Returns an opaque "sandbox" object.
(cl-defun start-sandbox (form &key input-files output-files) ...)
(defun wait-for-sandbox (sandbox) ...)
That would allow for some extensibility and also asynchronicity. The
API should fail if it can't establish a sandbox (e.g. if none of the
sandbox technologies are installed).

> - We need to have this in Emacs-28 if we want to enable flymake-mode in
>   ELisp by default in Emacs-28 (which I sure would like to do).

I guess having it in Emacs 28 is realistic, unless that is going to be
feature-frozen soon.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.