GNU bug report logs - #45198
28.0.50; Sandbox mode

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: alan <at> idiocy.org, mattiase <at> acm.org, 45198 <at> debbugs.gnu.org, stefankangas <at> gmail.com, joaotavora <at> gmail.com, monnier <at> iro.umontreal.ca
Subject: bug#45198: 28.0.50; Sandbox mode
Date: Sat, 17 Apr 2021 22:23:26 +0300

> 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?
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?  And what about users who make local changes
in their 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.

Previous Next

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