Threat model FAQ

Short answers to the questions security reviewers actually ask. The full reasoning is in the security model.

Can a user read their own central recordings?

No. The central store is root:root 0700 and recordings are 0600. Users cannot read anyone's central recordings — including their own. That is the point: a user who could read their own recording could also judge what the audit trail contains.

Can a user submit a session as someone else?

No. The socket is world-connectable (0666) so any user can submit their own session, but the daemon authenticates every connection with SO_PEERCRED — the kernel reports the peer's UID, and the session is attributed to that UID. Client-supplied identity is never trusted.

Can a user avoid being recorded?

Yes — and Ghost Shell says so plainly. The auto-record hook and ForceCommand wrapper are deliberately fail-open; a determined user with shell access can start an unwrapped shell. Non-circumventable capture would need PAM or kernel hooks, which this project does not implement. See the integrity caveat.

Can root read recordings?

Yes. Root is inside the trust boundary — the store, the key, and the daemon are all root-owned. The optional playback password adds a second factor on top of root (useful against a shared root account or a stolen session), but it is not protection from a hostile root.

What stops root from deleting the key?

chattr +i. The key cannot be removed or rewritten — even by root — until someone runs chattr -i, which is a deliberate, auditable act. On filesystems that ignore the immutable attribute (overlayfs, tmpfs, many network mounts) the daemon detects this and logs a loud warning. If the key is lost, recordings are unreadable, and the daemon refuses to start while encrypted recordings exist — loss is loud, never silent. Back up the key.

Does session data ever leave the machine?

Not by default. Recording, storage, search, and replay are all local. analyze talks only to a loopback Ollama endpoint unless you explicitly pass --allow-remote. The only data that leaves the box is a backup you configure yourself.

What happens when the disk fills?

The daemon logs a DISK FULL error naming the path, terminates the affected session cleanly, and keeps serving other users. New recordings fall back to user-local files and are ingested later. Fail loud, not silent-corrupt.

Can a crafted session ID or symlink escape the store?

No. Session IDs are validated at every ID-to-path entry point (../../etc/passwd, absolute paths, embedded NUL and friends all fail closed), and ingest admits only regular .cast files — a symlink pointing at /etc/shadow is refused. Both were adversarially tested in the audit.