Exportieren (0) Drucken
Alle erweitern
Erweitern Minimieren

Dr. Watson in Sachen Adminrechte

Veröffentlicht: 02. Sep 2005
Von Michael Willers

Dass man nach Möglichkeit ohne Administratorrechte arbeiten sollte, dürfte sich herumgesprochen haben. Schlagwörter wie Non-Admin und Limited User Acess, auch LUA genannt, beginnen sich einzubürgern. Nur, was tun, wenn sich eine lebenswichtige Anwendung der Entziehungskur partout verweigert und darauf besteht, nur mit Adminrechten zu laufen?

dotnetpro


Diesen Artikel können Sie dank freundlicher Unterstützung von dotnetpro auf MSDN Online lesen. dotnetpro ist ein Partner von MSDN Online.
Ausgabe 04/2005


Zur Partnerübersichtsseite von MSDN Online

Sofern es sich um eigenen Codehandelt, ist die Lösung einfach. SuchenSie nach allen Stellen, an denenEinstellungen in der Registry abgelegtwerden oder Ihr Programm Dateienerzeugt oder in diese schreibt.

Sofern dabei auf den Registry-ZweigHKEY_LOCAL_MACHINE geschriebenwird, haben wir den ersten Übeltäter entlarvt.Dies dürfen standardmäßig nur Administatorenund der lokale System-Account. Wenn es die Registry denn unbedingtsein muss, gehören die Einstellungenin den Zweig HKEY_CURRENT_USER.In diesem Abschnitt hat zusätzlich auchder aktuell angemeldete Benutzer Schreibrechte.

Ähnlich verhält es sich mit Dateien.Hier gehören sämtliche Einstellungen einesBenutzers auch in dessen Profil. Dasbeliebte Ablegen von Dateien im Programmverzeichnisist ebenfalls nur denAdministatoren und dem lokalen System-Account vorbehalten.

Das Stichwort zum Thema Benutzerprofileund Verzeichnisse lautet übrigensEnvironment.Specialfolders beziehungsweisefür die Windows-SDK-Programmiererunter uns SHGetFolderPath. Die Dokumentationin der MSDN Subscriptionhilft in diesem Fall weiter.

Sofern Sie keinen Zugriff auf den Codehaben oder ihre Anwendung umfangreichist, müssen Werkzeuge her, welchedie schwachen Stellen finden.

Ein erster Ansatz ist es, die HelferleinREGMON und FILEMON aus dem HauseSysinternals (www.sysinternals.com) aufdie Anwendung loszulassen. Mit ihrerHilfe lässt sich herausfinden, auf welcheRegistry-Einträge oder Dateien eine Anwendungzugreift. In Abbildung 1 sehenSie den Registry Monitor in Aktion - demÜbel auf der Spur.

Dem Übel auf der Spur
Abbildung 1: Dem Übel auf der Spur.

Aber Achtung: Die Tools hängen sichtief in das System ein (Kernel-Modus)und können deshalb nur mit Administratorrechtenlaufen.

Also gilt: Anwendung mit einem normalenBenutzeraccount laufen lassenund die Helferlein per "Run as" unterdem Administrator-Account ausführen.Oder anders gesagt: Finger weg von Produktivsystemen.

Auf dieser Seite

 Application Verifier: Der Helferin der Not
 Wie werde ich die Adminrechtelos?
 Es geht auch einfacher
 Fazit
 Der Autor

Application Verifier: Der Helferin der Not

Die Suche nach Übeltätern kann auf dieseWeise allerdings sehr aufwändig werden,weil diese Tools systemweit arbeitenund die Zugriffe sämtlicher Anwendungen"abhören". Selbst beim Einsatz vonFiltern - siehe Abbildung 2 - kann daleicht der Überblick verloren gehen.

Die Maschen werden enger - Filter im Regmon
Abbildung 2: Die Maschen werden enger - Filter im Regmon.

An dieser Stelle setzt der ApplicationVerifier von Microsoft an, den Sie in Abbildung3 in Aktion sehen. Mit seiner Hilfelassen sich gezielt die Zugriffe einereinzelnen Anwendung protokollieren -unabhängig davon, ob der Code Ihnenvorliegt oder nicht. Die Idee dieses Werkzeugsist es, eine Anwendung systematischauf verschiedene Fehlerszenarienhin abzuklopfen und die Ergebnisse in einerLogdatei festzuhalten. Diese Szenarienberuhen auf den Erfahrungen vonMicrosoft und gelten als die am häufigstenauftretenden Fehler innerhalb vonWindows-Anwendungen. Weitere Informationenfinden Sie in der Dokumentationdes Verifiers.

Der Application Verifier in Aktion
Abbildung 3: Inspektion unter der Motorhaube: Der Application Verifier in Aktion.

Allerdings können Sie dieses Werkzeugnur dann wirklich sinnvoll einsetzen, wennSie wissen, was die Anwender mit IhremProgramm anstellen. Anders ausgedrückt:Dokumentieren Sie die Use-Cases! DokumentierenSie, auf welche Betriebssystemressourcen,wie Verzeichnisse, Drucker, Registry,Ihre Anwendung zugreift!

Ob das nun per UML-Diagramm odereinfaches Aufschreiben oder wie auchimmer geschieht ist völlig egal. Wichtigist, dass Sie dieses Wissen besitzen. Nurso haben Sie überhaupt eine Chance, imFalle eines Angriffs systematisch vorzugehenund das Problem zu orten.

Haben Sie diese Hausaufgaben gemacht,lässt sich dieses Werkzeug wunderbarzur Qualitätssicherung einsetzen,da man Testszenarien beliebig oft wiederholenund die Ergebnisse anhand derLogdateien (siehe Abbildung 4) vergleichenkann. Übrigens kann man damitauch ganz hervorragend MSI-Pakete einemprüfenden Blick unterziehen.

Schwarz auf Weiß - Application Verifier Logdateien
Abbildung 4: Schwarz auf Weiß - Application Verifier Logdateien.

Der Application Verifier ist Bestandteildes Application Compatibility Toolkits,das man unter [1] herunterladen kann.Auch er muss im Kernel-Modus laufenund sollte daher nicht auf einem Produktivsystemeingesetzt werden.

Sollte es Ihnen nun in den Fingern jucken,nur zu. Auf der Heft-CD finden Siezwei Beispiele mit einer Anleitung zumAusprobieren.

Schwierigerwird es allerdings,wenn es sich nichtum fehlende Rechte,sondern um Betriebssystemprivilegien[2] handelt.Hier hilft nur Trialand-Error weiter.Also erst mal sämtlichePrvilegienvergeben unddann schrittweisewieder wegnehmen.

Wie werde ich die Adminrechtelos?

Wenn Sie nun wissen,warum IhreAnwendung unbedingtmit Administratorrechtenlaufenwill, stellt sichdie Frage, wie Sie das Problem behebenkönnen. Soferndie Anwendung Zugriffauf einzelneRessourcen benötigt(zum Beispiel einenganz bestimmten Registry-Schlüssel)oder gar Privilegien voraussetzt (zum Beispiel"Log on as Service") bietet sich diefolgende Arbeitsweise an:

  • erstellen Sie eine Benutzergruppe,

  • ordnen Sie dieser Gruppe gezielt dieZugriffsrechte oder Privilegien zu,

  • ordnen Sie der Gruppe alle Benutzerzu, die die Anwendung nutzen.

Das Modell ist also "Pro Anwendungeine Benutzergruppe" mit den entsprechendenRechten. Sie behalten so leichterden Überblick auch bei mehreren Anwendungenund die Administration wirdvereinfacht. Bei einer überschaubarenAnzahl von Rechnern können Sie die notwendigenPrivilegen lokal über die ManagementConsole (SECPOL.MSC) beziehungsweisenetzwerkweit über die GroupPolicies vornehmen oder die notwendigenRechte über die Eigenschaften vergeben(zum Beispiel über Rechtsklick aufeine Datei, Properties/Security).

Bei einer großen Anzahl vonMaschinen ist dies nicht praktikabel.Eine mögliche Lösungwäre es hier, ein MSI-Paket fürden Windows Installer zu erstellen,das gezielt die Rechtebeziehungsweise Privilegienfreischaltet und die Benutzergruppeeinrichtet.

Mit Visual Studio .NET kannein solches Paket leicht über Installerklassenerstellt werden.Weitere Hinweise zum programmatischenEinrichen vonRechten und Privilegen findenSie auch unter [2]. Das fertigePaket könnte dann per GroupPolicy über Active Directory imNetzwerk verteilt werden. Dabeimacht man sich ein besonderesFeature des Windows Installerszunutze: Mit seiner Hilfekann man bei Installationen im Netzwerkeinen so genannten Elevated Installdurchführen. Der Netzwerk-Administratorkann also dem Setup-Programm dieMöglichkeit einräumen, sich vorübergehendzum Administrator zu befördern.

Es geht auch einfacher

Falls Sie nun aber angesichts des Programmieraufwandsein wenig nach Luftschnappen, kann ich Sie beruhigen: Esgibt vielleicht auch eine andere Lösung.Und die kommt von Microsoft in Formdes Compatibility Administrator Toolsdaher, das ebenfalls Bestandteil des ApplicationCompatibility Toolkits ist - sieheauch Abbildung 5.

Das Compatibility Administrator Tool in Aktion
Abbildung 5: Das Compatibility Administrator Tool in Aktion.

Seit dem Erscheinen von Windows2000 gibt es viele Anwendungen, die entwedernicht mehr korrekt oder überhauptnicht mehr laufen. Und sie haben einesgemeinsam: Die Fehlerursachen sind inder Mehrzahl der Fälle immer wieder diegleichen. Für diese Fehler hat Microsoftseit Windows 2000 so genannte CompatibilityFixes in das Betriebssystem eingebaut,die diese Fehler beheben. Oder aufgut Deutsch: Fehlerbehebungen. Sie biegensozusagen die in der Anwendungschlampig programmierten Aufrufe soum, dass die Anwendung trotzdem läuft.Sie finden Sie übrigens als UnterverzeichnisAppPatch im Windows-Verzeichnis.Damit dieses Verfahren auch für Ihre eigenenAnwendungen funktioniert, müssenSie Windows mitteilen, wie es IhreAnwendung handhaben soll, und genaudies ist die Aufgabe des Compatibility AdministratorTools. Mit seiner Hilfe erstellenSie eine Datenbank, die die Zuordnungvon Fehlerbehebung und Anwendungherstellt, und aktivieren dann durchInstallation dieser Datenbank das "Umbiegen"der Aufrufe auch für Ihre Anwendung.

Dabei haben Sie die Möglichkeit, denAnwender mit einer Hinweismeldung zubeglücken und auch den Start einer Anwendunggänzlich zu untersagen.

Und um Ihnen das Leben ein wenigleichter zu machen, gibt es vorkonfigurierteSzenarien, die verschiedene CompatibilityFixes zusammenfassen, um eine Anwendung unter Windows 2000 oderhöher zum Laufen zu bringen.

Ein solches Szenario wird auch mitCompatibility Mode bezeichnet. Die nachAnsicht von Microsoft am häufigsten gebrauchtenSzenarien können Sie auch direktüber den Explorer einstellen, zumBeispiel über einen Rechtsklick auf eineDatei, Properties/Compatibility, sieheauch Abbildung 6.

Kompatibilitätseinstellungen im Explorer
Abbildung 6: Kompatibilitätseinstellungen im Explorer.

Viele Anwendungen laufen wie eingangserwähnt nur deshalb mit Administratorrechten,weil sie Einträge im Registry-Zweig HKEY_LOCAL_MACHINE erstellenoder Dateien in Bereichen ablegen,die vom Betriebssystem geschütztsind. Für genau diesen Zweck wird ein eigenerKompatibilitätsmodus mit der BezeichnungLUA bereitgestellt. Er fasst dienachfolgend beschriebenen Fehlerbehebungenzusammen:

  • LUARedirectReg
    Das Anlegen und Schreiben von Registryeinträgenim Zweig HKEY_LOCAL_MACHINE wird auf den ZweigHKEY_CURRENT_USER umgeleitet.Die Einträge werden dann im Bereich\Software\Redirected abgelegt.

  • LUARedirectFS
    Das Anlegen und Beschreiben vonDaten, die nicht im Profil des Benutzersabgelegt sind, wird auf eben diesenBereich umgeleitet und die Dateienim Verzeichnis \Document andSettings\<username>\ApplicationData\<Name der Anwendung> abgelegt(zum Beispiel \Documents andSettings\Michael Willers\ApplicationData\ConsoleApp).

Beim Entfernen der Anwendung müssendiese Umleitungen natürlich wiederaufgehoben werden. Da aber das Setupprogrammdavon nichts weiss, muss esanders gehen. Und eben deshalb gibt eseinen weiteren Problemlöser, der auf denNamen LUACleanup hört und mit denFehlerbehebungen LUARedirectRegCleanupund LUARedirectFSCleanup dieseAufhebung durchführt.

LUA steht dabei für "Limited User Access".Microsoft bezeichnet damit allgemeinSzenarien, in denen Anwendungennicht mit Administratorrechten, sondernim Kontext einens normalen Benutzerslaufen.

Anders gesagt: Sofern die Anwendungnur deshalb mit Adminrechten läuft, weilsie die Registry falsch beschreibt oder Dateiablegen will, wo diese nicht hingehören,brauchen Sie keine einzige Zeile Code zu implementieren.Hier können Sie dasProblem mit dem CompatibilityAministratorTool rein deklarativ lösen.Kurz: Eine Entziehungkurin Sachen Adminrechtenohne vielAufwand!

Zum Thema Deploymentdes Toolkits undder notwendigen Datenbankfinden Sie übrigensweitere Informationenin der Dokumentationdes ApplicationCompatibility Toolkitsunter dem Stichwort"Deploying CompatibilityFixes" .

Und so es Ihnen jetztwieder in den Fingernjuckt finden Sie auf derHeft-CD eine schrittweiseAnleitung, mit derSie dieses Werkzeug einfachmal ausprobierenkönnen.

Eine große Ausnahme bilden übrigensGerätetreiber. Sofern diese so programmiertsind, dass sie im Kernmodus laufen,haben Sie keine Chance. Das gehtohne Administratorrechte schlicht wegnicht. Andererseits: Sobald eine Anwendungim Kernmodus läuft, kann sie sowiesosämtliche Sicherheitsmechanismenaushebeln. Sprich: Ihre Annahmenund Garantien bezüglich der Sicherheitgehen komplett den Bach runter, sobaldeine Anwendung im Kernmodus läuft.

Viele Treiber - die, die nicht im Kernmoduslaufen - lassen sich aber auch installieren,wenn der Benutzer das Privileg"Load and unload device drivers" besitzt.

Das allerdings ist nicht ohne Risiko:Ein Angreifer könnte versuchen, bösenCode einzuschleusen, der als Treiber getarntist. Aus diesem Grund sollten nurmöglichst wenig Benutzer überhaupt inder Lage sein, Treiber zu installieren unddeshalb dürfen dies standardmäßig ebennur die Administratoren.

Sie haben in diesem Fall zwei Möglichkeiten:Sie schwingen sich kurzzeitigper "Run as" (siehe auch [3]) zum Administratorauf oder Sie installieren als priviligierterBenutzer grundsätzlich nur signierteTreiber. Natürlich muss dieser Benutzerauch Schreibrechte auf den Registry-Zweig HKEY_LOCAL_MACHINE unddem Windows-Systemverzeichnis (System32) besitzen. Eine höchst gefährlicheAngelegenheit also - selbst dann, wenndie Treiber signiert sind. Kurz gesagt: Siesollten Treiber grundsätzlich nur als Administratorinstallieren.

Fazit

Jede Anwendung, die mit Administratorrechtenläuft, ist ein potenzielles Sicherheitsrisiko.Allerdings hängt es vom Einsatzfallab, ob es wirtschaftlich sinnvoll ist,Abhilfe zu schaffen. Um dann eine Entziehungskurin Sachen Adminrechten erfolgreichdurchzuführen, bedarf es zweier Dinge.Zum einen müssen Sie wissen, was soalles auf Ihre Anwendung zukommt. Siemüssen die Use-Cases kennen.

Zum anderen benötigen Sie Analysewerkzeuge,um diese Fälle auf Sicherheitsproblemehin abzuklopfen und diesezu beheben. Das Application CompatibilityToolkit von Microsoft und die Helferleinvon Sysinternals bieten Ihnen dieseWerkzeuge. Machen Sie sich damit vertraut.Oder wollen Sie etwa derjenigesein, der im Falle eines Falles den Steckeraus der Wand zieht?

[1] www.microsoft.com/windows/appexperience/
[2] Michael Willers, Sichere Software-Verteilung,dotnetpro 12/2004, Seite 114 ff.

Der Autor

Michael Willers ist Senior Architect beider newtelligence AG.Er berät Projektverantwortliche,Software-Architektenund Entwickler beim Design und derImplementierung von Lösungen fürdie Microsoft .NET Plattform. Er warzuvor mehrere Jahre technischer Beraterbei Microsoft. Nach einer Entziehungskurlebt er seit nunmehr zweiJahren ohne Administratorrechte undberichtet von seinen Erfahrungen imWeb unter staff.newtelligence.net/michaelw/.


Anzeigen:
© 2015 Microsoft