[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#45198: 28.0.50; Sandbox mode
From: |
Mattias Engdegård |
Subject: |
bug#45198: 28.0.50; Sandbox mode |
Date: |
Thu, 17 Dec 2020 18:55:52 +0100 |
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.
bug#45198: 28.0.50; Sandbox mode, Mattias Engdegård, 2020/12/14
- bug#45198: 28.0.50; Sandbox mode, Philipp Stephani, 2020/12/14
- bug#45198: 28.0.50; Sandbox mode, Stefan Monnier, 2020/12/14
- bug#45198: 28.0.50; Sandbox mode, Mattias Engdegård, 2020/12/14
- bug#45198: 28.0.50; Sandbox mode, Philipp Stephani, 2020/12/17
- bug#45198: 28.0.50; Sandbox mode,
Mattias Engdegård <=
- bug#45198: 28.0.50; Sandbox mode, Philipp Stephani, 2020/12/18
- bug#45198: 28.0.50; Sandbox mode, Mattias Engdegård, 2020/12/18
- bug#45198: 28.0.50; Sandbox mode, Philipp Stephani, 2020/12/19
- bug#45198: 28.0.50; Sandbox mode, Mattias Engdegård, 2020/12/19
- bug#45198: 28.0.50; Sandbox mode, Stefan Monnier, 2020/12/19
- bug#45198: 28.0.50; Sandbox mode, Mattias Engdegård, 2020/12/19
- bug#45198: 28.0.50; Sandbox mode, João Távora, 2020/12/19
- bug#45198: 28.0.50; Sandbox mode, Stefan Monnier, 2020/12/19
- bug#45198: 28.0.50; Sandbox mode, Mattias Engdegård, 2020/12/20
- bug#45198: 28.0.50; Sandbox mode, Stefan Monnier, 2020/12/20