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: Thu, 17 Dec 2020 14:08:04 +0100
Message-ID:
References: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@acm.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="22820"; mail-complaints-to="usenet@ciao.gmane.io"
Cc: Bastien , 45198@debbugs.gnu.org,
Stefan Monnier ,
=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?=
To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?=
Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 17 14:16:36 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 1kpt8z-0005if-1k
for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 17 Dec 2020 14:16:33 +0100
Original-Received: from localhost ([::1]:59170 helo=lists1p.gnu.org)
by lists.gnu.org with esmtp (Exim 4.90_1)
(envelope-from )
id 1kpt8y-0003ki-2x
for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 17 Dec 2020 08:16:32 -0500
Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37632)
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from )
id 1kpt1i-0005wh-Tw
for bug-gnu-emacs@gnu.org; Thu, 17 Dec 2020 08:09:03 -0500
Original-Received: from debbugs.gnu.org ([209.51.188.43]:51729)
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from )
id 1kpt1i-0003u6-F6
for bug-gnu-emacs@gnu.org; Thu, 17 Dec 2020 08:09:02 -0500
Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2)
(envelope-from ) id 1kpt1i-0001ee-9j
for bug-gnu-emacs@gnu.org; Thu, 17 Dec 2020 08:09: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: Thu, 17 Dec 2020 13:09: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.16082105066313
(code B ref 45198); Thu, 17 Dec 2020 13:09:02 +0000
Original-Received: (at 45198) by debbugs.gnu.org; 17 Dec 2020 13:08:26 +0000
Original-Received: from localhost ([127.0.0.1]:35042 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from )
id 1kpt17-0001dl-Ei
for submit@debbugs.gnu.org; Thu, 17 Dec 2020 08:08:25 -0500
Original-Received: from mail-ot1-f54.google.com ([209.85.210.54]:35333)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from ) id 1kpt14-0001dU-9j
for 45198@debbugs.gnu.org; Thu, 17 Dec 2020 08:08:24 -0500
Original-Received: by mail-ot1-f54.google.com with SMTP id i6so27187159otr.2
for <45198@debbugs.gnu.org>; Thu, 17 Dec 2020 05:08:22 -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:content-transfer-encoding;
bh=ERpuRURCF52tkm8ZeFhpWXGFRgcXRWNOWpe7PvC9gGo=;
b=R3Qqb/fvCknLoVwU6R/lOXomup+owvCUgMD1oTC5ETBYmWH5JKRkE0NV9QCpU6m7wU
zK3YUSrhvu9uDSWwR2zeCPQlUY34wzc6SGJb9oDHQx39lASHwHUhr/FiesEoD5iD5DzK
AxGErVsa/RlHKP5jALQu8IejWosprJmldKSRCmlpG8k6Cr6nN4Lu0DlLYEt+QPN+36hS
ywKcKKbTiiYg2ml0R+SL5B/ojqXXqMdpzIl1F3aAfglfDbEUxczkW9cbszRKMNptBw8C
yJpu4ka24GeBy1WAnq3IxPWNk8xABHen+7dw5fwp/qvgRZHLFbhTFskBNfMhPeakPOiX
ADFw==
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=ERpuRURCF52tkm8ZeFhpWXGFRgcXRWNOWpe7PvC9gGo=;
b=dbwfJ7i+zGg1GVL+mWF09ZwEa8O0q6hl77sMB+kibWdy69sKQRAeLiMuFI5kNQ2toV
xrPfl+rI0hKrekIL9pp/cyjyKxlREQmCNsa7r3wCHFr2qD22FjfQrnZzBTaxQRJMhMCT
gLoOn6Sm+RZDYRkTC7IhcXnKvKMvKrqnkUQbQuVyx7IvdOzqUbWVwb3kB+z8Deyq9IyE
Rpguz3/r6XIQzsyD7zZjHAXROPmYwL4SOUXg5GFdqNBYxwf7+iK3xUAAWhCxe612B1Fz
i0aUFTpO+bOFRd3nebHH7WwWDJlWWERKiZxxLoPxcvtT0pxLSw3USTrW1zFkryM1ycXf
5isQ==
X-Gm-Message-State: AOAM532x0Y8eBEx7uLTttV2nh6jx1AhzDFDihTmu0SFEvUo1cOnmsB31
kRg3f2nsDd4wShJc66hwkAThqaLPnetEj48AceI=
X-Google-Smtp-Source: ABdhPJwRgXB17gpiIMuGynvXdlk5DUpgfQm3weYYqrS0eqdI4Wr15SwQ/IxsSwGOs9J6zfsdvO9eXbaa4MLp0RW9s4M=
X-Received: by 2002:a9d:72c4:: with SMTP id d4mr29849025otk.149.1608210496348;
Thu, 17 Dec 2020 05:08:16 -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:196251
Archived-At:
Am Mo., 14. Dez. 2020 um 16:59 Uhr schrieb Mattias Engdeg=C3=A5rd :
>
> 14 dec. 2020 kl. 14.44 skrev Philipp Stephani :
>
> > Yes, it's not strictly required (as in, seccomp and unshare nominally
> > work at any point), though I think enabling sandboxing while user code
> > has already run can have confusing/unanticipated consequences. For
> > example, other threads might already be running in parallel, and they
> > would then suddenly be blocked from making some syscalls, potentially
> > in the middle of a critical section or similar.
>
> There shouldn't be many threads running in non-interactive mode,
Dynamic libraries tend to start threads for background work, so while
there aren't that many, they still exist.
> and those that are must be expected to work with the added restrictions b=
ecause why should they be exempt and what are they doing that we want to fo=
rbid anyway? It seems a bit far-fetched and probably not an immediate conce=
rn.
Libraries (and Emacs itself) can do arbitrary background processing as
an implementation detail, so we'd need to take that into account. I
agree though that this isn't a problem in practice, and, if at all,
requires some adjustments to the policy.
Just do give an example:
https://sourceware.org/git/?p=3Dglibc.git;a=3Dblob;f=3Dnptl/pthread_create.=
c;h=3Dbad4e57a845bd3148ad634acaaccbea08b04dbbd;hb=3DHEAD#l393
assumes that set_robust_list will work if it worked once. In the case
of an Emacs sandbox, threads are started before entering main (through
dynamic initialization and dynamic linking), so the function assumes
that set_robust_list works. (In that case we can just allow
set_robust_list as it's not dangerous.)
>
> That said, it is very much an implementation matter -- the run-function-i=
n-sandbox Lisp interface seems better than the original enter-sandbox becau=
se we get more ways to write the code. Thanks for proposing it!
Sure, I also don't mind adding a load-seccomp-filter function for
post-main invocation. Right now I believe it's not needed though.
>
> > For example, to achieve some amount of capability-based
> > security, you'd open files before sandboxing and then forbid the open
> > syscall, but that's not really possible with the current Emacs API
> > (which doesn't provide any access to open files).
>
> Well, almost -- elisp processes serve some of the purposes of open file d=
escriptors, at least for pipes and sockets.
>
> Is it really is practical to restrict file-system visibility? A spawned b=
yte-compiler will need to read almost arbitrary elisp files (autoload, 'req=
uire' calls) whose exact names are only known at runtime. Were you planning=
to build a name-space from a skeleton populated by load-path mounts?
I haven't tried this out yet, but allowing reads from load-path
entries plus the installation directory should be fine.
>
> My initial thought was simply inhibit pretty much everything except readi=
ng files and writing to already open descriptors (or just stdout/stderr), o=
n the grounds that while it would enable an adversary to read anything, exf=
iltration would be difficult.
Yes, but see my other comment: restricting an open policy after the
fact is much harder than opening up an initially-restrictive one, so
I'd really start with a restrictive one (no file reading allowed
except for allowed directories and files).
>
> (Some side-channels may be worth thinking about: if the machine cannot tr=
ust its file servers, it is possible to exfiltrate data to an already compr=
omised server merely by reading. But then there are probably more direct ap=
proaches.)
>
> > Even on Unix, a fork that's not immediately followed by an exec or
> > exit tends to not work any more. Lots of libraries nowadays assume
> > that the "weird in-between state" after a fork doesn't exist
> > permanently, and only a small number of async-signal-safe syscalls are
> > guaranteed to work between fork and exec.
>
> Yes, and I'm aware of the difficulties but wouldn't dismiss it out of han=
d since the gains are attractive. The main trouble stems from fork only bri=
nging the calling thread into the new process, which may cause deadlock if =
those threads were holding locks which the forked process goes on to acquir=
e later on. (pthread_atfork is supposed to be used by threaded libraries bu=
t typically isn't.)
Yes, and because libraries can and do start arbitrary threads, this
issue can't really be mitigated and makes fork without exec extremely
unsafe and largely useless.
The gains are largely realized using threads these days.
>
> It does work given some care (and I have done so in the past to good effe=
ct); it's mainly a matter of not touching anything that you don't want to u=
se anyway such as GUI frameworks. In Emacs, this would be done in some sort=
of become_noninteractive function which ensures that future program flow w=
ill not involve any GUI code whatsoever.
I don't think that's enough, even linking against some libraries
already causes background threads to spin up.
>
> Let's see what latency we get from spawning a typically overloaded Emacs =
configuration first.
>
I'd think that we'd always run the sandboxed Emacs with --quick
--batch and an empty environment (to provide for some reproducibility
and avoid LD_PRELOAD attacks etc.), and then startup tends to be fast
enough (emacs -Q -batch takes ~50 ms on my system).