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.