Am gestrigen 28.01.2019 gegen ca. 16:00 Uhr haben wir festgestellt, dass die Berechtigungen von /usr/bin/python auf dem Host vela.uberspace.de mit einem Setuid-Bit versehen waren. Das bedeutet, dass jeder User mittels dieses Python-Interpreters Code als root-User mit vollem Zugriff auf das gesamte System ausführen könnte. Wir haben insofern nach erster kurzer Analyse den Host um 17:33 Uhr aus Sicherheitsgründen komplett gestoppt. Eine umgehende Betrachtung aller anderen Hosts hat nichts Vergleichbares ergeben. Wir haben offline eine umfangreiche Bereinigung des Hosts vorgenommen und ihn am heutigen 29.01.2019 um 13:46 Uhr wieder hochgefahren. Wir haben allerdings den Start von User-Applikationen (dynamische Websites, eigene Services, Cronjobs, …) soweit möglich angehalten.

Ein Hinweis von dictvm auf einen Blogpost bei The Hacker News hat uns aufhorchen lassen:

Beware! If you have downloaded PHP PEAR package manager from its official website in past 6 months, we are sorry to say that your server might have been compromised.

tl;dr: Der auf pear.php.net bereitgestellte Installer go-pear.phar ist seit rund 6 Monaten kompromittiert. Wenn du den von uns bereitgestellten PEAR-Paketmanager verwendet hast, gibt es - nach derzeitigem Kenntnisstand - insofern keinen Anlass zur Sorge. Solltest du in den letzten 6 Monaten PEAR selbst über go-pear.phar installiert haben, hast du vermutlich eine kompromittierte Version erwischt und solltest jene dringend gegen eine neue, saubere Version austauschen.

First things first: Es gibt nun einen fertigen Vertrag zur Auftragsverarbeitung, der den Segen unseres externen Datenschutzbeauftragen bekommen hat. Du findest ihn unter https://uberspace.de/dpa und wir haben alles vorbereitet, damit du ihn Anfang ab nächster Woche im Dashboard per Klick abschließen kannst. Du kannst ihn insofern bereits lesen und prüfen oder prüfen lassen, beispielsweise durch deinen Datenschutzbeauftragten, und dann nächste Woche deinen Klick setzen.

Was noch fehlt, ist die Abnahme unseres Entwurfs zur Dokumentation der technischen und organisatorischen Maßnahmen durch unseren externen Datenschutzbeauftragten - dessen Workload, wie man sich vielleicht vorstellen kann, im Rahmen allgemeiner DSGVO-Panik gerade durch die Decke geht und der wundersamerweise dennoch Zeit findet, sich jedwedes Dokuments innerhalb von 2-3 Werktagen anzunehmen. Die vorige von uns gelieferte Fassung fand bereits Zuspruch und bedurfte nur noch geringer Änderungen an der Struktur des Dokuments, so dass die letzte Abnahme nur noch eine Formalität ist.

• Wir hatten uns in der Entwicklung darauf verständigt, virtuelle DocumentRoots - ein Feature von U5 und U6 - bei U7 nicht mehr als Feature anzubieten, sondern im Lauf der U7-Beta ein neues Dashboard zu releasen, mit dem es viel einfacher sein wird, mehrere Uberspaces zu verwalten, so wie wir uns das als “best practice” vorstellt haben. (Der Plan mit dem neuen Dashboard besteht natürlich weiter, und die Arbeit daran hat auch schon begonnen.)
• Wir haben schon damit gerechnet, dass diese Entscheidung erläuterungsbedürftig werden könnte. Der Widerspruch etlicher User traf uns allerdings in größerem Umfang, mit stärkerer Enttäuschung und mit Argumenten, die wir zu bedenken hatten. Wir wollten keinen “Okay, okay, okay”-Schnellschuss machen und unsere Entscheidung einfach wieder umwerfen, aber wir haben uns mit Usern ausgetauscht und Argumente und Use Cases eingesammelt, darüber gesprochen, und am Ende haben wir beschlossen, die virtuellen DocumentRoots entgegen der ursprünglichen Planung auch auf U7 einzuführen.
• Nach wie vor raten wir deutlich davon ab, dieses Feature zum Hosting mehrerer unterschiedlicher Projekte in einem Account zu verwenden, weil zwischen jenen Projekten dann keine Rechtetrennung besteht. Wenn Rechtetrennung wichtig ist - und das ist sie im Zweifelsfall fast immer - solltest du wie bisher dem Rat folgen, mehrere Uberspaces anzulegen. Wir werden das vereinfachen, versprochen.

Worum geht’s eigentlich?

Vom Konzept her ist ein Uberspace dazu gedacht, ein Projekt darauf zu hosten. Dafür wird /var/www/virtual/<user>/html als DocumentRoot angeboten. Schon ziemlich in der Anfangszeit trafen Fragen bei uns ein, ob man da nicht die Möglichkeit schaffen könnten, für kleinere Sachen einfach separate Verzeichnisse anzulegen, um keinen separaten Uberspace dafür anzulegen - “das lohnt doch gar nicht”. Wir waren mit Uberspace gerade erst gestartet, voller Tatendrang, ein wenig blauäugig vielleicht auch, und dachten uns: Klar, basteln wir doch schnell eine RewriteRule, und schon war das Feature geboren: User konnten ab sofort in /var/www/virtual/<user> einfach weitere Verzeichnisse ablegen, die so hießen wie Hostnamen, und schon wurden Anfragen nach jenen Hostnamen aus diesem Verzeichnis bedient (vorausgesetzt, der Hostname wurde auf den Uberspace aufgeschaltet). So weit, so gut - oder besser gesagt: So weit, so okay.

Welche Features machen die Beta schon heute besser als U6?

• vollautomatisches HTTPS-Handling mit Let’s Encrypt für alle Domains
• HTTP wird grundsätzlich auf HTTPS umgeleitet
• Diverse Security-Header werden als Default gesetzt
• wir unterstützen nun HTTP/2
• OCSP Stapling
• PHP ohne Startverzögerungen (eigene PHP-FPM-Instanz pro User)
• user.uber.space & *user*@uber.space
• MariaDB 10.1 ohne Klimmzüge
• insgesamt deutlich frischere Toolchain an Kommandozeilentools
• Webserver-Logging ist nun standardmäßig komplett aus (Datensparsamkeit FTW!), kann aber auf Wunsch eingeschaltet werden und liefert dann Logs mit gekürzten IP-Adressen
• komplett neues Handbuch auf manual.uberspace.de - aus einem Guss, auf Englisch, mobiltauglich und mit ChangeLog
• supervisord als leistungsstärkerer daemontools-Nachfolger zum Verwalten eigener Daemons

Was ist sonst noch fertig?

• Python 2.7, 3.4, 3.5, 3.6
• PHP 5.6, 7.0, 7.1, 7.2
• Perl 5.16.3
• Lua 5.1
• GCC 4.8 (C/C++)
• Cronjobs
• Subversion
• SQLite 3
• node.js 6, 8, 9
• virtuelle Mailuser (vmailmgr)
• maildrop
• ruby
• Adminer und phpMyAdmin
• Webmail
• Rspamd als Ersatz für SpamAssassin und DSPAM

Was kann die Beta noch nicht?

• Programmiersprachen: Ruby, Erlang und node.js
• Datenbanken: PostgreSQL, CouchDB und MongoDB
• virtuelle Mailuser (vmailmgr)
• Backups im direkten Userzugriff (wir machen durchaus Backups, aber der Zugriff ohne Support-Eingriff darauf fehlt noch)
• Adminer und phpMyAdmin
• Handbuch auf Deutsch
• ezmlm-idx
• maildrop
• gitolite 3
• Ports öffnen
• 2-Faktor-Authentifizierung für SSH
• Redis
• SpamAssassin
• Webmail

Welche Features werden wir auch nicht mehr einbauen?

• gitolite (ersetzt durch gitolite 3)
• DSPAM (unmaintained)
• daemontools (unmaintained, ersetzt durch supervisord)
• toast (unmaintained)
• CVS (unmaintained)
• Namensräume für Mail-Domains (hohe Komplexität und ein Support-Albtraum; nutze lieber separate Uberspaces dafür)
• Hostnamens-Verzeichnisse in /var/www/virtual/USER (hoher Supportaufwand, da technisch nicht 100% kompatibel zu echten DocumentRoots; motiviert zum Hosting unterschiedlichster Applikation im gleichen Account und vereinigt die Sicherheitsrisiken aller jener Applikationen; nutze lieber separate Uberspaces dafür)

Wie komme ich an einen U7-Beta-Account?

Auf https://uberspace.de/register?u7=1 bekommst du eine Checkbox angeboten, mit der einen Account auf U7 statt auf der derzeit stabilen Version U6 anlegen kannst.