Threat model: teams and devices

This continues the threat model for the sync server and the network.

A team member, or a former one

What holds

The server enforces who may view, edit or manage each vault. A removed member gets nothing new, since the next key rotation leaves them out. A port forward from a team vault, or one that listens beyond this device, starts only after you approve it on this device. A team host another member changed (address, jump hosts, login, startup command and more) stops before connecting, says who changed what and when, and asks. A team vault can’t turn on agent forwarding beyond your own setting, and a host key you accepted yourself wins over a team vault’s.

Where it ends

• A member with edit access can still write misleading items: a host they made, a snippet, a known host for a host nobody trusted before. The prompts make changes visible; they don’t judge them.
• The “changed by” name is the writer’s own claim. A dishonest member can put another member’s name there.
• Removed members keep the keys and items they synced before. Rotation protects only what’s written afterwards, so change credentials they may have seen.
• “Can view” is enforced only by the server. A viewer’s devices hold the vault key and could read all of it.

A team admin, and team policies

What holds

An admin can sign only what the owner allowed, and every device checks each change against the team’s rules before using it. So an admin can’t take the owner’s powers, grant access they don’t have, or relax a policy past what the owner allows. Each member’s app applies policies from the signed list. They never loosen a member’s own setting, and a team whose policy a device can’t read is refused, not treated as having none. Device reports are signed with each member’s own key, so the server can withhold them but not forge them.

Where it ends

A modified app can ignore app policies, and a malicious server can skip server policies while showing them as on. Admins who collude, or an admin with the server, can do what each may do; the owner sees every signed change and can revert relaxations. The server can read policy values and reasons.

Other apps on the phone

The app’s data is left out of Android backups. Only its main screen and its own links are open to other apps, and links into it (ssh://, sternway://) connect only after you confirm and never use a password from the link. The lock screen covers every screen and the recents preview. Screenshots are blocked while a secret is shown, or always with Block screenshots. Secrets copied to the clipboard are marked sensitive.

Malware or another user on the computer

What holds

The app’s data is sealed with a key the operating system’s keychain holds, its files are readable only by your user, a profile won’t open on another account or computer, and the window runs sandboxed with a strict content security policy.

Where it ends

• Malware running as you can read the keychain, the app’s memory and its files, as you can. Sternway isn’t a defence against it.
• The app lock is a screen. While the app is locked, the keys it already unlocked stay in memory, so it stops someone at the keyboard, not malware.

Imported files

An import never runs ProxyCommand, LocalCommand or Match exec from a file. A ProxyCommand runs only from your own linked ~/.ssh/config, which never syncs. Imports are previewed, read only regular files of 16 MiB or less, list every key file they’d read (none ticked for a team vault), and snapshot before replacing anything. CSV exports write formulas as text.

Where to read more

• How teams and trust work
• What leaves your device