Add some high-level sandboxing documentation. (#1353)

* Add some high-level sandboxing documentation.

* Update docs/security-sandboxing.md

Co-Authored-By: Nick Fitzgerald <fitzgen@gmail.com>

* Update docs/security-sandboxing.md

Co-Authored-By: bjorn3 <bjorn3@users.noreply.github.com>

* Grammar fixes.

* Mention that ANSI-style escape sequences sometimes augment other attacks.

* Fix another wordo.

Co-authored-by: Nick Fitzgerald <fitzgen@gmail.com>
Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>

docs/security-sandboxing.md

@@ -16,6 +16,65 @@ offer users choices of which tradeoffs they want to make.
 
 More will be added here over time!
 
+## WebAssembly Core
+
+The core WebAssembly spec has several features which create a unique sandboxed
+environment:
+
+ - The callstack is inaccessible. Unlike most native execution environments,
+   return addresses from calls and spilled registers are not stored in memory
+   accessible to applications. They are stored in memory that only the
+   implementation has access to, which makes traditional stack-smashing attacks
+   targeting return addresses impossible.
+
+ - Pointers, in source languages which have them, are compiled to offsets
+   into linear memory, so implementations details such as virtual addresses
+   are hidden from applications. And all accesses within linear memory are
+   checked to ensure they stay in bounds.
+
+ - All control transfers—direct and indirect branches, as well as direct and
+   indirect calls—are to known and type-checked destinations, so it's not
+   possible to accidentally call into the middle of a function or branch
+   outside of a function.
+
+ - All interaction with the outside world is done through imports and exports.
+   There is no raw access to system calls or other forms of I/O; the only
+   thing a WebAssembly instance can do is what is available through interfaces
+   it has been explicitly linked with.
+
+ - There is no undefined behavior. Even where the WebAssembly spec permits
+   multiple possible behaviors, it doesn't permit arbitrary behavior.
+
+## Filesystem Access
+
+Wasmtime implements the WASI APIs for filesystem access, which follow a
+capability-based security model, which ensures that applications can only
+access files and directories they've been given access to. WASI's security
+model keeps users safe today, and also helps us prepare for shared-nothing
+linking and nanoprocesses in the future.
+
+Wasmtime developers are intimately engaged with the WASI standards process,
+libraries, and tooling development, all along the way too.
+
+## Terminal Output
+
+If untrusted code is allowed to print text which is displayed to a terminal, it may
+emit ANSI-style escape sequences and other control sequences which, depending on
+the terminal the user is using and how it is configured, can have side effects
+including writing to files, executing commands, injecting text into the stream
+as if the user had typed it, or reading the output of previous commands. ANSI-style
+escape sequences can also confuse or mislead users, making other vulnerabilities
+easier to exploit.
+
+Our first priority is to protect users, so Wasmtime now filters writes to output
+streams when they are connected to a terminal to translate escape sequences into
+inert replacement sequences.
+
+Some applications need ANSI-style escape sequences, such as terminal-based
+editors and programs that use colors, so we are also developing a proposal for
+the WASI Subgroup for safe and portable ANSI-style escape sequence support, which
+we hope to post more about soon.
+
 ## Spectre
 
 Wasmtime does not yet implement Spectre mitigations, however this is a subject