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.