bug#45198: 28.0.50; Sandbox mode

[Eli Zaretskii]

> From: Philipp <p.stephani2@gmail.com>
> Date: Sat, 17 Apr 2021 21:52:59 +0200
> Cc: Mattias Engdegård <mattiase@acm.org>,
>  João Távora <joaotavora@gmail.com>,
>  45198@debbugs.gnu.org,
>  stefankangas@gmail.com,
>  monnier@iro.umontreal.ca,
>  alan@idiocy.org
> 
> > So you are going to suggest that we rely on some auditing of the
> > syscalls Emacs uses now to decide which ones to filter and which not?
> 
> I don't mean that we should wade through all potential syscalls that Emacs 
> could make.  Typically you can come up with such a Seccomp policy 
> iteratively: run Seccomp in advisory mode (i.e. only log syscalls), then 
> allow the syscalls that are both necessary and harmless in the policy.

Emacs can be invoked to do many different things, and will
correspondingly present very different profiles of syscalls.  Is the
procedure you envision practical, let alone seamless, given that it
will have to become part of the maintenance and the release process?

> > If so, how will this work in the future, when Emacs might decide to
> > issue some additional syscalls? who and how will remember to update
> > the filter definitions?
> 
> There are unit tests that ensure that the behavior we expect works.

Unit tests are a far cry from what Emacs does in real-life usage, so I
very much doubt that unit tests will suffice in this case.

> >  And what about users who make local changes
> > in their Emacs?
> 
> They can provide their own Seccomp policies or modify the ones included in 
> Emacs.

What does providing a policy entail? can you describe the procedure of
tailoring a policy to changes in the Emacs code?

> >> At least initially we should only care about batch mode, though -
> >> nothing prevents interactive mode in a sandbox in principle, but batch
> >> mode is much easier to deal with, and suffices for the Flymake use
> >> case.
> > 
> > I understand why batch mode might be easier to deal with, but I'm not
> > sure we should care more about it just because it's easier.
> 
> We care about it in the scope of the feature being discussed (Flymake) 
> because Flymake runs Emacs in batch mode anyway.

So we will make running Flymake safe, but what about all the other use
cases where similar dangers exist?  Flymake is just a tiny fraction of
what Emacs does, so it sounds strange, to say the least, to work on
solution for that use case alone, when it is clear from the get-go
that many other use cases aren't covered.