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 b228fec07e Let the shell user install packages with pacman 
The root user now owns the whole MSYS2 installation and can run pacman. The
login path the journey depends on - the sshd, the login shell zsh and cat - is
kept as a protected copy in C:\msys2\opt\kik that only SYSTEM and the
administrators may write, and the sshd runs as SYSTEM from there (the new
KiK sshd task; the msys2-sshd service is disabled). Replacing the user's own
/usr/bin/sshd therefore cannot touch the running server.

opt/kik is two levels below C:\msys2, so its runtime resolves the same
installation root and the login shell and the user's tools share one cygwin
runtime. A separate second installation does not work: two runtimes in one
process tree corrupt each other's file descriptors and pacman cannot lock its
database.

/etc/passwd and /etc/ssh are read-only to the user, /opt/kik is first on PATH
so cat README survives even if the user deletes their own /usr/bin/cat, and
the restore task rebuilds the protected copy and re-applies the permissions
every 30 minutes.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-10-25 21:37:55 +01:00

4.1 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.

Packages

The root user owns the whole MSYS2 installation and can install packages with pacman. That means they can also replace or delete the very programs the login needs. So the sshd, the login shell zsh and cat are kept as a second, protected copy in C:\msys2\opt\kik, which only SYSTEM and the administrators may write. The sshd runs as SYSTEM from that copy and the login shell is that copy's zsh, with /opt/kik first on the path, so the journey keeps working no matter what the user does to their own /usr/bin. Replacing /usr/bin/sshd cannot touch the running server, so the key on the website still never grants administrator access.

The copy has to be the same MSYS2 installation, not a second one: C:\msys2\opt\kik is two levels below C:\msys2, so its runtime resolves the same root and the login shell and the user's own tools share one cygwin runtime. A separate installation does not work - two runtimes in one process tree corrupt each other's file descriptors and pacman cannot even lock its database.

/etc/passwd (the login shell and home directory) and /etc/ssh (the host keys and config) are read-only to the user as well; everything else in the installation is theirs.

The cleanup tasks

Two scheduled tasks run as SYSTEM, both at startup, and the user cannot stop either:

  • KiK sshd runs the sshd from C:\msys2\opt\kik. It replaces the installation's own msys2-sshd service, which is disabled.
  • KiK restore shell files runs every 30 minutes and rebuilds the protected copy from its trusted originals, re-applies the permissions, and puts the home directory, the shell configuration, the website's key and the four texts back. Its second job is to best-effort revert other mockery and bring a fresh 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.