GNU bug report logs - #45198
28.0.50; Sandbox mode

Previous Next

Full log

Message #20 received at 45198 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: bzg <at> gnu.org, Eli Zaretskii <eliz <at> gnu.org>, 45198 <at> debbugs.gnu.org
Subject: Re: bug#45198: 28.0.50; Sandbox mode
Date: Sun, 13 Dec 2020 11:14:53 +0000

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> > You cannot usefully call error from redisplay.
>>> Hmm... but this is at the entrance to redisplay, so I though it should
>>> still be safe at that point.  If it's a problem we can replace the above
>>> with
>>>     if (emacs_is_sandboxed)
>>>       return;
>> Yes, I think this is what we should do in this case.
>
> With the change I just installed into `master`, I can now get
> `elisp-flymake-byte-compile` to use sandboxing successfully with the
> revised patch below.

Fantastic!

> Besides the above change, I made the same change in `Fdo_auto_save`
> (i.e. `do-auto-save` was made to just silently do nothing instead of
> signaling an error since it seemed to be too much trouble to change its
> callers to avoid calling it when sandboxed).
>
> I'm still worried that there remain wide open security holes, tho.

First, I wouldn't worry that terribly.  This is certainly and
improvement.  I won't be bitten again like that time I accidentally
typed (delete-directory ".") at macroexpand time.

That said, as you said the whitelisting approach is the safest one.
It'd be nice if you we a way to identify system calls and block all by
default.  Then whitelist a bunch of calls (checking arguments).  Not
sure if this can be done portably/systematically, though.  Chroot also
comes to mind, but it's only for linux, right?

João

Previous Next

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