Programm von Dienst starten lassen (Jetzt aber wirklich mal)

[CodeX]

Ich habe ein paar Beiträge zu ähnlichen Themen gefunden, jedoch sind diese bestenfalls auf Lösungsansätze hinausgelaufen.
Da ich das immer noch nicht hinbekommen habe, bitte ich hier um Hilfe.

Mein Szenario:
- Programm benötigt zwingend erhöhte Rechte (Adminrechte), da es diverse Systemeinstellungen ändern können soll
- Der Administrator des Systems kann natürlich Programme und Dienste installieren
- Nun soll ein normaler Benutzer das Programm verwenden können

Meine Idee:
- Administrator installiert einen Dienst
- Der normale Benutzer startet das Programm, dieses merkt, dass es nicht genügend Rechte hat, benachrichtigt den Dienst (über Pipes) und beendet sich wieder. 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?
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...

[Dezipaitor]

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

[CodeX]

Zitat von Dezipaitor:

Die einzige Möglichkeit das zu verhindern, wäre dein Programm zu signieren und den Dienst das überprüfen zu lassen.

Na, das sollte doch machbar sein. Damit ist meine Idee doch gar nicht so weit hergeholt.

Zitat von Dezipaitor:

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?

Richtig, Admin-Rechte reichen. Ich meinte auch nur, dass die System-Rechte, die ja dann wohl automatisch mitvererbt werden, auch ihre Arbeit tun würden.

Zitat von Dezipaitor:

Der Benutzer ist kein Administrator. Aber vielleicht hat er das Passwort?

Nein, davon kann ich nicht ausgehen. D.h. für diese Lösung müsste das Passwort vom Administrator verschlüsselt gespeichert werden. Aber da es spätestens im Speicher wieder entschlüsselt werden muss, ist das ja nun nicht die sicherste Lösung.
Entsprechend würde ich wirklich gerne eine Lösung mit Verwendung eines Services finden.

Das angesprochene "XP Elevation" zielt auf die Lösung mit (der sicheren Methode) der Passworteingabe ab, oder? Und ich würde zudem gerne alle OS ab Win2000 abdecken. Also inklusive Vista.

Zitat von Dezipaitor:

Tja es ist machbar. Ich habe es schon gemacht. Und ein anderer auch.

Tja, genau das würde mich interessieren. Kannst Du mir hier bitte aushelfen?

[Dezipaitor]

Zitat von CodeX:

Nein, davon kann ich nicht ausgehen. D.h. für diese Lösung müsste das Passwort vom Administrator verschlüsselt gespeichert werden. Aber da es spätestens im Speicher wieder entschlüsselt werden muss, ist das ja nun nicht die sicherste Lösung.
Entsprechend würde ich wirklich gerne eine Lösung mit Verwendung eines Services finden.

Es ist aus sicherheitstechnischen Gründen untersagt, mit SYSTEM Rechten zu arbeiten. Zudem würde die gestartete Anwendung plötzlich mit dem dem SYSTEM Profil und Umgebungsvariablen arbeiten müssen. Da sind einige Sachen anders. Daher funktionieren einige Anwendungen nicht damit.
Aber man kann natürlich den Benutzer für den zu startenden Prozess mit der Administratorgruppe ausstatten. Das ist ja auch das Hauptziel von XP Elevation. Der zu startende Prozess bekommt unter dem aktuellen Benutzer Administratorrechte, ohne dass der Benutzer Administrator sein muss. Dazu bleiben die Profilpfade erhalten.
Das einzige was sein muss, ist dass der Benutzer sein Passwort eingeben muss. Aber selbst das könnte man z.B. so machen, dass es nur einmal notwendig ist und nach jedem Dienststart. Das Passwort wird dazu nicht gesichert, sonder das Token selbst. Die Abfrage ala UAC muss jedoch bestehen bleiben, da sonst jedes beliebige Programm ein anderes ohne Benutzerwissen starten kann - mit Adminrechten!
Natürlich ist es möglich ein eigenes Token zu erstellen. Dann ist garkeine Passworteingabe mehr notwendig. Dies ist aber nicht unbedingt der Königsweg, da es doch noch einige Fallstricke enthalten könne.

Zitat:

Das angesprochene "XP Elevation" zielt auf die Lösung mit (der sicheren Methode) der Passworteingabe ab, oder? Und ich würde zudem gerne alle OS ab Win2000 abdecken. Also inklusive Vista.

Ab Windows2000 sollte es funktionieren. Für Vista müsste man noch meine andere Komponente einbauen. Windows NT <= 4 wird nicht unterstützt.

Zitat:

Tja, genau das würde mich interessieren. Kannst Du mir hier bitte aushelfen?

Lade dir die JWSCL runter und mach ein update mit Subversion (z.B. Tortoise SVN). Nur so bekommst du die inoffiziellen Teile des Paketes, darunter auch XP Elevation. Ich kann dir leider nicht alles Schritt für Schritt erklären, aber sonst helfe ich dir gerne.
Versuch dich dort einzuarbeiten, wenn es Probleme gibt, dann schreibe einfach. Wäre super wenn XP Elevation mehr Unterstützung bekommen würde.

[CodeX]

Hallo Dezipaitor,

musste mich damals von diesem Problem trennen, weil ich mich um andere dringende Dinge kümmern musste. Nun ist das wieder aktuell für mich, weil ich das definitiv immer noch benötige.

1. XP Elevation
Ich habe XP Elevation in der aktuellen Version geholt und kriege das aber nach wie vor nicht zum Laufen. Du hast gesagt, Du arbeitest da immer noch dran. Kann es sein, dass es deshalb noch nicht vollständig ist? Zumindest erhalte ich solche Meldungen:

Delphi-Quellcode:

[Pascal Fehler] JwsclVersion.pas(854): E2003 Undefinierter Bezeichner: 'IsTerminalServiceRunning'
[Pascal Fehler] JwsclSid.pas(1349): E2003 Undefinierter Bezeichner: 'CachedGetUserFromSid'
[Pascal Fehler] JwsclTerminalServer.pas(2129): E2003 Undefinierter Bezeichner: 'TWinStationShadowInformation'
[Pascal Fehler] JwsclTerminalServer.pas(2442): E2003 Undefinierter Bezeichner: 'WinStationNameFromLogonIdW'

Diese werden aber erst beim Kompilieren angezeigt, sind also noch einige mehr. Sind diese Teile einfach noch nicht veröffentlicht oder habe ich vergessen noch was einzubinden?

Ich habe mich in den letzten Tagen durch Dutzende von Artikeln zu dem Thema durchgewälzt. Mir ist dabei aufgefallen, dass es sehr wohl noch einige andere Menschen gibt, die gern genau das gleiche machen würden wie ich. Die Ansätze, die als Antworten gegeben wurden, waren unglaublich vielfältig, leider aber keins davon auf Anhieb funktionsfähig. Ich habe viel ausprobiert (2000, XP und Vista laufen bei mir seit Tagen als VM parallel mit ) und habe immer wieder eine Erkenntnis dazugewonnen. Nur leider habe ich immer noch keine Lösung.


2. Niedrigere Rechte vergeben
Nach meinen jetzigen Recherchen ist es wohl nicht möglich, dass ein Programm ein anderes Programm mit niedrigeren Rechten als den eigenen ausführt.
Also bspw. ein Programm mit Adminrechten führt ein Programm mit normalen Benutzerrechten aus.
Oder ein Programm mit Systemrechten führt ein Programm mit Adminrechten aus.

Geht das denn wirklich nicht? Dass ein Programm nicht zur Laufzeit seine Rechte ändern kann, verstehe ich. Aber dass ein Programm ein anderes nicht einfach so mit geringeren Rechten starten kann, leuchtet mir nicht ein. Es ist doch rein Sicherheitstechnisch absolut nichts dagegen einzuwenden!?


3. Systemrechte mit Benutzerumgebung
Das einzige, was ich mir jetzt nach so viel unmöglichen Möglichkeiten noch vorstellen kann, ist das der Service das Programm mit den eigenen Rechten (System) ausführt und als lpEnvironment irgendwie die Umgebung des eingeloggten Benutzers übergibt. Das lässt sich ja hoffentlich auslesen (zB über die Umgebung des Explorers). Ich meine, dass das möglich sein sollte, habe es aber noch nicht hinbekommen. Hast Du (oder natürlich gerne jemand anderes auch!) hier eine Lösung?

[Dezipaitor]

1. XPElevation
Ich vermute mal, du hast nicht die Entwicklerquellcodeversion. Die ist immer Vorraussetzung, wenn man die internen Beispiele kompilieren will. Zudem ist XPElevation im Branch und nicht im Trunk das aktuelleste. Da arbeite ich noch dran.

2. Man kann immer ein anderers Token nehmen und dies mit CreateRestrictedToken nochmals einschränken. Und als SYSTEM kann man ein eigenes Token erstellen mit LsaLogonUser oder gar CreateToken.
XPElevation nutzt LsaLogonUser, d.h. man brauchte in Password. Es kann aber (verschlüsselt) gespeichert werden.

3. Die Benutzerumgebung bringt nichts zur Sicherheit.

[Remko]

Zitat:

[Pascal Fehler] JwsclVersion.pas(854): E2003 Undefinierter Bezeichner: 'IsTerminalServiceRunning'
[Pascal Fehler] JwsclSid.pas(1349): E2003 Undefinierter Bezeichner: 'CachedGetUserFromSid'
[Pascal Fehler] JwsclTerminalServer.pas(2129): E2003 Undefinierter Bezeichner: 'TWinStationShadowInformation'
[Pascal Fehler] JwsclTerminalServer.pas(2442): E2003 Undefinierter Bezeichner: 'WinStationNameFromLogonIdW'

These are all functions defined in JwaWinsta, maybe you need to update and/or rebuild Jwa?

[SirThornberry]

warum eigentlich so kompliziert?
Letzendlich soll ja nicht ein ganzes Programm mit Adminrechten laufen sondern nur einzelne Funktionen.
Im Web wird es ja auch nicht anders gemacht. Sucht man nach etwas im Internet schickt man den Suchbegriff an einen Server und der liefert einem nur das Ergebnis zurück - also auch nicht so das man Zugang zur gesamten Datenbank bekommt.
Genau so kann man es ja auch bei einem Service machen. Der Service läuft die ganze Zeit im Hintergrund und nimmt bestimmte Anfragen entgegen und behandelt diese. Das Ergebnis schickt er dann zurück. Und schon hat man nicht mehr das Problem das die Anwendung mehr machen kann als sie soll.

[Dezipaitor]

Wenn das Programm bereits besteht und es eben Adminrechte benötigt, dann macht man es so. Andernfalls müsste man ne Client-Serverbeziehung von vorne herstellen.

[CodeX]

@SirThornberry
Das Programm besteht eben schon länger und da ist es um ein vielfaches komplizierter, das auszulagern. Zumal würde ich gerne die Option behalten, das Programm (sofern mit Adminrechten gestartet) ohne Service zu benutzen.


@Remko
I'll have a look. Thanks.


@Dezipaitor
zu 2. Das andere Token bekomme ich aber wirklich nur von einem bestimmten Administratoraccount auf dem Rechner, oder? Es wäre eben schön, wenn das auch anders gehen könnte und der User nicht gezwungen wäre, irgendein Passwort einzugeben. Kann ich denn als SYSTEM ein Admin-Token einfach so erstellen und das nicht von einem bestehenden Account kopieren? Dann bräuchte man eben keine Login-Daten...

zu 3. Ne, nichts zur Sicherheit, aber damit das Programm normal funktionieren kann und z.B. auf Current_User zugreifen kann und auf dessen Desktop dargestellt werden kann. Sonst besteht doch auch das Problem, dass die GUI gar nicht sichtbar ist.