# New functionality

## Other "sandboxing" features
https://chromium.googlesource.com/chromium/src.git/+/HEAD/docs/linux/sandboxing.md#User-namespaces-sandbox

User namespaces option? Something like:

rust
```
SafetyContext::new()
.isolate_process()
``` 

using unshare maybe? https://docs.kernel.org/userspace-api/unshare.html unshare is a bit tricky because e.g. newpid doesn't actually unshare the current thread, only its children. so maybe it would be better with a wrapper around creating a thread like ctx.run below.

Maybe even a macro similar to tokio::main? is something like 

```
fn my_context() -> SafetyContext {
}

#[extrasafe::main(my_context)]
fn main() {
	foo();
	//...
}
```

possible? it should ideally also work transparently with tokio::main as well as long as you put it first

see also https://blog.lizzie.io/linux-containers-in-500-loc.html

## custom landlock configurations?
more than just file read/write path create/list/delete
unix socket, named pipe, character device, symlink, deny truncate, etc

## Simple mode

Something either like "Network::everything()" (rather than Network::nothing etc) and "SystemIO::everything" or a separate wrapper over the existing RuleSet mechanism.

# Nice to haves

- convenience function to enable ssl cert directories with landlock
- convenience function to enable dns files/directories with landlock
  - update examples to use them

- more builtin profiles
	take inspiration from pledge promises (https://man.openbsd.org/pledge.2)
	and systemd profiles https://github.com/systemd/systemd/blob/main/src/shared/seccomp-util.h
		https://github.com/systemd/systemd/blob/3989bdc1ad7cca4d75c06cdf601fea2cb37ba337/src/shared/seccomp-util.c#L285
	see also old rkt allowlist https://github.com/rkt/rkt/blob/master/stage1/init/common/seccomp_wildcards.go

- benchmarks
  - only allow fs access and run ripgrep, compare vs without
  - only allow network access and run warp or actix server
  - more complicated example involving server thread + fs writer thread vs no separation?
  - *just re-use existing libraries' benchmarks and add extrasafe calls*
  - make sure we're using a separate benchmark profile/cfg so that those dependencies aren't pulled in to ci

- script (maybe already exists in libseccomp or systemd or firejail etc.) or extrasafe "util" API that you can run your tests with and it prints out the syscalls used
  - could even match against built-in profiles and make suggestions

- ctx.run(|| func)
  rather than loading into the current thread, start a new thread and load the context just into that thread. additionally would make it easier/possible to use some of the unshare functionality built into clone
- extrasafe! macro
  sugar over run() + get return value over channel
  need to determine what syscalls crossbeam channels need (if any) vs flume (if any) (std mpsc is going to be deprecated)
  - feature flag for macro with return value over channel
- something to orchestrate "run these subthreads with these contexts but don't start them until the parent thread's context is loaded"
  see halldisplay/render/src/main.rs

# Multiplatform
bsd: pledge
osx: Seatbelt (`sandboxd`), see gaol below
windows: ProcessSystemCallDisablePolicy?, see chrome

see
https://github.com/servo/gaol/
and chrome?

# Remove all dependencies
If you're using extrasafe to provide extra security, it then becomes a target for vulnerabilities, including supply-chain attacks.

### syscalls
Relatively easy to remove by copying directly into the repository, but comes with a maintenance burden of having to update the lists when new syscalls are created.