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).