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: Sat, 17 Apr 2021 18:20:15 +0200 Message-ID: References: <5818DFAA-3A9C-4335-BAAF-1227A02C290A@acm.org> <19511709-E42B-4ABD-9823-39EA08A79B1F@gmail.com> <83v98kvr7y.fsf@gnu.org> <9A5BCDF3-6543-46C0-AB56-2311392FC549@gmail.com> <83tuo4vqet.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29320"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Alan Third , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , 45198@debbugs.gnu.org, Stefan Kangas , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , Stefan Monnier To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 17 18:21:48 2021 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 1lXnhc-0007X1-BX for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 17 Apr 2021 18:21:48 +0200 Original-Received: from localhost ([::1]:38668 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lXnhb-00048L-Bo for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 17 Apr 2021 12:21:47 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54248) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lXngs-0003t4-Oe for bug-gnu-emacs@gnu.org; Sat, 17 Apr 2021 12:21:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:60912) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lXngs-000549-43 for bug-gnu-emacs@gnu.org; Sat, 17 Apr 2021 12:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lXngr-0004NO-W2 for bug-gnu-emacs@gnu.org; Sat, 17 Apr 2021 12:21:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 Apr 2021 16:21: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.161867643516776 (code B ref 45198); Sat, 17 Apr 2021 16:21:01 +0000 Original-Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 16:20:35 +0000 Original-Received: from localhost ([127.0.0.1]:44225 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXngQ-0004MV-Ls for submit@debbugs.gnu.org; Sat, 17 Apr 2021 12:20:34 -0400 Original-Received: from mail-oo1-f43.google.com ([209.85.161.43]:35750) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lXngO-0004MI-AN for 45198@debbugs.gnu.org; Sat, 17 Apr 2021 12:20:33 -0400 Original-Received: by mail-oo1-f43.google.com with SMTP id i20-20020a4a8d940000b02901bc71746525so6804618ook.2 for <45198@debbugs.gnu.org>; Sat, 17 Apr 2021 09:20:32 -0700 (PDT) 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:content-transfer-encoding; bh=95ERRKeJdZdRu4SQoVtuuzPA+A10dOVHsIlSu813uNQ=; b=Br1f1q3mEt0qPl8+bvfxJD+HcYtVkpyQXFOwEc36Nqu6eB2LHg/Brw1Kr0RCViUw1g ztn2zAyiN5RffpNAUntb4w7eXZi3eUHXZdr4s/mUy3vx49w7wrdBpNyb0qy6lrVmDr22 Kjiap1kOR0gjnSMYxRCzfun3WoqdLtoQhyefZbaTLHK1lspc4UZItN0iL7s4LDBDU7VB hoGeH0GLeAMwEjWBEpJisnmynIsARf4xUGO37+P/9rWWXOuwe6gRX37DJP2smR1A4TvF vIJuBCowubU2zs/Och94OMY2EekLQOgIrgQiy3TXShcIcXfxXKGmWNLYN0KcbM+yK4hb DJcg== 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:content-transfer-encoding; bh=95ERRKeJdZdRu4SQoVtuuzPA+A10dOVHsIlSu813uNQ=; b=JDeFboXXIKB5AAPkpe6NxBKxaiEZ69XTDbhkQkFL5XKgHbaAEvxWDsEDoiXgN3xx3W p790xtXI81ujhUKZmEomXCQW/qXIWVB9ZXdM83Ujmxiow0bxEis0P6E2hJWHlCjwjbJJ NcuvmlbC8BlU7TCWUKoIiNc9Ezu5NUS2zWRKnzAXJSaHEb5ugzzFGjZO1d2arzcIjx81 Ll7eiFbTfVk/SjbjeTgg6lgWTmQJMIgd/2+XWWm+wzbsJnTmMX80iLpHhKaBN8OmGynL Jotv9EecsX4Ty5YMS0RsToZSy4RnMmt68zhPvETHojmjkDKtjQaZGJCNtComMiylrvDK p4RQ== X-Gm-Message-State: AOAM532uYOO4Eg/CrAeFxhRYdJcXMUHKjLN3JdgWNd5whxxuYqGOVdLx Go3U9c7gNbtRCDeYl4+N0BlWN/Q20e1fd8TY6iI= X-Google-Smtp-Source: ABdhPJwbKsM7xol3fwnphHsNj5Bvs4Fs8pi8p6n+sL3/dAKvLSEdlZh1q12p7dkS34YyfLygkZAKl7aUCf8Ky0/+njA= X-Received: by 2002:a4a:4f53:: with SMTP id c80mr1396067oob.45.1618676426702; Sat, 17 Apr 2021 09:20:26 -0700 (PDT) In-Reply-To: <83tuo4vqet.fsf@gnu.org> 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:204225 Archived-At: Am Sa., 17. Apr. 2021 um 18:15 Uhr schrieb Eli Zaretskii : > > > From: Philipp > > Date: Sat, 17 Apr 2021 18:10:14 +0200 > > Cc: mattiase@acm.org, > > joaotavora@gmail.com, > > 45198@debbugs.gnu.org, > > stefankangas@gmail.com, > > monnier@iro.umontreal.ca, > > alan@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 l= ook like: > > > > (cl-defun start-sandbox (function &key readable-directories stdout-buff= er) ...) > > (defun wait-for-sandbox (sandbox) ...) > > > > where start-sandbox returns an opaque sandbox object running FUNCTION t= hat 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 int= o 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).