e48e0644ba
It logs in as Administrator, whose shell is a Windows one, copies the scripts and the resources to the server and runs the installer there. It uses the key the website uses and checks the host key against the one the website pins. Co-Authored-By: Claude Code <noreply@anthropic.com>
81 lines
4.1 KiB
Markdown
81 lines
4.1 KiB
Markdown
# 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.
|
|
|
|
Neither the setup nor the cleanup ever runs as the `root` user. The setup runs in an elevated PowerShell, as an
|
|
administrator, and refuses to run without those rights; the cleanup runs as SYSTEM. The `root` account is a
|
|
different one, without administrator rights, and it never executes any of it.
|
|
|
|
What the cleanup does:
|
|
|
|
1. Creates `/home/root` if it is gone, and gives the `root` account write access on it.
|
|
2. 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
|
|
|
|
- `shell/` - the shell configuration, `~/.zshrc` and `~/.zshenv`, which is where the prompt is set.
|
|
- `resources/` - the copies the cleanup restores from: the shell configuration and the four text files.
|
|
- `scripts/make_files.py` - builds the resources.
|
|
- `scripts/deploy.sh` - deploys the cleanup to the server and installs it.
|
|
- `scripts/install_restore_task.ps1` - installs the scheduled task.
|
|
|
|
The resources are built from the website's pages and the shell configuration:
|
|
|
|
python3 server/scripts/make_files.py
|
|
|
|
## Installing the cleanup on the server
|
|
|
|
server/scripts/deploy.sh
|
|
|
|
The script logs in as `Administrator` - whose shell is a Windows one - copies the scripts and the resources to the
|
|
Administrator's home directory and runs the installer there. It uses the key the website uses, which is authorized
|
|
for the Administrator account as well, and checks the host key against the one the website pins. `--uninstall`
|
|
removes the task again.
|
|
|
|
The installer can also be run by hand, in an elevated PowerShell on the server:
|
|
|
|
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`.
|