none
Sichere Klassenbibliotheken ? RRS feed

  • Frage

  • Hallo,

    Ich plane eine Anwendung die später beliebig erweiterbar sein soll, durch das hinzufügen entsprechender Assemblies (Klassenbibliotheken). In den Assemblies sollen sich dann Klassen befinden, die ein bestimmtes "ITask" Interface implementiert haben.

    Neue Tasks können dann "einfach" aus "neuen" Assemblies instanziiert und ausgeführt werden ITask.DoWork().

    Nun möchte ich aber irgendwelchen Bösewichten nicht Tür und Tor öffnen um Schädlings-Assemblies hinzuzufügen die dann auch das ITask Interface unterstützen...

    Daher die Frage : Wie sollte man in einem solchen Fall vorgehen?

    Danke für Hilfe und Hinweise.

    Gruß
    Rainer

    Montag, 20. September 2010 11:26

Antworten

Alle Antworten

  • Hallo Rainer

    vorab,
    sollen nur deine eigenen Assemblies zugelassen sein,
    oder auch bestimmte von Dritten, welchen du zB eine 'Lizenz' gegeben hast?

    Ein Ansatz (primär für eigene Assemblies) wäre per Strong Name / Signatur, Prüfung zB:
    http://blogs.msdn.com/b/shawnfa/archive/2004/06/07/150378.aspx

    http://stackoverflow.com/questions/369248/can-strong-naming-an-assembly-be-used-to-verify-the-assembly-author

    und/oder auch
    Friend Assemblies
    http://msdn.microsoft.com/en-us/library/0tke9fxk.aspx

    Aber alle solche Massnahmen sind rein 'technisch' (im Handling), haben nichts mit Code-Schutz/Verschlüsselung zu tun;  (sind also umgehbar).
    • Als Antwort markiert Rainer Queck Montag, 20. September 2010 12:23
    Montag, 20. September 2010 11:49
  • Hallo Thomas,

    danke für die Tipps. Der erste Ansatz (eigene Assemblies) klingt schon mal nicht schlecht. Dass ein PublicKeyTocken gehackt werden kann scheint mir vorstellbar, setzt aber schon etwas mehr Aufwand voraus als nur eine "schlechte Assembly" hinzuzufügen.

    Außerdem "Unknackbar" ist nichts.

     

    Gruß

    Rainer

    Montag, 20. September 2010 12:35
  • Hallo Rainer,

    [Assemblys mit starkem Namen] sind hier kein wirklicher Schutz - dies ist bereits viele Jahre bekannt - es ist sogar so extrem einfach, dass man das heutzutage nicht mehr in professionellen Apps für reine Schutz-Zwecke so machen sollte.
    Eine sauberere Art ist hier ggf. über MEF ganz bestimmte MetadataAttribute des Interface-Attributes verschlüselt zu fordern, das dann mit dem Hash der Assembly zu vergleichen. Ggf. auch unter Zuhilfenahme der [LicenseProvider-Klasse].


    ciao Frank
    Montag, 20. September 2010 12:37
  • Hallo Frank,

    danke für Deine Tipps. Ich habe sie "mal kurz" überflogen.

    Was MEF angeht, konnte ich "erstmal" nichts erkennen, wie ich verhindern kann dass eine "böse" Erweiterung angehängt wird. Wenn ich es richtig sehe, dann müsste eine Erweiterung ja bereits laufen, um deren MetadataAttribute verschlüsselt zu fordern, aber bis ich das tue, könnte schon viel passiert sein (Konstruktor -> Thread -> und los gehts.....). Oder habe ich das mit MEF noch nicht richtig verstanden?

    Am besten wäre es, vor dem Instanziieren irgendwelcher Objekte einer Assembly sicher zu sein, dass die Assembly OK ist....

    Gruß
    Rainer

    Montag, 20. September 2010 12:58
  • Hallo Rainer,

        > Wenn ich es richtig sehe, dann müsste eine Erweiterung ja bereits laufen,
        > um deren MetadataAttribute verschlüsselt zu fordern, aber bis ich das tue,
        > könnte schon viel passiert sein (Konstruktor -> Thread -> und los gehts.....).

    Eine "böse Erweiterung" kann hier nicht aktiv werden. Eine Erweiterung muss über MEF auch nicht "laufen"!
    MEF benutzt da einen reflektionsbezogenen Kontext. Es ist Dir auch absolut freie Hand über den Konstruktions-Zeitpunkt gelassen. Das sind u.a. doch gerade die Vorteile bei guten IoC Frameworks.


    ciao Frank
    • Als Antwort markiert Rainer Queck Montag, 20. September 2010 14:28
    Montag, 20. September 2010 13:05
  • Hallo Frank,

    das kling so erst mal sehr interessant. Dann werde ich mich mit MEF mal intensiver auseinander setzen.

    Danke für den Tipp!

    Gruß
    Rainer

    Montag, 20. September 2010 14:30
  • Hallo Rainer,

    schön. Wenn Du das angehen willst, ist sicher noch eine kleine Hilfe, dass Du in Deinem Szenario dann die AllowRecomposition-Eigenschaft beim Import-Attribut auf true setzen solltest.

    Zu MEF habe ich (und u.a. auch die MSDN Hotline) ansonsten schon ein paar Links und Infos in anderen Threads dieses Forums gegeben. Vielleicht sind sie hier hilfreich:
    http://social.msdn.microsoft.com/Forums/de/visualcsharpde/thread/cdb1515b-2766-48e7-8359-50971f54c01e
    http://social.msdn.microsoft.com/Forums/de-DE/dotnetframeworkde/thread/a24480ce-4a69-4130-949c-9f88bebe8059


    ciao Frank
    Montag, 20. September 2010 15:21
  • Hallo Rainer,

    > Sichere Klassenbibliotheken ?

    Zusätzlich zu den bereits erhaltenen Antworten: Wenn Du nach einer einfachen Möglichkeit suchst, nur "bekannten" Assemblies den Zugriff zu gewähren, könntest Du dir vielleicht das InternalsVisibleToAttribute näher ansehen:

    Friend-Assemblys (C# und Visual Basic):
    http://msdn.microsoft.com/de-de/library/0tke9fxk.aspx

    InternalsVisibleToAttribute-Klasse:
    http://msdn.microsoft.com/de-de/library/system.runtime.compilerservices.internalsvisibletoattribute.aspx

    In Kombination mit einer vernünftigen Zugriffskontrolle hast Du beste Chancen, Deine Bibliotheken zu schützen.

    Gruß
    Marcel

    Montag, 20. September 2010 17:15
  • Hallo Marcel,

         > "zusätzlich" [...] Friend-Assemblys, InternalsVisibleToAttribute

    das hatte ja Thomas schon gesagt und verlinkt.
    Ist aber zum einen kein Vergleich zur Flexibilität mittels MEF etwa - und wie ja auch von Thomas "(sind also umgehbar)" und mir erwähnt: ("kein wirklicher Schutz").


    ciao Frank
    Montag, 20. September 2010 19:14
  • Deshalb auch mein Vorschlag mittels Zugriffskontrolle dem entgegenzuwirken ;-)

    Montag, 20. September 2010 19:19
  • Hallo Frank,

    da Du hier allerorten bezüglich MEF schwärmst, erzähle uns doch mal,
    wie man damit einen Zugriffsschutz realisiert, denn die Rainers Frage lautet:

    Nun möchte ich aber irgendwelchen Bösewichten nicht Tür und Tor öffnen um Schädlings-Assemblies hinzuzufügen die dann auch das ITask Interface unterstützen...
    Daher die Frage : Wie sollte man in einem solchen Fall vorgehen?

    Die Links sind durch, aber nichts gefunden, bis auf
    http://blogs.microsoft.co.il/blogs/bnaya/archive/2010/01/01/securing-the-mef-directory-catalog.aspx

    dort findet sich

    1. IT => nichts mit MEF (oder .NET i.a.) zu tun
    2. CAS => siehe Thomas (plus Authenticode  wäre etwas mehr => muß aber auch bezahlt werden)
    3. hat es wohl nicht geschafft .

    womit die Frage offenbleibt:

    Welchen Mehrwert bietet MEF bei Zugriffsschutz für Rainer ?
    Fachlich präzise Aussagen wären gewünscht, wie von Dir gewohnt.

    Gruß Elmar

    Montag, 20. September 2010 21:10
    Beantworter
  • Hallo Elmar,

       > irgendwelchen Bösewichten nicht Tür und Tor öffnen  [...] das ITask Interface unterstützen...
       > Daher die Frage : Wie sollte man in einem solchen Fall vorgehen?


    ja, das steht aber schon in meinem vorangegangenen Posting [hier] beschrieben.
    Lies es ggf. noch mal nach und frage ggf. detaillierter nach, was Du daran nicht verstehst. Klar, es ist kein Beispiel-Code, aber ich denke Rainer hat das schon verstanden und wenn detaillierte Fragen sind, kann ich natürlich helfen.
    Mein Vorschlag ist ja hier ein eigenenes MetadataAttribute nebst Assembly-Hash und Encryption und nicht wonach Du wohl gegoogelt hast, ein StrongName. StrongName-Systeme sind letzlich aushebelbar - wir haben das schon vor vielen Jahren in der C# Gruppe beschrieben - möchte aber hier keine Hacker-Anleitung schreiben.
    Dein Artikel-Link (DirectoryCatalog) hat das übrigens auch umgesetzt, aber hat es nicht ins Release geschafft - nur, um den gebrochenen Satz etwas klarer zu stellen.
    Das gute ist ja, das Du mit MEF eigentlich komplett frei bist, Deine Security-Anforderungen auf Deine Weise umzusetzen. Ausserdem kennen wir ja sicher beide die geänderte CAS Strategie in .NET 4:

    [Is CAS dead in .NET 4? - .NET Security Blog - Site Home - MSDN Blogs]
    http://blogs.msdn.com/b/shawnfa/archive/2010/02/24/so-is-cas-dead-in-net-4-or-what.aspx

    Durch den Assembly-Hash benutzt man letztlich ähnliche Techniken wie bei signierten Assemblies, nur eben kostenlos, und frei in der Entscheidung der Implementation. 

    Mein Vorschlag ist kein wirklich bekannter oder oft genutzter Weg, sondern eine Idee von mir, bzw. Ideen-Teile scheinen ja auch im Netz auffindbar zu sein. Das liegt aber auch daran, dass das Ganze noch "verhältnismäßig" neu ist.


    ciao Frank
    Dienstag, 21. September 2010 07:58
  • Hallo Frank,

    ich habe keine Aktien in MEF - und wollte keine erwerben ;-),
    aber liesse mich (und andere bestimmt auch) umstimmen,
    wenn die Leistungsfähigkeit von MEF an einem Beispiel demonstriert würde.

    Dein Aussage ist mir schlicht und einfach zu vage.
    Da Du so viel über MEF schreibst (schwärmst), gehe ich (optimistisch) davon aus,
    dass Du es mit Deiner Expertise leicht tun könntest, und

    sondern eine Idee von mir, bzw. Ideen-Teile scheinen ja auch im Netz auffindbar zu sein.

    bei Deinen Studien von MEF entstanden ist.
    Und es wäre IMHO in Rainers wie im Interesse des Forums dieses Wissen zu teilen.

    Zwei Fliegen mit einer Klappe könntest Du dabei schlagen, in dem Du es es kombiniert,
    und zeigst im Zusammenhang mit
    Plugin-Basierte GUI

    100% perfektes erwartet niemand.

    Gruß Elmar

    Dienstag, 21. September 2010 08:15
    Beantworter
  • Hallo Elmar,

    danke für Deinen Hinweis. Problem ist ein wenig (um kurz zu privat zu werden), dass ich in dieser Woche umziehe und wenig Zeit habe - und das soll dann schon Hand und Fuß haben. Es ist aber eine gute Idee, das mal (vielleicht in meiner Webseite) zu veröffentlichen. Ich versuche das im Hinterkopf zu halten und sonst hier mal in ein paar Wochen einfach posten/nachfragen. Ich könnte mir auch vorstellen, Rainer ist schneller ;-)
    Ich hatte noch das Wort Assembly-Hash nicht verlinkt, soll MD5 Checker (Download) nachgeholt sein.


    ciao Frank

    Dienstag, 21. September 2010 13:49
  • Hallo Frank,

    dann wünsche ich Dir bei Deinem Umzug viel Glück.
    Toi, Toi, Toi, dass alles heile bleibt und am Ende wieder gefunden wird ;-)

    Gruß Elmar

    Dienstag, 21. September 2010 15:34
    Beantworter
  • Hallo Elmar,

    danke :-)


    ciao Frank
    Dienstag, 21. September 2010 19:25
  • Ich könnte mir auch vorstellen, Rainer ist schneller ;-)

    Hallo Frank,

    ich fürchte da muss ich Dich enttäuschen. Wie eingangs erwähnt befinde ich mich in der Planungsphase. Bis ich dazu komme MEF in Angriff zu nehmen, wird es wohl noch ein bisschen dauern.

    Im übrigen verfolge ich Eure Diskussion mit regem Interesse. Ich hoffe offen gestanden, dass Du mit Deinem Umzug - auch von mir "viel Glück" - rechtzeitig fertig wirst und dann ein Beispiel zur Verfügung steht bevor ich mit den Thema beginne ;-)

    Gruß
    Rainer

    Mittwoch, 22. September 2010 07:44