[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#45198: 28.0.50; Sandbox mode
From: |
Stefan Monnier |
Subject: |
bug#45198: 28.0.50; Sandbox mode |
Date: |
Mon, 14 Dec 2020 09:44:30 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
> In some way certainly, but it's not necessarily through stdout. I tend
> to write potential output into a file whose filename is passed on the
> command line. That's more robust than stdout (which often contains
> spurious messages about loading files etc).
Hmm... but that requires write access to some part of the file system,
so it requires a finer granularity of control. I'd much rather limit
the output to something equivalent to a pipe (the implementation of the
sandboxing doesn't have to use stdout for that if that's a problem).
>> Also, I think the async option is the most important one. How 'bout:
>> (sandbox-start FUNCTION)
>> Lunch a sandboxed Emacs subprocess running FUNCTION.
> Passing a function here might be confusing because e.g. lexical
> closures won't work.
What makes you think they don't?
> It might be preferable to pass a form and state
> that both dynamic and lexical bindings are ignored.
If closures turn out to be a problem I'd rather use FUNCTION + VALUES
than FORM (using FORM implies the use of `eval`, and you have to think
of all those kitten that'll suffer if we do that).
>> Returns a process object.
> Depending how much we care about forward compatibility, it might be
> better to return an opaque sandbox object (which will initially wrap a
> process object).
We always use process objects to represent file-descriptors, so I can't
find any good reason why this one should be different or why an
implementation might find it difficult to expose a process object.
>> FUNCTION is called with no arguments and it can use `sandbox-read`
>> to read the data sent to the process object via `process-send-string`,
>> and `sandbox-reply` to send back a reply to the parent process
>> (which will receive it via its `process-filter`).
> That is, sandbox-read and sandbox-reply just read/write stdin/stdout?
While it may use stdin/stdout internally, I can imagine good reasons why
we'd want to use some other file descriptors.
> That would certainly work, but (a) it doesn't really have anything to
> do with sandboxing, so these functions should rather be called
> stdin-read and stdout-write or similar,
I think "the right thing" would be to represent the parent as a process
object inside the child. I proposed dedicated functions only because
but when it uses stdin/stdout, providing a process object seems awkward
to implement.
>> The sandboxed process has read access to all the local files
>> but no write access to them, nor any access to the network or
>> the display.
> This might be a bit too specific. I'd imagine we'd want to restrict
> reading files to the absolute minimum (files that Emacs itself needs
> plus a fixed set of input files/directories known in advance), but
> often allow writing some output files.
I'm trying to design an API which can be made to work in as many
circumstances as possible without imposing too high a maintenance
burden. So while I agree that it'd be better to limit the set of files
that can be read and to allow writing to some files, I think I'd rather
start with something more crude.
We can refine it later if/when we have more experience with how it's
used, and how it's implemented in the various OSes.
>> >> - I suspect we'll still want to use the extra "manual" checks I put in
>> >> my code (so as to get clean ELisp errors when bumping against the
>> >> walls of the sandbox, and because of the added in-depth security).
>> > That's reasonable, though I'm worried that it will give users a false
>> > sense of security.
>> That would only be the case if we don't additionally use process-level
>> isolation, right?
> My worry is that people see a function like enter-sandbox and then
> assume that Emacs will be secure after calling it, without actually
> verifying the security implications.
This seems universally true and hence suggests we should just forget
about this idea of providing a sandbox functionality. IOW I'm not sure
what this has to do with the `ensure_no_sandbox` calls I'm suggesting
we keep.
> I've looked into this, and what I'd suggest for now is:
> 1. Add a --seccomp=FILE command-line option that loads seccomp filters
> from FILE and applies them directly after startup (first thing in
> main). Why do this in Emacs? Because that's the easiest way to prevent
> execve. When installing a seccomp filter in a separate process, execve
> needs to be allowed because otherwise there'd be no way to execute the
> Emacs binary. While there are workarounds (ptrace, LD_PRELOAD), it's
> easiest to install the seccomp filter directly in the Emacs process.
> 2. Generate appropriate seccomp filters using libseccomp or similar.
> 3. In the sandboxing functions, start Emacs with bwrap to set up
> namespaces and invoke Emacs with the new --seccomp flag.
Sounds OK, tho I must say I don't understand why we care particularly
about disallowing execve inside the bwrap jail. AFAIK anything that an
external process can do can also be done directly by Emacs since ELisp
is a fairly fully-featured language (since there's nothing like setuid
inside a bwrap jail). I mean, I agree that we want to disallow running
subprocesses, but can't think of a good reason why we would need this to
be 100%, so we could rely on `ensure_no_sandbox` for that.
Stefan
- bug#45198: 28.0.50; Sandbox mode, (continued)
bug#45198: 28.0.50; Sandbox mode, Mattias Engdegård, 2020/12/13
bug#45198: 28.0.50; Sandbox mode, Philipp Stephani, 2020/12/13
- bug#45198: 28.0.50; Sandbox mode, Stefan Monnier, 2020/12/13
- bug#45198: 28.0.50; Sandbox mode, Philipp Stephani, 2020/12/13
- bug#45198: 28.0.50; Sandbox mode, Stefan Monnier, 2020/12/13
- bug#45198: 28.0.50; Sandbox mode, Philipp Stephani, 2020/12/14
- bug#45198: 28.0.50; Sandbox mode,
Stefan Monnier <=
- bug#45198: 28.0.50; Sandbox mode, Philipp Stephani, 2020/12/14
- bug#45198: 28.0.50; Sandbox mode, Philipp Stephani, 2020/12/19
- bug#45198: 28.0.50; Sandbox mode, Stefan Monnier, 2020/12/19
- bug#45198: 28.0.50; Sandbox mode, Philipp Stephani, 2020/12/20
- bug#45198: 28.0.50; Sandbox mode, Philipp Stephani, 2020/12/22
- bug#45198: 28.0.50; Sandbox mode, Stefan Monnier, 2020/12/22
bug#45198: 28.0.50; Sandbox mode, Philipp Stephani, 2020/12/19
bug#45198: 28.0.50; Sandbox mode, Philipp Stephani, 2020/12/19
bug#45198: 28.0.50; Sandbox mode, Eli Zaretskii, 2020/12/20
bug#45198: 28.0.50; Sandbox mode, Philipp Stephani, 2020/12/20