cccb-website-team/kik-website
Watch
0
0
Fork
You've already forked kik-website
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
kik-website/server/README.md
Zebreus 49c61b6b91 Keep the shell configuration and the key out of the user's reach 
The user could empty the authorized_keys and break the login of the
website, change the shell configuration to break the prompt, and write
startup files that zsh reads on every login. The shell configuration and
the key are now read-only for the user, and the shell reads its
configuration from ~/.zsh, so the files in the home directory are
ignored.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-10-25 15:26:01 +01:00

2.7 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

Anything that breaks the following user journey is not acceptable:

  • The user can connect with the SSH key as root.
  • The prompt: root@khaos-im-kiez:~#, which ~/.zsh/.zshrc sets.
  • The home directory the user ends up in: /home/root. They cannot change where it is, and they cannot delete it.
  • 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.

So in summary running ssh root@nowhere.wirs.ing cat README must always succeed and display the contents of the file.

Anything thats not specified above (like the content of README for example) is NOT part of the user journey.

What we do not keep working

As long as the user story above does not break, we do not guarantee the functionality of anything else on the server. However the cleanup task should still try to best-effort restore everything to a working condition.

The cleanup task

The scheduled task KiK restore shell files runs every 30 minutes and at every startup, as SYSTEM. The user cannot stop it. Cleanup has two jobs:

  1. Act as a secondary safeguard to restore the essential files for the user journey above.
  2. Revert any other mockery the user did that might affect the system.

The second job should also be able to restore a new server to the expected state.

The files that have to stay belong to the administrators, so the user cannot delete them, and they cannot change the shell configuration or the key the website logs in with either. The shell reads its configuration from ~/.zsh, so the startup files the user could write in the home directory are ignored.

Installing the cleanup on the server

To deploy the cleanup task an the server, run:

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.