Die Konsole ist ein Vorrecht: warum sie ihre eigene Berechtigung verlangt

Eine Konsole sieht aus wie ein Bildschirm. Du öffnest sie, ein Fenster erscheint, darin läuft Text. Es fühlt sich an wie "ich schaue nur".

Doch eine Konsole ist eine Shell. Und die Shell des Servers ist das höchste Recht, das es auf dieser Maschine gibt.

Zwei getrennte Mächte

Einstellungen ändern. Du kannst tun, was die Oberfläche erlaubt. Die Grenzen sind klar, denn die Oberfläche zieht sie.

Eine Shell öffnen. Du kannst alles tun. Auch das, was die Oberfläche verweigern würde, und das, wovon sie nie gehört hat.

Diese beiden Mächte enthalten einander nicht. Die eine zu haben, verlangt nicht die andere, und wichtiger noch: die eine zu gewähren, sollte nicht heißen, die andere zu gewähren.

Die Unterscheidung ist echt und zeigt sich in den eingebauten Rollen

Proxmox bindet die Konsole an ihre eigene Berechtigung, nicht an das allgemeine "darf ändern". Dass das echt ist, siehst du in den eingebauten Rollen: die Rolle des Systemverwalters trägt die Prüf-, Konsolen- und Protokollrechte und enthält kein Änderungsrecht.

Es ist also eine legitime Einrichtung, jemandem das Recht zu geben, eine Konsole zu öffnen, ohne das Recht, Einstellungen zu ändern. Und umgekehrt ebenso.

Die häufige Lage, die das wichtig macht

Proxmox erlaubt eigene Rollen, und eine solche Rolle ist sehr verbreitet: eine Bedienkraft, die Netzwerkeinstellungen ändern darf, aber die Shell des Servers nicht erreichen soll.

Das ist ein vernünftiger Wunsch. Netzwerkkonfiguration zu bearbeiten und auf dem Server jeden beliebigen Befehl auszuführen sind nicht dasselbe.

Doch schließt ein Produkt "wer ändern darf, darf auch die Konsole öffnen", dann gibt es dieser Bedienkraft unbemerkt eine Root-Shell. Sie bekommt über das Panel, was sie in Proxmox nicht bekäme.

Das daraus folgende allgemeine Prinzip

Ein Berechtigungsmodell muss die eigene Definition der Plattform kopieren, nicht umschreiben.

Ein Tor, das "ungefähr dasselbe" sagt, arbeitet bei gewöhnlichen Einrichtungen richtig, und niemand merkt etwas. Die Lücke öffnet sich an dem Tag, an dem eine ungewöhnliche Rolle geschaffen wird. Und wenn dieser Tag kommt, erinnert sich niemand an eine vor Jahren geschriebene Näherung.

Dieselbe Latte gilt für den Dateizugriff

Noch ein Detail, denn es wird oft übersehen: Zugriff auf das Dateisystem des Servers ist einer Shell gleichwertig, selbst wenn er nur lesend ist.

Der Grund ist einfach: Passwortdateien, Schlüssel und Cluster-Geheimnisse liegen in diesem Dateisystem. Wer mit einem Nur-Lese-Recht Dateien lesen kann, kann bereits alles erfahren.

Dateizugriff lässt sich also nicht mit einem Recht zum "Schauen" gewähren; er verlangt dieselbe Latte wie eine Shell.

Was Atlas tut

In Atlas sind Konsole, entfernte Shell und Dateizugriff allein an die Konsolenberechtigung gebunden. Das Änderungsrecht für sich öffnet diese Flächen nicht.

Das war nicht immer so, und der Artikel muss ehrlich enden: früher nahmen diese Flächen auch das Änderungsrecht an. Der Kommentar im Code sagte das Richtige, er sagte "die Entsprechung ist die Konsolenberechtigung", doch der Code tat etwas anderes.

Das wurde gefunden, indem gegen die eigene Definition von Proxmox gemessen wurde, und es wurde behoben. Das Messergebnis war eindeutig: Proxmox bindet die Shell allein an die Konsolenberechtigung und nimmt das Änderungsrecht nicht an.

Auch das tatsächliche Gewicht gehört genannt: mit eingebauten Rollen war es nicht ausnutzbar, denn die einzige eingebaute Rolle mit Änderungsrecht hat auch die Konsolenberechtigung. Das Risiko lag bei eigenen Rollen, also im oben beschriebenen Beispiel der Netzwerk-Bedienkraft.

Die daraus folgende Lehre gilt auch für das Produkt selbst: dass ein Kommentar recht hat, heißt nicht, dass der Code recht hat. Beide müssen getrennt gemessen werden.