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

Mein Baby

Es wird Zeit für ein Coming Out. Ich habe ein Baby, und zwar seit 5 Jahren schon. Es heisst "ideri Note" und ich bin stolz auf den kleinen Racker. Mein Baby ist der Beweis dafür, dass man innerhalb von 4 Monaten 60.000 lines of code schreiben kann, wenn man will und motiviert ist. Und das am Feierabend und wochenends. Und dass es möglich und gar nicht so schwierig ist, das "Compatible with Windows 7" logo und das "Works with Windows Server 2008 R2" logo mit Glanz und Gloria zu bekommen, und das ohne eine einzige Warnung im Prüfprotokoll. Mein Baby war mir in den letzten 5 Jahren der Ausgleich zur hauptberuflichen Tätigkeit, die Sache, an der ich alle ausgetretenen Pfade verlassen durfte und scheinbar spinnerte Ideen produktiv werden lassen konnte, wofür ich Alex und Joe unendlich dankbar bin. Und natürlich das, wo ich mein Herzblut verschüttet habe. Selbstverständlich ist ideri Note nicht mein Produkt, sondern das der ideri GmbH aus Ostfildern.

Und wer von meinen Ex-Kollegen sich immer gewundert hat, woher ich so viel über Winqual und Sysdev wusste und wie das alles geht mit Symbol Stores, cab files von winqual runterladen und debuggen, der weiss jetzt, wo ich mir das alles vorher angeeignet habe. Bei der Gelegenheit ist es dann fast schon Eigenlob, wenn ich erwähne, dass es bis heute auf der winqual/sysdev-Seite von ideri Note keinen einzigen Minidump aus dem Feld gibt. Nur die von mir selbst fabrizierten, damit ich die ganze Infrastruktur mal testen kann. Das ist ein echter Ritterschlag, ideri Note hat keine Bugs, die bekannt wären, seit Jahren schon. Der einzige bekannte Crash trat einmal im ideri Note Administrator beim Beenden auf, das war kurz vor dem Release von ideri Note 2.0 und kurz vor dem Release von Windows XP SP2. Da haben die Jungs von Microsoft ihre eigenen Regeln verletzt und in DllMain von aclui.dll einen delete-operator aufgerufen. Den Bug haben sie in SP3 von Windows XP gefixt, aber mein Code in ideri Note hat natürlich eine Sonderbehandlung von XP SP2 an dieser Stelle :-)

Besonders spiffy finde ich an ideri Note immer wieder selber die Dokumentation. Sie besteht aus normalen Textdateien, die einer ältlichen Version von doxygen eingefüttert werden und daraus, nach kräftiger Massage durch Skripte, die alles entfernt, was irgendwie nach doxygen aussieht, LaTeX und html generiert. Das wird dann durch die entsprechenden Compiler übersetzt und sieht dann wie professionelle Windows-CHM-Hilfe und via LaTeX nach pdf übersetzt, wie ein richtig gutes Handbuch aus.

Und auch geil sind die Setups , alle mit WiX gemacht, mit eigenem Transform-Wizard zum Erzeugen von MSTs für das Setup des ideri Note Clients. Und so Dinge wie vollständiger Support für Group-Policies mit ADM-files. Ich frage mich ja bis heute, warum so wenige Entwickler Group-Policy-Overrides für ihre Registry-Settings implementieren. Das ist so eine tolle Technologie und kaum einer benutzt es.

Wer es nicht weiss: ideri Note ist ein Real-Time Enterprise Messaging Programm, das in seiner Integrationstiefe in das Active Directory unerreicht ist. Es ist eine 2-Tier Client-Server Lösung (tut das nicht mal gut, keinen third tier mit einer Datenbank haben zu müssen?) bei der Integrated Windows Security, ohnehin mein Lieblingsthema, ganz im Vordergrund steht und nach meinem unmassgeblichen Dafürhalten perfekt implementiert ist.

Und wem das alles noch nicht genügt, sollte den Client oder die command line tools mal auf Linux mit WINE installieren. Mit einer Standardinstallation von Samba und einer AD-Integration mit winbind läuft auch das.

Update 07/15/2012: Hier der Downloadlink von Heise:


IDERI Note, Download bei heise


Natürlich kann man sich das auch von der ideri Note Website runterladen.

OMG, the windows side bar is gone...

Da habe ich mir Ende 2008 einen abgebrochen und für meine Freunde von ideri ein total abartiges Sidebar-Gadget entwickelt, das aus JavaScript ideri-Note APIs aufruft, mit flyouts und mehreren Instanzen und MSI-Installer dazu, einem für x86 und einem für x64, und jetzt erklärt Microsoft, dass das Ganze Ding mit der Sidebar ein Irrtum war, eine Sicherheitslücke, die man jetzt  einfach bleiben lässt? Das nenne ich konsequent.

Quote of the day

"Gut, vielleicht gibt es ein paar wenige passionierte CD-Sammler, die sind aber fast so selten wie Galapagos-Riesenschildkröten und stehen diesen auch in puncto Sexyness in nichts nach."

Die Onlineausgabe der "Süddeutschen Zeitung" heute über den (vermeintlichen) Niedergang der Musik-CD. Wow, eine derartig ernüchternde Bescheinigung meiner Attraktivität hat mir schon lange niemand mehr ausgestellt...

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.

<< 1 ... 4 5 6 7 8 9 10 11 12 13 14 ... 45 >>