Delphi-PRAXiS - Delphi Vista: Rechte anfordern OHNE Manifest?

Man kann die UAC verwenden, um erhöhte Rechte zu bekommen. Das geht entweder über ein Manifest oder über ein OutOfProcess COM-Server. Der Com-Server ist auch nicht mehr als eine Exe oder DLL-Datei, die einfach mit erhöhten Rechten ausgeführt wird. Man muss immer einen neuen Prozess mit den erhöhten Rechten starten damit es funkz.

Windows2000 führte eingeschränkte Benutzertoken ein. Ein Token enthält Informationen, wie Gruppenmitgliedschaften. Ein eingeschränktes Token enthält daher ein oder mehrere eingeschränkte Gruppen. Eine eingeschränkte Gruppe wird nur für Verweigerungen in Zugriffskontrolllisten (DACL) verwendet. In Vista werden eingeschränkte Benutzertoken werden nun aktiv verwendet.
Unter Vista gibt es zudem Zwillings- oder LinkedToken. Ist u.a. die Gruppe Administratoren in einem Token vorhanden, so erstellt das System eine Kopie dieses Tokens, entfernt einige Privilegien und ändert die Admin-gruppe, wie schon beschrieben, auf nur-verweigern.
Diese beiden Token werden nun verknüpft und man kann mit GetTokenInformation das jeweilige andere Token erhalten. Anfangen kann man damit jedoch nicht wirklich etwas. Ist der Benutzer übrigens in keine entsprechenden Admingruppe, so entfällt das Zwillingstoken. Die UAC fordert in diesem Falle auf, einen Adminaccount und dessen Passwort einzugeben.

Wenn ein Prozess erhöhte Rechte erfordert, dann kann er zuersteinmal nichts machen. Er fährt mit dem Token, welches die nur-verweigern Admingruppe enthält. Was die UAC also nun macht, ist den Prozess mit dem Zwillingstoken zu starten. Das geht über einen Service ganz einfach, indem man CreateProcessAsUser verwendet und das Token verwendet, welches die Admingruppe aktiv enthält.
Jetzt ist es auch einsichtig, warum CreateProcessWithLogonW und LogonUser mit CreateProcessAsUser oder ImpersonateLoggedOnUser, sowie ähnliche Funktionen nicht mit der UAC funktionieren. Das System loggt den Benutzer ein und liefert immer ein eingeschränktes Token zurück.
Was wir also brauchen ist ein Dienst, der dies macht.

Mit einem COM-Server läuft das etwas anders. Hier wird nicht direkt ein neuer Prozess aufgerufen. Um es zu vereinfachen, kann man es so ausdrücken: Das System lädt das COM Objekt in einen internen Prozess, der mit dem erhöhten Token läuft. Dort werden die Methoden des Objekts mit erhöhten Rechten ausgeführt. Jedesmal wenn eine Methode ausgeführt werden soll, wird der Methodenname und dess Parameterwerte mit der Hilfe eines Marshalls in einen Datenstrom zerlegt, der dann an den internen Prozess gesendet wird. Dort wird die Funktion ausgeführt und die Rückgabewerte werden genauso zurückgesendet.

Der Schluss liegt also jetzt nahe, dass ein eigener Dienst, das "Problem" des UAC-Prompts umgeht. Ein Dienst könnte das eigene Programm auf Anfrage mit erhöhten Rechten erneut starten. Dazu umgehen wir völlig die UAC - es kommt also keinerlei Abfrage.
Große Nachteile sind jedoch:
1. Es muss ein Dienst installiert werden. Dies kommt der Einrichtung eines COM-Servers nahe. Stichwort: Adminrechte
2. Der Dienst muss gesichert mit der Anwendung kommunizieren. D.h. entweder über Pipes, gemeinsamer anonymer Speicher (nicht-anonymer Speicher würde kein Sinn machen, da ihn jeder verwenden könnte. Man kann ihn auch nicht wirklich sichern.) oder andere Möglichkeiten. Hier muss ich jedoch wirklich darauf hinweisen, dass ein Dienst, der Befehle annehmen kann, ein wirkliches Sicherheitsrisiko darstellen kann, wenn man es nicht richtig macht und einfach alle Befehle annimmt und nicht überprüft. Zudem kommen TerminalServer spezifische Sachen, wie Sessionquarantäne und -restriktionen in Spiel. Ein Dienst muss genau wiessen, aus welcher Terminalsitzung ein Programm stammt und dort das Programm mit erhöhten Rechten starten. Zudem können keinerlei Handles über zwei verschiedenen Sitzungen vererbt werden. Darunter fallen auch Handles zu Pipes und gemeinsamer anonymer Speicher.
3. Die neue (erhöhte) Anwendung sollte nicht auf dem normalen Desktop des Anwenders gestartet werden. Laut Microsoft ist es sonst möglich per Nachrichten (SendMessage) die Anwendung zu kompromitieren. Daher wäre ein neue Desktop erforderlich. Leider ist es aktuell nicht ohne weiteres möglich einen Desktop in einer WindowStation (Winsta0) in einer anderen TSitzung zu erstellen. CreateDesktop wurde dafür nicht geschaffen. Hier wäre es notwendig, direkt mit den Kernelobjekten (NT objects) zu arbeiten.

PS.
CreateProcessWithLogonW verwendet den Dienst "Sekundärer Anmeldedienst" und wird fehlschlagen wenn dieser deaktiviert ist, wie z.B. im Kioskmodusvon Windows. LogonUser mit CreateProcessAsUser wäre eine Lösung dafür.