Prozess mit eingeschränkten/Administratorrechten starten

[False Pretense]

Hallo!

Ich habe ein Kontrollprogramm für ein Internet-Café geschrieben.
Wie in jedem Internet-Café arbeitet man nicht mit Administratorrechten, sondern mit eingeschränkten Rechten.
Das habe ich ausgenutzt und lasse mein Programm mit CreateProcessAsLogon unter Adminrechten laufen, damit man es nicht mit dem Windowstaskmanager oder anderen Taskmanagern beenden kann.

Hier mein Problem:
In dem Programm habe ich eine Funktion eingebaut, mit der sich andere Programmdateien starten lassen.
Jedoch erben diese die Administratorrechte meines Kontrollprogrammes, wenn ich sie mit ShellExecute aufrufe.
Die Funktion CreateProcessAsLogon kann ich nicht verwenden, um Programme mit eingeschränkten Rechten zu starten, da dieses Konto nicht kennwortgeschützt ist.
Ohne Kennwort lässt sich diese Funktion nicht verwenden.

Weiß da einer eine Lösung?

Die Funktion CreateProcessAsLogon sieht folgendermaßen aus:
(Benötigt wird noch die Unit MpuWinNT von Luckie.)

Delphi-Quellcode:

function CreateProcessAsLogon(const User, PW, Application, CmdLine: WideString):
  Boolean;
var
  si: TStartupInfoW;
  pif: TProcessInformation;
begin
  ZeroMemory(@si, sizeof(TStartupInfo));
  si.cb := SizeOf(TStartupInfoW);
  si.dwFlags := STARTF_USESHOWWINDOW;
  si.wShowWindow := 1;
  Result := CreateProcessWithLogonW(PWideChar(User), nil, PWideChar(PW),
    LOGON_WITH_PROFILE, nil, PWideChar(Application + ' ' + CmdLine),
    CREATE_DEFAULT_ERROR_MODE, nil, nil, si, pif);
end;

Mit freundlichen Grüßen,
False Pretense

[Dezipaitor]

Statt diese Funktion zu verwenden kannst du einfach das Benutzertoken der aktuellen Session auslesen.
Es gibt da mehrere Wege, die ich mal bereits beschrieben habe. Siehe dazu auch
http://blog.delphi-jedi.net/2008/04/...m-a-service-2/

[False Pretense]

Danke, ich werde mir diese Funktionen genauer anschauen.
Aber gibt es keine Möglichkeit das ohne diese JEDI Windows API Library zu realisieren?
MfG

[Luckie]

Zitat von False Pretense:

Danke, ich werde mir diese Funktionen genauer anschauen.
Aber gibt es keine Möglichkeit das ohne diese JEDI Windows API Library zu realisieren?
MfG

Natürlich. Oder denkst du die JEDI Winapi Library zaubert das aus der holen Hand? Die Library kapselt doch auch nur die Windows Funktionen.

[Dezipaitor]

Die JEDI Windows Security Code Library kapselt viel mehr als nur die Security Windows API. Sie sorgt dafür, dass fehlerhafte Aufrufe auch tatsächlich gesehen werden - sprich durch Exceptions - und natürlich auch danach gehandelt wird. Der Programmierer bekommt eine Exception, die er nur durch böswillige Absicht (try except end ignorieren kann. Weitherhin steckt viel Wissen dahinter, wie die API Funktionen richtig bedient werden und deren Rückgabewerte richtig ausgewertet werden können. Dazu gehört besonders die Erzeugung von korrekten Speicherblöcken auf denen die API arbeitet, sowie die korrekte Umwandlung von C Typen der API in normale und einfache Delphitypen (z.B C Strukturen und Pointerlisten in Objektstrukturen und natürlich alle Strings). Weiterhin ist die Highlevel Security API schwer fehlerbehaftet und reagiert sehr explosiv auf falsche Eingaben (ACE Funktionen, LSALogonUser). Solche falschen Eingaben werden, wenn möglich, schon vorher abgefangen und durch (hoffentlich) verständlich beschriebene Exceptions angeprangert.

Es spielt sich viel im Hintergrund ab und die Bibliothek ist daher dafür gedacht, dass Leute, die eine Aufgabe verfolgen, sich nicht um den "Kleinkram" kümmern müssen, sondern sich auf das Wesentliche/die eigentliche Aufgabe, konzentrieren können. Wer lernen und verstehen will, der kann gerne direkt die C Funktionen und Strukturen bedienen und so mehr Erfahrung durch das Try&Error Verfahren bekommen. Dazu gibt es auch den Quelltext der JWSCL, um zu sehen, wie es richtig gehen kann. "Kann" deshalb, denn es gibt sicherlich mehrere Wege zum Ziel.
Ich rate jedoch dringend davon ab, einfach Quelltexte aus JWSCL zu nehmen und so sich seine "Lösung" zusammenzukopieren! Das geht leicht nach hinten los, wenn man die Zusammenhänge nicht versteht. Zudem sind die Quelltexte sicherlich nicht 100% korrekt. D.h. man kann auch einfach einen Fehler mitkopieren, der durch die Einkapselung in die JWSCL nie aufgetreten ist.

Weiterhin ist derjenige mit der C API besser bedient, wenn es um minimalistische Programme geht oder diese auf Höchstgeschwindigkeit, u.a. für leistungsschwache Rechner, geht.
Die JWSCL funktioniert zu einem großen Teil auch für Windows NT 4, jedoch wurde sie nie dafür ausgelegt, da dieses System doch schon zu alt ist und von MS nicht mehr unterstützt wird.

"Schuster bleib bei deinen Leisten." Das DEBIAN Debakel mit dem fehlerhaften Zufallsgenerator (der keiner war) ist so ein schönes Beispiel. Die Debian Leute hatten eine "Verbesserung" im OpenSSL Paket vorgenommen, die zu diesem Fehler führten. Hätten sie mal diesen Fehler/Problem an das OpenSSL Team gerichtet, dann wäre soetwas passiert.
Was will ich damit sagen? Nutze die JWSCL, auch wenn es so aussieht, als ob es sich nicht lohnen würde ("mit Kanonen auf Spatzen schiessen"). Denn es ist viel wahrscheinlicher, dass beim "selberschreiben" ein Fehler passiert, als dass er in einer Methode der JWSCL passiert, die schon oft benutzt wurde. Klar 100%ige Sicherheit gibt es nie. Aber die JWSCL wird von mehreren Leuten benutzt, die nicht nur Ahnung haben, sondern auch Fehler melden. D.h. Code, der in der JWSCL steckt, wird oft benutzt und ist daher mit hoher Sicherheit fehlerfrei. Gibt es doch einen Fehler, so ist die Wahrscheinlichkeit hoch, dass dieser schnell und sicher erkannt wird.

In einem parallel Thread hier in der DP, habe ich mich schon über die "CreateProcessWithLogonW" ausgelassen. Ich sehe da riesen Probleme, genauso wie ein Crashtest-Ingenieur ungern mit einem Autor fährt, welches er vorher einem Crashtest unterzogen hat, der nicht gut lief.


PS.
Sorry@Autor: Es geht hier nicht direkt um deinen Beitrag mit CreateProcessWithLogonW sondern um das allgemeine Thema "Wann C-API und wann JWSCL) klarzustellen, welches mir immer wieder aufgefallen ist und mir am Herzen lag.

PSS.
Die Funktion CreateProcessAsLogon hat ein paar Problemstellen:

• 
  ZeroMemory(@si, sizeof(TStartupInfo)); "si" ist vom Type "TStartupInfoW", aber die angegebene Größe für ZeroMemory ist eine andere.
• Application muss Quotes beinhalten, damit lange Dateinamen erkannt werden.
• Prozess- und Threadhandle müssen danach geschlossen werden.
• Ich bin mir nicht sicher was mit PWideChar(Application + ' ' + CmdLine) passiert, da die Funktion diesen String ändert. Scheint mir reiner Zufall zu sein (Delphi macht das schon), dass es funktioniert.
• si.wShowWindow := 1; Wer soll das mal später verstehen?
• Man weiß nicht, wie welche Delphiversion "PWideChar(PW)" übersetzt. Im dümmsten Fall, bleibt ein Password unverschlüsselt im Speicher.

Weiterhin gibt es Probleme:

• Diese Funktion funktioniert nicht in einem Service!
• Sie funktioniert auch dann nicht, wenn der "Sekundäre Anmeldedienst deaktiviert ist".
• Stürzt der Dienst ab, und der Benutzer meldet sich ab und einer Neuer meldet sich an (z.B. Gast), dann bleiben alle Anwendungen, die mit dieser Fkt gestartet wurde (vllt sogar als Administrator), für den neuen Benutzer zugänglich. Siehe auch "Warum Surun CreateProcessWithLogonW nicht mehr benutzt."
• Sie umgeht Einschränkungen auferlegt durch einen Job für den aktuellen Prozess. (Out of the "Sandbox")
• Anwendungen, die ihre Daten bei der Nachricht WM_QUERYENDSESSION oder WM_ENDSESSION, ihre Daten sichern oder sonstige wichtige Tätigkeiten machen wollen (z.B. Shutdown verhindern, wegen CD-Brennen), funktionieren nicht richtig, da diese Nachrichten nicht von diesen Apps empfangen werden.
• Es gibt einige Probleme auf einigen Systemen mit dem lpDesktop in StartupInfo.

[False Pretense]

Hallo!

@Dezipaitor:
Danke für deine Hilfe und die Mühe für die lange Erklärung.
Dann werde ich mir die JEDI Windows Security Code Library mal genauer anschauen und mich darüber informieren.

Vielen Dank,
MfG, False Pretense