Zusammenfassung

  • Eine Amoeba-Capability bestand aus 48 Bit Server-Port, 24 Bit Objektnummer, 8 Bit Rechten und 48 Bit Prüffeld. Sie verband Adressierung, Objektbezug, erlaubte Operationen und Fälschungsschutz in einer Referenz.
  • Akzeptierte der Server das Token, waren dessen Felder nach seiner Regel gültig und die angeforderte Operation von den Rechtebits gedeckt. Name, Zweck, organisatorisches Mandat, externe Wirkung und Persistenz folgten daraus nicht.

Ein überprüfbares Recht ohne Namensfeld

Der Client legte dem Server nicht zuerst eine Personalakte vor. Er übergab eine Capability und einen Operationscode. Der Port führte zum Dienst. Die Objektnummer wählte ein Objekt in dessen lokalem Namensraum. Die Rechtebits begrenzten die möglichen Befehle. Das Prüffeld band diese sichtbaren Angaben an ein Geheimnis, das der Server zum Objekt aufbewahrte.

In diesen vier Feldern stand kein Personenname. Das war mit Amoebas Verteilungsmodell vereinbar: Benutzerprozesse sollten Capabilities direkt handhaben können, während der Server seine Objekte und deren Operationen verstand. Berechtigung reiste mit der Referenz; eine zentrale Liste aller Besitzer war nicht Teil jeder Prüfung.

Damit beantwortete die Capability eine präzise Frage: Darf der Inhaber dieses gültigen Tokens diese Operation an diesem Objekt anfordern? Sie beantwortete nicht, welcher Mitarbeiter handelte, welche Geschäftsabsicht bestand oder ob eine Genehmigungskette erfüllt war. Diese Aussagen benötigen andere Belege.

Die vier Felder und ihre getrennten Aufgaben

Using Sparse Capabilities in a Distributed Operating System nennt 48 Bit für den Server-Port, 24 für das Objekt, 8 für die Rechte und 48 für das Prüffeld. Der Statusbericht von 1991 erklärt, dass der Kernel den Port zur Lokalisierung des Servers nutzt. Der Server interpretiert die übrigen Teile. Bei einem Dateiserver kann die Objektnummer ähnlich wie eine UNIX-Inode-Nummer funktionieren.

Die acht Rechtebits bilden kein systemweit einheitliches Wörterbuch. Ihre Bedeutung stammt vom jeweiligen Server. Ein Dateiobjekt kann Lesen, Schreiben und Löschen anbieten, ein Prozessobjekt Start, Stopp und Inspektion. Die gleiche Bitposition kann deshalb nicht ohne den Objektvertrag interpretiert werden.

Das Prüffeld soll Manipulation erkennen. Ein Server speichert einen Zufallswert zum Objekt und prüft eine Einwegtransformation, in die Rechte und gespeicherter Wert eingehen. Wer nur ein Rechtebit verändert, erzeugt nicht automatisch den dazu passenden Prüfwert. Das Token wird ungültig.

„Nicht fälschbar“ bleibt dennoch eine historische, modellgebundene Aussage. Das Verfahren war für Amoebas Annahmen ausgelegt; ein 48-Bit-Feld erhält dadurch keine heutige Sicherheitszertifizierung. Eine vollständige Kopie eines gültigen Bearer-Tokens ist außerdem keine Fälschung. Der Statusbericht weist selbst darauf hin, dass in unsicheren Umgebungen Verschlüsselung gegen unbeabsichtigte Offenlegung nötig sein kann.

Rechteabbau als monotone Operation

Die anfängliche Owner-Capability besaß alle Rechte. Sollte ein anderer Prozess weniger erhalten, konnte der Inhaber den Server um eine eingeschränkte Capability bitten. Der Server prüfte das Ausgangstoken, schnitt dessen Rechte mit einer Maske, behielt das Objekt bei und erzeugte einen neuen Prüfwert. Im Programmierhandbuch steht die entscheidende Zeile sinngemäß als rights &= mask.

Das Resultat kann Rechte behalten oder entfernen, nicht hinzufügen. Ein manuell eingeschaltetes Bit passt nicht zum Prüffeld und scheitert bei der Validierung.

Dabei dürfen die in den Quellen untersuchten Varianten nicht vermengt werden. Die Arbeit von 1986 beschreibt mehrere Schutzideen: Verschlüsselung eines kombinierten Feldes, eine Einwegfunktion über Objektgeheimnis und Rechte, servergestützte Ausstellung einer schwächeren Capability sowie kommutative Einwegfunktionen für lokale Abschwächung. Der Bericht von 1991 beschreibt den servergestützten Pfad. Das sind verwandte Entwürfe, aber nicht ein einziges gleichzeitig eingesetztes Verfahren.

Auch die Urheberschaft ist verteilt. Die Arbeit von 1986 stammt von Andrew S. Tanenbaum, Sape J. Mullender und Robbert van Renesse. Den Statusbericht von 1991 verfassten Tanenbaum, M. Frans Kaashoek, van Renesse und Henri E. Bal. Tanenbaum ist der biografische Zugang zu dieser Geschichte, nicht ihr alleiniger Autor.

Besitz sagt nichts über die Übergabekette

Eine Capability konnte durch Kopieren ihres Bitmusters weitergegeben werden. Der Server musste keine vollständige Liste der Besitzer führen. Das unterstützte lokale Delegation und Ortsunabhängigkeit, beseitigte aber die Herkunftsinformation.

Bei erfolgreicher Prüfung weiß der Server, dass das Token unter dem aktuellen Objektgeheimnis zu Objekt und Rechten passt. Er weiß nicht, ob der Prozess es vom Erzeuger, aus einem Verzeichnis, von einem anderen Prozess oder aus einer unbeabsichtigten Kopie erhalten hat. Die Bindung an eine Person, ein verwaltetes Gerät oder eine Vertragsrolle ist ein anderer Kontrollmechanismus.

Auch der Zweck ist nicht im Rechtebyte enthalten. Schreibrecht kann für geplante Wartung, Notfallwiederherstellung oder eine nicht genehmigte Änderung verwendet werden. Das Bit erlaubt ein Verb, nicht dessen Begründung.

Eine Änderung des gespeicherten Zufallswertes kann bestehende Capabilities des Objekts ungültig machen. Das ist ein breiter Objekt-Widerruf, keine selektive Sperre nach Identität. Er findet nicht jede Kopie, erklärt keine frühere Nutzung und löscht keine alten Tokens aus Backups.

Erfolg endet an der Semantik der Operation

Eine positive Serverantwort belegt das Ergebnis, das die konkrete Serveroperation definiert. Sie belegt nicht automatisch Crash-Festigkeit, Replikation, eine physische Betätigung, eine externe Zahlung oder die Einhaltung eines Change-Prozesses.

Für diese Aussagen sind getrennte Beobachtungen nötig. Speicher- und Wiederherstellungssysteme belegen Persistenz. Das ausführende Subsystem belegt die äußere Wirkung. Die verantwortliche Organisation belegt das menschliche Mandat. Wer alles in die Capability-Antwort hineinliest, erhält eine einfache, aber falsche Beweiskette.

Amoebas Beitrag bleibt deshalb aktuell: Die Referenz sagt sehr klar, was sie autorisiert. Ihre Stärke liegt darin, nicht zugleich Identitätsausweis, Genehmigungsakte und Ergebnisquittung zu spielen.

Quellen