CageFS im Hosting-Alltag: Dateisystem-Isolation zwischen Kundenkonten

Warum Hosting-Konten Isolation brauchen

Beim Shared Hosting betreiben mehrere Kunden ihre Websites auf demselben Server. Wird ein Skript in Konto A kompromittiert, kann es versuchen, Informationen über die Umgebung zu sammeln und Dateien anderer Konten zu erreichen. Dazu können Konfigurationsdateien mit Zugangsdaten oder persönliche Daten gehören. Die Trennung der Konten soll solche Zugriffe erschweren, obwohl die Infrastruktur gemeinsam genutzt wird.

Dabei sind Sichtbarkeit und Zugriffsrechte unterschiedliche Fragen. Ein Verzeichnisname kann sichtbar sein, obwohl das Lesen seines Inhalts durch Dateiberechtigungen verweigert wird. Umgekehrt reicht eine eingeschränkte Ansicht allein nicht als Ersatz für sorgfältig gesetzte Rechte: Was innerhalb der Umgebung erreichbar ist, muss weiterhin passend geschützt werden.

CageFS ergänzt die Berechtigungen um eine benutzerspezifische Dateisystemumgebung. Ein Prozess im vorgesehenen Kontext erhält nicht einfach dieselbe Sicht auf den Host wie ein Administrator. Dadurch soll ein Skript aus Konto A fremde Kontoverzeichnisse nicht ohne Weiteres auskundschaften können. Welche Bereiche tatsächlich sichtbar sind, hängt von der Einrichtung ab.

Für Betreiber ist das eine zusätzliche Trennschicht, keine Zusicherung gegen jede Auswirkung auf andere Kunden. Fehler in gemeinsam genutzten Diensten, zu weit gefasste Berechtigungen oder eine unvollständige Dienstintegration können die Schutzwirkung beeinflussen. Deshalb muss die Isolation dort geprüft werden, wo Kundenprogramme tatsächlich ausgeführt werden, und nicht nur anhand einer Einstellung im Verwaltungsbereich.

Für Hosting-Kunden ist die Unterscheidung ebenfalls wichtig: Dass eine eigene Anwendung kein fremdes Verzeichnis sieht, beschreibt zunächst nur ihren konkreten Ausführungskontext. Es belegt weder die Konfiguration aller Dienste noch den Schutz sämtlicher anderer Konten. Für die übergreifende Einrichtung und Kontrolle bleibt der Anbieter verantwortlich.

Wie CageFS die Dateisystemsicht gestaltet

CageFS stellt Benutzern eine eigene Sicht auf das Dateisystem bereit. Grundlage ist das Skeleton: eine Vorlage mit Dateien und Verzeichnissen, die für die jeweilige Umgebung bereitgestellt werden. Benötigte Teile werden eingebunden; auch das eigene Home-Verzeichnis des Benutzers wird in dessen Umgebung integriert. Der sichtbare Verzeichnisbaum ist damit nicht einfach eine unveränderte Kopie der Host-Ansicht.

Die Einbindung lässt sich anhand eines Werkzeugs veranschaulichen: Ein Administrator installiert ein Programm auf dem Host, aber ein Kundenprozess findet es in seiner Umgebung nicht. Das ist nicht automatisch ein Installationsfehler. Das Programm kann auf dem Host vorhanden sein, ohne im Skeleton beziehungsweise über die vorgesehenen Einbindungen für den Kunden verfügbar zu sein.

Umgekehrt erweitert jede zusätzlich bereitgestellte Datei die Umgebung, die ein Prozess sehen kann. Dasselbe gilt für ein eingebundenes Verzeichnis. Betreiber müssen daher den Funktionsbedarf gegen die zusätzliche Sichtbarkeit abwägen: Eine Anwendung benötigt möglicherweise ein bestimmtes Werkzeug und dessen Abhängigkeiten, aber nicht unbedingt ein ganzes Verzeichnis des Hosts.

Die Mount-Konfiguration bestimmt mit, welche Teile des Dateisystems in der Umgebung erscheinen. Sie entscheidet aber nicht allein darüber, ob ein Prozess eine sichtbare Datei lesen, ändern oder ausführen darf. Dafür bleiben unter anderem Eigentümerschaft und Berechtigungen relevant. Ein sichtbarer Pfad ist also nicht gleichbedeutend mit einem erlaubten Schreibzugriff.

Das eigene Home-Verzeichnis bleibt für den Hosting-Alltag besonders wichtig: Dort liegen typischerweise die Dateien des jeweiligen Kontos. Die Einbindung ermöglicht den Zugriff im vorgesehenen Kontext, während die übrige Ansicht begrenzt wird. Ob eine konkrete Anwendung alle benötigten Dateien erreicht, hängt jedoch von ihrer Einrichtung und den tatsächlich verfügbaren Pfaden ab.

CageFS, LVE und gemeinsame Risiken

CageFS und LVE lösen unterschiedliche Probleme. CageFS gestaltet die Dateisystemsicht und den Ausführungskontext eines Benutzers; LVE dient der Erfassung und Begrenzung von Ressourcen wie CPU, Speicher und Ein- und Ausgabe. Ein Prozess mit eingeschränkter Dateisystemsicht kann weiterhin Ressourcen benötigen. Umgekehrt verhindert ein Ressourcenlimit für sich genommen keinen Zugriff auf falsch freigegebene Dateien.

Ein Hosting-Control-Panel erfüllt eine weitere Aufgabe: Es verwaltet unter anderem Konten und kann CloudLinux-Komponenten integrieren. Aus der bloßen Installation eines Panels folgt jedoch nicht, dass jeder Webprozess, jede Shell und jede geplante Aufgabe im vorgesehenen CageFS-Kontext läuft. Betreiber müssen die passende Integration für ihre konkrete Plattform prüfen.

CageFS ist keine eigene virtuelle Maschine für jedes Konto. Die Konten nutzen weiterhin einen gemeinsamen Kernel und können von gemeinsam betriebenen Diensten abhängen. Eine Schwachstelle oder Fehlkonfiguration in diesen gemeinsamen Komponenten gehört deshalb weiterhin zum Bedrohungsmodell. Die Dateisystem-Isolation reduziert einen Teil der sichtbaren Umgebung, ersetzt aber nicht die Absicherung und Wartung des Hosts.

Auch innerhalb eines korrekt isolierten Kontos bleiben Risiken bestehen. Eine verwundbare Anwendung kann beispielsweise ihre eigenen Daten preisgeben; gestohlene Zugangsdaten können einem Angreifer Zugriff im Rahmen des betroffenen Kontos verschaffen. CageFS korrigiert weder unsicheren Anwendungscode noch zu großzügige Rechte auf Dateien, die innerhalb dieses Kontos erreichbar sind.

Für eine belastbare Sicherheitsstrategie müssen die Schichten deshalb zusammenpassen: Konten und Dienste korrekt integrieren, Dateirechte kontrollieren, Ressourcenlimits passend wählen und Anwendungen aktuell halten. Welche Schutzwirkung daraus entsteht, hängt von der tatsächlichen Konfiguration und den betriebenen Diensten ab. Der Name einer einzelnen Komponente ersetzt diese Prüfung nicht.

Konten und Websites getrennt betrachten

Zwei Kundenkonten auf demselben Server sind ein anderer Fall als zwei Websites innerhalb eines Kontos. CageFS stellt eine benutzerspezifische Umgebung bereit und schränkt so die Sicht eines Kontos auf das Dateisystem ein. Daraus folgt aber nicht, dass jede Website innerhalb dieses Kontos eine eigene Dateisystemgrenze erhält.

Betreibt eine Agentur mehrere Projekte unter demselben Hosting-Konto, können deren Anwendungen abhängig von Ausführungskontext und Berechtigungen auf Dateien anderer Projekte zugreifen. Gelangt ein Angreifer über ein verwundbares Plugin in eine Website, ist deshalb zu prüfen, welche Konfigurationsdateien und Zugangsdaten unter diesem Konto erreichbar sind. Die Trennung gegenüber einem zweiten Kundenkonto beantwortet diese Frage nicht.

Für eine feinere Website-Trennung dokumentiert CloudLinux mit CloudLinux Isolates eine zusätzliche domänenbezogene Dateisystem-Isolation. Ob sie nutzbar ist, hängt von der konkreten Produktverfügbarkeit, Version und Panel-Integration ab. Prüfe diese Voraussetzungen für den eigenen Hosting-Stack, statt allein aus der CageFS-Aktivierung auf eine Trennung der Domains zu schließen.

Auch domänenbezogene LVE-Limits sind eine getrennte Funktion mit eigenen Voraussetzungen. Eine zusätzliche Dateisystemgrenze bedeutet daher nicht automatisch, dass CPU oder Speicher für jede Domain separat begrenzt sind. Der Beitrag über CloudLinux Site Isolation vertieft den Unterschied zwischen Konto- und Website-Ebene; maßgeblich für die Einrichtung bleiben die Voraussetzungen der eingesetzten Produktvariante.

Für die Planung lohnt sich zunächst eine Bestandsaufnahme: Welche Sites teilen sich ein Konto, welche Dateien müssen sie gemeinsam nutzen und welche Zugangsdaten sollen getrennt bleiben? Daraus lässt sich ableiten, ob getrennte Konten oder eine verfügbare domänenbezogene Isolation zum Betriebsmodell passen. Beide Varianten erfordern eine Prüfung der tatsächlichen Anwendungspfade.

Pilot und CageFS-Status prüfen

Vor einem Pilot prüfst du als Betreiber, ob die eingesetzte Betriebssystemvariante unterstützt wird, die benötigten Pakete und die Lizenz vorhanden sind und das Control Panel passend integriert ist. Die dokumentierte Unterstützung eines Panels bedeutet nicht, dass jede Funktion in jeder Kombination gleich arbeitet. Halte auch fest, welche Anwendungen und Werkzeuge die ausgewählten Testkonten benötigen.

Beginne mit ausdrücklich autorisierten Testkonten und einer überschaubaren Auswahl typischer Anwendungen. Prüfe deren Home-Verzeichnisse, benötigte Programme und relevante Ausführungspfade, bevor weitere Konten folgen. Für die Einführung kannst du den Modus nutzen, in dem CageFS grundsätzlich deaktiviert ist und einzelne Konten aktiviert werden; alternativ gibt es einen grundsätzlich aktivierten Modus mit Ausnahmen.

Die folgenden lesenden Befehle sind für berechtigte Administratoren auf einem System mit installiertem CageFS vorgesehen. TESTBENUTZER ersetzt du durch ein vorhandenes, für die Prüfung freigegebenes Konto. Erforderliche Rechte und die konkrete Ausgabe hängen vom System ab; die Befehle ändern keine Konfiguration.

/usr/sbin/cagefsctl --cagefs-status
/usr/sbin/cagefsctl --display-user-mode
/usr/sbin/cagefsctl --user-status TESTBENUTZER

Der erste Befehl zeigt den globalen CageFS-Status, der zweite den Betriebsmodus. Der dritte fragt den Status des gewählten Kontos ab. Modus und Kontostatus gehören zusammen betrachtet: Ein grundsätzlich aktivierter Modus kann Ausnahmen haben, während im anderen Modus einzelne Konten ausdrücklich aufgenommen werden.

Eine positive Statusausgabe ist noch kein Nachweis, dass jeder Dienst tatsächlich im vorgesehenen Kontext läuft. Dokumentiere deshalb getrennt, was die Verwaltung meldet und welche Ausführungspfade mit dem Testkonto überprüft wurden. Erst danach lässt sich entscheiden, ob der Pilot auf weitere Konten ausgeweitet werden kann und welche Ausnahmen betrieblich nötig sind.

Schutzansätze im Vergleich

Die Ansätze unterscheiden sich vor allem darin, welche Grenze sie ziehen und wer sie verwaltet. Die Tabelle ordnet ihre Schutzziele ein; die Angaben zum Betriebsaufwand sind qualitative Planungshinweise, keine gemessenen Werte. Konkrete Anforderungen hängen von der jeweiligen Plattform und ihrer Konfiguration ab.

Dateiberechtigungen und eine eingeschränkte Sicht sind keine austauschbaren Begriffe: Auch ein sichtbarer Pfad muss nicht lesbar sein, und ein bereitgestellter Pfad muss passend abgesichert werden. CageFS ergänzt diese Rechte durch eine gestaltete Umgebung. LVE adressiert dagegen den Ressourcenverbrauch; für eine gemeinsame Nutzung müssen beide Schichten passend eingerichtet sein.

Eine eigene VM verschiebt die Verwaltungsgrenze gegenüber einer benutzerspezifischen Umgebung: Das Gastsystem muss selbst gepflegt werden und bleibt von der Virtualisierungsplattform abhängig. Ein separater Server verändert die gemeinsam genutzte Infrastruktur nochmals. Welche Variante angemessen ist, hängt vom Bedrohungsmodell, den benötigten Rechten und den verfügbaren Betriebsressourcen ab.

Eine pauschale Sicherheitsrangliste wäre deshalb irreführend. Für einen Vergleich weiterer Mechanismen und ihrer jeweiligen Einsatzbereiche hilft der Überblick zur Prozessisolation im Hosting. Entscheidend ist anschließend die konkrete Prüfung: Welche Grenze soll welchen Zugriff verhindern, welche Dienste überschreiten sie und wer überwacht die Konfiguration?

Ausführungspfade kontrolliert testen

Ein aktiviertes Konto sagt noch nicht aus, ob jeder zugehörige Prozess tatsächlich in CageFS startet. Entscheidend ist der jeweilige Ausführungspfad: SSH-Anmeldung, Webserver und geplante Aufgaben können unterschiedliche Integrationen nutzen. Betreiber müssen deshalb für jeden relevanten Dienst prüfen, wie er Prozesse dem Konto und seiner Umgebung zuordnet.

Für eine kontrollierte Prüfung richtet der Betreiber ein autorisiertes Testkonto ein und verwendet ausschließlich eigene, ausdrücklich freigegebene Testdateien. Eine Datei innerhalb der vorgesehenen Umgebung kann zeigen, ob der erwartete Zugriff funktioniert; eine separat vorbereitete Datei außerhalb der vorgesehenen Sicht dient zur Prüfung der Abgrenzung. Fremde Kundenverzeichnisse sind dafür kein geeignetes Testmaterial.

Prüfe zunächst über SSH, welche Umgebung das Testkonto tatsächlich erhält und ob die vorgesehenen Testdateien wie erwartet erreichbar sind. Wiederhole die Prüfung mit einer dafür eingerichteten Webanwendung und einer geplanten Aufgabe. Die Ergebnisse können sich unterscheiden, wenn Dienste anders integriert sind oder unter einem anderen Benutzerkontext laufen.

Halte für jeden Versuch Dienst, Konto, Pfad und Ergebnis fest. Ein verweigerter Zugriff belegt nur die beobachtete Grenze in genau diesem Kontext; er beweist weder die korrekte Isolation aller Dienste noch die Sicherheit des gesamten Hosts. Umgekehrt sollte ein unerwartet erfolgreicher Zugriff untersucht werden, bevor weitere Konten in den Betrieb übernommen werden.

Als Hosting-Kunde kannst du deinen eigenen Ausführungskontext und freigegebene Dateien prüfen. Globale CageFS-Einstellungen, andere Konten und die Integration sämtlicher Dienste kannst du normalerweise nicht unabhängig bestätigen. Für diese Fragen ist der Betreiber zuständig; beschreibe ihm bei Auffälligkeiten den betroffenen Dienst und den konkreten Pfad.

Fehlende Werkzeuge und Skeleton-Wartung

Ist ein Werkzeug auf dem Host installiert, aber im Kundenkonto nicht auffindbar, prüfe zuerst den Ausführungskontext. Ein Aufruf per SSH muss nicht dieselbe Umgebung verwenden wie eine Webanwendung oder eine geplante Aufgabe. Kontrolliere anschließend den Suchpfad und die konkrete Fehlermeldung, bevor du von einem fehlenden Paket ausgehst.

Danach untersucht der Betreiber das Skeleton und die Mount-Konfiguration. Das Skeleton bestimmt mit, welche Dateien und Verzeichnisse in CageFS bereitgestellt werden. Ein Programm kann daher auf dem Host vorhanden sein und trotzdem in der benutzerspezifischen Umgebung fehlen; auch benötigte Bibliotheken und andere Abhängigkeiten müssen bei der Bereitstellung berücksichtigt werden.

Die praktische Lösung ist nicht, vorsorglich große Host-Verzeichnisse einzubinden. Dadurch würden möglicherweise mehr Dateien sichtbar als für die Aufgabe nötig. Der Betreiber sollte stattdessen anhand der Herstellerdokumentation die benötigten Programmdateien und Abhängigkeiten auswählen und anschließend im vorgesehenen Dienstkontext prüfen, ob das Werkzeug funktioniert.

Zur Skeleton-Wartung gehört auch, Änderungen an Systempaketen und am Control Panel zu berücksichtigen. CloudLinux dokumentiert eine periodische Aktualisierung; nach bestimmten Änderungen kann eine erzwungene Aktualisierung nötig sein. Auch nach einem Apache-Rebuild kann sie erforderlich werden. Daraus folgt nicht, dass nach jedem Update derselbe manuelle Befehl auszuführen ist.

Plane die Aktualisierung passend zur eingesetzten Plattform und prüfe danach die betroffenen Anwendungen und Werkzeuge. Wenn eine Anwendung zuvor funktionierte und nach einer Änderung scheitert, helfen der Zeitpunkt der Paketänderung, der betroffene Dienst und die genaue Fehlermeldung bei der Eingrenzung. So lässt sich zwischen einem Bereitstellungsproblem und einem Fehler der Anwendung unterscheiden.

Sicher betreiben und bewusst entscheiden

Für die Betriebsentscheidung zählt nicht nur, ob CageFS grundsätzlich verfügbar ist. Der Betreiber muss wissen, welche Konten und Dienste geschützt werden sollen, welche Programme sie benötigen und wer Integration und Wartung verantwortet. Die eingeschränkte Dateisystemsicht ergänzt andere Sicherheitsmaßnahmen; sie ersetzt weder sichere Anwendungen noch den Schutz von Zugangsdaten.

Besondere Aufmerksamkeit verdienen gemeinsame Bereiche und zusätzliche Mounts. CloudLinux beschreibt für /dev/shm eine gemeinsame Einbindung und eine Möglichkeit zur Isolation pro Benutzer. Welche Variante tatsächlich gilt, muss anhand der konkreten Konfiguration geprüft werden. Zusätzliche Mounts sollten nur bereitstellen, was Anwendungen benötigen, weil sie die sichtbare Umgebung erweitern können.

Auch ein Fehler beim Eintritt in CageFS ist sicherheitsrelevant. CloudLinux dokumentiert ab CageFS 7.2.0-1 eine Option, mit der sich die Ausführung von Prozessen bei einem solchen Fehler verhindern lässt. Prüfe die installierte Version und die tatsächliche Einstellung, statt aus der Existenz dieser Option auf ihr Verhalten bei einem konkreten Hosting-Angebot zu schließen.

Änderungen an Skeleton, Mounts oder Kontenzuordnung gehören in ein abgestimmtes Wartungsverfahren. Berücksichtige dabei mögliche Remounts, betroffene Anwendungen und ein Wartungsfenster; dokumentiere außerdem, wie sich die Änderung bei Problemen zurücknehmen lässt. Anschließend sollten die relevanten Ausführungspfade und benötigten Werkzeuge erneut mit den vorgesehenen Testkonten geprüft werden.

Für Kunden ist die entscheidende Frage, welche Trennung der Anbieter tatsächlich betreibt und wie er sie prüft. Betreiber müssen dagegen Schutzbedarf und laufenden Aufwand zusammen betrachten: Eine zu großzügig bereitgestellte Umgebung kann die Abgrenzung schwächen, eine zu knappe Umgebung benötigte Anwendungen beeinträchtigen. Beides verlangt eine bewusste Konfiguration und regelmäßige Überprüfung.