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: Fri, 18 Dec 2020 16:21:45 +0100 Message-ID: References: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@acm.org> <26556EDE-9133-450F-9181-2859E058677C@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="6194"; 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 Fri Dec 18 16:39:48 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 1kqHr9-0001Tz-LO for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 18 Dec 2020 16:39:47 +0100 Original-Received: from localhost ([::1]:57096 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kqHr8-00005U-MS for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 18 Dec 2020 10:39:46 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56706) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kqHax-0005ll-GX for bug-gnu-emacs@gnu.org; Fri, 18 Dec 2020 10:23:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56331) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kqHaw-0000RH-GV for bug-gnu-emacs@gnu.org; Fri, 18 Dec 2020 10:23:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kqHaw-0004SV-DM for bug-gnu-emacs@gnu.org; Fri, 18 Dec 2020 10:23: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: Fri, 18 Dec 2020 15:23: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.160830493117043 (code B ref 45198); Fri, 18 Dec 2020 15:23:02 +0000 Original-Received: (at 45198) by debbugs.gnu.org; 18 Dec 2020 15:22:11 +0000 Original-Received: from localhost ([127.0.0.1]:39640 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kqHa7-0004Qo-6D for submit@debbugs.gnu.org; Fri, 18 Dec 2020 10:22:11 -0500 Original-Received: from mail-oo1-f46.google.com ([209.85.161.46]:36133) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kqHZz-0004QC-Qd for 45198@debbugs.gnu.org; Fri, 18 Dec 2020 10:22:09 -0500 Original-Received: by mail-oo1-f46.google.com with SMTP id j8so627525oon.3 for <45198@debbugs.gnu.org>; Fri, 18 Dec 2020 07:22:03 -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=ylzMn+aEF9dAHuCMkyEfkX3soxLiwfI0nQeLUaXm+b0=; b=X7/mOvpPESzcQ6ZJqKxaMJYbzlhMigyubN34HfxpZUCCQWvL43m0Y4Rpj6DT9SfS6B u6kEgP0Zcu+7V/kcXxxAG7FLG/krWNVZGFcFqNG8u1XRQwC78K4FK6mLO47hJrhh5IYs EF0yAbu4vdASQL2WaR4cxqSTErdMLpwDmFmnaXnSEIZoeW4o8YvisYOH7LIoHmcd0blg 3tABUu+KtCt7yLgMOTCbMbtD5emIrqvNKkOpmNEWwFzjVisxm7zmpmls0gNcQ319LA7U 9Q02qhenXntuKIR9YIEfEcqKecGJEYLbuikjiozjZTAXPJ51tI7AzpsiT726dgX/ll9i IR4g== 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=ylzMn+aEF9dAHuCMkyEfkX3soxLiwfI0nQeLUaXm+b0=; b=bfg8Ozl5Ua4pABnD9Ka2Of6SfQxLAgCDQ1xCMQrBvwCIqCeAca1Wg61Tjqp21ZvTA6 NqZKO6CErT186mRHiuGZh5teCTVqVomnJYk/XY2QJ/JTIsJDKY88CReWSfONJLTRFshB 3C8ljtDnKAKVIJddbgViWQcjVg85miWNnym5ErsSof0r93DdoR5rK4FlUslL6yYlaIIT grz5YnTdNarH0HT0wOGmoY+WTOosvcpikkjDuYKJVTaaQw3eDNVf/LT/aoGZkmjQZsiK m0lR5nYX0JoGgUhOc4zGvj36v3irnIEGyBl6EI+r4iqWjLXrQZSDC5WHu2L99dh1Zshb XjJw== X-Gm-Message-State: AOAM533D7la+IgcdfrfnAjWEPtHQ8vnbAUP82hQk09t3Fjj2o5jiCdFW hEO6YFWcpEomzmtc9RqUoiLssCHLDPTaIKPHD8g= X-Google-Smtp-Source: ABdhPJwwLDcEFlGgSqUJQs3p2mY7xM6S8dzUwCsilia75/obdIj7Z4ulY0dasouMstL0ZAU2BikFmNzdq+niNeitMJ8= X-Received: by 2002:a4a:e8d1:: with SMTP id h17mr3110407ooe.71.1608304917069; Fri, 18 Dec 2020 07:21:57 -0800 (PST) In-Reply-To: <26556EDE-9133-450F-9181-2859E058677C@acm.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:196328 Archived-At: Am Do., 17. Dez. 2020 um 18:56 Uhr schrieb Mattias Engdeg=C3=A5rd : > > 17 dec. 2020 kl. 14.08 skrev Philipp Stephani : > > > Dynamic libraries tend to start threads for background work, so while > > there aren't that many, they still exist. > > Well, there's no accounting for taste. Still, I'm not ready to close the = door to possible solutions until they really do appear to lead no way. (It'= s not an urgent concern since we will need a traditional fork-exec solution= first of all.) Yeah, I didn't want to imply to close the door, just to first start with what we need to solve the task at hand. > > > I haven't tried this out yet, but allowing reads from load-path > > entries plus the installation directory should be fine. > > Assuming this is sufficient; I think autoloaded definitions can specify f= iles in arbitrary directories, not necessarily in the load-path. Sure, but things like Flymake byte-compilation are best-effort anyway. It's fine to (at least initially) not cover a few "exotic" cases. > > > 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). > > Depends on the platform I suppose -- macOS and BSD should work either way= . On Linux it depends on the method used; I admit not having looked closely= at seccomp lately. Ah, I was talking about the engineering/product management aspect, not about the technical one: If you start with an initially-open sandbox policy, locking it down in future releases is much harder than the other way round. > > > The gains are largely realized using threads these days. > > Indeed, although forking still has a few niche uses. (For there record I'= m a firm believer that the fork-exec model was a mistake from its inception= , but now that it's there...) > > Emacs would be better served with threads, too, if it weren't that (I) we= don't have a good threading story yet and (II) Elisp code can cause way to= o much damage at compile time. Fixing either would bring many other benefit= s! Yeah, and while there are a few ideas (the "web worker" model looks most promising), we're not even close to having a design yet. > > > 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). > > That's not quite fair; the byte-compiler needs the right load-path and au= toload definitions, and the byte-compiler itself needs to be loaded as well= . (Anyone who can set LD_PRELOAD already has the machine.) > > The easiest way is to run the user's init file. Perhaps it's possible to = just transmit a list of paths and packages to the subprocess as arguments b= ut the user may have things loaded or defined outside the standard package = manager. > We should be very hesitant to use the easiest way. Often it's the wrong way, and fixing things after the fact tends to be hard. Again, the goal is not to provide a perfect solution that works for all ELisp files, but something that works well for "typical" use cases. We should definitely run the subprocess with --quick --batch and an empty environment by default, not only for security and speed, but also for reproducibility. That's also what Flycheck does (https://github.com/flycheck/flycheck/blob/a11b789807d1d942d6fcfac17508d072= b9cf7ba8/flycheck.el#L8435)