From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#45198: 28.0.50; Sandbox mode Date: Sun, 18 Apr 2021 09:20:54 +0300 Message-ID: <83czusun95.fsf@gnu.org> 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> <8491CEA9-E230-48E4-9AB3-71DF0B4D8A2B@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="629"; mail-complaints-to="usenet@ciao.gmane.io" Cc: alan@idiocy.org, mattiase@acm.org, 45198@debbugs.gnu.org, stefankangas@gmail.com, joaotavora@gmail.com, monnier@iro.umontreal.ca To: Philipp Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 18 08:22:20 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 1lY0p1-000AaA-9U for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 18 Apr 2021 08:22:19 +0200 Original-Received: from localhost ([::1]:57384 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lY0oz-0003eh-RQ for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 18 Apr 2021 02:22:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46812) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lY0ok-0003eM-1U for bug-gnu-emacs@gnu.org; Sun, 18 Apr 2021 02:22:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:33575) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lY0oj-0006hH-Pv for bug-gnu-emacs@gnu.org; Sun, 18 Apr 2021 02:22:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lY0oj-00049S-KB for bug-gnu-emacs@gnu.org; Sun, 18 Apr 2021 02:22:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 18 Apr 2021 06:22: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.161872688515912 (code B ref 45198); Sun, 18 Apr 2021 06:22:01 +0000 Original-Received: (at 45198) by debbugs.gnu.org; 18 Apr 2021 06:21:25 +0000 Original-Received: from localhost ([127.0.0.1]:45121 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lY0o8-00048a-PD for submit@debbugs.gnu.org; Sun, 18 Apr 2021 02:21:25 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34096) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lY0o6-00048J-Rz for 45198@debbugs.gnu.org; Sun, 18 Apr 2021 02:21:23 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:47211) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lY0nz-0006EA-Hd; Sun, 18 Apr 2021 02:21:15 -0400 Original-Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3088 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1lY0nz-0003jO-0J; Sun, 18 Apr 2021 02:21:15 -0400 In-Reply-To: <8491CEA9-E230-48E4-9AB3-71DF0B4D8A2B@gmail.com> (message from Philipp on Sat, 17 Apr 2021 21:52:59 +0200) 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:204298 Archived-At: > From: Philipp > Date: Sat, 17 Apr 2021 21:52:59 +0200 > Cc: Mattias Engdegård , > João Távora , > 45198@debbugs.gnu.org, > stefankangas@gmail.com, > monnier@iro.umontreal.ca, > alan@idiocy.org > > > 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. Emacs can be invoked to do many different things, and will correspondingly present very different profiles of syscalls. Is the procedure you envision practical, let alone seamless, given that it will have to become part of the maintenance and the release process? > > 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. Unit tests are a far cry from what Emacs does in real-life usage, so I very much doubt that unit tests will suffice in this case. > > 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. What does providing a policy entail? can you describe the procedure of tailoring a policy to changes in the Emacs code? > >> 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. > > > > 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. So we will make running Flymake safe, but what about all the other use cases where similar dangers exist? Flymake is just a tiny fraction of what Emacs does, so it sounds strange, to say the least, to work on solution for that use case alone, when it is clear from the get-go that many other use cases aren't covered.