Daten in HKEY_LOCAL_MACHINE ohne Adminrechte schreiben

[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