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: Mon, 14 Dec 2020 14:44:25 +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="10751"; 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 Mon Dec 14 14:45:11 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 1kooA3-0002f6-GN for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 14 Dec 2020 14:45:11 +0100 Original-Received: from localhost ([::1]:52356 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kooA2-0001fN-5R for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 14 Dec 2020 08:45:10 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59938) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1koo9u-0001ey-4L for bug-gnu-emacs@gnu.org; Mon, 14 Dec 2020 08:45:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40077) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1koo9t-0001P8-T1 for bug-gnu-emacs@gnu.org; Mon, 14 Dec 2020 08:45:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1koo9t-0008F3-PP for bug-gnu-emacs@gnu.org; Mon, 14 Dec 2020 08:45:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Dec 2020 13:45: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.160795348431641 (code B ref 45198); Mon, 14 Dec 2020 13:45:01 +0000 Original-Received: (at 45198) by debbugs.gnu.org; 14 Dec 2020 13:44:44 +0000 Original-Received: from localhost ([127.0.0.1]:51623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koo9b-0008EG-Vp for submit@debbugs.gnu.org; Mon, 14 Dec 2020 08:44:44 -0500 Original-Received: from mail-ot1-f68.google.com ([209.85.210.68]:45030) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1koo9a-0008E4-Qp for 45198@debbugs.gnu.org; Mon, 14 Dec 2020 08:44:43 -0500 Original-Received: by mail-ot1-f68.google.com with SMTP id f16so15684792otl.11 for <45198@debbugs.gnu.org>; Mon, 14 Dec 2020 05:44:42 -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=B4X35+dCh66GLhjJLrDaEmWkU4PBMcqZb4KydkQDfPI=; b=P/eDWQpS6niuvxbjQZPBPbTwIDShIJBUA0RUHq7Z64CmzEywr2VJ4NRuoykvxbDLap 2tevc8kWvXLmuoWvApAFiyPQ2W1IH8fsv/QpnuDcx9TEFgU/530J5Fm8UYRwzlE5RwU0 fyzWswhpnZkxPN32YNzsiWoLbGTnoTkJqsnMfW/4CDFingAuh1D0W+FFdt2z5vAhDZ87 VNNuTAXLIH4k+gy4xckKkfSIpxkwTgvYsMJtVwD2CpT3I2z7WUsx7yhD+RTIKvalni79 7FzlT+2ntxe2yLfX7kSwRx0BwVkX9n2pfaJudMxA01m3auB5MCJhtAjq0yb217qtkmMB w/YQ== 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=B4X35+dCh66GLhjJLrDaEmWkU4PBMcqZb4KydkQDfPI=; b=mqOGJr3ChOE0tpGIANqH6MDPWAj3j/pXGYVBuPMVuCpT0QABi4NOcjvMqAgmmZ+ORh cVBxq0zheIceEOHVaWr4RXpV/sYtbtCIlyO9PG05cgRymrdtTBrsEKzNJ91j4m4FdkWR bieRSWUIZfj2Y8zcJYkmNVfXSO5XIPh4/FfiSbq0QYvXbdhe/TL8hCeXIev1J1xD/QmC BcFuHBb3RmTf43a6mCQ5vREdMn+Uf+cNdzqQqpjy+8OqWv1fj3k7PdGNHR4xjNRkVtIJ 6Ze9n22h5ZU0/vifWQmOgbu31kuxuKfSnri41Ka/tFOb26/aLA79KxmmacvxQUIQ4dP0 ZFwQ== X-Gm-Message-State: AOAM531JLN5rWfyAgYZSDd7fOvrY7Gw89SlYliAzBNYc5RVvXi2S2XDn QBTzfquRTMvtbLqnMZHIHWO45E/5fb42tiRB850= X-Google-Smtp-Source: ABdhPJz2othmtOzyrP81+hZ5Cta/xJ0N43poJ7XsA2YWAcI717AwZwz2ESDsaC8u4aBPmR/hTATtPSTHExGIn3mzqTk= X-Received: by 2002:a9d:269:: with SMTP id 96mr19220077otb.174.1607953476769; Mon, 14 Dec 2020 05:44:36 -0800 (PST) In-Reply-To: <0917E396-F78C-45BF-8A1F-5C23CA722D9A@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:196045 Archived-At: Am Mo., 14. Dez. 2020 um 12:12 Uhr schrieb Mattias Engdeg=C3=A5rd : > > > The sandboxing technologies I'm aware of are process-based (because Lin= ux namespaces and kernel syscall filters are per-process), so a "start sand= box from here" function likely can't be implemented. The interface should r= ather be something like > > If you mean that the sandbox needs to be active from the very start of th= e process, I don't see why that has to be the case. It does not appear to b= e necessary for macOS, OpenBSD or FreeBSD, nor for at least some the Linux = options I'm aware of. 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. I'd expect that there's lots of code around that doesn't expect syscalls to suddenly start failing. Other sandboxing technologies like unsharing the user namespace also don't work in multithreaded processes. Allowing sandboxing (at least for now) only at process startup avoids such issues and should be good enough for the given use case (Flymake background compilation), since we need to start a new process anyway. > > Perhaps I misunderstood, and there may indeed be some desirable sandboxin= g methods that require from-exec sandboxing. It is often useful to allow fo= r a set-up period prior to activating restrictions allowing for specific fi= les to be opened and so on and can make the sandboxing itself simpler by be= ing less selective. That is true, though it would require more significant changes to Emacs. 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). > > From-exec sandboxing also precludes using simple forking (without exec) a= s a cheap way to start the Emacs subprocess (if somewhat Unix-specific). > 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.