bug#45198: 28.0.50; Sandbox mode

[Philipp]

> Am 18.04.2021 um 16:25 schrieb Stefan Monnier <monnier@IRO.UMontreal.CA>:
> 
>>> 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).