From 8bad6a39d05d8ccaaca9d9690e088b161aa7ea95 Mon Sep 17 00:00:00 2001 From: Reactor Scram Date: Mon, 18 Mar 2024 11:24:19 -0500 Subject: [PATCH] chore: propose process splitting for Linux (#4153) --- rust/gui-client/docs/process_split.md | 43 +++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 rust/gui-client/docs/process_split.md diff --git a/rust/gui-client/docs/process_split.md b/rust/gui-client/docs/process_split.md new file mode 100644 index 000000000..f85d523f1 --- /dev/null +++ b/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)