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.

firezoned - A daemon that runs the tunnel and has elevated privilege
firezonectl - A CLI program that runs unprivileged and exits once each operation is complete, like systemctl or nmcli
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)

2.6 KiB Raw Blame History