[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: |
Mon, 14 Dec 2020 16:59:28 +0100 |
14 dec. 2020 kl. 14.44 skrev Philipp Stephani <p.stephani2@gmail.com>:
> 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.
There shouldn't be many threads running in non-interactive mode, and those that
are must be expected to work with the added restrictions because why should
they be exempt and what are they doing that we want to forbid anyway? It seems
a bit far-fetched and probably not an immediate concern.
That said, it is very much an implementation matter -- the
run-function-in-sandbox Lisp interface seems better than the original
enter-sandbox because we get more ways to write the code. Thanks for proposing
it!
> 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).
Well, almost -- elisp processes serve some of the purposes of open file
descriptors, at least for pipes and sockets.
Is it really is practical to restrict file-system visibility? A spawned
byte-compiler will need to read almost arbitrary elisp files (autoload,
'require' calls) whose exact names are only known at runtime. Were you planning
to build a name-space from a skeleton populated by load-path mounts?
My initial thought was simply inhibit pretty much everything except reading
files and writing to already open descriptors (or just stdout/stderr), on the
grounds that while it would enable an adversary to read anything, exfiltration
would be difficult.
(Some side-channels may be worth thinking about: if the machine cannot trust
its file servers, it is possible to exfiltrate data to an already compromised
server merely by reading. But then there are probably more direct approaches.)
> 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.
Yes, and I'm aware of the difficulties but wouldn't dismiss it out of hand
since the gains are attractive. The main trouble stems from fork only bringing
the calling thread into the new process, which may cause deadlock if those
threads were holding locks which the forked process goes on to acquire later
on. (pthread_atfork is supposed to be used by threaded libraries but typically
isn't.)
It does work given some care (and I have done so in the past to good effect);
it's mainly a matter of not touching anything that you don't want to use anyway
such as GUI frameworks. In Emacs, this would be done in some sort of
become_noninteractive function which ensures that future program flow will not
involve any GUI code whatsoever.
Let's see what latency we get from spawning a typically overloaded Emacs
configuration first.
- bug#45198: 28.0.50; Sandbox mode, (continued)
- bug#45198: 28.0.50; Sandbox mode, Eli Zaretskii, 2020/12/29
- bug#45198: 28.0.50; Sandbox mode, Philipp Stephani, 2020/12/29
- bug#45198: 28.0.50; Sandbox mode, Eli Zaretskii, 2020/12/29
- bug#45198: 28.0.50; Sandbox mode, Philipp Stephani, 2020/12/31
- bug#45198: 28.0.50; Sandbox mode, Eli Zaretskii, 2020/12/31
- bug#45198: 28.0.50; Sandbox mode, Stefan Monnier, 2020/12/13
- bug#45198: 28.0.50; Sandbox mode, João Távora, 2020/12/13
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 <=
- bug#45198: 28.0.50; Sandbox mode, Philipp Stephani, 2020/12/17
- bug#45198: 28.0.50; Sandbox mode, Mattias Engdegård, 2020/12/17
- 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