61 lines
3.3 KiB
Markdown
61 lines
3.3 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`. They can delete it, but not change where it is.
|
|
- `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.
|
|
- The website can log in: the key it uses is in `~/.ssh/authorized_keys`. That key gets access to the `root` user
|
|
only, never to the Administrator account.
|
|
|
|
Modifying the four files is allowed; the next cleanup undoes it. Deleting them is not permanent either.
|
|
|
|
The user may add keys of their own to `authorized_keys`; they stay. The key of the website is put back, so that the
|
|
site keeps working. The user owns their home directory, so they can always delete the file - nothing on Windows can
|
|
stop them from that - but the next cleanup brings it back. Until then, the site cannot log in.
|
|
|
|
## 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: the entry in `/etc/passwd` with the home directory and the shell, because
|
|
`/etc` is read-only for them, 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.
|
|
|
|
It creates `/home/root` if it is gone, and puts the copies from `C:\ProgramData\kik-restore\files` back into the
|
|
home directory: the shell configuration, the keys and the four text files. Anything that is not a regular file is
|
|
replaced, so that the files cannot become anything but text.
|
|
|
|
## 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, with the personal key of the deployer. The key of the
|
|
website never gets administrator rights. `--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
|