Sandboxing support
## What

This is issue is for discussing sandboxing capabilities built-in Cuprate.
It has been a [feature proposed at the beginning of the project](https://github.com/Cuprate/cuprate/commit/58a076f3aa44c4a19c6758308a8336d48861ae17#diff-5a831ea67cf5cf8703b0de46901ab25bd191f56b320053be9332d9a3b0d01d15L51-L55)

## Why

Some sandboxing API in operating system requires the running process to setup the jail itself or through the help of a helper.
Integrating the use of these API into Cuprate will help at mitigating the damage of a potential bug or exploit if it ever happens, by attempting to enforce a more precise execution of the [Principle of least privilege](https://en.wikipedia.org/wiki/Principle_of_least_privilege).

## How

If available on the platform, Cuprate will use the native OS API to sandbox itself. Cuprate will attempt to restrict iself to only
access and interact with the resources it needs (Configuration, database and network) and nothing else.

### Linux

Linux have a wide variety of options to enable a process isolation:

| Method      | Benefits   | Min.Version | Potential crates | Notes |
|-------------|------------|-------------|------------------|-------|
| [seccomp-bpf](https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html) | syscall filtering | Linux kernel 3.17 | [seccompiler](https://crates.io/crates/seccompiler) | [A lot of software uses this method](https://en.wikipedia.org/wiki/Seccomp#Software_using_seccomp_or_seccomp-bpf) |
| [landlock](https://www.kernel.org/doc/html/latest/userspace-api/landlock.html) | File access control | Linux kernel 5.13 | [landlock](https://crates.io/crates/landlock) | Landlock have recently received the ability the restrict unix socket (which was impossible before). But we cannot count on very recent feature for compatibility purposes |
| [user namespaces](https://www.man7.org/linux/man-pages/man7/user_namespaces.7.html) | Resources/File access control | Linux kernel 3.8 | libc | Double-edged sword. While many praises user namespaces for its isolation capabilities, it is also a trivial way to acquire significantly more kernel attack surface. It is also very difficult to implement |

#### Apparmor&SELinux

These are external access control that requires a policy. Cuprate process have no involvements in setting up these access controls methods.
An example Apparmor/SELinux policy could be maintained if wished.

#### SUID helper

Some software have historically made great use of SUID binary to setup new chroot and other kernel namespaces to sandbox their application. This is bad for security:
- It requires to build another binary.
- It should absolutely be safe from any vulnerability (impossible). (as SUID bit will immediately elevate the binary as root).
For more informations on why Chromium has been transitioning to unprivileged namespaces: https://issues.chromium.org/issues/40338793

#### Additional options

`yama_ptrace` could apparently be used to mitigate compromised processes from inspecting other processes memory (of the same user).

### Windows

The only available option is using built-in permissions system in Windows API. See [Chromium Windows sandbox architecture](https://chromium.googlesource.com/chromium/src/+/HEAD/docs/design/sandbox.md#Sandbox-Windows-architecture)

### MacOS

There is an [available API for Swift and Objective-C program](https://developer.apple.com/documentation/security/app-sandbox) to enable a permission sandbox. However, whether this can be used
by other programming languages is unknown.