...someplace, where there isn't any trouble? Do you suppose there is such a place, Toto?

Trickkiste: Wozu ist GetTokenInformation(..., TokenLinkedToken,...) gut?

Die Doku auf MSDN zeigt sich reichlich dürr, was die Beschreibung dieser TOKEN_INFORMATION_CLASS angeht. Es heisst lediglich: "The buffer receives a TOKEN_LINKED_TOKEN structure that contains a handle to another token that is linked to this token". Und in der Beschreibung zur Struktur TOKEN_LINKED_TOKEN heisst es zum einzigen Member der Struktur, LinkedToken:  "A handle to the linked token."

Sehr elaboriert, diese Erklärungen. Hier beschreibe ich mal, welches Problem man mit dem Linked Token löst:

Wenn man eine Anwendung (oder in dem Fall eher einen Service) am Laufen hat, der einen AccessCheck mit einem restricted Token gegen einen Security Descriptor macht, der dann deswegen scheitert, weil der Token restricted ist, aber erfolgreich wäre, wenn der Token kein restricted Token wäre, dann sollte die Anwendung einen AccessCheck nicht gegen den restricted Token machen, sondern gegen dessen linked Token, wenn man diese Semantik nicht haben möchte mit dem Scheitern wegen eines restricted Tokens.

"Errhhh, whut?"

Vielleicht lässt sich das Ganze an einem Beispiel erklären: Wir haben einen Service, der unter Vista oder Server 2008 oder höher läuft. Wir nehmen weiterhin an, dass der Service einen Client impersonated und der Impersonation Token ist bei einem Clientrequest mal zufällig der restricted Token eines Consent Admins. Wenn nun in unserem Service ein Aufruf von AccessCheck mit diesem Token gegen einen Security Descriptor stattfindet, der für ein Access Right, das dem AccessCheck übergeben wurde, eine Access Allowed ACE in der DACL beinhaltet, dann scheitert AccessCheck mit ERROR_ACCESS_DENIED, obwohl das eine Access Allowed ACE war. Das ist so by design, so funktionieren restricted Tokens, das ist die erhöhte Sicherheit, die man seit Windows Vista mit User Account Control hat, wo man für solche Fälle einen Consent Admin eben zu einem Full Admin elevaten muss. Wäre nämlich der Client-Prozess, von dem der Token stammt, elevated, so würde der Service den full Token impersonaten und derselbe Aufruf von AccessCheck wäre dann erfolgreich (unter der Annahme, dass im Security Descriptor nicht noch irgendeine explizite Access Denied ACE in der DACL wäre). Wenn man will, dass der AccessCheck mit dem restricted Token in diesem Fall scheitert, weil etwa der Service dann eine privilegierte Aktion auslöst, dann kann man natürlich mit diesem Verhalten durchaus auch zufrieden sein. Dann benutzt der Service die User Account Control und daraus entstandene restricted Tokens genau so wie beispielsweise der Rest des Betriebssystems beim Zugriff auf das Dateisystem etc.

Aber nicht jeder AccessCheck den man in seinem Service macht, führt zu einer privilegierten Aktion. Und nicht jeder Service möchte unbedingt dieselbe Semantik mit restricted Tokens verwenden wie der Rest des Systems, vielleicht will unser Service ja die traditionelle Semantik verwenden aus der Zeit vor dem Erscheinen der restricted Tokens.

Aber wie kommt es überhaupt zu der Situation, dass ein impersonated Token ein restricted Token ist? Restricted Token gibt es schliesslich nur für interaktiv angemeldete User und der Impersonation Token eines Service entstammt üblicherweise einer Netzwerklogonsession eines Users, der an einer entfernten Maschine interaktiv angemeldet ist.

Die Antwort: Der Token kann genau dann restricted sein, wenn der Clientprozess auf derjenigen Maschine läuft, auf der auch der Service läuft, also wenn Client und Server lokal laufen und der zugehörige User zum Client ein Consent Admin ist. Das ist nur auf den ersten Blick ein etwas pathologisches Szenario, denn das gibt es tatsächlich alle Nase lang. Vorstellbar beispielsweise bei einem Service, der Custom Windows NT object security verwendet um Zugriff auf die Ressourcen, die er verwaltet, zu regulieren und dieser Service ist zufällig auf einem Terminal Server installiert, auf dem die User den zu diesem Service zugehörigen Client benutzen.

In dieser Situation wäre es nun erforderlich, dass das Clientprogramm elevated wird, und das kann es ja auch nicht sein, dass lokale Clients unseres Service immer elevated werden müssen, wenn der User des Clients ein Consent Admin ist. Und hier kommt nun der Linked Token ins Spiel: Anstatt dass vom Client eine Spezialbehandlung erwartet wird indem man gezwungen wird, ihn zu elevaten, muss der Server sich in dem Fall anders verhalten. Er darf nicht den Impersonation Token mit dem AccessCheck API verwenden, sondern dessen linked Token. Tatsächlich ist das einer der seltenen Fälle wo man älteren Servercode ein wenig abändern muss, damit er unter Vista und Server 2008 und später genauso funktioniert wie unter Server 2003 und früher.

Nun könnte man noch auf folgendes Angriffsszenario kommen: Wenn man ein Consent Admin ist, dann besorgt man sich seinen linked Token (der nicht mehr restricted ist) und ruft damit CreateProcessAsUser auf, um sich so ohne Elevation einen privilegierten Prozess zu verschaffen. Geht aber nicht, weil der linked Token kein primary Token ist (und sich auch nicht zu einem machen lässt). Das geht nur, wenn der eigene Prozess das Privileg SE_TCB_NAME ("act as part of the operating system") enabled hat. Wenn man allerdings  SE_TCB_NAME enablen kann, ist man in der "Trusted Computing Base" und damit eh schon privilegiert und muss sich nicht noch privilegierter machen. Also kein Angriffsszenario.

Betriebssystemgynäkologie

Aus einer Unterhaltung während einer Probe im Oktober 2011, die mir gerade wieder eingefallen ist:

 

Christina E.: "Stefan, was machst Du eigentlich beruflich?"

Stefan: "Ich bin ... blah, rhabarber, wichtigtu ... fasel. Und der frühere Geschäftsführer meines Arbeitgebers hat mich dewegen immer als den Betriebssystemgynäkologen bezeichnet."

Klaus K.: "So jemand könnten wir hier an der Musikschule auch mal gut gebrauchen."

Christina E.: "Was, einen Gynäkologen!?!"

Klaus K.: "Das vielleicht auch, aber hauptsächlich jemand, der sich mit Betriebssystemen auskennt."

 

Die Komik der Situation erschliesst sich einem nur, wenn man weiss, dass Christina E. zum damaligen Zeitpunkt zu zweit war und schon aussah, als hätte sie einen Medizinball verschluckt.

Bow-Tie Gig am IMS Stuttgart

Heute war auch noch ein Gig der Bow-Tie am IMS der Uni Stuttgart. Die Bilder dazu sind hier. Dieses hier gefällt mir am Besten, das ist Laura, Ralph, Olli Schulz und ich, vermutlich bei Bobby Timmons' "Moanin'", ein Klick auf das Bild öffnet es in einem neuen Browserfenster in gross:

Ausstand/Farewell party

I have begun to hate these farewell parties years ago. It was a PITA to see all these brilliant and nice people go over the course of the years. But even though I am neither brilliant nor a nice guy, I felt obliged to invite my peers to a farewell party on 06/27/2012 during lunch time. Until the day before, only 9 people had acknowledged to participate and I already suspected that this is now the consequence of me being such an anti-social lad throughout the last years. But luckily, it turned out that this was either because of people recently having changed their groupware client to a newer version that they do not yet master sufficiently or simply an Exchange configuration problem. Sort of like 25 people eventually joined the party and it was really some very emotional event.

Please see the pictures from this party using this link.

At the beginning I held a very eloquent speech and the picture where you see Kai kneeling before me is where I promote him to the new mission control supreme commander. After that, my Teamlead, Oliver, held his speech as well and part of it was his request to me demonstrating for the very last time what I always deemed being something way cool: Swallowing a giant chocolate marshmallow in one fell swoop. That's what I always did for the delightment of my peers in the past when someone brought a box of chocolate marshmallows into the office and the only person who always found this really disgusting was Swetlana. Maybe for a reason.

After this fun part was over, the real fun part began: My farewell present. It was the complete "Calvin and Hobbes" edition in English. Cute! Thank you everyone for this nice present.

After that, people enjoyed the wonderful salads and the non-vegetarians have told me, that the meat loaf was delicious, too.

In eigener Sache: "We had to let them go..."

Die letzten Wochen waren weder Fisch noch Fleisch. Zwischen Baum und Borke. Nicht hüh und nicht hott. Between the devil and the deep blue sea. Neither fish, nor flesh, nor good red herring. Neither here nor there. Zwischen Triebwerk und Toilettentür. Oder was es sonst noch so an mehr oder weniger brauchbaren Metaphern gibt.

Der Grund ist der, dass ich - sagen wir es mal so - in der zweiten Maiwoche ganz bewusst etwas an meiner Erwerbsbiographie geändert habe. Ich habe bei meinem soon-to-be-ex-Arbeitgeber gekündigt und werde ab 1.7.2012 unter neuer Flagge segeln, und zwar bei einer Firma in Leinfelden (gerne gebe ich genauere Informationen über meinen neuen Arbeitgeber nach einer persönlichen Mail). Und zum Zeitpunkt meiner Kündigung war eine grössere Menge Resturlaub aufgelaufen, so dass ich seither viele Wochen Zeit zum Nachdenken, fürs Freibad und sonst alles mögliche hatte und mich auch auf meine neue Stelle fachlich ein wenig vorbereiten konnte. Also sowas wie grosse Ferien und sowas wie nicht mehr so richtig für den alten Arbeitgeber und noch nicht so richtig für den neuen Arbeitgeber. Daher das Füllhorn an passenden und unpassenden Metaphern am Anfang.

Damit wären dann gut 10 Jahre bei demselben Arbeitgeber, zuerst als NetSupport GmbH, dann umbenannt in enteo GmbH und schliesslich nach der Akquisition durch gleichnamige Firma als FrontRange Solutions Deutschland GmbH, für mich Geschichte. Zeit also für eine kleine Abrechnung :-) ...

Keine Angst, so unprofessionell bin ich dann doch nicht. Denn was in der Erinnerung bleibt, sind sowieso immer nur die positiven Dinge, und selbst mir als ausgemachtem Zyniker wird's jetzt, vor meiner letzten Arbeitswoche mit zwei letzten harten Arbeitstagen, schon beinah a bissal schwer um's Herz, wenn ich an die letzten 10 Jahre zurückdenke. Und schliesslich hat ja auch schon Oscar Wilde (jedenfalls schreibt man ihm diesen Spruch zu) gesagt:

"Scratch a cynic?s surface and you'll find a disappointed romantic."

 

Vieles wird mir fehlen. Nicht das heimelige Surren der zuletzt 8 Maschinen an meinem Arbeitsplatz. Nicht das Privileg, direkt neben der Firma zu wohnen und an heissen Sommertagen zwischendurch schnell mal eine eiskalte Dusche daheim nehmen zu können. Nicht der beispiellos lässige und meiner Meinung nach vorbildliche Umgang mit Home Office und Vertrauensarbeitszeit. Nicht der wöchentliche Massageservice und auch nicht die früher kostenlosen "Süssies", das kostenlose Obst und die kostenlosen Getränke.

Was ich vermissen werde, sind die Menschen. "Uhhh, Stefan spricht über "Menschen", das menschelt ja schon richtig, das ist gar nicht seine Art", höre ich da den Kai jetzt sagen. Aber es ist wirklich so: Das grossartige Team, das wir einmal waren und zu dem wir uns über Jahre entwickelt haben, war beileibe nichts Alltägliches, darüber sollte sich jeder, vor allem aber die Jüngeren im Team, im Klaren sein. 10 Jahre in derselben Firma und man kann niemanden während dieser Zeit und auch im Nachhinein als ausgemachtes Arschloch identifizieren, das spricht nicht nur für eine kluge Einstellungspolitik sondern ganz besonders für die beteiligten Individuen ("Individuen" ... ist das jetzt besser, Kai?).

Was ich sicher auch vermissen werde:

  • Die (Sub-)Kultur der durchgängig persönlichen Anrede mit dem Kürzel ("Hey SKU!", "Hi, AFU, schon gelesen...", "Mahlzeit FZO, Du alte Schabracke..."). Wobei eindeutig diejenigen im Nachteil waren, deren Kürzel  - ganz sperrig - nur dreisilbig auszusprechen war, wie etwa bei Kai (KIH - also "Kah - Ih - Ha"). Dagegen ich mit meinem geschmeidigen Einsilber ("SKU") war da natürlich an der Spitze der Nahrungskette. Ein Sonderfall war da zweifellos der SGL, zwar Dreisilber ("Es - Geh - Ell"), aber eben auch Geschäftsführer. Aber zur Not konnte man sein Kürzel ja auch ganz elegant schwäbifiziert und mit gewollt abfälliger Konnotation zweisilbig aussprechen ("Seg-gel").
  • Die grossartigen Releaseparties. Can you say "Long Island Ice Tea", FZO?
  • Mein Büro, Mission Control, Namensgeber dieses Blogs. Und alle seine Bewohner, besonders die Säugetiere darunter, namentlich Kai. Wir beide waren die einzigen in der Firma, die niemals in andere Räumlichkeiten reloziert oder sonstwie auseinanderdividiert wurden.
  • Das Suppenschlürfen mit MLO und das gelegentliche Kakaoschlürfen mit MNE
  • Jeder fachliche Diskurs mit OTE. Ein besserer Teamlead als Oliver Tengler ist für mich nur schwer vorstellbar.
  • Die Zusammenarbeit mit dem grossartigen Testteam, das wir einmal hatten. Etwas besseres kann einem Entwickler nicht passieren, als mit so kompetenten und motivierten Leuten zu arbeiten.
  • Die perfekte Organisation des Teams durch AFU. Es gibt keinen besseren Projektleiter und Program Manager auf diesem Planeten als Andreas Fuchs.

Ich bin dankbar dafür, dass ich viel lernen durfte in diesen 10 Jahren und natürlich dafür, dass ich vielleicht dem einen oder anderen auch so einiges beibringen durfte während dieser Zeit. Aber bevor dieses Narrativ nun vollends zum sentimentalen Rührstück verkommt, lohnt sich vielleicht ein Blick nach vorne.

Moving on to greener pastures

 

Der erste, der während meiner Anstellungszeit die Firma verlassen hatte, und das schon 2003, war IBI, dem ich seither in einer Art Hassliebe zugetan bin. Er kommentierte seinen Abgang damals mit den Worten:

"Etwas Besseres als den Tod findest Du überall".

 

Das haben die drei Bremer Stadtmusikanten ihrem vierten Mitstreiter, dem Hahn gesagt, der im Kochtopf landen sollte. Dieses Motto will ich mir aber keinesfalls zueigen machen, und es gibt auch keinen Grund dazu. Denn bei meinem neuen Arbeitgeber hat man mich eingestellt, obwohl ich erst mal in einem Team landen soll, das sich mit managed code und dem IIS und Datenbanken beschäftigt, also mit Themen, die bisher von mir grosszügig gemieden wurden. Das ist ein Vertrauensvorschuss, den ich erst einmal zurückzahlen muss, denn die Lernkurve für mich wird nicht nur vorhanden, sondern vor allem erst mal steil sein. Und man hat mich wegen meines Faibles für Security-Themen eingestellt, womit ich in meinem bisherigen Berufsleben eigentlich immer eher als lästiger Fragesteller und Nestbeschmutzer, und bestenfalls - unter Absingen schmutziger Lieder - als willfähriger Erfüllungsgehilfe für die dirty little secrets aufgefallen bin. In dem Team, in dem ich arbeiten werde, geht es um Lösungen für die unzweifelhaft wichtigste Herausforderung, die unsere Gesellschaft hat, und das ist die Energiewende. Also ein Thema, das für mich als Bürger von höchster Wichtigkeit ist, für mich als Ingenieur aber die Chance bietet, an Dingen mitzuarbeiten, die dieser Gesellschaft unmittelbar nützen. Gibt es was schöneres? Wünscht mir Glück und drückt mir bitte die Daumen, dass das auch klappt.

<< 1 ... 5 6 7 8 9 10 11 12 13 14 15 ... 46 >>