Programm mit Adminrechten starten, ohne dass eine Sicherheitsabfrage erscheint

Hallo zusammen,

ich habe folgendes Problem.
Ich möchte gerne ein Programm unter Adminrechten starten. Grundsätzlich muss dazu scheinbar eine Manifest-Datei mit folgenden Inhalt erstellt werden.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity version="1.0.0.0"  name="someProgram.exe" type="win32"/>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="requireAdministrator"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>

Dazu habe ich das Zusatzprogramm mt.exe verwendet mit folgendem Befehl:

C:\>c:\Users\xxx\Desktop\mt.exe -manifest c:\Users\xxx\Desktop\someProgram.exe
.manifest -outputresource:C:\Users\xxx\Desktop\someProgram.exe

Wenn ich die Exe jetzt starte wird mir der Dialog zur Benutzerkontesteuerung angezeigt. Ich hatte eigentlich gedacht, dass das dann nicht passiert, aber dann habe ich gemerkt, dass das gleiche passiert wenn ich rechte Maustaste->Als Administrator ausführen klicke.

Kann man das ihrgendwie abstellen?

Ich möchte grundsätzlich ja die UAC nicht aushebeln, aber ich möchte ein Update bauen und prüfen in Hauptanwendung ob ich unter Programme schreiben darf um die neuen Programmdateien abzulegen. Evtl. kann man das vielleicht noch anders lösen. Dann würde ich mich freuen über ein paar Tipss.

Güße

Der Dialog kommt vom Betriebssystem aufgrund der Benutzereinstellung.
Der wünscht explizit die Information, dass eine Anwendung Adminrechte erfordert. Es wäre fatal, wenn das umgangen werden könnte.

Das, was Du da einstellst und einstellen kannst, das ist eben dieser Anfangsdialog, sodass Du innerhalb der Anwendung das nicht abfangen musst.
Mehr geht aber Gott sei dank nicht.

Dass bei Updatern der Dialog kommt ist völlig normal.

Hallo,

klar ist das richtig so, mein Problem ist nur, dass ich in der Hauptanwendung die neuen Dateien für mein Update herunterlade und diese in einem Temp verzeichnis im Programmordner ablege. Danach wird die Hauptanwendung geschlossen und es kommt ein zusätzliches Updateprogramm welches die neuen Dateien über die alten kopiert, also auch Schreibberechtigungen braucht. Nach dem das passiert ist startet wieder die Hauptanwendung und löscht die alten Dateien im Programmordner.

Somit müsste ich die Hauptanwendung auch immer im Adminmodus starten und das will ich eigentlich nicht.

Mmmmm. Gibt es da bessere Lösungsansätze als jetzt meinen Ansatz?

Grüße

Hallo neo,

es es reicht, den Updater mit Adminrechten zu starten. Wenn der User dabei im Dialog der Benutzerkontesteuerung "Nein" oder "Abbrechen" wählt, dann passiert nicht mehr als der Updater nicht gestartet wird. Wenn das Hauptprogramm (das ja zu diesem Zeitpunkt noch läuft) erkennt, dass der Updater nicht gestartet wurde, kann es eine entsprechende Meldung anzeigen, dass das Update nur durchgeführt werden kann, wenn der Zugriff erlaubt wird. Der Benutzer kann in diesem Fall das Update erneut anstoßen (oder sollte es können).

herbivore

Hallo herbivore,

ist ist mir grundsätzlich klar,dass ich den Updater unter Adminrechte starten kann, aber die Hauptanwendung lädt ja schon die neuen dateien runter, daran scheichtert es ja. Deshalb müsste ich sogar die Hauptanwendung mit Adminrechten starten.

Wenn alles über den Updater passieren würde, dann hättest du natürlich recht.

Meine Idee ist jetzt, dass ich pürfe ob der aktuelle User in das Programmverzeichnis schreiben kann. WEnn nicht, werde ich einen Dialog anzeigen, der zeigt wie man die Software komplett im Adminmodus starten kann für das Update.

Das ist leider keine schöne Lösung.

Grüße

Das sollte nicht die Hauptanwendung tun, sondern der Updater.
Der lädt und installiert Dateien/Updates.

Im Prinzip ist das ganz einfach Separation of concerns
Ich sehe keinen Grund, wieso die Hauptanwendung irgendeine Datei-Aktivität durchführen sollte. Wie Du siehst macht das auch in der Durchführung Probleme.

Hallo neo,

ich sehe es wie Abt. Das Herunterladen gehört in den Updater.

Davon abgesehen, sehe ich keinen Grund, warum die Dateien direkt ins Programmverzeichnis heruntergeladen werden sollen. Wenn du sie in ein Verzeichnis lädst, in das der User Schreibrechte hat (z.B. in temp), dann kann das Herunterladen ohne Adminrechte erfolgen und man braucht diese erst, wenn das Update tatsächlich durchgeführt werden soll.

BTW: Admins dürfen nicht automatisch alles. Es ist also keineswegs garantiert, dass wenn ein Benutzer auf ein bestimmtes Verzeichnis keinen Zugriff hat, dass dann der Zugriff als Admin erlaubt ist. Für Programmverzeichnisse wird in der Regel klappen, aber ich wollte es grundsätzlich mal (wieder) erwähnen.

herbivore

Hallo zusammen,

grundsätzlich habt ihr Recht. Die Anwendung ist aber nicht auf meinem Mist gewachsen und hat leider Fehler im Design. Wir verscuhen das zu ändern.

Grundsätzlich habe ich erst einmal herausgefunden wie ich einen Prozess als Administrator starte:

process.StartInfo.Verb = "runas";

Soweit so gut, der neue Prozess startet auch mit Adminrechten.
Wenn ich in diesem Prozess erneut eine Prozess/Exe startet wird dieser auch automatisch mit Adminrechten gestartet. Gewollt ist aber, dass dieser dann nicht mehr im Adminmodus läuft.
Ich habe dazu folgendes probiert:

process.StartInfo.Verb = "";

Ging aber leider nicht 😃

Die Berechtigung scheint weitergetragen zu werden.

Grüße

Hast Du schon mal überlegt, den Updater als Windows-Dienst zu implementieren? Macht ja etwa Mozilla für den Firefox so... der läuft als Local System und fragt somit nicht bei jedem Start nach Admin-Rechten, sondern nur einmalig bei der Installation des Update-Dienstes.

das ist grundsätzlich auch ne gute Idee.

weiß jemand wie ich den Adminkontext unterbrechen kann? Wie gsagt mit process.StartInfo.Verb = ""; kann ich es leider nicht zurücksetzten 😦

Grüße

Ich kann davon nur abraten.
Machs einfach sauber über einen Updater wie 99,9% der Software. Den Service bzw dessen Sinn von Mozilla versteh ich bis heute nicht.

Vor allem ein Service, der dauernd Adminrechte hat... da sollten die Alarmglocken laut läuten.

Machs einfach sauber über einen Updater wie 99,9% der Software.

99,9% der Software benötigt beim Installieren des Updates das Abnicken von UAC - und genau das möchte der OP ja nicht.

Den Service bzw dessen Sinn von Mozilla versteh ich bis heute nicht.

Und weil Du ihn nicht verstehst, rätst Du davon ab? 😉
Sinn des Ganzen ist, dass viele Anwender von der UAC "abgeschreckt" werden und die Abfrage verneinen. Mit der Folge, dass das Update fehlschlägt und die Anwender somit weiter mit veralteteter, potentiell unsicherer Software unterwegs sind. Adobe geht übrigens beim Flashplayer den gleichen weg.

Vor allem ein Service, der dauernd Adminrechte hat... da sollten die Alarmglocken laut läuten.

Interessante Logik... auf einem Windows-System existieren bereits von Haus aus über 100 Dienste, die als Local System ausgeführt werden. Du müsstest Dich also so fühlen, als stündest Du direkt im Glockenturm von Notre Dame 😉
Ich stimme Dir aber grundsätzlich schon zu: Dienste sollten nur mit den Rechten laufen, die sie auch wirklich benötigen - was hier aber der Fall wäre.

By the way ist es keineswegs so, dass der Updater-Dienst permanent läuft... der wird nur gestartet, wenn auch tatsächlich ein Update installiert werden muss. Somit ist der Angriffsvektor deutlich kleiner, als würde der Dienst permanent laufen.

Versteh mich nicht falsch: ich will keineswegs sagen, dass ein Update-Dienst die Non-Plus-Ultra-Lösung ist. Aber es ist ein praktikabler und durchaus verbreiteter Weg, der die Anforderung des OPs löst. Schöner wäre natürlich, wenn die Anwendung sich selbst updaten könnte, ohne administrative Rechte zu benötigen. Spätestens wenn Registry-Keys außerhalb von HKCU gespeichert werden oder irgendwas ins Windows-Verzeichnis muss, wird's eng.

Aber nur zu behaupten, das sei unsauber ist schon etwas dünn...

Das, was Mozilla oder Chrome da machen hat nur einen Sinn/Grund: Silent Updates.
Ansonsten ist das gesamte Konstrukt ein in-transparenter Haufen.

Hier geht es um einen völlig anderen Usercase.
Der Anwender bekommt offensichtlich gesagt, dass ein Update bereit steht und er nun updaten könne.
Die (vernünftige) Variante wäre nun, dass der Anwender eben auf aktualisieren drückt, die Anwendung sich beendet, der Update die Dateien lädt und diese dann installiert - anschließend bei Bedarf eine Migration der Daten durchführt und dann die Anwendung wieder gestartet wird.

Software, die mit dieser Aktion den UAC umgeht halte ich definitiv für unsauber, selbst wenn sie Chrome oder FF heissen und ja ich rate von diesem Vorgehen, vorallem wegen der Intransparenz und der völlig unnötigen potenziellen Lücke ab.
Und ja, im Falle von FF läuft der Service permanent.

PS: geschlossene SystemServices mit einem Updater zu vergleichen ist schon eine ziemliche Apfel-Birnen-Aktion, nicht?
Wenn Du Dir die Privilegien von LocalSystem anschaust ist das definitiv mit Kanonen auf Spatzen geschossen und zu sagen, dass das auf Dauer kein potenzielles Einfallstor wäre, ist schon etwas arrogant/ignorant in Sachen Sicherheit 😉

Das, was Mozilla oder Chrome da machen hat nur einen Sinn/Grund: Silent Updates.

Korrekt.

Und ja, im Falle von FF läuft der Service permanent.

Da ich mir nun selbst nicht mehr sicher war, ob ich mich irre, oder doch Du gesundes Halbwissen verbreitest, habe ich Firefox eben nochmal in einer VM installiert. Deine Aussage ist falsch: der Mozilla Maintenance Service läuft NICHT permanent, sondern steht auf Manual und wird nur bei Verfügbarkeit während der Installation des Updates gestartet.

Wenn Du Dir die Privilegien von LocalSystem anschaust ist das definitiv mit Kanonen auf Spatzen geschossen und zu sagen, dass das auf Dauer kein potenzielles Einfallstor wäre, ist schon etwas arrogant/ignorant in Sachen Sicherheit 😉

Ich würde Dir zustimmen, wenn der Dienst permanent laufen würde... darüberhinaus finde ich Deine Aussage "geschlossene System-Dienste" seien per se "sicher"(er als selbstgeschriebene) deutlich bedenklicher in Bezug auf Sicherheits-Ignoranz 😉

Aber bevor wir hier weiter in Richtung OffTopic abtauchen, sollten wir die Diskussion an der Stelle beenden. Der OP wird sich selbst ein Bild davon machen können, ob er das Risiko "hochprivilegierter Dienst" zugunsten eines bequemeren Updateprozesses tragen möchte, oder nicht.