mayho33
Goto Top

C Sharp Ordner als anderer User öffnen

Hallo @ All!

Ich stehe etwas am Schlauch und hoffe auf eure Unterstützung, weil ich irgendwie nix Brauchbares zum Thema finde:
Meine kleine Applkation soll nichts anderes machen als einen Ordner als anderer User zu öffnen und den Inhalt weiter verarbeiten.

Hat irgend jemand eine Idee wie ich das machen könnte?

Danke für die Hilfe!

Mayho

Content-Key: 246605

Url: https://administrator.de/contentid/246605

Ausgedruckt am: 28.03.2024 um 19:03 Uhr

Mitglied: falscher-sperrstatus
falscher-sperrstatus 15.08.2014 um 20:09:42 Uhr
Goto Top
Hallo Mayho,

ich vermute, diese Anfrage hast du schon gestellt:
https://www.google.de/webhp?sourceid=chrome-instant&ion=1&espv=2 ...

Grüße,

Christian
Mitglied: mayho33
mayho33 15.08.2014 um 22:43:56 Uhr
Goto Top
Hi Christian!

Danke! Ja hatte ich auch schon. der Impressionator scheint aber nicht mit System.Security.SecureString umgehen zu können und habe jetzt echt keine Ahnung wie ich ihm das beibringen könnte. das Passwort als normaler String kommt nicht in Frage. C#-exen lassen sich da viel zu leicht auslesen.

Ich habe mehr an etwas Start.Process-mäßiges gedacht mit SecureString.

symbolisches Beispiel:
System.Diagnostics.Process p = new System.Diagnostics.Process();

// Domain and User Name:
p.StartInfo.Domain = ""; // "optional_domain";  
p.StartInfo.UserName = "SuperHeftigGeneral";  

// Build the SecureString password...
System.String rawPassword = "MeinPw";  
System.Security.SecureString encPassword = new System.Security.SecureString();
foreach (System.Char c in rawPassword)
{
	encPassword.AppendChar(c);
}
p.StartInfo.Password = encPassword;

..Tja und dann sollte mit diesen Cedentials der Ordner geöffnet werden. Nur wie?? Kein Tau!! Hast du da eventuell ne Idee??

Grüße!

Mayho
Mitglied: falscher-sperrstatus
falscher-sperrstatus 15.08.2014 um 22:58:34 Uhr
Goto Top
Wenn wir das Pferd hier mal nicht von hinten herum aufzäumen..

was ist denn der Sinn von dem Spektakulum? ;)
Mitglied: mayho33
mayho33 15.08.2014 aktualisiert um 23:27:18 Uhr
Goto Top
...Pferd hier mal nicht von hinten herum aufzäumen... Tja vielleicht! Gehts denn besser? Was der Sinn ist? Naja, das Ding soll als Standarduser ausgeführt, über ein Dienstkonto mit eigenen Credentials die nicht jeder wissen braucht einen Ordner (der übrigends eigene Permissions hat) öffnen und die Infos lesen die sich darin verbergen (die auch nicht jeder wissen braucht) und diese dann weiter verarbeiten.

Ich würde mir ja eigentlich ein paar Hinweise auf meine möglicherweise dumme Frage erhoffen wie ich das bewerkstellingen könnte und weniger die Frage was ich damit bezwecken will face-wink Liege ich da falsch?

Grüße
Mitglied: colinardo
colinardo 16.08.2014 aktualisiert um 09:13:10 Uhr
Goto Top
Hi mayho,
Stichwort: Impersonation
Hier an einem Beispiel mit Zugriff auf einen Ordner erläutert:
http://dotnet-assembly.blogspot.de/2012/11/c-accessing-remote-file-by-u ...

das Passwort als normaler String kommt nicht in Frage. C#-exen lassen sich da viel zu leicht auslesen
Da wiedersprichst du dir aber gerade, wenn du in deinem Beispielcode dein Passwort in einer Variablen hinterlegst, bringt dir SecureString auch nicht mehr Sicherheit, denn du hat es ja bereits im Code hinterlegt! Abhilfe schafft dagegen nur ein Code-Obfuscator, zumindest hilft das gegen Gelegenheits-Cracker ohne Cryptokenntnisse face-wink

Grüße Uwe
Mitglied: mayho33
mayho33 16.08.2014 aktualisiert um 12:08:49 Uhr
Goto Top
Hi Uwe!

Soll ja auch nur ein symbolisches Beispiel sein. Der Impersionator ist super! Den hat mir ja auch certifiedit.net schon gezeigt und zurzeit verwende ich das nun auch.

Abhilfe schafft dagegen nur ein Code-Obfuscator, zumindest hilft das gegen Gelegenheits-Cracker ohne Cryptokenntnisse

scheint so. Wie könnte ich es denn etwas sicherer machen? Frage mich wozu es dann SerureString gibt wenn man ihn sogar aus der kompilierten exe ganz einfach auslesen kann.

Grüße
Mayho
Mitglied: falscher-sperrstatus
falscher-sperrstatus 16.08.2014 um 12:11:49 Uhr
Goto Top
Moin Mayho,

es geht u.a darum zu überprüfen ob die Strategie ggf nicht die richtige ist. Was spricht dagegen diesen Ordner entsprechend für den Std User zugreifbar zu machen (und nur die für ihn nötige Datei) dort abzulegen. Zugreifen muss er ja so oder so?

Daher ja, du liegst damit schon semi-Falsch, denn man kann ein Problem schlecht abschätzen, wenn man die Fransen dessen nicht kennt (in dem Fall den "Körper"). Macht unsere Politik zwar in Ihren Problemlösungsstrategien (falls man das so nennen kann) oft genug auch so, aber was dabei heraus kommt wissen wir ja ;)

Grüße + Schönes We.
Mitglied: colinardo
colinardo 16.08.2014 aktualisiert um 13:02:17 Uhr
Goto Top
Zitat von @mayho33:
scheint so. Wie könnte ich es denn etwas sicherer machen?
Absolute Sicherheit hast du bei sowas nie. Keine Passwörter im Code hinterlegen, lautet die oberste Regel eines Programmierers !! Das wäre dann höchstens security by obscurity, denn was man verschlüsselt im Code ablegt, kann ein Angreifer durch Analyse des Codeabschnitts der Dechiffrierung selber wieder rückgängig machen. Du kannst nur versuchen es dem Angreifer so schwierig wie möglich zu machen, und da ist Obfuscating das Mittel der Wahl wenn unbedingt Passwörter im Code hinterlegt werden müssen. Was mir dazu noch einfallen würde, wäre eine gegenseitige Authentifizierung via PKI das ist aber vermutlich für deine Aufgabe Overkill. Du solltest deine Zugriffs-Strategie aber besser überdenken.
Frage mich wozu es dann SerureString gibt wenn man ihn sogar aus der kompilierten exe ganz einfach auslesen kann.
SecureString ist nur für die Verschlüsselung von Stringwerten während der Ausführung der Anwendung im Hauptspeicher, so dass ein Angreifer im Speicher keine Klartextpasswörter abgreifen kann.
http://msdn.microsoft.com/de-de/library/system.security.securestring%28 ...

Grüße Uwe
Mitglied: mayho33
mayho33 16.08.2014 um 13:36:51 Uhr
Goto Top
Hi Christian!

Was spricht dagegen diesen Ordner entsprechend für den Std User zugreifbar zu machen (und nur die für ihn nötige Datei) dort abzulegen.

Es geht um folgendes: Eine Gruppe von Außendienstmitarbeitern (ca 90 Leute weltweit) ist oft monatelang höchstens via VPN mit mäßiger Geschwindigkeit mit dem Firmennetzwerk verbunden. Trotzdem brauchen sie oft neue Software oder bestehende wird aktualisiert. Im Netzwerk passert das via SCCM. Es ist unmöglich nur wegen einem Update zu einem Standort der Firma zu kommen. Aus firmenphilosophischen Gründen haben die Leute keine Adminrechte.
Jetzt kommt mein Tool ins Spiel. Es soll als Standarduser ausgeführt Programme die sich in diesem Ordner befinden als Admin installieren. Da die Software die da installiert wird teuer ist, will man nicht, dass jeder darauf Zugriff bekommt.


Daher ja, du liegst damit schon semi-Falsch, denn man kann ein Problem schlecht abschätzen, wenn man die Fransen dessen nicht kennt
(in dem Fall den "Körper"). Macht unsere Politik zwar in Ihren Problemlösungsstrategien (falls man das so nennen kann) oft genug auch so, aber > was dabei heraus kommt wissen wir ja ;)


Mag sein. Manchmal liegen aber ganz klare Anforderungen auf dem Tisch und diese Herausforderung kann man annehmen oder nicht. Ich habe mir das Konzept nicht ausgedacht. Ich setze es nur um.

ebenfalls ein schöne WE

mayho
Mitglied: mayho33
mayho33 16.08.2014 um 13:46:42 Uhr
Goto Top
Hi Uwe!

Absolute Sicherheit hast du bei sowas nie. Keine Passwörter im Code hinterlegen, lautet die oberste Regel eines Programmierers !!

Aber wenn's ohne Authentifizierung durch den User erfolgen soll muss ich irgendwo die Credentials hinterlegen

Was mir dazu noch einfallen würde, wäre eine gegenseitige Authentifizierung via PKI das ist aber vermutlich für deine Aufgabe Overkill.

Da hast du 1000% meine Zustimmung face-wink

Du solltest deine Zugriffs-Strategie aber besser überdenken.

Habe schon mehrere Möglichkeiten angedacht. Die Krux ist aber, dass die Sourzen Offline verfügbar sein müssen. Da komme ich um irgendeine Authentifierung nicht herum. AVECTO war ebenfalls angedacht (User X darf Sofware A installieren User Y aber nicht, dafür darf User B den Inhalt des Ordners ändern,User C aber nicht, usw.).

SecureString ist nur für die Verschlüsselung von Stringwerten während der Ausführung der Anwendung im Hauptspeicher, so dass ein Angreifer im > Speicher keine Klartextpasswörter abgreifen kann.

Aha!

Dann wird es wohl Impersionation in Verbindung mit Obfuscation. Mal schauen...

Danke Leute!

Mayho
Mitglied: falscher-sperrstatus
falscher-sperrstatus 16.08.2014 um 13:49:13 Uhr
Goto Top
Jetzt wird es klarer. Was spricht gegen einen Dienst, der mit höheren Rechten (ggf) arbeitet und den die User gar nicht beeinflussen können?

Unser blöder Adobe und Flash und Chrome Updater brauchen, wenn man sie manuell startet auch höhere Rechte (Admin Zugang), wenn man es aber einmal so einrichtet, dass sie diese bekommen haben arbeiten sie transparent im Hintergrund. Das kannst du ggf. mit der VPN koppeln.

Wäre das kein Ansatz, der bedeutend effektiver ist?
Mitglied: mayho33
mayho33 16.08.2014 um 14:08:17 Uhr
Goto Top
Ein Dienst? Hmm! Damit habe ich in etwa so viel Erfahrung wie meine Oma mit Maschinentechnik. Mein eigentlicher Aufgabenbereich ist Automation SCCM-seitig. C# habe ich kürzlich für mich entdeckt um Powershell-CMDLETS zu basteln. in Oberflächenprogrammierung stehe ich eher erst am Anfang. Aber der Ansatz ist gut.
Wie müsste ich diesen Dienst dann ansprechen vom meinem Tool aus damit ich den Inhalt des Ordners auslesen kann und die Software installieren?
Wie muss der Dienst aussehen?

Wieder mal 0 TAU!

Danke!

Mayho
Mitglied: falscher-sperrstatus
falscher-sperrstatus 16.08.2014 um 14:18:24 Uhr
Goto Top
Das kommt auf das Tool an. Dazu würde ich aber die erfahreren Programmierer (gerade in C#) bemühen. Ich bin da eher im Design/Lösungsweg finden als dem eigentlichen Programmieren unterwegs.
Mitglied: colinardo
Lösung colinardo 16.08.2014, aktualisiert am 25.08.2014 um 09:09:19 Uhr
Goto Top
Zitat von @mayho33:
Wie müsste ich diesen Dienst dann ansprechen vom meinem Tool aus damit ich den Inhalt des Ordners auslesen kann und die Software installieren?
Wie muss der Dienst aussehen?
Dafür eigenet sich die WCF (Windows Communication Foundation) hervorragend.
In diesem sehr anschaulichen Tutorial werden die Grundlagen dafür in 6 Steps erläutert:
http://msdn.microsoft.com/en-us/library/ms734712.aspx
Du implementierst deine Zugriffs-Logik in den Dienst (Service-Host) und stellst über darin deklarierte Funktionen der Clientanwendung die gewünschte Funktionalität (wie z.B. das Auslesen eines Files) zur Verfügung.
Den Dienst konfigurierst du dann mit den benötigten Credentials.

Grüße Uwe
Mitglied: mayho33
mayho33 19.08.2014 um 14:36:02 Uhr
Goto Top
Hi Uwe!

Danke für den Link. Leider (oder Gott sei dank) fällt diese Option flach. Die Anwendung muss portable sein. Einen Dienst müsste ich wieder erst installieren. Aber dafür brauche ich Adminrechte. Da diese Clients nicht im Netzwerk sind wäre das eh unmöglich.

Ich werde das Problem so lösen: Eine kleine Exe enthält als Ressource die eigentliche exe und elevated diese direkt mit den entsprechenden Credentials. So schlage ich mehrere Fliegen mit einer Klappe.

Leider löse ich damit aber das Problem des PW im Code nicht. Obfuscating war bzgl Verschleierung ne Niete. Da braucht man nur 5 Minuten googeln und gute Augen und kann das PW auslesen:

Zitat: colinardo 16.08.2014 um 12:15 Uhr
Du kannst nur versuchen es dem Angreifer so schwierig wie möglich zu machen, und da ist Obfuscating das Mittel der Wahl wenn unbedingt Passwörter im Code > hinterlegt werden müssen. Was mir dazu noch einfallen würde, wäre eine gegenseitige Authentifizierung via PKI das ist aber vermutlich für deine
Aufgabe Overkill. Du solltest deine Zugriffs-Strategie aber besser überdenken.

Ja das wird es wohl nicht ganz werden, aber wie würde es mit einer Datei als Ressource aussehen welche die Credentials enthält? zur Laufzeit lese ich die Datei aus und starte dann die Hauptapp mit den erhöhten Rechten. Würde das gehen oder muss die Datei aus den Ressourcen vorher entpackt werden um darauf zugreifen zu können?

Grüße

Mayho
Mitglied: falscher-sperrstatus
Lösung falscher-sperrstatus 19.08.2014, aktualisiert am 25.08.2014 um 09:09:16 Uhr
Goto Top
Einen tot wirst du aber - vermutlich - sterben müssen. Woher sollen die Credentials denn kommen, wenn es keine Verbindung zwischen Client und Server gibt?

Hier liegt der Fehler im Design, du erwartest eine Eierlegende Wollmilchsau in Bezug auf Komfort und Sicherheit.
Mitglied: mayho33
mayho33 19.08.2014, aktualisiert am 25.08.2014 um 09:08:59 Uhr
Goto Top
Hi!

Ne das ist ein LocalAdmin Bei dien Clients gibt es keine Client-Server-Connection. bzgl. PW-Sicherheit habe ich auch schon eine Lösung...eventuell:

eine AES verschlüsselte Datei als Resource die ich zur Laufzeit auslese. Den Schlüssel muss ich natürlich trotzdem hinterlegen, aber ich denke fürs Entschlüsseln braucht man schon KnowHow. Somit fallen 99,999% der User die das Tool bekommen sollen aus. das 1 Promille an Unsicherheit ist verkraftbar.

So zumindest die Theorie...Hi!

Ne das ist ein LocalAdmin Bei dien Clients gibt es keine Client-Server-Connection. bzgl. PW-Sicherheit habe ich auch schon eine Lösung...eventuell:

eine AES verschlüsselte Datei als Resource die ich zur Laufzeit auslese. Den Schlüssel muss ich natürlich trotzdem hinterlegen, aber ich denke fürs Entschlüsseln braucht man schon KnowHow. Somit fallen 99,999% der User die das Tool bekommen sollen aus. das 1 Promille an Unsicherheit ist verkraftbar.

So zumindest die Theorie...

EDIT:

Hi!

Sorry, dass ich mich so lange nicht gemeldet habe.Mein Problem konnte ich erfolgreich lösen wie folgt:

Die Verschlüsselung des Passworts mithilfe diese Beispiels: http://www.obviex.com/samples/Encryption.aspx. Dito Entschlüsseln.

Salted PW damit: https://crackstation.net/hashing-security.htm.

Extract der App aus den embeded Resourcen in den Tmp-Folder als GUID.exe

public void ExtractResource(string res, string path)
        {
            Stream stream = GetType().Assembly.GetManifestResourceStream(res);
            byte bytes = new byte[(int)stream.Length];
            stream.Read(bytes, 0, bytes.Length);
            File.WriteAllBytes(path, bytes);
        }

Start mit den entsprechenden Credentials

 
Process.Startinfo() 
.... 
Process.Start() 

Da die App dann direkt als LocalAdmin ausgeführt wird habe ich auch kein Problem mehr mit Installationen bzw. Zugriff auf gesperrte Ordner.

Danke an euch beide (certifiedit.net und colinardo) für die Tipps.

Grüße!
Mayho