From mboxrd@z Thu Jan 1 00:00:00 1970
Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail
From: Philipp
Newsgroups: gmane.emacs.bugs
Subject: bug#45198: 28.0.50; Sandbox mode
Date: Sat, 17 Apr 2021 21:52:59 +0200
Message-ID: <8491CEA9-E230-48E4-9AB3-71DF0B4D8A2B@gmail.com>
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>
<83r1j8vpku.fsf@gnu.org>
<83fszovhox.fsf@gnu.org>
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
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="5707"; mail-complaints-to="usenet@ciao.gmane.io"
Cc: alan@idiocy.org, Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= ,
45198@debbugs.gnu.org, stefankangas@gmail.com,
=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= ,
monnier@iro.umontreal.ca
To: Eli Zaretskii
Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Apr 17 21:54:22 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 1lXr1J-0001OD-RR
for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 17 Apr 2021 21:54:21 +0200
Original-Received: from localhost ([::1]:58034 helo=lists1p.gnu.org)
by lists.gnu.org with esmtp (Exim 4.90_1)
(envelope-from )
id 1lXr1I-0001cD-Mi
for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 17 Apr 2021 15:54:20 -0400
Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41124)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from )
id 1lXr12-0001bv-3I
for bug-gnu-emacs@gnu.org; Sat, 17 Apr 2021 15:54:04 -0400
Original-Received: from debbugs.gnu.org ([209.51.188.43]:33158)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from )
id 1lXr10-0006n3-78
for bug-gnu-emacs@gnu.org; Sat, 17 Apr 2021 15:54:02 -0400
Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2)
(envelope-from ) id 1lXr10-0001Qf-6E
for bug-gnu-emacs@gnu.org; Sat, 17 Apr 2021 15:54:02 -0400
X-Loop: help-debbugs@gnu.org
Resent-From: Philipp
Original-Sender: "Debbugs-submit"
Resent-CC: bug-gnu-emacs@gnu.org
Resent-Date: Sat, 17 Apr 2021 19:54:02 +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.16186891895435
(code B ref 45198); Sat, 17 Apr 2021 19:54:02 +0000
Original-Received: (at 45198) by debbugs.gnu.org; 17 Apr 2021 19:53:09 +0000
Original-Received: from localhost ([127.0.0.1]:44704 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from )
id 1lXr09-0001Pb-Aw
for submit@debbugs.gnu.org; Sat, 17 Apr 2021 15:53:09 -0400
Original-Received: from mail-ed1-f50.google.com ([209.85.208.50]:39731)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from ) id 1lXr07-0001PB-4c
for 45198@debbugs.gnu.org; Sat, 17 Apr 2021 15:53:07 -0400
Original-Received: by mail-ed1-f50.google.com with SMTP id g17so35454082edm.6
for <45198@debbugs.gnu.org>; Sat, 17 Apr 2021 12:53:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=ehCvAHzswN4dSh+lj3ESMjjurqy/kyAOScBpDQB2UIs=;
b=mCF5EoLL20Y7HT/NIHGLdwGJmWmeugWc63fMIIqWsf3kJ3h22TMVDEOabE76Dk2uBp
X0t1EhYtK7siPULAS91K/IoOnv9ewgF4rWwgALN1cCURBF9YGFJa/8bg5e5a6PoADQ04
ccLw958NzfsoWWhSaccztkWYZZTun9rS4pklFr+pTbFEhE8MoNE9Fpju8VT4vKGtYIQK
Fu1gOUp6ImRPP6D1341VMCXTQfB2GTWnnkWvjT+f0ueNVDnWHo8C5dECZXkXqD9ixqNk
h+qJb2/VtYNXIUBOE0pKLXmhgv1dp0EPPUXonwTinVPJBpQK9CY5wOueQFLdXAoDxGZ9
GU3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=ehCvAHzswN4dSh+lj3ESMjjurqy/kyAOScBpDQB2UIs=;
b=ct2ztXBshI87yhmcBu5n1F1+vjc1ChYeJm741uuDJym/Ds6V0aIHfosEw2i/fqZm+z
LOcnhZBNEJPK8gCNClvuGzZ78xrYeQ4vEKQeIuHU9mBjm5Fz46fTCTBbTrLrAAhnyASS
r9vvK3HhGNOJLFYPjKX8F/oOscePbhVS3RhR82osCbkdCG55H0VhH27Clsuwv69lddC+
1ey54ImZKopDeSCWBkwZS5tz7C9/Qwjc7lzep9hSKHH+4onj/8c9xjxfAM72KLaASjrv
0u1+iDbWtOUHDGoRr6avWX5L2/MS+zrFV9WQyty8gknUqwvWhRdDhQl4OkTZpra4elCG
R4ww==
X-Gm-Message-State: AOAM532tBf3LS3buEbiJhKoyaR0L7ynbdYyYsv32zF2Dx8GAeEQVbYXe
ZTP2uGGwQ6xoZ7mdqUJ2se0=
X-Google-Smtp-Source: ABdhPJweuaiuwMxDS5YAkJqVVzQ5qqhWR6hrbxhku98V5b22Fjd7XY4pc0CdziCVk2EUT5CAF8RBaQ==
X-Received: by 2002:aa7:c850:: with SMTP id g16mr16813797edt.324.1618689181312;
Sat, 17 Apr 2021 12:53:01 -0700 (PDT)
Original-Received: from philipps-macbook-pro.fritz.box (p57aafcaa.dip0.t-ipconnect.de.
[87.170.252.170])
by smtp.gmail.com with ESMTPSA id nd36sm6739304ejc.21.2021.04.17.12.52.59
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Sat, 17 Apr 2021 12:53:00 -0700 (PDT)
In-Reply-To: <83fszovhox.fsf@gnu.org>
X-Mailer: Apple Mail (2.3654.60.0.2.21)
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:204262
Archived-At:
> Am 17.04.2021 um 21:23 schrieb Eli Zaretskii :
>=20
>> From: Philipp Stephani
>> Date: Sat, 17 Apr 2021 21:14:02 +0200
>> Cc: Mattias Engdeg=C3=A5rd ,=20
>> Jo=C3=A3o T=C3=A1vora ,=20
>> 45198@debbugs.gnu.org, Stefan Kangas ,=20=
>> Stefan Monnier , Alan Third =
>>=20
>>> "Performing computations" in Emacs corresponds to invoking gobs of
>>> system interfaces, and if we are going to filter most of them, I =
fear
>>> we will get a dysfunctional Emacs. E.g., cursor blinking requires
>>> accessing the system time, displaying a busy cursor requires =
interval
>>> timers, profiling requires signals, and you cannot do anything in
>>> Emacs without being able to allocate memory. If we leave Emacs only
>>> with capabilities to read and write to a couple of descriptors, how
>>> will the result be useful?
>>=20
>> We would definitely allow more stuff (e.g. some other syscalls are
>> required for Emacs to even start up). For example, Emacs needs to
>> allocate memory and thus needs mmap/sbrk. Timing functions are not
>> security-sensitive (timing attacks exist, but should be prevented in
>> this case by blocking any relevant use of the data such obtained), =
and
>> signals only affect the sandboxed Emacs process. The two big things =
we
>> need to prevent is writing arbitrary files and creating sockets.
>=20
> So you are going to suggest that we rely on some auditing of the
> syscalls Emacs uses now to decide which ones to filter and which not?
I don't mean that we should wade through all potential syscalls that =
Emacs could make. Typically you can come up with such a Seccomp policy =
iteratively: run Seccomp in advisory mode (i.e. only log syscalls), then =
allow the syscalls that are both necessary and harmless in the policy.
> If so, how will this work in the future, when Emacs might decide to
> issue some additional syscalls? who and how will remember to update
> the filter definitions?
There are unit tests that ensure that the behavior we expect works. For =
example, an existing unit test verifies that the sandboxed Emacs process =
can write to standard output (and it has already failed a few times on =
various systems, which is expected and is how we can find new syscalls =
to add). So we only need to remember to run the unit tests (and have =
good test coverage).
> And what about users who make local changes
> in their Emacs?
They can provide their own Seccomp policies or modify the ones included =
in Emacs.
>=20
>> At least initially we should only care about batch mode, though -
>> nothing prevents interactive mode in a sandbox in principle, but =
batch
>> mode is much easier to deal with, and suffices for the Flymake use
>> case.
>=20
> I understand why batch mode might be easier to deal with, but I'm not
> sure we should care more about it just because it's easier.
We care about it in the scope of the feature being discussed (Flymake) =
because Flymake runs Emacs in batch mode anyway.