Magnemite
Operating it

Security model

What holds a token, what is stored, and what the root agent will not do.

Tokens

  • Each device gets its own bearer token; only its sha256 is stored. Artifact downloads are gated on it, through Caddy's forward_auth, or the hub's own check when it serves the files.
  • The enrollment token is dropped from the box's config once it has traded it for a device token, so a stolen box cannot enroll more devices.
  • Enrollment tokens can be limited by use count and revoked from Settings.

The dashboard

  • Sessions are Better Auth cookies signed with AUTH_SECRET (request check in MAGNEMITE_DASHBOARD_URL).
  • Sign-up is disabled; accounts are only created by you in the .env file.
  • Every server action re-checks the caller's role.

The internal API

The hub's /internal/* API is reachable only from the web container, behind HUB_INTERNAL_SECRET, and neither proxy routes to it from outside. On the agents' domain, anything that is not /ws/device, /api/enroll, /files/* or /healthz is a 404.

The agent

It runs as root but changes no device settings of its own accord (by default). It installs, reads package versions and free space, collects logs when asked, writes the MITM config its group declares, and runs the shell you gave it: the pre/post-install hooks, and whatever an operator types into Execute.

It refuses a path that is relative or un-normalised, anything under /system, /vendor, /product, /apex, /proc, /sys, /dev or /boot, and its own config.json (holds the agent device token).

A MITM config holds credentials of its own: a bearer token, a device auth token, an account email. It is never written to the hub's log, never into an audit entry.

adb keys

Adding a box over adb needs the box to trust a key, and an adb key on a box that has su is an unrestricted root shell on it. So the keys are handled as the credentials they are:

  • The hub has one keypair, generated on first use and kept in the database — not on the artifacts volume, which is served, and where a file called adbkey would be downloadable by anything holding a device token.
  • Each machine keeps its own, in /etc/magnemite/adb, generated the first time it is asked to relay. The hub's private key is never sent anywhere. One compromised relay is then root on the boxes that trusted that machine, not on the fleet.
  • Settings → Enrollment → adb keys offers all of the public halves as one adb_keys file to preseed into a golden image. Removing a machine from that file and reflashing is how a key is revoked; there is no way to un-trust one on a box that is already running except to edit /data/misc/adb/adb_keys on it.

Network adb is worth turning off on a box once it is enrolled. The agent never needs it again — it dials out, and every later update rides that socket.

Integrity of what gets installed

The hub computes a sha256 while caching a bundle. Every agent verifies that hash before it opens an install session, and verifies with dumpsys package that the expected version is really installed afterwards. pm printing Success is not taken as proof.

What to rotate, and when

SecretRotate when
HUB_INTERNAL_SECRETAnyone who had shell on the server leaves. Restart hub and web together.
AUTH_SECRETSame, note it signs out every session.
Enrollment tokensA batch is flashed and done, or a laptop with the token on it goes missing.
A device tokenThe box is lost or reimaged: delete the device, let it enroll again.
The hub's adb keyA hub server is compromised. Delete the AdbIdentity row, then reseed adb_keys on the boxes — until you do, they still trust the old one.

On this page