chore: propose process splitting for Linux (#4153)

rust/gui-client/docs/process_split.md

@@ -0,0 +1,43 @@
+# Process split
+
+This is meant for Linux, but it will probably be similar on Windows.
+
+## TODO
+
+- Are splitting the process for just the GUI client, or for CLI too?
+
+## Decisions
+
+- The CLI and GUI client packages will have a `conflicts` tag, at least for now.
+- Eventually, Clients and Gateways will be allowed to run on the same host, so avoid conflicts there
+- If the service account token exists, we are in service mode and won't accept connections from a GUI client, even if the token is invalid.
+
+## Binaries
+
+I gave them new names to clarify.
+
+1. `firezoned` - A daemon that runs the tunnel and has elevated privilege
+2. `firezonectl` - A CLI program that runs unprivileged and exits once each operation is complete, like `systemctl` or `nmcli`
+3. `firezone-gui` - An unprivileged GUI program that keeps an icon in the system tray / notification center and is similar to `firezonectl`
+
+## Docker
+
+`firezoned` runs all the time. You can do `docker exec` to run `firezonectl` within the container.
+
+## Desktop
+
+`firezoned` is started as a systemd service. It tries to find a service account token and use that. If there is no service account token, it waits for a GUI to connect over IPC.
+
+`firezone-gui` performs auth using deep links and sends the token to `firezoned`.
+
+## Security concerns
+
+Given a group `firezone` and users `firezone-user` (Belonging to a Firezone Actor) and `other-user` (Belonging to another person):
+
+- What if an attacker has root? (That is outside scope, we can't protect from that.)
+- What if malware is running as `firezone-user`? (Then it can command the tunnel to sign out, and possibly steal tokens depending on how the desktop keyring works.)
+- What if `firezone-user` signs in to Firezone, then `other-user` signs in to Linux and uses Resources under `firezone-user`'s name? (We can't help that, the tunnel is system-wide. Per-app permissions may come after GA.)
+- How does the UI know that it's connected to the real tunnel? (The tunnel claims a privileged D-Bus address or listens on a socket that no other service would be allowed to listen on)
+- What if `other-user` tries to sign out the tunnel using `firezonectl`? (The tunnel should be able to check the GID of incoming IPC connections and refuse the command, same as Docker does)
+- How does the tunnel know that it's getting IPC commands from a real UI binary? (It doesn't. Permissions belong to users, not to binaries.)
+- What if an "evil maid" reads the hard drive of a system while it's in a hotel room? (Service account tokens would be compromised, but hopefully interactive GUI logins would be secured by the desktop's keyring)