Bleibt die Freigabe einer Sitzung bei einer Prozessersetzung durch exec bestehen?

Eine Sitzungsfreigabe sollte einer verifizierten Ausführungsidentität folgen, nicht einer Prozesskennung des Betriebssystems. Wenn ein Prozess exec aufruft, kann der Kernel seine PID beibehalten, während er Code, Argumente, Umgebung und oft auch den praktischen Zweck des Prozesses ersetzt. Wenn die alte Freigabe diese Ersetzung überlebt, erhält nicht geprüfter Code die Berechtigung, die eine Person zuvor etwas anderem erteilt hat.

Die Regel, die ich ausliefern würde, ist klar: Bei einer Ersetzung mit einer anderen Identität der ausführbaren Datei muss vor autorisierten Aktionen erneut eine Freigabe eingeholt werden. Kontinuität bleibt nur bei einem eng verifizierten Re-Exec desselben Programmbilds erhalten. Diese Richtlinie erzeugt in einem legitimen Ablauf gelegentlich eine zusätzliche Abfrage. Sie schließt eine weitaus gefährlichere Lücke in allen Abläufen, in denen ein Agent, Wrapper, Updater oder eine kompromittierte Abhängigkeit entscheiden kann, was als Nächstes ausgeführt wird.

Eine Freigabe bindet einen Akteur, keine PID

Eine PID bezeichnet einen Verwaltungsplatz im Kernel. Eine Freigabe muss dagegen das Programm identifizieren, das eine menschliche Entscheidung nutzen darf. Das sind unterschiedliche Aufgaben. Wer beide Objekte gleichsetzt, bekommt Probleme, sobald Code anderen Code startet.

Sallyport beschreibt die Autorisierung pro Sitzung als Freigabe für einen neuen Agent-Prozess, die bis zum Ende dieses Laufs gilt. Das ist eine nützliche Regel für die Benutzeroberfläche. Intern braucht die Implementierung jedoch eine präzisere Definition: Der freigegebene Lauf muss weiterhin die freigegebene ausführbare Datei sein und darf nicht bloß dieselbe PID behalten.

Der Unterschied ist wichtig, weil die Geheimnisse im Gateway bleiben und der Agent Ergebnisse statt Zugangsdaten erhält. Damit entfällt das bekannte Desaster, bei dem ein Kindprozess ein Token aus einer Umgebungsvariable liest. Ein ersetzter Prozess kann das Gateway aber weiterhin auffordern, eine API aufzurufen oder SSH mit einer gespeicherten Zugangsdaten auszuführen. Wenn dieser Prozess die Freigabe übernimmt, kann er denselben externen Schaden verursachen, ohne das Geheimnis jemals zu sehen.

Mach das Subjekt der Freigabe ausdrücklich. Es sollte eine stabile Identität der ausführbaren Datei, das Prozesserstellungsereignis oder eine Sitzungs-Nonce, den der Person angezeigten Signaturherausgeber und genügend Startkontext enthalten, um den Zweck des Prozesses zu erklären. Verwende die PID als Auditmerkmal und praktisches Hilfsmittel zur Fehlersuche. Verwende sie nicht als Träger der Berechtigung.

Diese Unterscheidung hält auch den Widerruf sauber. Wenn ein Benutzer einen Lauf widerruft, sollte das Gateway weitere Aufrufe dieses Laufs ablehnen, selbst wenn er sich per Re-Exec neu startet. Erhält eine Ersetzung eine neue Freigabe, sollte sie einen neuen Sitzungseintrag erhalten, den der Benutzer unabhängig widerrufen kann.

exec ändert die ausführbare Datei, auch wenn die PID bleibt

exec sollte die Autorisierung zurücksetzen, wenn es ein anderes Programm lädt, weil es das Programmbild ersetzt, auch wenn das Betriebssystem die PID beibehalten kann. POSIX sagt, dass eine exec-Funktion „das aktuelle Prozessabbild ersetzt“. Diese Formulierung ist kurz und trifft den entscheidenden Punkt: Die Kontinuität ist administrativ, kein Beweis dafür, dass derselbe Akteur bestehen bleibt.

Bei einer Shell übersieht man das leicht. Ein Entwickler startet einen freigegebenen Agenten, der Agent ruft einen Helfer auf, und der Helfer verwendet exec, damit kein zusätzlicher Elternprozess bestehen bleibt. Prozesslisten können vor und nach der Ersetzung dieselbe PID anzeigen. Wenn die Sitzungsabfrage sagt pid 4127 ist freigegeben, besitzt der neue Helfer nun die Berechtigung des alten Agenten.

Die Änderung der ausführbaren Datei kann das Risiko auf eine Weise verändern, die eine PID nicht beschreibt. Die Ersetzung kann mit einem anderen Host kommunizieren, eine nicht vertrauenswürdige Repository-Datei auswerten, Erweiterungen laden, Daten über die Standardeingabe annehmen oder ausschließlich dazu dienen, Aktionsanfragen weiterzuleiten. Keine dieser Eigenschaften steckt in einer Prozessnummer.

Stütze die Entscheidung nicht darauf, ob die neue Befehlszeile vertraut aussieht. Befehlsargumente liefern nützlichen Kontext, aber ein Programm kann sie ändern, und ein Wrapper kann einen harmlos wirkenden Befehl ein unabhängiges Ziel starten lassen. Leite die Identität der ausführbaren Datei aus dem Programmbild ab, das das Betriebssystem tatsächlich gestartet hat. Bewahre den beobachteten Pfad und die Argumente zusätzlich als Belege für die Person auf, die die Anfrage prüft.

posix_spawn gehört in dieselbe Designdiskussion, führt aber zu einem anderen Ergebnis. Es erzeugt einen Kindprozess, statt das Programmbild des Aufrufers zu ersetzen. Das Kind sollte standardmäßig keine Sitzungsfreigabe erhalten. Auch ein Fork mit anschließendem Exec sollte zum selben Ergebnis führen: Der neue Prozess beantragt eine Freigabe für das Programmbild, das letztlich ausgeführt wird.

Eine neue ausführbare Datei braucht eine neue Freigabe

Ein Gateway sollte eine neue Freigabe verlangen, bevor eine andere ausführbare Datei über eine bereits autorisierte Sitzung irgendeine Aktion ausführen darf. Definiere „anders“ anhand einer verifizierten Identität des Programmbilds, nicht anhand eines Dateinamens und nicht anhand eines Anzeigenamens.

Ein praktischer Identitätseintrag kann die unveränderliche Kennung der Plattform für die ausführbare Datei, einen Hash des signierten Codes, sofern verfügbar, den Signaturherausgeber und den beim Start beobachteten konkreten Pfad enthalten. Die ersten beiden Felder beantworten die Frage, ob sich das Programmbild geändert hat. Der Signaturherausgeber zeigt der prüfenden Person, wer Verantwortung für den Code übernommen hat. Der Pfad zeigt, woher der Start kam. Jedes Feld beantwortet eine andere Frage. Fasse sie daher nicht zu einer einzigen Zeichenfolge zusammen.

Das ist der Fehler, durch den eine großzügige Vererbung attraktiv wirkt, bis es zu spät ist. Ein freigegebener Coding-Agent ruft einen Repository-Helfer auf. Der Helfer sieht eine Umgebungsvariable und ersetzt sich am erwarteten Pfad durch ein lokal gebautes Dienstprogramm. Dieses Dienstprogramm muss keine API-Zugangsdaten auslesen. Es bittet um eine HTTP-Aktion, die eine Bereitstellung löscht, eine Abrechnungseinstellung ändert oder eine Veröffentlichung erstellt. Das Gateway sieht die alte PID und akzeptiert den Aufruf. Die Person hat den Coding-Agenten freigegeben, nicht das Dienstprogramm, das sich nach der Freigabe selbst ausgewählt hat.

Das übliche Argument für vererbte Freigaben lautet Abfragemüdigkeit. Diese Sorge ist berechtigt, aber beliebige Ersetzungen lösen sie nicht. Sie verbergen eine Entscheidung vor der einzigen Person, die beurteilen kann, ob die Ersetzung sinnvoll ist. Halte Freigabekarten selten, indem der normale Agent-Lauf stabil bleibt. Frage erneut, sobald sich der Akteur ändert.

Die Prüfung muss vor der Injektion von Zugangsdaten, der SSH-Ausführung und jeder anderen ausgehenden Aktion stattfinden. Sie muss auch erfolgen, bevor das Gateway Metadaten zurückgibt, die einer Ersetzung bei der Planung einer Aktion helfen könnten. Eine ausstehende Freigabe ist kein teilweise autorisierter Zustand.

Re-Exec desselben Programmbilds ist die enge Ausnahme

Ein verifizierter Re-Exec exakt desselben Programmbilds kann die Sitzungsfreigabe behalten, weil kein neuer Akteur eingeführt wird. Programme verwenden einen Selbst-Re-Exec für saubere Neustarts, geänderte Dateideskriptoren oder eine bewusste Übergabe nach der Aktualisierung ihrer eigenen Umgebung. In diesem Fall eine neue Karte zu erzwingen, erzeugt Lärm, ohne eine wichtige Entscheidung hinzuzufügen.

Halte die Ausnahme eng. Das Gateway sollte das aktuell beobachtete Programmbild mit dem Bild vergleichen, das die Freigabe erhalten hat. Sind die Identitäten identisch, kann es die Sitzungs-Nonce behalten und ein Kontinuitätsereignis in das Auditprotokoll schreiben. Kann das Gateway die Identität nicht feststellen, sollte es erneut fragen. Unklarheit ist kein Beweis dafür, dass die Ersetzung sicher ist.

Mach daraus keine Ausnahme für den gesamten Signaturherausgeber. Ein Herausgeber kann einen Agenten, ein Installationsprogramm, ein Diagnosewerkzeug und ein Netzwerkdienstprogramm veröffentlichen. Diese Programme können sehr unterschiedliche Aktionsrechte haben. Der sichtbare Signaturherausgeber hilft dem Benutzer bei der Beurteilung der Anfrage. Er sollte die Freigabe jedoch nicht stillschweigend auf jede Binärdatei mit derselben Signatur ausdehnen.

Mach daraus auch keine Ausnahme für den gesamten Pfad. Ein Selbst-Update kann Bytes an einem festen Pfad ersetzen. Ein Symlink kann nach der Freigabe auf einen anderen Ort zeigen. Ein Skript kann seinen Dateinamen behalten, während sich sein Inhalt ändert. Der Identitätsvergleich muss alle drei Fälle abdecken.

Wenn ein legitimes Update eine neue Agent-Version installiert, soll sie erneut fragen. Diese Abfrage vermittelt eine wichtige Tatsache: Die ausführbare Datei, die handeln wird, hat sich geändert. Ein Benutzer, der das Update erwartet, kann es mit einem Klick freigeben. Wer keine Änderung erwartet hat, erhält die Möglichkeit, sie zu stoppen.

Der Code-Signaturherausgeber hilft bei der Beurteilung, erteilt aber keinen Berechtigungsumfang

Zeige den Code-Signaturherausgeber deutlich an, weil er eine Frage beantwortet, die sich Menschen tatsächlich stellen: Wer hat diese ausführbare Datei veröffentlicht? Verwechsle diese Antwort nicht mit einer vollständigen Autorisierungsregel.

Apples Codesignaturmodell ermöglicht es macOS, signierten Code zu identifizieren und seine Integrität nach den geltenden Vertrauensregeln zu prüfen. Das ist ein starker Beleg für die Freigabekarte. Es sagt jedoch nicht, dass jeder Code eines Herausgebers denselben operativen Zweck hat. Ebenso zeigt es dem Gateway nicht, ob ein übergeordneter Prozess die ausführbare Datei über eine nicht vertrauenswürdige Repository-Einstellung ausgewählt hat.

Eine gute Freigabekarte stellt zuerst den Namen und den Pfad der ausführbaren Datei dar, danach den Signaturherausgeber, die Identität des Elternprozesses und den Grund für die neue Anfrage. Bei einer exec-Ersetzung sollte sie beide Seiten der Änderung in einem Satz nennen: Der freigegebene Agent hat sich durch diese ausführbare Datei ersetzt. Die Person sollte den Übergang nicht aus zwei voneinander getrennten Abfragen erschließen müssen.

Signierte und unsignierte Fälle brauchen dieselbe Grenze. Ein unsignierter lokaler Entwickler-Build kann zu einem erwarteten Entwicklungsablauf gehören, und ein signiertes Dienstprogramm kann trotzdem der falsche Prozess sein, um eine Berechtigung zu übernehmen. Die Karte sollte die Belege beschreiben, ohne so zu tun, als mache eine Signatur eine neue ausführbare Datei zur alten.

Vermeide unklare Bezeichnungen wie „vertrauenswürdiger Prozess“. Sie verleiten Menschen dazu, eine Kategorie statt einer konkreten Anfrage freizugeben. Nenne die ausführbare Datei und zeige ihre Beziehung zum bereits freigegebenen Prozess. So erhält die prüfende Person etwas, das sie wiedererkennen oder ablehnen kann.

Skripte und Launcher zeigen die schwache Grenze

Ein skriptgesteuerter Start braucht zwei Identitäten: den Interpreter, der die Ausführung übernimmt, und das Skript, dessen Inhalt den Ablauf steuert. Wenn du nur den Interpreter prüfst, sieht jedes Shell-Skript wie dieselbe Shell aus. Wenn du nur das Skript prüfst, kannst du einen Interpreter übersehen, der über eine Shebang-Zeile oder einen Wrapper ausgewählt wurde.

Bei einem Shell-Skript solltest du die Identität der ausführbaren Interpreter-Datei, den aufgelösten Skriptpfad und einen Hash des Skriptinhalts erfassen. Wenn das Skript über eine freigegebene Shell läuft und diese Shell anschließend eine andere Binärdatei per exec startet, braucht die Ersetzung der Binärdatei weiterhin eine neue Freigabe. Ein Skript darf nicht zum Tunnel durch die Sitzungsgrenze werden.

Launcher verursachen ein verwandtes Problem. Ein freigegebener Launcher kann eine Konfigurationsdatei prüfen, ein Werkzeug in PATH finden, einen Helfer herunterladen oder ein Versionsverzeichnis auswählen. Häufig wird der Launcher freigegeben und sein ausgewähltes Ziel als Teil desselben Laufs behandelt. Diese Regel ist falsch, wenn der Launcher die sicherheitsrelevante Entscheidung erst nach der Freigabe trifft.

Verwende einen von zwei Ansätzen. Wenn der Launcher sein Ziel vor dem ersten Gateway-Aufruf kennt, soll die Karte das endgültige Ziel anzeigen und diese Ausführungsidentität freigeben. Wenn der Launcher die Auswahl später trifft, soll er ohne Aktionsberechtigung laufen und eine Freigabe verlangen, sobald das ausgewählte Ziel erstmals handeln möchte. Die zweite Option erzeugt ein ehrlicheres Auditprotokoll.

Dasselbe gilt für Laufzeit-Plugins und eingebettete Interpreter. Ein nativer Host kann unverändert bleiben, während er Code aus einem Projektverzeichnis lädt. Wenn dieser geladene Code Gateway-Anfragen formulieren kann, beschreibt die Identität des Host-Programmbilds allein den tatsächlichen Akteur nicht. Das Gateway kann nicht jede Laufzeit sicher prüfen. Die sicherere Standardeinstellung besteht daher darin, die Sitzungsfreigabe auf eine definierte Agent-Datei zu begrenzen und eine neue Entscheidung zu verlangen, sobald sie die Aktionskontrolle an ein externes Programm übergibt.

Kinder und Exec unterscheiden sich bei der Delegation

Ein Kindprozess sollte die Sitzungsfreigabe nicht allein deshalb übernehmen, weil sein Elternprozess sie besitzt. Die Prozesserzeugung führt einen neuen Akteur ein, während exec den aktuellen Akteur ersetzt. In beiden Fällen ist bei einer anderen ausführbaren Datei eine neue Freigabe nötig, wenn sie Gateway-Aufrufe ausführen soll. Die Auditbeziehungen unterscheiden sich jedoch.

Erstelle für ein Kind einen neuen Sitzungskandidaten mit einem Verweis auf die Elternsitzung. Zeige den Elternprozess auf der Freigabekarte an, weil er nützlichen Kontext liefert, nicht weil er eine Berechtigung erteilt. Wenn der Benutzer das Kind freigibt, erhält es eine eigene Sitzungs-Nonce und einen eigenen Widerrufsgriff.

Bei exec schließe die alte Identität der ausführbaren Datei oder markiere sie als überholt und erstelle einen Ersatzkandidaten, der an die vorherige Sitzung gebunden ist. Wenn das neue Programmbild exakt dem freigegebenen Bild entspricht, behalte die Kontinuität bei und protokolliere dieses Ergebnis. Weicht es ab, stoppe an der Kontrollstelle und warte auf eine Entscheidung. So vermeidest du einen übergroßen Sitzungseintrag, der mehrere unabhängige Programme enthält.

Erstelle kein allgemeines Delegationstoken, das ein Elternprozess an Kinder oder Ersetzungen weitergeben kann. Ein Token mit der Aussage „Alles, was ich starte, darf handeln“ wird zum leichten Ziel für einen kompromittierten Agenten oder einen verwirrten Wrapper. Ein Elternverweis im Journal reicht aus, um den Ablauf zu dokumentieren, ohne Abstammung in Berechtigung umzuwandeln.

Diese Trennung verbessert auch die Untersuchung von Vorfällen. Du kannst feststellen, ob der Elternprozess ein Kind gestartet, sich selbst ersetzt und ob eine Person die resultierende ausführbare Datei freigegeben hat. Ein flaches Protokoll erlaubter Anfragen kann diese Fragen nach einer schädlichen Aktion nicht beantworten.

Erfasse die Ersetzung als eigenes Ereignis

Ein Auditprotokoll sollte eine exec-Ersetzung als eigenes Ereignis anzeigen, unabhängig davon, ob das Gateway die Freigabe beibehalten oder erneut angefordert hat. Ohne dieses Ereignis sieht die prüfende Person Aktionen aus einer Sitzung und nimmt möglicherweise an, dass eine einzige stabile ausführbare Datei alle Aktionen ausgeführt hat.

Ein Designvertrag kann so aussehen. Das folgende Beispiel zeigt die zu speichernden Informationen, ist aber kein vorgeschriebenes Übertragungsformat:

{
  "event": "execution_replaced",
  "session_id": "sess_8f2c",
  "previous_image": {
    "identity": "image:4f19...",
    "path": "/work/agent/bin/agent"
  },
  "current_image": {
    "identity": "image:b66a...",
    "path": "/work/agent/bin/release-helper",
    "signing_authority": "Example Development Team"
  },
  "decision": "approval_required",
  "parent_relation": "exec"
}

Das Ereignis braucht die vorherigen und aktuellen Identitäten, nicht bloß den Hinweis, dass exec stattgefunden hat. Es muss außerdem das Ergebnis der Entscheidung enthalten. Ein späterer Aktionseintrag sollte auf die aktuelle Sitzungsidentität verweisen, damit ein Ermittler die Aktion mit der Freigabe verbinden kann, die sie erlaubt hat.

Führe diesen Eintrag zusammen mit dem restlichen Aktionsverlauf nur anhängend fort. Sallyports verschlüsseltes, hashverkettetes Auditprotokoll und die Offline-Prüfung mit sp audit verify sind hier besonders nützlich, weil das Ersetzungsereignis und die anschließenden Aktionen eine gemeinsam verifizierbare Sequenz bilden können. Das Prüfergebnis bestätigt, dass die gespeicherte Sequenz nicht verändert wurde. Es macht eine zu weit gefasste Freigaberichtlinie jedoch nicht nachträglich akzeptabel.

Wenn ein Benutzer eine Sitzung widerruft, erfasse den Widerruf für die Identität der ausführbaren Datei, die diese Sitzung besaß. Hat eine Ersetzung eine neue Freigabe erhalten, sollte sie weiterhin separat sichtbar bleiben. Dieses Detail verhindert, dass eine Widerrufskontrolle eine umfassendere Wirkung suggeriert, als sie tatsächlich hat.

Eine Freigabekarte braucht die Fakten davor und danach

Eine Karte für eine neue Freigabe nach exec sollte die Ersetzung auf einen Blick erklären und die sichere Entscheidung erleichtern. Allgemeine Abfragen führen dazu, dass Menschen sie einfach durchklicken. Eine Karte, die die geänderte ausführbare Datei nennt, liefert genau dann einen Grund zum Innehalten, wenn sich etwas geändert hat.

Beginne mit der Identität der neuen ausführbaren Datei und dem Aktionskanal, den sie verwenden möchte. Zeige anschließend, dass ein bereits freigegebener Prozess sie gestartet hat, sowie den Namen und Pfad der alten ausführbaren Datei, den neuen Pfad und den Signaturherausgeber. Stammt die Ersetzung aus einem Skript oder Launcher, beschreibe diese Beziehung in klaren Worten.

Verwende ein Entscheidungsmodell, das genau offenlegt, was der Benutzer freigibt. Die Freigabe der Ersetzung soll den Lauf dieser ausführbaren Datei bis zum Beenden autorisieren, vorbehaltlich der Tresorkontrolle und aller Zugangsdaten, die eine Freigabe pro Aufruf verlangen. Sie soll keine Geschwisterprozesse, künftige Ersetzungen oder eine aktualisierte Datei am selben Pfad nachträglich autorisieren.

Für die Formulierung gibt es einen nützlichen Test: Könnte ein müder Entwickler einen erwarteten Helfer von einem unerwarteten Downloader unterscheiden? Wenn nicht, fehlen der Karte die entscheidenden Fakten. Mehr dekorative Sicherheitssprache wird das nicht beheben.

Halte die Zahl der Abfragen durch stabile Ausführung niedrig, nicht durch eine weit gefasste Vererbung. Ein normaler Agent, der dasselbe Programmbild behält, sollte eine Sitzungskarte anzeigen. Ein Prozess, der den Akteur wechselt, sollte eine Karte anzeigen, weil er genau die Grenze überschritten hat, die das Sitzungskonzept durchsetzen soll.

Baue Tests für die tatsächlichen Umgehungsversuche

Teste die Autorisierungsgrenze mit Ersetzungen, die oberflächliche Kennungen beibehalten. Tests mit einer stabilen Binärdatei finden nicht die Fehler, durch die die Berechtigung an die falsche ausführbare Datei gelangt.

Beginne mit diesen Fällen:

• Eine freigegebene Binärdatei führt einen Re-Exec einer exakten Kopie ihrer selbst aus. Das Gateway behält die Sitzung bei und erfasst ein Kontinuitätsereignis.
• Die Binärdatei führt einen Re-Exec einer anderen signierten ausführbaren Datei desselben Herausgebers aus. Das Gateway verweigert Aktionen, bis die Person den neuen Lauf freigibt.
• Ein Symlink hat weiterhin dieselbe Pfadzeichenfolge, verweist aber auf eine andere ausführbare Datei. Das Gateway fordert erneut eine Freigabe an.
• Ein Shell-Skript ändert seinen Inhalt, nachdem die Sitzung begonnen hat. Die nächste vom Skript gesteuerte Anfrage verwendet die frühere Entscheidung nicht erneut.
• Ein Launcher startet ein Kind, und das Kind versucht eine HTTP- oder SSH-Aktion. Das Kind braucht eine eigene Sitzungsentscheidung.

Teste anschließend die Reihenfolge. Lass die Ersetzung unmittelbar nach exec eine Aktionsanfrage senden. Bestätige, dass das Gateway sie ablehnt oder ausstehend hält, und prüfe, dass weder Zugangsdaten injiziert noch SSH ausgeführt wird, bevor das Ergebnis der Freigabe eintrifft. So findest du Implementierungen, die ihr Journal erst aktualisieren, nachdem sie die Arbeit bereits gestartet haben.

Teste den Widerruf in derselben Suite. Widerrufe einen freigegebenen Lauf, versuche einen Re-Exec desselben Programmbilds und bestätige, dass der widerrufene Zustand Vorrang hat. Gib eine neue Ersetzung frei, widerrufe nur die ursprüngliche Sitzung und prüfe, ob sich die beiden Einträge entsprechend den ausdrücklich beschriebenen Produktkontrollen verhalten. Ein Sitzungsmodell verdient Vertrauen, wenn sich seine Grenzfälle so verhalten, wie es seine sichtbare Sprache verspricht.

Prüfe zum Schluss die Audit-Ausgabe aus Sicht eines Menschen. Du solltest eine einzelne Aktion über ein Ersetzungsereignis bis zur Freigabekarte zurückverfolgen können, die die ausführbare Datei abgedeckt hat. Wenn dafür PIDs abgeglichen, Zeitstempel erraten oder ein möglicherweise geänderter Pfad als vertrauenswürdig angenommen werden muss, enthält das Modell weiterhin eine Lücke.

Beim Prozessersatz ist der Moment für klare Grenzen. Der alte Code hatte eine Freigabe. Der neue Code braucht eine eigene.