Tamper resistance

Anyone with root access can interfere with any software on their own machine, shellz included. What shellz guarantees is that interference is undone where possible, and always reported: shellz can't be disabled quietly.

On a serverCopy Anchor Link

The recorder serviceCopy Anchor Link

The shellz-recorder systemd unit is set up so that:

• systemctl stop shellz-recorder is refused (RefuseManualStop=yes);
• if the process is killed or crashes, systemd restarts it after one second, with no limit on restarts, and shellz raises a tamper alert on the next start;
• the kernel's out-of-memory killer avoids it, and it doesn't produce core dumps;
• the process can't be inspected with ptrace by unprivileged users.

Continuous repairCopy Anchor Link

Every 15 seconds, and immediately when /etc/passwd changes, the agent checks and repairs:

• the shellz binary and session shell;
• the recorder unit file, and whether it's enabled and running;
• the login shells of recorded accounts;
• the SSH drop-in that turns off ~/.ssh/rc;
• the SELinux policy module and file labels, where SELinux is enabled;
• on Docker hosts, the Docker socket and drop-ins (checked every second).

Each repair raises a tamper-repaired alert describing what was changed. shellz files are also marked immutable (chattr +i), so changing them first requires removing the flag.

Sessions that avoid the recorderCopy Anchor Link

A session auditor looks for login sessions on the server that didn't go through the session shell, for example a login using a service account with a shell set by hand. Unless the recording policy is fail-open, it ends them and raises unrecorded-session-terminated. Under fail-open it raises unrecorded-session and lets them continue.

RemovalCopy Anchor Link

shellz uninstall only works after an owner or admin has approved removal of that server in the dashboard, which sends the server a signed policy that allows it. Without that, the command is refused and an uninstall-refused alert names the account that tried. See Updates and removal.

Going silentCopy Anchor Link

A server that stops sending heartbeats, for example because it was shut down, cut off from the network, or shellz was forcibly removed, is marked offline after 90 seconds and raises a heartbeat-missing alert. When it comes back, heartbeat-recovered is raised.

Inside containersCopy Anchor Link

In containers, shellz runs as PID 1:

• kill -9 1 from inside the container has no effect, because the kernel doesn't deliver unhandled signals to PID 1 from inside its own namespace.
• The exec watcher finds sessions that bypass the shell shim within 500 ms. Under fail-closed, unrecorded sessions with a terminal are killed and raise unrecorded-container-exec.
• Stopping the container stops the workload too, and is reported as stopped with its reason and exit code. A container that disappears without a clean stop is shown as lost after 3 minutes.

RecordingsCopy Anchor Link

Once uploaded, recordings are protected by signatures, the hash chain and write-once storage with a 365-day retention lock. See Encryption.

A server also can't rewrite its own history: shellz refuses a segment that conflicts with one it already stored, and marks the session as tampered.

Policies and keysCopy Anchor Link

Servers only apply policies and org keys signed by your org, with a revision higher than the current one. Attempts to replay an older policy or substitute a key are refused and raise policy-rejected or org-key-rejected. With Perfect Secrecy, only your team's browsers can sign them.

LimitsCopy Anchor Link

• Root can still interfere, for example by editing memory, loading a kernel module, or cutting the network. shellz is designed so that these leave a trace: a gap in a recording, a tamper alert, or a silent server.
• In an unprivileged LXC container, chattr +i isn't available. shellz still repairs changes every 15 seconds and raises a single immutable-unsupported warning.
• In containers, someone with access to the node can enter a container's namespaces without going through kubectl exec or docker exec. Record node logins with a host install where you manage the nodes.

See Alerts for every alert and its severity.