Lokal Adminrechte erlangen

[Assarbad]

Zitat:

Zitat von Der schöne Günther (Beitrag 1463259)

Ganz konkret:

• Zwei Benutzer, "localUser" und "localAdmin". Ersterer gehört nicht zur Gruppe "Administratoren", letzterer schon
• Eine aktive Sitzung im Benutzer "localUser". Der Benutzer doppelklickt unseren Prozess
• Der Prozess hat in seinem Manifest, wie wohl so ziemlich jeder,
  Delphi-Quellcode:

  requestedExecutionLevel
  level="asInvoker"

• Der Prozess soll nun das Verzeichnis C:\Program Files\Watzn erstellen.

Kann er das?

asInvoker bezieht sich auf UAC, welches bekanntlich nur wenig mit Sicherheit zu tun hat (siehe auch hier).

Bei standardmäßig gesetzten Zugriffslisten (ACLs) sollte das nicht erfolgreich sein. Aaaaber, es gibt noch die UAC File Virtualization (der entsprechende Minifilter kann per fltmc unter dem Eintrag luafv gefunden werden), welche den Zugriff transparent auf einen anderen Ordner umleitet auf den der (unprivilegierte) Anwender sehr wohl Zugriff hat (UAC muß dafür natürlich aktiviert sein).

Ich weiß also noch immer nicht, ob es dir um Admin (entsprechende Benutzerrechte und Gruppenzugehörigkeit), oder um Elevation (UAC) oder um Mandatory Integrity Control (MIC) geht.

Zitat:

Zitat von Der schöne Günther (Beitrag 1463259)

Dein Beitrag liest sich so als ginge das.

Unter der genannten Bedingung kann das gehen, ja.

Dein Delphicode sollte auch das tun was man annimmt, da sich der Admin ja über LogonUser dem System gegenüber ausweist. Kommt natürlich auf die involvierten Integrity-Level an. Sprich: zwar kann ein einzelner Thread "Admin werden", aber er unterliegt trotzdem noch MIC.

Zitat:

Zitat von Der schöne Günther (Beitrag 1463259)

Selbst bei TeamViewer kann man das beobachten: Der Benutzer führt einen TeamViewer-QuickSupport aus. Authentifiziert sich jemand von außen mit den Kontodaten eines Administrator-Accounts startet TeamViewer sich selbst noch einmal und beendet sich dann. So kannte ich es bislang.

Genau, das klingt jetzt wiederum stark nach MIC.

[Der schöne Günther]

Zitat:

Zitat von Assarbad (Beitrag 1463268)

Ich weiß also noch immer nicht, ob es dir um Admin (entsprechende Benutzerrechte und Gruppenzugehörigkeit), oder um Elevation (UAC) oder um Mandatory Integrity Control (MIC) geht.

Mir geht es eigentlich nur um die Frage des Themen-Erstellers.

Wir sind mittlerweile angekommen bei wilden Abkürzungen wie MIC, UAC, ACL, RID und was weiß ich noch, aber wenn es um das eigentliche Problem geht kommt wieder "kann gehen", "sollte" und "müsste".

Ich bekomme es nicht hin, ohne Neustarten des "normal doppelgeklickten" Prozesses ein Verzeichnis unter C:\Programme anzulegen. Vielleicht du? Dann könnten wir alle davon lernen.

[Assarbad]

Zitat:

Zitat von Der schöne Günther (Beitrag 1463269)

Wir sind mittlerweile angekommen bei wilden Abkürzungen wie MIC, UAC, ACL, RID und was weiß ich noch, aber wenn es um das eigentliche Problem geht kommt wieder "kann gehen", "sollte" und "müsste".

Wenn man mit den Sicherheitsmechanismen von Windows umgehen will, sollten diese "wilden Abkürzungen" eben geläufig sein. Ich hab ja auch absichtlich verlinkt, damit man sich notfalls schlaulesen kann.

Und ja, es kommt der Konjunktiv, weil der Fragesteller eben nicht relevante Fragen beantwortet ala UAC File Virtualization; sprich ob UAC nun aktiv ist oder nicht. Das spielt nunmal hier rein. Genauso wie MIC reinspielt, welches ja wiederum über "Elevation" mit UAC verbunden ist.

Zitat:

Zitat von Der schöne Günther (Beitrag 1463269)

Ich bekomme es nicht hin, ohne Neustarten des "normal doppelgeklickten" Prozesses ein Verzeichnis unter C:\Programme anzulegen.

Liegt nah und weist auf MIC in Aktion hin.

Ich hab kein Windows zur Hand um das auf die Schnelle selbst zu testen, zumal ich aktuell auf Linux unterwegs bin und komplett andere Dinge im Kopf hab. Um das zu testen empfehle ich euch mal den Process Explorer zur Hand zu nehmen, da kann man die Spalten Virtualization (da geht's um die UAC File Virtualization) und Integrity Level aktivieren. Zusammen mit Process Monitor sieht man dann sehr schnell warum es nicht klappt.

Das Problem ist, daß du gleich mehrere Dimensionen mit folgender Aussage

Zitat:

Zitat von Der schöne Günther (Beitrag 1463191)

Das Impersonate gibt dem Prozess nicht plötzlich Adminrechte. Entweder ein Prozess wird mit Adminrechten gestartet, oder ohne. Das lässt sich nicht nachträglich ändern.

total verkürzt. Und daher ja meine Frage an dich, was du unter Admin-Fähigkeiten bzw. Adminrechten verstehst.

Je nachdem was man darunter faßt, stimmt deine Aussage eben oder nicht. So allgemein stimmt die Aussage aber eben nicht.

Oder um es anders auszudrücken: deine Diagnose hat fachliche Schwächen, aber dein Fazit dürfte weiterhin gelten.

[Hobbycoder]

Okay, ich bin durch eure Diskussion leicht verwirrt. Soll/muss/kann es jetzt gehen oder nicht?

In meinem o.g. Code hier bekomme ich ja bei korrekten Anmeldedaten (in meinem Fall vom lokalen Administrator) vom Impersonate ein True zurück, was ja nun bedeutet, dass diese Anmeldung korrekt war. Das darauf folgende ForceDirectories im Programme-Order schlägt jedoch fehl mit "Zugriff verweigert".

Heißt das jetzt, dass die Funktion Impersonate lediglich dazu verwendet werden kann ein fremden Userkontext zu laden, oder könnte man tatsächlich systemweit als dieser Benutzter handeln, sprich eben Dinge tun, die dem Administrator vorbehalten sind.

Denn das:

Zitat:

Zitat von Assarbad (Beitrag 1463243)

Öhm ... also ImpersonateLoggedOnUser gibt in der Tat dem Thread die Rechte des Nutzers dessen Identität man annimmt. Himitsu erwähnte es bereits.

widerspricht dem:

Zitat:

Zitat von Der schöne Günther (Beitrag 1463220)

Man durch diese "Impersonation" sich als anderer Benutzer ausgeben, auf dessen Resourcen (z.B. Registry oder Dateien) zugreifen, aber die Admin-Fähigkeiten kommen dadurch nicht nach.

[Assarbad]

Zitat:

Zitat von Hobbycoder (Beitrag 1463328)

Denn das:

Zitat:

Zitat von Assarbad (Beitrag 1463243)

Öhm ... also ImpersonateLoggedOnUser gibt in der Tat dem Thread die Rechte des Nutzers dessen Identität man annimmt. Himitsu erwähnte es bereits.

widerspricht dem:

Zitat:

Zitat von Der schöne Günther (Beitrag 1463220)

Man durch diese "Impersonation" sich als anderer Benutzer ausgeben, auf dessen Resourcen (z.B. Registry oder Dateien) zugreifen, aber die Admin-Fähigkeiten kommen dadurch nicht nach.

Nein, es widerspricht sich nicht. Beide Aussagen - wie ich in meiner (vorletzten?) Antwort herausgearbeitet habe, haben ihre Berechtigung. Sie beziehen sich auf verschiedene Aspekte.

MIC ist der Grund warum du scheiterst. Somit ist der Rat vom schönen Günter korrekt, daß du es in einen anderen Prozeß auslagern mußt, um diese "Security Boundary" zu überbrücken.

Die Frage, der bisher alle geflissentlich ausgewichen sind, ist: wie definiert ihr Adminrechte/Admin-Fähigkeiten. Denn auch mit Impersonate lassen sich durchaus noch diverse Dinge tun, die vor dem Annehmen der Adminidentität so nicht möglich gewesen wären. Daß das für die Erstellung eines Verzeichnisses an dem besagten Ort nicht reicht, hat mit MIC zu tun.

Zitat:

Zitat von Hobbycoder (Beitrag 1463328)

Heißt das jetzt, dass die Funktion Impersonate lediglich dazu verwendet werden kann ein fremden Userkontext zu laden, oder könnte man tatsächlich systemweit als dieser Benutzter handeln, sprich eben Dinge tun, die dem Administrator vorbehalten sind.

MIC gibt es "erst" seit Vista oder so. Davor reichte Impersonate durchaus um so gut wie alles als der jeweilige Benutzer zu machen.

Kurzfassung: starte die Erstellung des Verzeichnisses in einem anderen Prozeß mit höherem Integritätslevel. Es reicht dazu, wenn du bspw. dein Programm über eine Befehlszeilenoption nochmal selbst - diesmal als Admin auf entsprechendem Integritätslevel - startest.

[Hobbycoder]

Danke, dass du dir nochmal die Mühe gemacht hast, dieses mir so ausführlich klar zu machen. Jetzt ist der Groschen gefallen.
Natürlich auch Dank an alle anderen.