GNU bug report logs - #45198
28.0.50; Sandbox mode

Previous Next

Full log

View this message in rfc822 format

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

Am Sa., 17. Apr. 2021 um 18:15 Uhr schrieb Eli Zaretskii <eliz <at> gnu.org>:
>
> > From: Philipp <p.stephani2 <at> gmail.com>
> > Date: Sat, 17 Apr 2021 18:10:14 +0200
> > Cc: mattiase <at> acm.org,
> >  joaotavora <at> gmail.com,
> >  45198 <at> debbugs.gnu.org,
> >  stefankangas <at> gmail.com,
> >  monnier <at> iro.umontreal.ca,
> >  alan <at> idiocy.org
> >
> > > IMO, if we have no reasonably clear idea how this will be used on the
> > > high level,
> >
> > I have a relatively clear idea how I want the high-level interface to look like:
> >
> > (cl-defun start-sandbox (function &key readable-directories stdout-buffer) ...)
> > (defun wait-for-sandbox (sandbox) ...)
> >
> > where start-sandbox returns an opaque sandbox object running FUNCTION that wait-for-sandbox can wait for.  That should be generic enough that it's extensible and implementable on several platforms, and doesn't lock us into specific implementation choices.
> >
> > If that's OK with everyone, then I'm happy to write the code for it.
>
> I'm sorry, but I don't really understand what the above means in
> practice.
>
> What I'm missing is some details about what operations (in Emacs
> terms) should not be allowed in the sandbox, and how can users take
> advantage of that.  I asked more questions about this a few days ago,
> but got no responses.  I don't really understand how we can
> intelligently talk about using this in Emacs while we remain on the
> level of file descriptors and syscalls.

That's a fair statement, and I'll try to answer here (and hopefully
later in the other thread as well). The sandbox should be able to
perform operations that are in some sense not security-relevant:
mostly performing computations, reading some necessary files, and
writing some diagnostics to standard output. The initial use case can
be running byte compilation in a Flymake backend. This would allow us
to enable Flymake byte compilation support by default, even on
untrusted code, because due to the sandbox that code could never
perform harmful operations. The Flymake backend would then use the
high-level sandbox functions to asynchronously start byte compilation
in a sandbox. The start-sandbox function in turn would launch an Emacs
subprocess using bwrap or similar to set up appropriate mount
namespaces and apply a Seccomp filter (in the GNU/Linux case).

Previous Next

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