Finalize `sandbox_permissions` configuration option

I think a good solution to this problem would have the following properties:

• Supports having a preset (like --full-auto) to use as a "base configuration," to which additional rules can be applied on top. These "additional rules" can add or remove priviliges.
• Produces an internal sandbox policy abstraction that can be directly translated into rules that both Seatbelt and Landlock can implement.
• Also has a succinct way of declaring "do not run commands in a sandbox [because my execution environment provides sufficient sandbox guarantees and/or I am choosing to take the risk of not using a sandbox]."
• Introduces one flag (that can be specified multiple times and have a complex type) to the CLI instead of having individual flags for each permission type.
• Can be expressed succinctly in config.toml.

In principle, we have three types of permissions today:

• disk read
• disk write
• network access

Roughly, each permission could have "three" settings:

• full
• none
• custom

Though certainly "custom" is where things get dicey. Currently, we do not even support "custom" configuration for disk read or network access (only all or nothing), but the customization for disk write is a bit complicated because we support specifying exact folders as well as more "declarative" type things like disk-write-cwd.

Spitballing, perhaps introducing support for enable- and disable- prefixes would make it more straightforward to build on top of a sandbox preset:

--full-auto -s enable-disk-write-platform-user-temp-folder -s enable-disk-write-folder=/Users/mbolin/.pyenv/shims

though then perhaps the TOML would have to look something like:

sandbox_base = "full-auto"

sandbox_permissions = [
    "enable-disk-write-platform-user-temp-folder",
    "enable-disk-write-folder=/Users/mbolin/.pyenv/shims",
]

which seems distasteful.

It also reinforces this issue where --full-auto is overloaded to provide a base config for both sandboxing and approvals.

Maybe something more like:

# Use a read-only sandbox.
-s read-only-preset

# World readable, only cwd is writable, network disabled, and then include two additional writable folders.
-s write-cwd-preset -s enable-disk-write-platform-user-temp-folder -s enable-disk-write-folder=/Users/mbolin/.pyenv/shims

# Commands are never run inside a sandbox.
-s dangerously-operate-without-a-sandbox-preset

In this scheme, the TOML has one sandbox-related config option, which is always a list:

sandbox = [
    "write-cwd-preset",
    "enable-disk-write-platform-user-temp-folder",
    "enable-disk-write-folder=/Users/mbolin/.pyenv/shims",
]

Note that overriding sandbox as defined in config.toml on the command line would effectively be easier to do via -s than via -c because -c would only support redefining sandbox outright rather than amending entries to the existing list.

In other words, -s args would have to satisfy one of the following conditions:

• start with enable-
• start with disable-
• end with -preset

In the header in the TUI, the sandbox entry would likely be more succinct than it is today since we wouldn't expand the preset definition there.

We would also have to define what happens if multiple preset- values are passed via -s as well as what happens if -s dangerously-operate-without-a-sandbox-preset is used in combination with disable- options...

Revisiting this issue, I think my last proposal is too verbose. For example, there should be a limited set of presets, so the -preset suffix should be unnecessary since we can ensure their names not overlap with other options. Similarly, enable- should be far more common than disable-, so we should omit the enable- prefix, as it should be an implicit default.

In practice, today we have three "sandbox presets" that we want to support:

• global read; no writes; no network
• global read; write cwd [and tmp?]; no network
• no sandbox

In terms of "relaxing" the sandbox, the only thing we really let you do is add more writable roots. (Though we might want to let users enable network while still limiting writes?)

As far as naming these preset modes, we could go with:

• read-only
• workspace-write
• danger-full-access

And perhaps to simplify things, we require a "base mode" (defaults to read-only) and any further sandbox permissions must be "additive" to the mode that was originally specified.

Here is a simpler scheme:

• specify sandbox mode, one of: read-only, workspace-write, danger-full-access
• users can specify additional writable roots (ignored in danger-full-access mode)
• users can enable network (ignored in danger-full-access mode)

For now, there is no way to disable global read-only access (or restrict it to a specific set of folders), but we can consider that later, if appropriate.

In the config file, this would look like:

# Defaults to "read-only". Can specify via CLI using `-s/--sandbox MODE`.
sandbox = "workspace-write"  # or "read-only" or "danger-full-access"

# Optional list. Can add to list via CLI `--sandbox-writable-root PATH`.
# Seems rare enough that it does not need a short-form arg name?
sandbox_writable_roots = [
    "/Users/mbolin/.pyenv/shims",
    "/tmp",
]

# Defaults to false. For now, no special CLI arg, though the more generic `-c sandbox_network_access=true` will work.
sandbox_network_access = true

Upon further consideration, a better config file format is probably:

[sandbox]
mode = "workspace-write"
writable_roots = ["/tmp"]
network_access = true