kik-website/server

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