From mboxrd@z Thu Jan 1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Philipp Stephani
Newsgroups: gmane.emacs.bugs
Subject: bug#45198: 28.0.50; Sandbox mode
Date: Mon, 14 Dec 2020 12:05:09 +0100
Message-ID:
References:
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214";
logging-data="31535"; mail-complaints-to="usenet@ciao.gmane.io"
Cc: Bastien , 45198@debbugs.gnu.org,
=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=
To: Stefan Monnier
Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 14 12:06:27 2020
Return-path:
Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org
Original-Received: from lists.gnu.org ([209.51.188.17])
by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.92)
(envelope-from )
id 1kolgQ-00084m-CV
for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 14 Dec 2020 12:06:26 +0100
Original-Received: from localhost ([::1]:43688 helo=lists1p.gnu.org)
by lists.gnu.org with esmtp (Exim 4.90_1)
(envelope-from )
id 1kolgP-0007yt-Cp
for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 14 Dec 2020 06:06:25 -0500
Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51360)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from )
id 1kolg2-0007xm-EM
for bug-gnu-emacs@gnu.org; Mon, 14 Dec 2020 06:06:02 -0500
Original-Received: from debbugs.gnu.org ([209.51.188.43]:39831)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from )
id 1kolg2-0006gw-5T
for bug-gnu-emacs@gnu.org; Mon, 14 Dec 2020 06:06:02 -0500
Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2)
(envelope-from ) id 1kolg2-0008OR-1D
for bug-gnu-emacs@gnu.org; Mon, 14 Dec 2020 06:06:02 -0500
X-Loop: help-debbugs@gnu.org
Resent-From: Philipp Stephani
Original-Sender: "Debbugs-submit"
Resent-CC: bug-gnu-emacs@gnu.org
Resent-Date: Mon, 14 Dec 2020 11:06:01 +0000
Resent-Message-ID:
Resent-Sender: help-debbugs@gnu.org
X-GNU-PR-Message: followup 45198
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
Original-Received: via spool by 45198-submit@debbugs.gnu.org id=B45198.160794392832220
(code B ref 45198); Mon, 14 Dec 2020 11:06:01 +0000
Original-Received: (at 45198) by debbugs.gnu.org; 14 Dec 2020 11:05:28 +0000
Original-Received: from localhost ([127.0.0.1]:51377 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from )
id 1kolfT-0008Nc-Tl
for submit@debbugs.gnu.org; Mon, 14 Dec 2020 06:05:28 -0500
Original-Received: from mail-oi1-f170.google.com ([209.85.167.170]:42646)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from ) id 1kolfR-0008NP-W2
for 45198@debbugs.gnu.org; Mon, 14 Dec 2020 06:05:26 -0500
Original-Received: by mail-oi1-f170.google.com with SMTP id l200so18732901oig.9
for <45198@debbugs.gnu.org>; Mon, 14 Dec 2020 03:05:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=0UeIQSmyHCrfPbxPyKyCUMo/yT6Jplt4z6y+Ji8Bv5Y=;
b=kxUDZ3eI3ypRjUGdb84Iw6KM6PnCEwpUtIKlN8SA8YSPg1SbvwcdjwuqjS7P+PlJ9j
yaXNn3nTmRsNLSHQY/1B8TfR7uXonFa1Khw3MnBaEl+M057MCOZtQoP8GvNPFFHo+k9S
AAcvgjUjwWvC9x8o6pOtrAvcst/C1dpIxkrjyUyJhUGmHN95mOPXq3Fc5+Nbi99uHlnC
VtGHp55my4oKirtgaQ3j5GFmJzGsjiUnI9P/l31bwcxq7SeUa6NcTPLNx8I1F/HW+KFP
RX3yLFWC4AqkwBKJTXrmMhelwx6PbU8bsIl0ZKQ/GYrQelsYNbM391CurOH956Wl5QwQ
h6fQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=0UeIQSmyHCrfPbxPyKyCUMo/yT6Jplt4z6y+Ji8Bv5Y=;
b=sTF9cfTCxlpq976+9kHXTz6tAQoY7FNytx1sZU+w02OkH1RkQicgcsFZFAIGulxNvt
zchEQiE2vImNhEKRigh5JEjACFVjwyd77Eg9Z7lsjM3pEJyYiwJJBZp8RQXHvCaDpuZP
k6cuZstPdK6LQWA/BIY5Wy4d9AmOGzudMpWAO5rUgomrUBQaq8xfYwOeeHi1YVEM9/b7
pE38I9IV+DUxjqZusiCceuOnfeySjvRVHVBQCNkLmN99fBuQtMmtSYf2P3tvOWJKIIdo
zPkaUCTNE5PKRLvWWhKFNeOUSzRStHlA4WakKCqX4Al9tGtdB7S/is/Xqm8fHLeFPvBw
KBLw==
X-Gm-Message-State: AOAM531vauqIeKsoPqyWlwAPrIJEOp8k+gWd13L0nE6ldZKdx/N/G3Mg
qCBxDMpwZrA8lw9vu6nn+g7N2U9gZRAaV1T+eRU=
X-Google-Smtp-Source: ABdhPJyZcpuph/6k3Ty2LjKLFYtAU6xRpWrmdPAbuxDmwQWRDNf+WZFyLK9FpM/NlEmbWb9iSi9wSkvxTVgnJdKq/oc=
X-Received: by 2002:aca:3a02:: with SMTP id h2mr17041529oia.65.1607943920185;
Mon, 14 Dec 2020 03:05:20 -0800 (PST)
In-Reply-To:
X-BeenThere: debbugs-submit@debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
X-BeenThere: bug-gnu-emacs@gnu.org
List-Id: "Bug reports for GNU Emacs,
the Swiss army knife of text editors"
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org
Original-Sender: "bug-gnu-emacs"
Xref: news.gmane.io gmane.emacs.bugs:196039
Archived-At:
Am So., 13. Dez. 2020 um 19:43 Uhr schrieb Stefan Monnier
:
>
> > The sandboxing technologies I'm aware of are process-based (because
> > Linux namespaces and kernel syscall filters are per-process), so a
> > "start sandbox from here" function likely can't be implemented. The
> > interface should rather be something like
> >
> > (defun run-in-sandbox (form)
> > (eql 0 (call-process "bwrap" ... "emacs" "--quick" "--batch" (format
> > "--eval=%S" form))))
> >
> > (Maybe with some async variant and the opportunity to return some
> > result, like emacs-async.)
>
> Thanks. We definitely want some output, otherwise there's no point in
> running `form`, right?
In some way certainly, but it's not necessarily through stdout. I tend
to write potential output into a file whose filename is passed on the
command line. That's more robust than stdout (which often contains
spurious messages about loading files etc.).
>
> Also, I think the async option is the most important one. How 'bout:
>
> (sandbox-start FUNCTION)
>
> Lunch a sandboxed Emacs subprocess running FUNCTION.
Passing a function here might be confusing because e.g. lexical
closures won't work. It might be preferable to pass a form and state
that both dynamic and lexical bindings are ignored.
> Returns a process object.
Depending how much we care about forward compatibility, it might be
better to return an opaque sandbox object (which will initially wrap a
process object).
> FUNCTION is called with no arguments and it can use `sandbox-read`
> to read the data sent to the process object via `process-send-string`,
> and `sandbox-reply` to send back a reply to the parent process
> (which will receive it via its `process-filter`).
That is, sandbox-read and sandbox-reply just read/write stdin/stdout?
That would certainly work, but (a) it doesn't really have anything to
do with sandboxing, so these functions should rather be called
stdin-read and stdout-write or similar, and (b) especially in the
stdout case might be too brittle because Emacs likes to print
arbitrary stuff on stdout/stderr.
Alternatively, the sandbox could use dedicated files or pipes to communicate.
> The sandboxed process has read access to all the local files
> but no write access to them, nor any access to the network or
> the display.
This might be a bit too specific. I'd imagine we'd want to restrict
reading files to the absolute minimum (files that Emacs itself needs
plus a fixed set of input files/directories known in advance), but
often allow writing some output files.
>
> WDYT?
I think the interface is mostly OK, but I think we want to restrict
the set of allowed input/output files.
>
> >> - I suspect we'll still want to use the extra "manual" checks I put in
> >> my code (so as to get clean ELisp errors when bumping against the
> >> walls of the sandbox, and because of the added in-depth security).
> > That's reasonable, though I'm worried that it will give users a false
> > sense of security.
>
> That would only be the case if we don't additionally use process-level
> isolation, right?
My worry is that people see a function like enter-sandbox and then
assume that Emacs will be secure after calling it, without actually
verifying the security implications.
>
> >> - This will need someone else doing the implementation.
> > Looks like we already have a volunteer for macOS.
> > For Linux, this shouldn't be that difficult either. The sandbox needs
> > to install a mount namespace that only allows read access to Emacs's
> > installation directory plus any input file and write access to known
> > output files, and enable syscall filters that forbid everything except
> > a list of known-safe syscalls (especially exec). I can take a stab at
> > that, but I can't promise anything ;-)
>
> Looking forward to it.
>
I've looked into this, and what I'd suggest for now is:
1. Add a --seccomp=FILE command-line option that loads seccomp filters
from FILE and applies them directly after startup (first thing in
main). Why do this in Emacs? Because that's the easiest way to prevent
execve. When installing a seccomp filter in a separate process, execve
needs to be allowed because otherwise there'd be no way to execute the
Emacs binary. While there are workarounds (ptrace, LD_PRELOAD), it's
easiest to install the seccomp filter directly in the Emacs process.
2. Generate appropriate seccomp filters using libseccomp or similar.
3. In the sandboxing functions, start Emacs with bwrap to set up
namespaces and invoke Emacs with the new --seccomp flag.