unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "Mattias Engdegård" <mattiase@acm.org>
To: Philipp Stephani <p.stephani2@gmail.com>
Cc: Bastien <bzg@gnu.org>,
	45198@debbugs.gnu.org,
	"Stefan Monnier" <monnier@iro.umontreal.ca>,
	"João Távora" <joaotavora@gmail.com>
Subject: bug#45198: 28.0.50; Sandbox mode
Date: Thu, 17 Dec 2020 18:55:52 +0100	[thread overview]
Message-ID: <26556EDE-9133-450F-9181-2859E058677C@acm.org> (raw)
In-Reply-To: <CAArVCkTWdYNSe+=uvUMXMe0pcSL+gWsfQW=mVWn3aq5bGF5iTg@mail.gmail.com>

17 dec. 2020 kl. 14.08 skrev Philipp Stephani <p.stephani2@gmail.com>:

> 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.)

> 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 files in arbitrary directories, not necessarily in the load-path.

> 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.

> 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 too much damage at compile time. Fixing either would bring many other benefits!

> 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 autoload 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 but the user may have things loaded or defined outside the standard package manager.






  reply	other threads:[~2020-12-17 17:55 UTC|newest]

Thread overview: 102+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-12 18:01 bug#45198: 28.0.50; Sandbox mode Stefan Monnier
2020-12-12 19:48 ` Eli Zaretskii
2020-12-12 21:06   ` Stefan Monnier
2020-12-13  3:29     ` Eli Zaretskii
2020-12-13  4:25       ` Stefan Monnier
2020-12-13 11:14         ` João Távora
2020-12-13 17:07         ` Philipp Stephani
2020-12-13 15:31 ` Mattias Engdegård
2020-12-13 17:09   ` Philipp Stephani
2020-12-13 17:04 ` Philipp Stephani
2020-12-13 17:57   ` Stefan Monnier
2020-12-13 18:13     ` Philipp Stephani
2020-12-13 18:43       ` Stefan Monnier
2020-12-14 11:05         ` Philipp Stephani
2020-12-14 14:44           ` Stefan Monnier
2020-12-14 15:37             ` Philipp Stephani
2020-12-19 22:41             ` Philipp Stephani
2020-12-19 23:16               ` Stefan Monnier
2020-12-20 12:28                 ` Philipp Stephani
2020-12-22 10:57                   ` Philipp Stephani
2020-12-22 14:43                     ` Stefan Monnier
2020-12-19 18:18           ` Philipp Stephani
2021-04-10 17:44             ` Philipp Stephani
2020-12-19 22:22           ` Philipp Stephani
2020-12-20 15:09             ` Eli Zaretskii
2020-12-20 18:14               ` Philipp Stephani
2020-12-20 18:29                 ` Eli Zaretskii
2020-12-20 18:39                   ` Philipp Stephani
2020-12-29 13:50             ` Philipp Stephani
2020-12-29 15:43               ` Eli Zaretskii
2020-12-29 16:05                 ` Philipp Stephani
2020-12-29 17:09                   ` Eli Zaretskii
2020-12-31 15:05                     ` Philipp Stephani
2020-12-31 16:50                       ` Eli Zaretskii
2021-04-10 19:11             ` Philipp Stephani
2020-12-13 18:52       ` Stefan Monnier
2020-12-13 20:13     ` João Távora
2020-12-14 11:12 ` Mattias Engdegård
2020-12-14 13:44   ` Philipp Stephani
2020-12-14 14:48     ` Stefan Monnier
2020-12-14 15:59     ` Mattias Engdegård
2020-12-17 13:08       ` Philipp Stephani
2020-12-17 17:55         ` Mattias Engdegård [this message]
2020-12-18 15:21           ` Philipp Stephani
2020-12-18 18:50             ` Mattias Engdegård
2020-12-19 15:08               ` Philipp Stephani
2020-12-19 17:19                 ` Mattias Engdegård
2020-12-19 18:11                   ` Stefan Monnier
2020-12-19 18:46                     ` Mattias Engdegård
2020-12-19 19:48                       ` João Távora
2020-12-19 21:01                       ` Stefan Monnier
2020-12-20 13:15                         ` Mattias Engdegård
2020-12-20 14:02                           ` Stefan Monnier
2020-12-20 14:12                             ` Mattias Engdegård
2020-12-20 15:08                               ` Stefan Monnier
2020-12-22 11:12                   ` Philipp Stephani
2020-12-28  8:23                     ` Stefan Kangas
2020-12-29 13:58                       ` Philipp Stephani
2020-12-30 14:59 ` Mattias Engdegård
2020-12-30 15:36   ` Alan Third
2021-04-17 15:26 ` Mattias Engdegård
2021-04-17 15:44   ` Philipp
2021-04-17 15:57     ` Eli Zaretskii
2021-04-17 16:10       ` Philipp
2021-04-17 16:15         ` Eli Zaretskii
2021-04-17 16:19           ` Eli Zaretskii
2021-04-17 16:20           ` Philipp Stephani
2021-04-17 16:33             ` Eli Zaretskii
2021-04-17 19:14               ` Philipp Stephani
2021-04-17 19:23                 ` Eli Zaretskii
2021-04-17 19:52                   ` Philipp
2021-04-18  6:20                     ` Eli Zaretskii
2021-04-18  9:11                       ` Philipp Stephani
2021-04-18  9:23                         ` Eli Zaretskii
2021-04-17 17:48         ` Mattias Engdegård
2021-04-17 18:21           ` Stefan Monnier
2021-04-17 18:59             ` Mattias Engdegård
2021-04-17 19:42               ` Philipp
2021-04-17 19:57                 ` Alan Third
2021-04-19 15:41                 ` Mattias Engdegård
2021-04-17 19:19           ` Philipp Stephani
2021-04-17 17:22     ` Mattias Engdegård
2021-04-17 17:57       ` Stefan Monnier
2021-04-17 19:21         ` Philipp Stephani
2021-04-17 19:16       ` Philipp Stephani
2021-04-17 16:58   ` Stefan Monnier
2021-04-17 17:14     ` Eli Zaretskii
2021-04-17 17:53       ` Stefan Monnier
2021-04-17 18:15         ` Eli Zaretskii
2021-04-17 18:47           ` Stefan Monnier
2021-04-17 19:14             ` Eli Zaretskii
2021-04-17 20:26               ` Stefan Monnier
2021-04-18  6:24                 ` Eli Zaretskii
2021-04-18 14:25                   ` Stefan Monnier
2021-07-05 19:12                     ` Philipp
2021-09-17 12:13 ` Mattias Engdegård
2021-09-17 13:20   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-09-17 19:49     ` Mattias Engdegård
2022-09-11 11:28       ` Lars Ingebrigtsen
2022-09-13 12:37         ` mattiase
2022-09-13 12:53           ` João Távora
2022-09-13 13:02             ` João Távora

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=26556EDE-9133-450F-9181-2859E058677C@acm.org \
    --to=mattiase@acm.org \
    --cc=45198@debbugs.gnu.org \
    --cc=bzg@gnu.org \
    --cc=joaotavora@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    --cc=p.stephani2@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).