GNU bug report logs - #45198
28.0.50; Sandbox mode

Previous Next

Full log

View this message in rfc822 format

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

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

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).
- This will need someone else doing the implementation.
- 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.
- 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'd like to have this yesterday in order to build the Info files of
  GNU&NonGNU ELPA packages from their .org documentation without having
  to store the Info in the Git branch nor having to maintain some LXC
  container just for that.


        Stefan

Previous Next

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