Tja es ist machbar. Ich habe es schon gemacht. Und ein anderer auch.
Allerdings was du vorschlägst, ist die Vordertüre ins Haus einfach offenstehen zu lassen und zudem noch die Schlüssel zum Tresor auf der Türschwelle.
Zitat von
CodeX:
- Der normale Benutzer startet das Programm, dieses merkt, dass es nicht genügend Rechte hat, benachrichtigt den Dienst (über Pipes) und beendet sich wieder.
Ein böses Programm könnte dein Programm ersetzen oder einfach nur den Dienst über die Pipe benachrichtigen, dass es ein (böses) Programm gestartet haben will. Die einzige Möglichkeit das zu verhindern, wäre dein Programm zu signieren und den Dienst das überprüfen zu lassen.
Es gäbe noch die Möglichkeit den Dienst das Programm mit SHARE_DENY_WRITE offenzuhalten. Aber es gibt Mittel und Wege dies während des Bootvorgangs zu umgehen.
Zitat von
CodeX:
Der Dienst startet nun das Programm, sodass dieses über die geerbten erhöhten Rechte des Dienstes verfügt, und kann normal verwendet werden.
Ist das machbar? Wenn ja, wie genau?
Und schon sind wir an der Stelle angelangt, an der du ein Programm startest, welches nur Adminrechte benötigt aber nicht gleich SYSTEM-Rechte. SYSTEM ist doch ein bisschen härter. Also nutzen wir doch nur Adminrechte. Wie?
Der Benutzer ist kein Administrator. Aber vielleicht hat er das Passwort? Ein Aufruf zu LogonUser mit dem Passwort erzeugt das Admintoken. (nur nicht in Vista) Damit kann man mit CreateProcessAsUser einen Prozess mit Adminrechten starten. Aber hier gibt es schon wieder ein Problem:
Wo wird das Passwort eingegeben? In einem Dialog natürlich. BÖSE. Der Dialog sollte niemals auf dem Benutzerdesktop angezeigt werden, da jedes andere Programm dies abhöhren könnte (Wenn ein systemweiter Keylogger installiert ist, dann ist eh alles zu spät). Also sollte dieser Dialog in einem eigenen Desktop dargestellt werden.
Das dumme dabei ist: Ein Dienst kann das nicht (ohne beträchtlichen Aufwand). Er muss ein Prozess mit normalen Benutzerrechten erzeugen, der den Desktop erzeugt, das Passwort abfragt und es dem Dienst übermittelt. Und das die ganze Kommunikation geht nichtmal mit Pipse, wie Experte Apollonius sicher bezeugen kann (Er hat es ja so gemacht).
Nun bleibt noch die Frage, welcher Benutzer will denn den Prozess gestartet haben? Ist der Benutzer vielleicht über RemoteDesktop eingeloggt? Hat der Benutzer ein FastSwitch gemacht und sitzt als anderer Benutzer Y vor dem PC? Sind mehrere angemeldet? Läuft der Benutzer in Session 0 oder noch 1 rum? 0,1,2,3,4,5,6... ?
In welche Session soll der Prozess gespawnt werden?
Zu allem überfluss muss der Prozess auch noch
GUI darstellen können. D.h. er benötigt Rechte in der Windowstation und Desktop. Die LogonSessionID in den Tokengroups ist ideal dazu. Leider funkz das nicht mit LogonUser. Wir benötigen "The function from hell" : LsaLogonUser.
Hab ich schon LoadUserProfile erwähnt? Es lädt das Benutzerprofil. Und man sollte es auch wieder entladen, wenn der Prozess fertig ist und seine Kinder.
Zitat:
Hier und
hier gibt es jasehr interessante Informationen und Ansätze, aber allein damit komme ich nicht weiter.
Ich hoffe sehr, dass wir auf eine allgemein verwendbare Lösung kommen können...
Allgemein kann man da nichts verwenden. Es ist schon so spezifisch alleine, dass man, wenn man es allgemein Verwendbar machen würde ein riesiges Sicherheitsproblem beschwören würde. Ohne das obige Wissen würde man bis dahin aber erst garnicht kommen. Es würde nur durch pures Glück überhaupt funktionieren. Jedoch allein die obige Aufzählung beschreibt ja noch nichteinmal annähernd, wie man es implementiert.
In der
JWSCL ist ein Projekt mit dem Namen XP Elevation drin. Es ist noch nicht fertig - leider. Ein Benutzer ohne Adminrechte kann dadurch ein Prozess mit Adminrechten starten. Hat all das was oben drin ist (Mit Ausnahme von Vista-spezifischem, die ich extra gelagert habe). Zudem wird der neue Desktop mit den Benutzerhingergrund bemalt. Echt super Feature
