GNU bug report logs - #45198
28.0.50; Sandbox mode

Previous Next

Full log

View this message in rfc822 format

From: Philipp <p.stephani2 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: alan <at> idiocy.org, Mattias Engdegård <mattiase <at> acm.org>, 45198 <at> debbugs.gnu.org, stefankangas <at> gmail.com, João Távora <joaotavora <at> gmail.com>, monnier <at> iro.umontreal.ca
Subject: bug#45198: 28.0.50; Sandbox mode
Date: Sat, 17 Apr 2021 21:52:59 +0200

> Am 17.04.2021 um 21:23 schrieb Eli Zaretskii <eliz <at> gnu.org>:
> 
>> From: Philipp Stephani <p.stephani2 <at> gmail.com>
>> Date: Sat, 17 Apr 2021 21:14:02 +0200
>> Cc: Mattias Engdegård <mattiase <at> acm.org>, 
>> 	João Távora <joaotavora <at> gmail.com>, 
>> 	45198 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>, 
>> 	Stefan Monnier <monnier <at> iro.umontreal.ca>, Alan Third <alan <at> idiocy.org>
>> 
>>> "Performing computations" in Emacs corresponds to invoking gobs of
>>> system interfaces, and if we are going to filter most of them, I fear
>>> we will get a dysfunctional Emacs.  E.g., cursor blinking requires
>>> accessing the system time, displaying a busy cursor requires interval
>>> timers, profiling requires signals, and you cannot do anything in
>>> Emacs without being able to allocate memory.  If we leave Emacs only
>>> with capabilities to read and write to a couple of descriptors, how
>>> will the result be useful?
>> 
>> We would definitely allow more stuff (e.g. some other syscalls are
>> required for Emacs to even start up). For example, Emacs needs to
>> allocate memory and thus needs mmap/sbrk. Timing functions are not
>> security-sensitive (timing attacks exist, but should be prevented in
>> this case by blocking any relevant use of the data such obtained), and
>> signals only affect the sandboxed Emacs process. The two big things we
>> need to prevent is writing arbitrary files and creating sockets.
> 
> 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.

> 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.  For example, an existing unit test verifies that the sandboxed Emacs process can write to standard output (and it has already failed a few times on various systems, which is expected and is how we can find new syscalls to add).  So we only need to remember to run the unit tests (and have good test coverage).

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

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

Previous Next

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