Watch

Zebreus 23896bced5 Keep the shell server's basic user journey working

The cleanup job now restores the whole home directory instead of only
the four text files: the directory itself, the shell configuration that
gives the prompt, and the files. Anything that is not a regular file is
replaced, so the files stay text files.

The README in server/ describes the security model: the box is a
disposable VPS that may be compromised, the root user may do whatever
they want, and only the prompt, the home directory and the four files
are kept working.

Co-Authored-By: Claude Code <noreply@anthropic.com>

2026-10-25 13:02:25 +01:00

3.3 KiB

Raw Blame History

The shell server

The website's terminal connects to a shell server, whose root user logs in at wss://web.nowhere.wirs.ing and gets a shell on the box.

The security model

The box is an isolated, disposable VPS at a random hoster. We assume that it can be compromised and that this is acceptable: the worst case is that the gimmick on the website stops working. Nothing else is on the box. The website and the websocket bridge that carries the connection run on other servers, so a compromised shell server cannot get at them.

The root user on the box is a normal Windows account without administrator rights. It may do a lot of things there, including things we did not plan for. We do not try to contain it and we do not try to undo what it does. We only keep the basic user journey working.

What we keep working

The prompt: root@khaos-im-kiez:~#, which ~/.zshrc sets.
The home directory the user ends up in: /home/root. It is the one from the root entry in /etc/passwd, which the user cannot change, because /etc is read-only for them. They can delete their home directory, though.
cat README, cat README.en, cat CODE_OF_CONDUCT and cat CODE_OF_CONDUCT.en always work. The four files are always there and always regular text files.

Modifying the four files is allowed; the next cleanup undoes it. Deleting them is not permanent either.

What we do not keep working

Everything else. If the user breaks the shell, the packages, the disk or the connection, we fix that by hand or throw the box away. The cleanup does not try.

Two things that the user cannot break and therefore do not need to be restored: the entry in /etc/passwd with the home directory and the shell, and the host keys in /etc/ssh, which the website pins. The sshd runs as SYSTEM, so the user cannot restart it with a different key either.

The cleanup

The scheduled task KiK restore shell files runs every 30 minutes and at every startup, as SYSTEM. The user cannot stop it: the task, its script and the copies it restores from are readable and writable only by SYSTEM and the administrators.

What it does:

Creates /home/root if it is gone, and gives the root account write access on it.
Puts every copy in files/ back into the home directory: the shell configuration and the four text files.

Anything that is not a regular file - a directory or a link - is removed and replaced by the copy, so that the files cannot become anything but text. The contents are restored as well: the user may edit the files, the next run undoes that.

This directory

resources/ - the copies the cleanup restores from: the four text files and the shell configuration.
scripts/make_files.py - builds the four text files from the website's pages.
scripts/install_restore_task.ps1 - installs the scheduled task.

The four text files are generated, the shell configuration is copied from the server by hand:

python3 server/scripts/make_files.py

Installing the cleanup on the server

Copy server/scripts and server/resources to the server and run this in an elevated PowerShell:

powershell -ExecutionPolicy Bypass -File .\scripts\install_restore_task.ps1

The task runs as SYSTEM, so the root user can neither stop it nor change the copies it restores from. It also runs at startup. Remove it again with -Uninstall.

3.3 KiB Raw Blame History