From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Philipp Stephani <p.stephani2@gmail.com>
Cc: Bastien <bzg@gnu.org>,
45198@debbugs.gnu.org, "João Távora" <joaotavora@gmail.com>
Subject: bug#45198: 28.0.50; Sandbox mode
Date: Mon, 14 Dec 2020 09:44:30 -0500 [thread overview]
Message-ID: <jwv4kkoiim5.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <CAArVCkRahKpNVNQXsA_bYMoso-eQwy6b=LnaNTG9BtrJ0cMi1g@mail.gmail.com> (Philipp Stephani's message of "Mon, 14 Dec 2020 12:05:09 +0100")
> 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
next prev parent reply other threads:[~2020-12-14 14:44 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 [this message]
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
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=jwv4kkoiim5.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=45198@debbugs.gnu.org \
--cc=bzg@gnu.org \
--cc=joaotavora@gmail.com \
--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).