bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#45198: 28.0.50; Sandbox mode


From: Eli Zaretskii
Subject: bug#45198: 28.0.50; Sandbox mode
Date: Sat, 17 Apr 2021 22:23:26 +0300

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sat, 17 Apr 2021 21:14:02 +0200
> Cc: Mattias Engdegård <mattiase@acm.org>, 
>       João Távora <joaotavora@gmail.com>, 
>       45198@debbugs.gnu.org, Stefan Kangas <stefankangas@gmail.com>, 
>       Stefan Monnier <monnier@iro.umontreal.ca>, Alan Third <alan@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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]