Daten in HKEY_LOCAL_MACHINE ohne Adminrechte schreiben

[skyobserver]

Hallo,

auf den Client-PCs in unserem Windows-Netzwerk laufen Delphi-Programme
welche verschiedene ODBC-Einträge benötigen. Diese tragen wir bei der
Installation der PCs im Bereich "System-DSN" ein, damit sie allen
Benutzern zur Verfügung stehen.

Wenn mal ein Eintrag fehlt, oder ein neuer dazu kommt, soll das Programm
diesen selbstständig per TRegistry oder Import einer *.Reg-Datei eintragen.

Die Benutzer sind allerdings nur mit Benutzer- oder Hauptbenutzerrechten
angemeldet und dürfen daher nicht auf HKEY_LOCAL_MACHNINE zugreifen.

Gibt es eine Möglichkeit (z.B.mit hinterlegtem Admin-Benutzer+Passwort) diese
ODBC-Einträge anzulegen? Der Shell-Befehl "RunAs" hat laut Hlife nicht die
Möglichkeit ein Passwort zu hinterlegen...

[himitsu]

Ihr könntet einen kleinen Service aufsetzen, welcher dann ja im System-Konto läuft.
Dieser muß nur einmal mit entsprechenden Rechten eingerichtet werden und läuft danach ohne Zutun.
Per Pipe, MMF o.Ä. könnte man dem nun die neuen Daten übergeben und er trägt sie dann dort ein.
Aber im Service nur die entsprechenden Einträge erlauben, da sonst ein Sicherheitsrisiko bestünde.

Ebenso wäre es doch wohl auch nicht so sicher, wenn irgendwo das Adminpasswort "ungeschützt" rumliegen täte, welches dann dein Programm verwenden würde.


CreateProcessAsUser und Co. aber ich würde, wie gesagt, eher davon abraten.

[generic]

Du kannst diese Einstellungen via ActiveDirectory (AD) per GroupPolicyObjects (GPO) machen.

Bei einen >=2008er Server (DomainController) sogar besonders einfach.

[RWarnecke]

Impersonate ist Dein Stichwort. Damit kannst Du in einem Delphi-Programm ein anderes Programm oder Vorgang als Admin aufrufen und ausführen.

[Luckie]

aber dann muss er auch irgendwo die Zugangsdaten hinterlegen, was wieder ein Sicherheitsrisiko bedeutet.

[Assarbad]

Zitat:

Zitat von Luckie (Beitrag 1085936)

aber dann muss er auch irgendwo die Zugangsdaten hinterlegen, was wieder ein Sicherheitsrisiko bedeutet.

Mit LsaStorePrivateData (alte Methode) oder CryptProtectData sollte dies ein geringes Problem sein.

[jobo]

Wieso muss man das System unbedingt verbiegen?
Was spricht gegen User DSN und Registry Import von einer gemeinsamen Netzdatei beim Login?
Bekommt man ohne Sicherheitsprobleme und Extras und nur mit Bordmitteln.

Man könnte auch gleich mit Datei DSN arbeiten.

Remote per Admin gehts dann auch mit Regedit in die jeweiligen HKLM Einträge. Ich kenne es aber so nur interaktiv.

[skyobserver]

Erst mal danke für die Antworten,

-Also das Passwort würde ich natürlich nicht im Klartext im Code hinterlegen.
Ich würde es kodieren und erst zur Laufzeit dekodieren, wenn es benötigt wird...

-Per GroupPolicy wird nicht gehen, da je nach installierter Datenbank-Client-Version
der ODBC-Eintrag etwas anders aussehen muss. Das Programm bzw. der Service muss erst
die Client-Version ermitteln und dann die entsprechenden Registry-Daten importieren...

-Per Remote-Registry kommt nicht in Frage - wir produzieren 24 Stunden / 7 Tage die Woche
und ich werde ungern Nachts um 04:00 angerufen um einen ODBC-Eintrag zu machen :wink:

-Diese Einträge sind nicht Benutzerspezifisch sondern für alle Benutzer gleichermaßen
verbindlich. Prinzipiell ist also System-DSN der richtige Ort - natürlich funktioniert
Benutzer-DSN grundsätzlich auch...


Werde mir also "CreateProcessAsUser" bzw. "Impersonate" mal ansehen...


Danke!

[alzaimar]

Wenn Du sowieso schon eine automatische Registrierung der DSN vorgesehen hast, nutze das doch. So viele unterschiedliche Benutzer gibt es ja nicht und im Kontext der Sicherheitsphilosophie ist diese Lösung die Richtige.

Wenn Du das Kennwort im Code hast, egal ob verschlüsselt oder nicht, wird das ein Angreifer ohne große Probleme ausnutzen können.

[DelphiSecurity]

Ich bin für den Service. Ist sinnvoll! :wink:

[Luckie]

Zitat:

Zitat von alzaimar (Beitrag 1086193)

Wenn Du das Kennwort im Code hast, egal ob verschlüsselt oder nicht, wird das ein Angreifer ohne große Probleme ausnutzen können.

Weil du musst das Passwort ja im Code mitliefern, um das eigentliche Passwort wieder zu entschlüsseln. Das ist ungefähr so, als wenn du den Türschlüssel unter die Fußmatte legst und einen Zettel an die Tür klebst auf dem steht: "Der Schlüssel liegt unter der Fußmatte."

[skyobserver]

Zitat:

Das ist ungefähr so, als wenn du den Türschlüssel unter die Fußmatte legst und einen Zettel an die Tür klebst auf dem steht: "Der Schlüssel liegt unter der Fußmatte."

Ganz so schlimm ist es wohl nicht - das Kennwort steht ja nirgendwo unverschlüsselt rum.
Man müßte schon den Quellcode in die Finger bekommen um die Dekodierung, mit Hilfe des
Kodierten Kennworts und der Dekodier-Routine, durchzuführen.

Weiterhin würde man nicht das Passwort des Domänen-Administrators verwenden, sondern das
des lokalen Administratros des PCs. Sollte der unwarscheinliche Fall auftreten, daß ein
Hacker Zugang zu unseren Quellcodes bekommt, aus den über 1000 *.pas Dateien die richtige
findet und das Kennwort dekodiert kann er sich maximal an Client-PCs als Admin austoben.
Daten liegen bei uns nur auf Servern rum wofür Rechte in der Domäne notwendig wären...

Außerdem weiß der Hacker ja gar nicht, wo er suchen muß...da dürfte es einfacher sein eine
Sicherheitslücke im Windows zu finden und auszunutzen: z.B. Abbruch des Login-Scripts führt
zu lokalen Adminrechten...

[himitsu]

Zitat:

Zitat von skyobserver (Beitrag 1086384)

Außerdem weiß der Hacker ja gar nicht, wo er suchen muß

Disassambler
Decompiler
Fremdprozess debugen
usw.

und schon weiß man was man braucht.

[generic]

Ich finde, dass ihr hier zwanghaft versucht das Sicherheitssystem von Windows auszuhebeln - was nicht gut ist.

Passwörter hinterlegen ist keine Lösung!

Zitat:

-Per GroupPolicy wird nicht gehen, da je nach installierter Datenbank-Client-Version
der ODBC-Eintrag etwas anders aussehen muss. Das Programm bzw. der Service muss erst
die Client-Version ermitteln und dann die entsprechenden Registry-Daten importieren...

Wer installiert die Datenbank?
Dazu sind doch sicherlich Adminrechte erforderlich!
Kann der Installationsprozess nicht die richtigen Werte konfigurieren?

Kannst du den Prozess genauer erklären?

[DelphiSecurity]

Zitat:

Zitat von skyobserver (Beitrag 1085905)

Wenn mal ein Eintrag fehlt, oder ein neuer dazu kommt, soll das Programm
diesen selbstständig per TRegistry oder Import einer *.Reg-Datei eintragen.

Dann muss man sich darum kümmern das keiner fehlt. Beim Installieren.
Und wenn etwas fehlt, führt man eine Reperatur-Anwendung aus. (Edit: Der Admin :wink:)
:dp:

[skyobserver]

@himitsu:

Bei der Installation der PCs werden verschiedene DB-Clients aufgespielt
und hinterher per Hand die ODBC-Einträge erstellt. Da einige Versionen
der Clients im Umlauf sind kann ich nicht einfach eine *.reg hinterlegen,
da die Inhalte manchmal unterschiedlich sind.
Die Einträge werden natürlich unter System-DSN angelegt damit Sie hinterher
allen Benutzern zur Verfügung stehen...


@generic:

Zitat:

Dann muss man sich darum kümmern das keiner fehlt

Zu dumm von mir :stupid: einfach keine Fehler machen und schon sind alle Probleme gegessen! :-D
Spass beiseite: wir haben über 140 PCs im Werk - eine Handvoll Win2K, die meisten WinXP und
mittlerweile auch 10 Window7 Maschinen. Alle paar Tage kommt einer aus dem Leasing raus und
ein neuer muß hergerichtet werden. Es kommt leider hin und wieder vor, das mal ein Eintrag
vergessen oder fehlerhaft angelegt wird. Sorry - In unserem werk arbeiten noch Menschen! :wink:
Manchmal wird die DB-Client Version durch eine neuere ersetzt oder eine weitere hinzugefügt die
bis dahin nicht im Einsatz war. Bei jeder Änderung zu allen PCs auf dem Werksgelände latschen
und alle Einträge kontrollieren ist nicht praktikabel. Solange keine Notwendigkeit besteht,
bleibt (z.B.beim Erscheinen eines neuen DB-Clients) auf den alten Rechnern auch der alte
Client drauf. Jedenfalls solange es keine Probleme gibt...

Zitat:

Und wenn etwas fehlt, führt man eine Reperatur-Anwendung aus.

Dafür würde dann z.B. Nachts um 04:00 die EDV-Bereitschaft angerufen...ich
weiß ja nicht wie es mit euch ist - ICH LIEBE MEINE NACHTRUHE!

Daher besteht der Wunsch, das ein Programm beim Start seine Umgebung prüft und einfache Dinge
wie ODBC_Einträge selber anlegt...

[jobo]

Zitat:

Daher besteht der Wunsch, das ein Programm beim Start seine Umgebung prüft und einfache Dinge
wie ODBC_Einträge selber anlegt...

Wie schon geschrieben, eine User DSN oder Datei DSN steht unter voller Hoheit des Benutzers.
Wieso willst Du Dich damit quälen, System DSN einzutragen? Doch nicht um Speicherplatz zu sparen oder?

[skyobserver]

Nein, ich will keinen Speicherplatz sparen...

Mir ist klar, daß das ganze Sicherheitstechnisch nicht optimal ist!

Wichtige Stellen in unserem Betrieb arbeiten mit unseren Delphi-Programmen.
Ein längerer Ausfall an einer dieser Stellen kann zum Abstellen der davorliegenden
Produktionsbereiche führen, was zu finanziellen Verlusten in Form von
Produktionsausfall und Strafzahlungen bei verspäteten Lieferungen führt!

Registry-Einstellungen für diese Programme haben in Bereichen, welche der Kontrolle
des Benutzer unterliegen, nichts zu suchen! Betriebsrelevante Einstellungen gehören
imho in Bereiche in denen Benutzer keine Schreibrechte haben!
Und es gibt immer Fuckler die auf Nachtschicht an der Workstation herumspielen
und meinen man könne den PC doch noch optimieren...

Nicht alle Mitarbeiter unserer EDV sind Delphi-Programmierer und gleichermaßen
"Sattelfest" mit den nötigen Einstellungen der vielen Programme.
Ein fehlender Eintrag ist noch leicht als Fehler zu erkennen aber ein verstellter
Parameter kann selbst einen erfahrenen Admin eine lange Suche bescheren...

Ich habe selbst schon erlebt, wie eine Maschine für zwei Tage abgestellt wurde
weil jemand auf einer Workstation mit englischem Bestriebssystem die Ländereinstellungen
von "Englisch" auf "Deutsch" umgestellt hat. Der Bediener hat sich nichts dabei
gedacht: Immerhin hat jeder Benutzer das recht seine Oberfläche anzupassen
und schließlich ist man ja hier in Deutschland...
Dummerweise funktionierte nachher in der Betriebssoftware der Maschine die Konvertierung
von Zahlen und Datumsformaten nicht mehr, weil sich das Zeichen für Dezimal- und
Tausender-Trennung geändert hatten. Der Programmierer (von einer Fremdfirma) hatte
versäumt die Zahl- und Datum-Behandlung Threadsicher zu programmieren damit unabhängig
von den Benutzereinstellungen im Bereich Ländereinstellungen immer das gleiche Ergebnis
herauskommt (Stichwort StrToDate/FormatSettings). Wir konnten den Grund des Fehlers in
der fremden Software nicht ausmachen, und selbst der Programmierer den wir erst am nächsten
Tag erreichen konnten brauchte eine ganze Weile.

Microsoft's Konzept von Sicherheit und Individuellen Einstellungen steht hier in einem
gewissen Konflikt mit der Praxis und der erforderlichen Betriebssicherheit. Hier muß
ich der Betriebssicherheit klar den Vorrang geben.

:wink: Mal ehrlich: Wer läßt sich Nachts rausklingeln, sucht nach einem Fehler (was halb
im Schlaf schon mal deutlich länger dauert) und meldet sich dann auf einem System als
Administrator an um Einstellungen vorzunehmen, wenn es auch in weniger als einer Sekunde
(mit vertretbarem Risiko) automatisch geht?

[himitsu]

Threadsicher hat absolut nichts mit unabhängig von den Benutzereinstellungen zu tun.

Wenn Zahlen umkodiert werden sollen, welche festen Definitionen unterliegen, dann müssen auch feste Umkodierungsparameter verwendet werden und nicht irgendwelche systemanhängigen Benutzereinstellungen.

PS: StrToTime und Co. bieten auch ein FormatSettings, wo man die nötigen Werte angeben kann.


Du willst also erreichen, daß Einstellungen im Benutzerkontext von der Anwendung geändert werden können,
aber gleichzeitig dem Benutzer dieses verbieten ... geht nicht, da es ja in seinem Kontext erlaubt ist.
> Die Anwendung mit Admin-Rechten zu starten wird wohl nicht möglich sein, also entweder die Einstellungen liegen im Zugriffsbereich des Benutzers und der der Benutzer kann es ändern oder es liegt nicht in seinem Zuständigkeitsbereich und Er + das Programm kann es nicht ändern.

[p80286]

Hab ich was übersehen?
Was spricht denn dagegen, dem Benutzer die Schreibrechte auf
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC
zu geben?

Da kann man sich die ganze Service / Passwort Hampelei ersparen.

Gruß
K-H

[skyobserver]

@himitsu:

Zitat:

PS: StrToTime und Co. bieten auch ein FormatSettings, wo man die nötigen Werte angeben kann.

Habe ich ja auch geschrieben (genau lesen)! In meinen Programmen mache ich das auch so (jedenfalls seit ich
weiß, daß das problematisch ist - jeder Fehler ist irgendwann der erste)...

Zitat:

Threadsicher hat absolut nichts mit unabhängig von den Benutzereinstellungen zu tun.

Der Begriff "Threadsicher" scheint mir auch unpassend, ich habe ihn direkt der Delphi-Hilfe zum Befehl
StrToDateTime entnommen:

Zitat:

Die erste Form von StrToDateTime ist nicht Thread-sicher, da die landesspezifischen Informationen der globalen Variablen verwendet werden.
Thread-sicheren zweiten Form werden die landesspezifischen Informationen im Parameter FormatSettings übergeben. Bevor Sie diese Form von StrToDateTime aufrufen, müssen Sie die Informationen in den Parameter FormatSettings schreiben. Die landesspezifischen Standardinformationen können mit GetLocaleFormatSettings zugewiesen werden.

@p80286:

Zitat:

Was spricht denn dagegen, dem Benutzer die Schreibrechte auf
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC
zu geben?

Dann hat der Benutzer wieder Eingriffsmöglichkeiten in meine Betriebsrelevanten Einstellungen...

[jobo]

Mir ist eingefallen, dass die Sache mit dem Taskscheduler machbar wäre. Ganz legal und -so hoffe ich- auch mit einer brauchbaren Passwortverschlüsselung.

Man braucht ein lokales oder Domain Konto mit Adminrechten und lässt darunter die Registry Einträge in einem "geplanten Task" ergänzen. Die Dateien können von einem Netzwerkverzeichnis kommen, das ebenfalls nur durch den Admin Account gelesen werden kann (oder zumindest nur durch den geschrieben werden kann)

Ich habs unter XP mit einem lokalen "Admininistrator" und einem lokalen "Benutzer" ausprobiert.
Registry Import mit Create und Silentschalter
Das funktioniert.
Wenn Ihr mit Vista oder höher arbeitet gibts vlt Theater mit UAC oder so.

Das Ganze kann je nach Definition des Tasks sogar vom minder Berechtigten User manuell ausgeführt werden oder per Cmd Script via SCHTASKS.EXE und Desktopverknüpfung als "ODBC Refresh" angeboten werden.

[p80286]

Zitat:

Zitat von jobo (Beitrag 1086847)

Die Dateien können von einem Netzwerkverzeichnis kommen, das ebenfalls nur durch den Admin Account gelesen werden kann (oder zumindest nur durch den geschrieben werden kann)

Mir hat bisher noch keiner der Benutzer eine ODBC-Einstellung "zerschossen". Und wenn dann doch einmal ein "Fachmann" am Werke war, dann wie JoBo vorgeschlagen hat, eine .reg Datei auf einem schreibgeschützten Laufwerk und gut war's.

Gruß
K-H