Subject: Re: bug#45198: 28.0.50; Sandbox mode

From: Philipp <[email-masked]>
Date: Mon, 5 Jul 2021 21:12:39 +0200

> Am 18.04.2021 um 16:25 schrieb Stefan Monnier <[email-masked]>:
> 
>>> The whole point of the sandboxing exercise is so as to be able to have
>>> flymake-mode in the hook without exposing yourself to
>>> these vulnerabilities.
>> 
>> So we are going to introduce all this non-trivial machinery into Emacs
>> just to solve the Flymake use case?  Is that reasonable from the
>> project management POV, in your eyes?
> 
> To the extent that this machinery will only be used by those rare places
> that need it (e.g. flymake), yes, as long as the low-level interface
> (e.g. the code that added the support for the `--seccomp` argument) is
> simple enough.
> 
> BTW, in the context of GNU/Linux, an alternative to `--seccomp` is to
> require the `bwrap` tool (that's what I use in the `elpa-admin.el`
> scripts to run makefile rules from ELPA packages).
> 

I wouldn't call it an alternative, they are rather complementary approaches, and I think we should require both for a sandbox that we consider "hard enough".  The --seccomp flag doesn't set up namespaces; that's rather subtle and best done out-of-process by a dedicated tool like bwrap.  On the other hand, setting up a seccomp filter out-of-process has the disadvantage that it needs to allow execve, thereby increasing the attack surface quite a bit.  The sandboxing I'd have in mind would be a combination of bwrap (with namespaces and a seccomp filter that allows execve) and Emacs's own seccomp filter (banning execve).