Exportieren (0) Drucken
Alle erweitern
Erweitern Minimieren

Least Privileges – Es geht auch ohne Administratorrechte!

Veröffentlicht: 15. Aug 2005
Von Michael Willers

Dass man nach Möglichkeit ohne Administratorechte arbeiten sollte, dürfte sich mittlerweile herumgesprochen haben und die Schlagworte Non-Admin und Limited User Acess, auch LUA genannt, beginnen sich einzubürgern. Nur, was tun, wenn eine lebenswichtige Anwendung die Entziehungskur partout verweigert und darauf besteht nur mit Adminrechten zu laufen? Und was tun, wenn die Anwendung über Jahre gewachsen ist? Wie macht man diese Komplexität beherrschbar? Dieser Beitrag zeigt geeignete Systemwerkzeuge und Lösungswege für die Analyse.

Auf dieser Seite

 Inspektion – Warum werden Adminrechte gebraucht?
 Entziehungskur – Wie werde ich die Adminrechte los?
 Resümee
 Weitere Ressourcen

Inspektion – Warum werden Adminrechte gebraucht?

Sofern es sich um eigenen Code handelt, möge man einfach mal nach allen Stellen suchen, bei denen Einstellungen in der Registry abgelegt werden oder die Anwendungen Dateien erzeugt und beschreibt. Sofern dabei auf den Registryzweig HKEY_LOCAL_MACHINE geschrieben wird, ist der erste Übeltäter identifiziert. Dies dürfen standardmäßig nur Administratoren und der lokale Systemaccount. Wenn es die Registry denn unbedingt sein muss gehören die Einstellungen in der Zweig HKEY_CURRENT_USER. Da hat zusätzlich auch der aktuell angemeldete Benutzer Schreibrechte.

Ähnlich verhält es sich mit Dateien. Hier gehören sämtliche Einstellungen eines Benutzers auch in dessen Profil. Das oftmals beliebte Ablegen von Dateien im Programmverzeichnis ist ebenfalls nur den Administratoren und dem lokalen Systemaccount vorbehalten. Das Stichwort zum Thema Benutzerprofile und Verzeichnisse lautet übrigens Environment.Specialfolders bzw. für die Windows SDK Programmierer unter uns SHGetFolderPath. Die MSDN-Dokumentation hilft hier weiter.

Sofern man keinen Zugriff auf den Code hat oder die Anwendung ziemlich umfangreich ist, müssen Werkzeuge her, um die schwachen Stellen zu finden. Ein erster Ansatz ist es, einfach mal die Helferlein REGMON und FILEMON aus dem Hause Sysinternals (ww.sysinternals.com) auf die Anwendung loszulassen. Mit Ihrer Hilfe lässt sich herausfinden, auf welche Registryeinträge oder Dateien eine Anwendung zugreift (siehe Bild 1).

Dem Übel auf der Spur
Bild 1: Dem Übel auf der Spur

Aber Achtung: Sie „hängen“ sich tief in das System ein (Kernmodus) und können deshalb nur mit Administratorrechten betrieben werden. Die Suche nach Problemen kann auf diese Weise allerdings sehr aufwändig werden, weil diese Tools systemweit arbeiten und die Zugriffe sämtlicher Anwendungen „abhören“. Selbst beim Einsatz von Filtern (siehe Bild 2) kann leicht der Überblick verloren gehen.

Die Maschen werden enger - Filter im Regmon
Bild 2: Die Maschen werden enger - Filter im Regmon

An dieser Stelle setzt der Application Verifier von Microsoft an (siebe Bild 3). Mit seiner Hilfe lassen sich gezielt die Zugriffe einer einzelnen Anwendung protokollieren- unabhängig davon, ob man Zugriff auf den Quellcode der Anwendung hat.

Die Idee dieses Werkzeugs ist es, eine Anwendung systematisch auf verschiedene Fehlerszenarien hin „abzuklopfen“ und die Ergebnisse in einer Logdatei festzuhalten. Diese Szenarien beruhen auf den Erfahrungen von Microsoft und gelten als die am Häufigsten auftretenden Fehler innerhalb von Windowsanwendungen.

Allerdings kann man dieses Werkzeug nur dann wirklich sinnvoll einsetzen, wenn bekannt ist, wie Anwender mit einem Programm arbeitet. Anders ausgedrückt: Man sollte die Use-Cases kennen! Es sollte dokumentiert sein, auf welche Betriebssystemressourcen (Verzeichnisse, Drucker, Registry, etc.) eine Anwendung zugreift!

Ob das nun per UML-Diagram oder einfaches Aufschreiben oder wie auch immer geschieht ist völlig egal. Wichtig ist, dass dieses Wissen vorhanden ist. Nur so besteht überhaupt die Chance, im Falle eines Angriffs systematisch vorzugehen und das Problem zu orten.

Sind die Use-Cases allerdings dokumentiert, lässt sich der Application Verifier wunderbar zur Qualitätssicherung einsetzen, da man Testszenarien beliebig oft wiederholen und die Ergebnisse anhand der Logdateien (siehe Bild 4) vergleichen kann. Übrigens kann man damit auch ganz hervorragend MSI-Pakete einem prüfenden Blick unterziehen.

Inspektion unter der Motorhaube - Der Application Verifier in Aktion
Bild 3: Inspektion unter der Motorhaube - Der Application Verifier in Aktion

Schwarz auf Weiß - Application Verifier Logdateien
Bild 4: Schwarz auf Weiß - Application Verifier Logdateien

Der Application Verifier ist Bestandteil des Application Compatibility Toolkits, das man unter [1] herunterladen kann. Auch er muss im Kernmodus laufen und sollte daher nicht auf einem Produktivsystem eingesetzt werden.

Schwieriger wird es allerdings, wenn es sich nicht um fehlende Rechte, sondern um Betriebssystemprivilegien [2] handelt. Hier hilft leider nur „Trial & Error“ weiter. Also erst mal sämtliche Privilegien vergeben und dann schrittweise wieder wegnehmen.

Entziehungskur – Wie werde ich die Adminrechte los?

Wenn nun bekannt ist, warum eine Anwendung unbedingt mit Administratorrechten laufen, will stellt sich die Frage, wie man das Problem beheben kann. Sofern die Anwendung Zugriff auf einzelne Ressourcen benötigt (z.B. ein ganz bestimmter Registryschlüssel) oder gar Privilegien voraussetzt (z.B. „Log on as Service“) bietet sich folgende Arbeitsweise an:

  • Erstellen Sie eine Benutzergruppe

  • Ordnen Sie dieser Gruppe gezielt die Zugriffsrechte oder Privilegien zu

  • Ordnen Sie der Gruppe alle Benutzer zu, die die Anwendung nutzen.

Das Modell ist also „Pro Anwendung eine Benutzergruppe“ mit den entsprechenden Rechten. Sie behalten so leichter den Überblick auch bei mehreren Anwendungen und die Administration wird vereinfacht. Bei einer überschaubaren Anzahl von Rechnern können Sie die notwendigen Privilegen lokal über die Management Console (SECPOL.MSC) bzw. netzwerkweit über die Group Policies vornehmen oder die notwendigen Rechte über die Eigenschaften vergeben (z.B. Rechtsklick auf eine Datei, Properties -> Security).

Bei einer großen Anzahl von Maschinen ist dies nicht praktikabel. Eine mögliche Lösung wäre es hier, ein MSI-Paket für den Windows Installer zu erstellen, welches gezielt die Rechte bzw. Privilegien freischaltet und die Benutzergruppe einrichtet.

Mit Visual Studio .NET kann ein solches Paket leicht über Installerklassen erstellt werden. Weitere Hinweise zum programmatischen Einrichen von Rechten und Privilegen finden Sie auch unter [2]. Das fertige Paket könnte dann per Group Policy über Active Directory im Netzwerk verteilt werden. Dabei macht man sich ein besonders Feature des Windows Installers zunutze: Mit seiner Hilfe kann man bei Installationen im Netzwerk einen sogenannten "Elevated Install" durchzuführen. Der Netzwerk-Administrator kann also dem Setup-Programm die Möglichkeit einräumen, sich vorübergehend zum Administrator zu befördern.

Falls sie nun aber doch angesichts des Programmieraufwands ein wenig Luft holen, gibt es vielleicht auch eine andere Lösung. Und die kommt von Microsoft in Form des Compatibility Administrator Tools daher, das ebenfalls Bestandteil des Application Compatibility Toolkits ist (siehe auch Bild 5).

Die Grundidee: Seit dem Erscheinen von Windows 2000 gibt es viele Anwendungen, die entweder nicht mehr korrekt oder überhaupt nicht mehr laufen. Und sie haben eines gemeinsam: Die Fehlerursachen sind in der Mehrzahl der Fälle immer wieder die gleichen. Für diese Fehler hat Microsoft seit Windows 2000 sogenannte Compatibility Fixes in das Betriebssystem eingebaut, die diese Fehler beheben. Oder auf gut deutsch: Fehlerbehebungen. Sie biegen sozusagen die in der Anwendung schlampig programmierten Aufrufe so um, daß die Anwendung dann trotzdem läuft (sie finden Sie übrigens als Unterverzeichnis AppPatch im Windowsverzeichnis).

Das Compatibility Administrator Tool in Aktion
Bild 5: Das Compatibility Administrator Tool in Aktion

Damit dieses Verfahren auch für Ihre eigenen Anwendungen funktioniert, müssen Sie Windows mitteilen, wie es Ihre Anwendung handhaben soll und genau dies ist die Aufgabe des Compatibility Administrator Tools. Mit seiner Hilfe erstellen Sie eine Datenbank, die die Zuordnung von Fehlerbehebung und Anwendung herstellt und aktivieren dann durch Installation dieser Datenbank das „Umbiegen“ der Aufrufe auch für Ihre Anwendung.

Dabei haben Sie auch die Möglichkeit, den Anwender mit einer Hinweismeldung zu beglücken und ggf. auch den Start einer Anwendung gänzlich zu untersagen.

Und um Ihnen das Leben ein wenig einfacher zu machen gibt es vorkonfigurierte Szenarien, die verschiedene Compatibility Fixes zusammenfassen, um eine Anwendung unter Windows 2000 oder höher zum Laufen zu bringen.

Ein solches Szenario wird auch mit Compatibility Mode bezeichnet. Die nach Ansicht von Microsoft am Häufigsten gebrauchten Szenarien können Sie auch direkt über den Explorer einstellen (z.B. Rechtsklick auf eine Datei, Properties -> Compatibility, siehe auch Bild 6).

Kompatiblität bequem – Kompaibilitätseinstellungen im Explorer
Bild 6: Kompatiblität bequem – Kompaibilitätseinstellungen im Explorer

Viele Anwendungen laufen wie eingangs erwähnt nur deshalb mit Administratorrechten, weil sie Einträge im Registryzweig HKEY_LOCAL_MACHINE erstellen oder Dateien in Bereichen ablegen, die vom Betriebssystem geschützt sind. Für genau diesen Zweck wird ein eigener Kompatibilitätsmodus mit der Bezeichnung LUA bereitgestellt. Er fasst die nachfolgend beschriebenen Fehlerbehebungen zusammen:

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

  • LUARedirectFS: Das Anlegen und Beschreiben von Daten, die nicht im Profil des Benutzers abgelegt sind, werden auf eben diesen Bereich umgeleitet und die Dateien im Verzeichnis \Document and Settings\<username>\Application Data\<Name der Anwendung> abgelegt
    (z.B. \Documents and Settings\Michael Willers\ApplicationData\ConsoleApp)

Beim Entfernen der Anwendung müssen diese Umleitungen natürlich wieder aufgehoben werden. Da aber das Setupprogramm davon nichts weiss, muß es anders gehen. Und eben deshalb gibt es einen weiteren Problemlöser, der auf den Namen LUACleanup hört und mit den Fehlerbehebungen LUARedirectRegCleanup und LUARedirectFSCleanup diese Aufhebung durchführt.

LUA steht dabei für „Limited User Access“. Microsoft bezeichnet damit allgemein Szenarien, in denen Anwendungen nicht mit Administratorrechten, sondern im Kontext einens normalen Benutzers laufen.

Anders gesagt: Sofern die Anwendung nur deshalb mit Adminrechten läuft, weil sie die Registry falsch beschreibt oder Datei ablegen will, wo diese nicht hingehören, brauchen Sie keine einzige Zeile Code zu implementieren. Hier können Sie das Problem mit dem Compatibility Aministrator Tool rein deklarativ lösen. Kurz: Eine Entziehungkur in Sachen Adminrechten ohne viel Aufwand!

Zum Thema Deployment des Toolkits und der notwendigen Datenbank finden Sie übrigens weitere Informationen in der Dokumentation des Application Compatibility Toolkits unter dem Stichwort „Deploying Compatibility Fixes“ .

Eine große Ausnahme bilden übrigens Gerätetreiber. Sofern diese so programmiert sind, daß sie im Kernmodus laufen, haben Sie keine Chance. Das geht ohne Administratorrechte schlicht weg nicht. Andererseits: Sobald eine Anwendung im Kernmodus läuft, kann sie sowieso sämtliche Sicherheitsmechanismen aushebeln. Sprich: Ihre Annahmen und Garantien bezüglich der Sicherheit gehen komplett den Bach runter, sobald eine Anwendung im Kernmodus läuft.

Viele Treiber (die, die nicht im Kernmodus laufen) 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ösen Code einzuschleusen, der als Treiber getarnt ist. Aus diesem Grund sollten nur möglichst wenig Benutzer überhaupt in der Lage sein, Treiber zu installieren und deshalb dürfen dies standardmäßig eben nur die Administratoren.

Sie haben in diesem Fall zwei Möglichkeiten: Sie schwingen sich kurzzeitig per „Run as“ zum Administrator auf oder Sie installieren als priviligierter Benutzer grundsätzlich nur signierte Treiber. Natürlich muss dieser Benutzer auch Schreibrechte auf den Registryzweig HKEY_LOCAL_MACHINE und dem Windows-Systemverzeichnis (System32) besitzen. Eine höchst gefährliche Angelegenheit also - selbst dann, wenn die Treiber signiert sind. Kurz gesagt: Sie sollten Treiber grundsätzlich nur als Administrator installieren.

Resümee

Jede Anwendung, die mit Administratorrechten läuft ist ein potentielles Sicherheitsrisiko. Allerdings hängt es vom Einsatzfall ab, ob es wirtschaftlich sinnvoll ist, Abhilfe zu schaffen. Um dann eine Erziehungskur in Sachen Adminrechten erfolgreich durchzuführen bedarf es zweier Dinge. Zum Einen müssen Sie wissen, was so alles auf Ihre Anwendung zukommt.

Sie müssen die Use-Cases kennen. Zum Anderen benötigen Sie Analysewerkzeuge, um diese Fälle auf Sicherheitsprobleme hin abzuklopfen und diese zu beheben. Das Application Compatibility Toolkit von Microsoft und die Helferlein von Sysinternals bieten Ihnen diese Werkzeuge. Machen Sie sich damit vertraut. Oder wollen Sie etwa derjenige sein, der im Falle eines Falles den Stecker aus der Wand zieht?

Weitere Ressourcen

[1] Application Compatibility Toolkit
Das Application Compatibility Toolkit ist ein kostenloses Analysewerkzeug von Microsoft, mit dem sich Kompatibilitätsprobleme von Anwendungen mit den aktuellen Windowsversionen ermitteln lassen. Damit können mögliche Probleme bereits während der Entwicklungsphase erkannt und entsprechende Maßnahmen zu deren Lösung ergriffen werden.

[2] Webcast: Übersicht Application Compatibility Toolkit
Sie haben noch nie vom Application Compatibility Toolkit gehört? Sie möchten sich einen Überblick zu diesem Werkzeug und dessen Einsatzmöglichkeiten verschaffen? Oder sind sie auf der Suche nach Praxistipps für den Einsatz in Ihren Projekten? Dann hilft dieser Webcast vielleicht weiter.


Anzeigen:
© 2015 Microsoft