none
Installation von Programmen und Bibliotheken laden

    Allgemeine Diskussion

  • Überblick

    Mein Ziel war anfangs lediglich, das Problem "DLL-Hölle" zumindest theoretisch zu lösen. Ich empfand die Lösung von Microsoft an dieser Stele immer als sehr unbefriedigend. Das auf diesem Weg die Schadsoftware ausgeschlossen werden kann, viel mir erst im Laufe der Zeit auf und ist eigentlich nur ein positiver Nebeneffekt. Es geht in diesem Konzept um einen anderen Ablageort für Software als das normale Dateisystem und als Folge davon um eine andere Art des Ladens von Software (kein whitelisting).

    Bildhaft kann man sagen, daß ein Computer mit der auf ihm installierten Software momentan ist wie ein Mensch ohne Haut. Sprich: Bakterien und Viren können problemlos eindringen und Schaden anrichten. whitelisting oder andere Schutzmeachnismen versuchen sich dann mit diesem Problem zu arrangieren und eine Lebensfähigkeit nachträglich herzustellen, die eigentlich nicht vorhanden ist. Bildhaft kann man sagen, legt whitelisting eine künstliche Schutzfolie um den Menschen ohne Haut. Dies bringt aber etliche Nachteile mit sich (schlechtere Performance, kein Schutz als Administrator, usw.). Das Ziel dieses Konzepts ist ein Mensch mit Haut (als natürlicher Bestandteil).

    Problembeschreibung

    Ich kannte in den vergangenen Jahren eigentlich nur die Vorgehensweise von Microsoft bzgl. der Installation von Software (SETUP.EXE-Programme, die die Installation ausführen). Nun habe ich mich vor kurzem ein wenig mit Linux beschäftigt und dabei dann Yast kennen gelernt. Und wie ich dann langsam die Konsequenzen dieser anderen Herangehensweise überblicken konnte, bin ich zu dem Schluß gekommen, daß dies viel besser ist als der Ansatz von Microsoft. Bei Microsoft üben viele Kontrolle über den Datenbestand der Bibliotheken, Programme, Registry usw. aus. Bei Linux nur einer. Dies hat aber fundamentale Bedeutung, wenn ich ein stabiles System haben will. Microsoft und deren Anwender sind immer von guten oder schlechten Installationsprogrammen abhängig. Linux nicht. Bei Windows ist es besser, Testinstallationen lieber in einer virtuellen Maschine durchzuführen, um das eigentliche System nicht negativ zu beeinflußen. Auch bei einer Deinstallation gibt es niemals 100%ige Sicherheit, daß kein Müll zurückbleibt und gleichzeitig noch alle anderen Programme einwandfrei funktionieren. Letztendlich überläßt Microsoft den Anwendungsprogrammen zu viel Verantwortung, die eigentlich zu ihrem Verantwortungsbereich gehören (Eindeutigkeit der DLL-Namen, Versionierung, Installation). Aus diesem Mangel seitens Microsoft erwachsen folgende Nachteile für die Anwender und auch für Microsoft:

    1. Keine Eindeutigkeit bei den DLL-Namen. Theoretisch kann ein Softwarehersteller in die Situation geraten, alle seine Bibliotheken, die er in System32 installieren muß, umzubenennen, weil ein anderen Hersteller die gleichen Namen benutzt.Dies kann sogar nachträglich noch entstehen, weil ein sehr viel größerer Hersteller die selben Namen benutzt und dessen Software aber nach der des kleineren Herstellers installiert wurde. Da wird dann der kleinere wohl kuschen müssen und seine Bibliotheken umbenennen. Ob dies so bereits vorgekommen ist, weiß ich nicht, aber es ist möglich.

    2. Abhängig von der Qualität der Installationsprogramme; man stelle sich mal vor, Windows ist davon abhängig, wie gut oder schlecht ein Programm die Prozesspriorität oder andere Werte in Windows einträgt. Dies wird hier durch die Get- und Set-Funktionen ausgeschlossen. Auch hier hat nur einer Kontrolle über die Daten.

    3. Microsoft muß sich mit solchen Problemen wie „Unerlaubte Änderungen am System erkennen und rückgängig machen“ herumschlagen (wobei diese Funktion aber auch beträchtliche Nachteile für Hersteller von Anwendungssoftware beinhaltet: ich hatte einmal einen solchen Fall, wo ich eine DLL im System32-Verzeichnis bei einem Kunden eintragen wollte und dies aber wegen dieser Funktion nicht so ohne weiteres möglich war). In meinen Augen ist das so ähnlich, wie das Unkraut, was man sieht, an der Oberfläche abschneiden. Bei Linux hingegen kann dieses Unkraut garnicht erst wachsen.

    4. Bei der Deinstallation kommen mitunter solche Meldungen wie „Soll diese DLL wirklich entfernt werden? Andere Programme könnten dann nicht mehr funktionieren.“ (ich hatte einmal eine solche Meldung). Diese Meldung ist doch eigentlich ein Armutszeugnis für Microsoft. Was soll der Anwender damit anfangen? Letztendlich kann er nur sagen „Die DLL soll nicht gelöscht werden“. Auf lange Sicht wird so zwar sein System vollgemüllt, aber immer noch besser, als wenn plötzlich sein Programm xxx nicht mehr funktioniert, daß er doch dringend braucht.
      Es kann natürlich sein, daß diese Meldung eigentlich vom Deinstallationsprogramm der Anwendung angezeigt wurde. Aber trotzdem ist Microsoft dadurch nicht aus dem Schneider. Erstens sagt man „Bei Windows hat man viele Probleme bei der Installation und Deinstallation“ und zweitens könnte Microsoft dieses Übel an der Wurzel beheben.

    5. Schadsoftware hat es sehr einfach, da DLLs und EXEs, ohne installiert sein zu müssen, ausgeführt werden können. Weiterhin hat sie es einfach (oder der Anwender schwer), da diese Programme eben auch Funktionen aufrufen können, die das System verändern (deswegen kommen dann ja solche Meldungen wie „Haben Sie diese Aktion ausgelöst?“). Sofern dies Installationsangelegenheiten sind, ist dieses Problem eigentlich überflüssig.

    6. Konflikte in der Versionierung der Bibliotheken können leicht auftreten. Dies liegt darin, daß die Versionsproblematik den Anwendungsprogrammen überlassen bleibt. Diese unterschlagen dann eben aus Unwissenheit/Oberflächlichkeit/Leichtfertigkeit mal Fakten, mit denen dann der Anwender zu kämpfen hat.

    Gemeinhin bezeichnet man dies alles dann wohl als „DLL-Hölle“.

    Problemlösung

    Weiterhin habe ich mir noch folgendes Konzept für die Ablage der Bibliotheken und Programme im System und das Laden überlegt:

    Die Bibliotheken und die EXEs werden bei der Installation in einer zentralen Datei abgelegt, die das System immer offen hält. Die aktuellen EXE- und DLL-Dateien dienen dann nur noch als Transportmedium für die Bibliotheken und Programme. Die Programme adressieren die benötigten Bibliotheken (statisch oder dynamisch) über eine ID, die in den EXE- und DLL-Dateien enthalten sein muß. Diese ID muß weltweit eindeutig sein. Mindestens sollte diese ID aus folgenden Feldern bestehen (Bit-Felder):

    CompanyID: Diese muß zentral verwaltet und beantragt werden.

    ModuleID: ID der Bibliothek/des Programms; kann dann innerhalb einer Firma verwaltet werden.

    Evtl. kann dies noch um eine CountryID, eine ProductID (Produkt innerhalb einer Firma) usw. erweitert werden.

    Diese CompanyID benötige ich auch noch für meine allgemeine ID-Klasse, zu deren Ableitungen solche IDs wie EventIDs (Fehler, Warnung, Information) und andere gehören. Dies ist Teil eines Ereignisprotokolls, daß mittels SharedMemory realisiert ist und, denke ich, ebenfalls in das Betriebssystem gehört. Ziel dieses Ereignisprotokolls ist es, solche Meldungen wie „Fehler 0x32432: Es ist ein Fehler aufgetreten.“ zu unterbinden.

    Das Betriebssystem muß dann Zuordungstabellen von der ID einer Bibliothek zu der Position in der Datei im Hauptspeicher halten. Diese Datei dient nur zur Abspeicherung auf der Festplatte. Beim Laden einer DLL/EXE in den Speicher bleibt alles wie gehabt (eigener Speicherbereich usw.).

    Weiterhin muß noch die Versionierung unterstützt werden. Eigentlich kann ich mit zwei Versionsnummern alles abdecken:

    1. rückwärtsgerichtete Versionsnummer (gemeinhin als Hauptversionsnummer bezeichnet); diese wird von Microsoft und anderen Firmen bisher durch 42 in MFC42.DLL oder die 32 in USER32.DLL abgedeckt. Sie ist eigentlich immer im Dateinamen codiert und hat die Bedeutung, daß Programme diese Bibliothek nur in genau dieser Version verwenden können. Es besteht keine Kompatibilität zwischen prinzipiell gleichen Bibliotheken mit einer solchen unterschiedlichen Versionsnummer.

    2. vorwärtsgerichtete Versionsnummer (gemeinhin als Nebenversionsnummer bezeichnet); dies wird bisher, da bisher nicht mehrere Versionen einer Bibliothek installiert sein können, nur anhand des Änderungsdatums oder unsichtbarerer Versionsnummern realisiert. Prinzipiell lautet die Frage, die diese Versionsnummer beantwortet: „Hat die Bibliothek mindestens schon den Stand x in dem die neue Funktion y enthalten ist (z.B. neue Parameterwerte mit spezieller Bedeutung, neue String-Resourcen, neue Funktionseinstiegspunkte, usw.). Ich bezeichne diese Versionsnummer als funktionale Versionsnummer.

    Ein Programm/Bibliothek, daß eine Bibliothek zwecks dynamischem/statischem Laden referenziert, muß dann neben der ID der Bibliothek auch die Version angeben, die es benötigt (Version bzgl. Kompatibilität und die funktionale Version).

    Bei der Installation wird dann in der Bibliothek ein Referenzzähler inkrementiert und bei der Deinstallation wieder dekrementiert. Bibliotheken werden dann erst beim Freigeben der letzten Referenz gelöscht.

    Evtl. muß das Betriebssystem dann auch Bibliotheken älterer funktionaler Versionen trotzdem noch gespeichert halten, da die neue Bibliothek entgegen den Aussagen des Herstellers nicht kompatibel ist oder andere Fehler enthält, die ein Zurückgehen auf die Vorgängerversion erforderlich machen.

     

    Die Ablage der Bibliotheken und Programme in einer zentralen Datei hat hierbei neben der Einführung einer technischen Grenze zwischen installierter und anderer Software der Zweck der Geschwindigkeitsoptimierung. So erspart man sich den Gang über das Dateisystem (Pfadauflösung, und Datei öffnen und schliessen).

    Solche Techniken wie DLL-Injektion usw. lassen sich auch mit diesem Konzept realisieren.

    Dieses Konzept hätte natürliche heftige Auswirkungen auf das gesamte Windows-System. Windows Vista umfaßt 5000 DLLs mit einem Speicherbedarf von 1.6GB und noch einige EXEs dazu. Das alles plus die Bibliotheken und EXEs der Anwendungsprogramme würde dann ja in diese Datei kommen. Da würde schnell 3-4 GB zusammenkommen.

    Auch sollte dafür eine Optimierungsmethode in das System integriert werden: Datei zusammenschrumpfen um Löcher zu stopfen und so die Gesamtgröße reduzieren, Defragmentierung, usw.

     

    Abschließend möchte ich noch sagen, daß mehrere Systeme meiner Meinung nach immer nur indirekt mit einander verbunden sein dürfen. Eine direkte Verbindung hat immer die Wirkung, daß das Zielsystem, daß adressiert wird, keine Kontrollmöglichkeit mehr über die Zieldaten hat. Im Falle der Bibliotheken z.B. hat das Betriebssystem durch die direkte Adressierung seitens der Programme keine Möglichkeit mehr, sich zu speichern, wer die Bibliotheken verwendet, bei Verfügbarkeit neuer Versionen diese zu laden und trotzdem noch ein Zurückgehen auf die Vorgängerversion zu ermöglichen, usw.

     

    Bitte teilen Sie mir doch Ihr Urteil mit und auch, ob Sie diese Idee weiterleiten. Danke!







    Montag, 4. Juli 2011 07:17

Alle Antworten

  • Hallo Johannes.

    Ich biete Dir das DU an. Ich habe Deinen Beitrag mehrfach gelesen. Du zeigst nicht nur die Probleme auf, sondern lieferst auch Lösungen. Das ist Ingenieur mässige Vorgehensweise.

    Johannes schieb:

    Bei der Deinstallation kommen mitunter solche Meldungen wie „Soll diese DLL wirklich entfernt werden? Andere Programme könnten dann nicht mehr funktionieren.“ (ich hatte einmal eine solche Meldung). Diese Meldung ist doch eigentlich ein Armutszeugnis für Microsoft.

    Also ich bevorzuge grundsätzlich immer diese DLL zu löschen ohne wirklich zu Wissen welche Auswirkungen das hat-

    Dein Beitrag ist wirklich interessant.

    Ich denke, dass DLLs von Anwendungen nichts im Verzeichniss system32 zu suchen haben. Wie der Name schon sagt system32. Da gehören nur  DLLs vom System hinhein und keine anderen.

    schöne Grüsse Ellen

     

     

     

     

     


    Ich benutze/ I'm using VB2008 & VB2010
    Samstag, 9. Juli 2011 20:48
  • Hallo Ellen,

    tut mir leid, daß ich so lange nicht geantwortet habe, aber ich habe nicht so schnell mit Antworten gerechnet.

    Wegen dieser Vorgehensweise bzgl. der Themen Ereignisanzeige und Application-Framework und einem eigenmächtigen Anstreben dieser Dinge, die aus der Inkompetenz meiner ehemaligen Vorgesetzten erwachsen ist, wurde mir vor zwei Jahren gekündigt. Ich bin im Moment arbeitslos und versuche jetzt gerade, wegen des schlechten Zeugnisses meines ehemaligen Arbeitgebers, einen Praktikumsplatz zu finden (damit ich wieder in einen normalen Arbeitsprozess komme).

    Bzgl. deiner letzten Aussage, daß DLLs von Anwendungen nichts in system32 zu suchen haben:

    Dies wird nur schwierig für Hersteller von Funktionsbibliotheken, auf die andere Hersteller aufbauen. Ich hatte früher immer List&Labels von Combit benutzt gehabt (Reporting-Tool; List&Labels besteht eigentlich nur aus DLLs und OCX-Controls). Da ja auch mehrere Firmen auf diese Bibliotheken aufbauen können, wird ein zentraler Ablageort benötigt. So stellen die z.B. auch ein OCX-Control bereit, um deren Reports dem Anwender anzeigen zu können. Das Programm, daß diese OCX-Controls aufruft, weiß nichts von den Dateien. Es kennt nur eine ID und diese wird von Windows dann den im System registrierten Bibliotheken über die Registry zugeordnet.

    Hast du vielleicht die Möglichkeit, dieses Konzept Microsoft ein wenig näher zu bringen? Wenn ja, wäre ich dir dankbar.

    Ich habe ja oben angeschnitten, daß ich auch an einem Ereignisprotokoll arbeite. Ich habe zu diesem Thema einen Artikel auf Englisch in einem Linux-Forum verfaßt. Wenn du Interesse hast, kannst du den ja auch mal durchlesen. Der Link lautet:
    http://cboard.cprogramming.com/linux-programming/136486-eventlog-errorids-shared-memory-file-system.html

    Prinzipiell denke ich auch bei diesem Ereignisprotokoll, daß es eigentlich in das Betriebssystem gehört. Die können mit Shared-Memory doch sehr viel leichter umgehen als Anwendungsprogramme.

    Ich selber benutze Microsoft Visual Studio 6.0 und 2008 (C++ und C) und MFC.

    Dienstag, 19. Juli 2011 21:47
  • Ich vergaß im obrigen Konzept noch die Entwickler von Software. Es ist für die ja nun nicht akzeptabel immer als Administrator zu arbeiten und das EXE/DLL erst zu installieren, bevor es ausführbar ist. Hierfür kann man evtl. im System dann eine Möglichkeit integrieren, auch weiterhin DLLs/EXEs ausführen zu können. Die Adressierung derselben erfolgt dann aber trotzdem über die ID. Sie dienen dann lediglich zur Ablage auf der Festplatte. In den Tabellen im Hauptspeicher, die eine Zuordnung von ID zu Bibliothek ermöglichen sollen, muß es dann auch eine Möglichkeit geben, dort alternativ einen Pfad einzutragen. Dieser Mechanismus würde ohne eine Absicherung für Schadsoftware natürlich wieder Tür und Tor öffnen. Man muß dann eben einen speziellen Modus einführen, der vom Anwender aktiviert werden muß und in dem dann die Ausführung von EXEs/DLLs möglich ist (ohne installiert sein zu müssen).

    Hier noch ein kleiner Nachtrag, was ich denke, besser wäre:

    1. Beim Anmelden führt man einen Button "Entwickler ja/nein" ein. Diesen Button blendet man normaler Weise (für Nicht-Entwickler) aus und Entwickler müssen im System eintragen, daß dieser Button angezeigt werden soll. Die Voreinstellung dieses Buttons (gesetzt: ja/nein) kann man sich dann in der speichern.
    2. In diesem Modus können DLLs/EXEs dann auch ohne Administrator-Rechte installiert werden. Die Compiler/Linker installieren das erstellte Modul (EXE/DLL) dann automatisch. Diese Möglichkeit, Module auch ohne Administrator-Rechte installieren zu können, wird wohl von Schadsoftware nicht genutzt werden, da die dann ja nur einen sehr geringen Teil der Anwender erreichen würde. Außerdem kann man diesen Modus evtl. auch ausschalten, wenn man in das Internet geht.

    Ein weiterer offener Punkt ist hierbei dann noch Software, die in einer Interpreter-Sprache ausgeliefert wird (jar-, cmd-, bat-Dateien usw.). Irgendwie denke ich, solche Software muß auch installiert werden. Sonst darf sie nicht ausführbar sein.

    Mittwoch, 20. Juli 2011 06:20
  • Hallo Ellen,

    tut mir leid, daß ich so lange nicht geantwortet habe, aber ich habe nicht so schnell mit Antworten gerechnet.

    Hast du vielleicht die Möglichkeit, dieses Konzept Microsoft ein wenig näher zu bringen? Wenn ja, wäre ich dir dankbar.

    Hallo Johannes,

    ich bin hier nur ein kleines Licht bei msdn und beruflich mit Microsoft nicht direkt verbunden. Es wäre sinnvoll, wenn Robert von Microsoft hier Stellung beziehen würde. Was Du ansprichst sind sehr interessante Themen.

    LG Ellen

     

     


    Ich benutze/ I'm using VB2008 & VB2010
    Donnerstag, 21. Juli 2011 19:29
  • Durch den Einsatz eines solchen Konzepts nimmt man dem Anwender aber jede Einflußmöglichkeit darauf, welche Bibliothek ein Programm verwendet. Bisher hat man ja durchaus die Möglichkeit, dies zu steuern. Man kann z.B. die Bibliothek in ein anderes Verzeichnis verschieben und durch die Suchreihenfolge, nach der Windows die DLL sucht (aktuelles Verzeichnis, system32, Pfad-Umgebung), so sicherstellen, daß in einem speziellen Programm eine andere Version der Bibliothek angezogen wird. Dies kann wichtig sein, da ein Programm, das man installieren will, mit einer neueren Version einer Bibliothek daher kommt, mit der ein bereits installiertes Programm (entgegen den Aussagen des Herstellers) nicht umgehen kann und die Arbeit verweigert. In solchen Fällen kann man sich bisher immer irgendwie helfen. Dies würde aber durch das oben beschriebene Konzept unmöglich werden, wenn nicht eine Möglichkeit integriert wird, daß der Anwender Programmen ganz spezielle Bibliotheken zuweisen kann.

     

    Man kann hier natürlich sagen, daß der Anwender nichts von solchen internen Abläufen wissen soll. Ich verstehe in diesem Fall unter Anwender aber auch Supporter von Software-Herstellern. Die kennen den Sachverhalt hingegen ganz genau und sollten die Möglichkeit haben, das, wenn nach der Installation ihres Programms der Kunde bemängelt, daß ein anderes Programm nicht mehr funktioniert, sie erstens die gemeinsam genutzten Bibliotheken ermitteln können (falls es denn daran liegt) und zweitens, dann dem fremden Programm die vorher installierte Version zuweisen können. Es muß also möglich sein, für das fremde Programm den selben Bibliothekenstand wie vor der Installation zu aktivieren.

    Ich denke, der entscheidende Unterschied zwischen meiner Herangehensweise und der von Microsoft ist der, daß Microsoft Bibliotheken und Programme nur teilweise als Datenbestand des Betriebssystems versteht, der zu schützen ist. Bzgl. Anwendungssoftware wie z.B. Firefox usw. ist die einzige Forderung, die Microsoft zu erfüllen versucht: Kompatibilität. Ich hingegen verstehe die Bibliotheken und Programme ausschließlich als Datenbestand des Betriebssystems. Mein Ansatz wird aber durch folgende Fakten gestützt:

    • Die Bibliotheken und Programme sind durch die Registry und andere Dinge (gemeinsame Bibliotheken) so eng mit dem Betriebssystem bzw. mit anderer Software verwoben, daß man 70-80% der Software nach einem Neuaufsetzen des Betriebssystems ebenfalls neu installieren muß. Es sind meistens eigentlich sehr kleine Programme, die ein Neuaufsetzen des Betriebssystems schadlos überstehen und danach problemlos lauffähig sind. Und hier ist das ganze Runtime (kennen tue ich dies im Falle von C/C++ und MFC) wohl auch statisch mit in das Programm gelinkt. Würde das dynamisch aus den Bibliotheken aus system32 geladen werden, müßten diese auch neu installiert werden.


    Ich habe über dieses Konzept jetzt noch mal ein paar Tage nachgedacht, und bin mittlerweile zu dem Schluß gekommen, daß es eigentlich absolut sicher ist und Schadsoftware vollkommen ausschließt (außer in Dokumenten enthaltene Viren wie z.B. in Mails, Word-Dokumenten usw.). Voraussetzung hierfür ist natürlich, daß der Anwender Schadsoftware nicht selber installiert. Nachfolgende Grafik stellt diesen Sachverhalt grafisch dar.

     



    Mittwoch, 27. Juli 2011 16:18
  • Hallo Ellen,

     

    der Robert Breitenhofer reagiert nicht auf meine Facebook-Nachricht. Ich fand über Google keine EMail-Adresse von Ihm aber eben ein FaceBook-Konto. Weißt du, wie ich ihm eine Nachricht zukommen lassen kann?

    Wie ist den überhaupt deine EMail-Adresse? Meine lautet: j.ody@web.de

    Mittwoch, 27. Juli 2011 16:27
  • Ich fand über Google keine EMail-Adresse von Ihm ...

    Wie ist den überhaupt deine EMail-Adresse? Meine lautet: j.ody@web.de


    Hallo Johannes Ody,

    Lies bitte folgenden Link: Wie vermeide ich Spam?

    **********************************************************************************************

    Alle Ansprechpartner und Blogger findest Du hier: http://www.microsoft.com/germany/msdn/kontakt/default.mspx

    Die

    Grüße,

    Robert

    Mittwoch, 27. Juli 2011 16:54
    Besitzer
  • Danke für die Antwort Robert Breitenhofer.

    allgemeine ID-Klasse

    So wie ich das sehe, ist das Problem der fehlenden garantierten weltweiten Eindeutigkeit bei jeder Form von IDs in der Softwareentwicklung ein fundamentales Übel. Bei Windows habe ich in folgenden Bereichen niemals wirkliche Sicherheit auf Eindeutigkeit:

    • Dateiypen: Viele Extensions werden für unterschiedliche Dateiformate doppelt benutzt. Daraus resultieren Konflikte bei den zugeordneten Operationen des Explorers (Öffnen, Drucken, usw.).
    • Fenster-Properties (SetProp, GetProp, RemoveProp): Bei diesen Namen gibt es auch niemals garantierte Eindeutigkeit.
    • CommandID (WM_COMMAND): Hier hat man das Problem, von Bibliotheken aus freie CommandIDs ermitteln zu können (um sie dann zu benutzen). Auch ist die Einhaltung der zulässigen Wertebereiche relativ schwierig.
    • ErrorCodes: Hier gibt es ebenfalls keine garantierte Eindeutigkeit. ErrorCodes von Microsoft müssen getrennt von denen anderer Hersteller behandelt/gespeichert werden.
    • StringID (LoadString): Ebenfalls keine eindeutige ID. Weiterhin hat man mit dem angeben des Moduls, aus dem der String geladen werden soll, auch immer redundante Information.

    Ich kann mir gut vorstellen, daß Software, die sich als DLL in fremde Anwendungen einklinkt, wegen dieser nicht garantierten Eindeutigkeit oftmals Probleme bereitet. nView ist so eine Software. Ich hatte bei meinem frühereren Arbeitgeber große Probleme, wenn diese Software auf dem Rechner installiert war und sich dann eben auch in meine Anwendung eingeklinkt hat.

    Um alle diese Probleme zu erschlagen, habe ich mir eine ID-Klasse überlegt, die mittels Bit-Datenfeldern realisiert ist. Diese gerade getätigten Ausführungen habe ich eigentlich nur vorgenommen, um nun diese ID-Klasse, deren Zielgebiet weit über die Bibliotheken und Programme hinausgeht, zu beschreiben:

    Typ der ID:

    • Event (ErrorCode)
    • String
    • Property
    • Parameter (diese habe ich nicht beschrieben, sehe dies aber trotzdem als sinnvoll an)
    • Licence (diese habe ich nicht beschrieben, sehe dies aber trotzdem als sinnvoll an)
    • Command
    • Module (Bibliothek, Programm)
    • Filetyp

    Dies muß natürlich nicht abschliessend sein.

    Diese Klasse besteht dann aus folgenden Feldern:

    int iType: x; //x Bit

    int iLevel: 2; //Error, Warning, Info; nur für EventIDs

    int iCountryID: x;

    int iCompanyID: x; //Diese muß dann von einer Firma beantragt werden.

    int iProductID: x; //Nötig ???

    int iModuleID: x; //Wird dann innerhalb einer Firma verwaltet.

    int iClassID: x; //Bei Type=Module immer 0.

    int iID: x; //Bei Type=Module immer 0.

    Das alles läßt sich in 32 Bit wohl nicht mehr unterbringen. Deshalb muß man wohl einen 64-Bit-Wert nehmen. Bei der Bitverteilung maß man aber auch berücksichtigen, daß z.B. für mehrere kleine Länder eine einzige CountryID verwendet werden kann. Ähnlich gilt dies für kleine Firmen, usw.

    Bisher gibt es ja soetwas wie eine CompanyID meines Wissens nach nicht. Bei der CountryID bin ich mir da nicht sicher.

    Gewissermaße habe ich eine natürliche Grenze zwischen installierter (und damit vom Anwender als vertrauenswürdig eingestufter) Software und anderer Software eingeführt. Diese fehlt bisher bei Windows und Linux.




    Mittwoch, 27. Juli 2011 20:07
  • Ich möchte zu diesem Thema noch nachtragen, daß Internet-Seiten ja mitunter auch sehr viel Programmcode enthalten können (PHP, Perl, JavaScript, usw.). Dies muß dann natürlich immer noch ausführbar sein. Allerdings dürfen für diese Sprachen die o.g. API-Funktionen Install und Update (s. Grafik) nicht aufrufbar sein. Das Installationsprogramm darf ebenfalls Software nur nach Anwenderbestätigung installieren. Solche Formen von Software sind dann per Definition immer kritisch (potentielle Schadsoftware). Insofern muß man als Hersteller einer solchen Sprache (PHP) sich dann auch darüber gedanken machen, was man erlauben kann. Ich persönlich denke, solche nicht installierte Software darf eigentlich alles, außer das System modifizieren und bestimmte sensible Daten abfragen.

    Durch dieses Konzept würde sich die Tätigkeit der Anti-Viren-Programme auch sehr grundlegend ändern. Die hätte dann eigentlich nur noch folgende Aufgaben:

    • Dokumente (Word-, Excel-Dokumente usw.) scannen
    • Mails scannen
    • Installationspakete scannen
    • Internet-Seiten scannen
    • Boot-Sektoren von CDs und Disketten scannen
    Donnerstag, 28. Juli 2011 21:55
  • Die Installation einer Software ist dann immer eigentlich eine Vertrauenserklärung durch den Anwender. D.h. dann aber auch, daß das Installationsprogramm immer min. eine Benutzerbestätigung entgegen nehmen muß.
    Samstag, 30. Juli 2011 16:12
  • Bei wikipedia habe ich in Puncto Versionierung noch von einer Revisionsnummer und einer Buildnummer gelesen. Die Revisionsnummer kennzeichnet hierbei dann die Anzahl der Fehlerbehebungen in einem Stand. Die Buildnummer wird meistens einfach immer nur hochgezählt (ohne zurücksetzen) und identifiziert einen Compilierungsstand. Die Buildnummer wird in dem oben beschriebenen Konzept wohl nicht benötigt. Enthält ja schließlich keine Aussage für das Betriebssystem. Die Revisionsnummer hingegen schon. Schließlich will man als Benutzer einer Bibliothek immer die mit den wenigsten Fehlern verwenden.

    Eine positive Folge einer Integration der Versionierung in das Betriebssystem ist dann auch, daß die Versionierung standardisiert wird und es nicht mehr der Firma überlassen bleibt, ob und wie sie versioniert. Früher hatte die Versionsnummer für mich keinen technischen Hintergrund, sondern lediglich einen kosmetischen Sinn. So habe ich die Versionsnummern dann so vergeben, wie ich das so von anderen gehört habe, daß man das machen soll. Aber ohne Systematik.

    Wenn eine Software dem Betriebssystem eine fremde ID vorlügt (z.B. das eine Schadsoftware sich als Teil des Betriebssystems ausgibt), so hat dies aber keine negativen Auswirkungen, da sie trotzdem noch die Hürde der Installation nehmen muß und der Anwender Software aus zweifelhaften Quellen niemals bedenkenlos installieren sollte.
    Samstag, 30. Juli 2011 20:20
  • Auswirkungen dieses Konzepts auf die Softwareentwicklung

    Langfristig wird sich durch den Einsatz dieses Konzepts die Strategie der Hersteller von Schadsoftware wohl dahingehend verändern, zu versuchen ihre Schadsoftware in die Produkte seriöser Hersteller einzuschleusen. Dadurch könnten die dann die Hürde der Installation wieder problemlos nehmen. Dies wäre bei der aktuellen Arbeitsweise der Softwareentwickler (Entwicklungswerkzeuge irgendwo aus dem Internet zu beziehen) relativ leicht. Es müßten nur solche Entwicklungswerkzeuge (z.B. HexEdit, mächtigere ASCII-Editoren, Task-Manager-Erweiterung, usw.) um den Schadcode erweitert werden. Sind die dann erstmal auf einem Rechner, auf dem entwickelt wird (und werden dort auch eingesetzt), so können sie dann den Compiler/Linker befallen und von dort aus dann die Softwareprodukte, die dort entwickelt werden. Will man dies vermeiden/begrenzen, so könnte man für Hersteller von Software ein Gütesiegel einführen, daß besagt: wir setzen nur Werkzeuge aus seriösen/sicheren Quellen ein, die ebenfalls dieses Gütesiegel tragen.

    Dann wäre der einzige Angriffspunkt für die Hersteller von Schadsoftware eigentlich noch die Bestechung von Mitarbeitern eines Softwareherstellers. Das läßt sich aber durch Systematik nicht in den Griff bekommen. Es bleibt eben ein Restrisiko.


    Gehbarer Weg für Microsoft für den Umstieg

    Es stellt sich dann noch die Frage, wie ein gehbarer Weg für den Umstieg auf dieses Konzept aussehen kann. Schließlich muß die bereits existierende Software weiterhin laufen (Kompatibilität). Ich denke, man müßte das Betriebssystem intern auf diesen Mechanismus umstellen und die bisherige Arbeitsweise als Zubringer für die neue Arbeitsweise erstmal im System lassen. Die Compiler-Hersteller müssen ihre Produkte dann umstellen. Bei der Installation von Windows kann der Anwender dann sagen:

    • bitte im Kompatiblitätsmodus installieren (alte Software soll noch lauffähig sein); die Schadsoftware kann wie bisher auch tätig werden
    • oder er sagt: nein, ich setze nur Software ein, die auf dieses Konzept aufbaut; alte Software soll nicht mehr lauffähig sein. Dann wird beim Laden solch alter Software ein Fehler zurückgegeben und die Ausführung verweigert. In diesem Betriebsmodus ist das System dann sicher vor Schadsoftware.
    Für die große Masse der Anwender, die nur Standardsoftware (MS Excel, MS Word, MS Outlook, usw.) benutzen, würde das Problem der Schadsoftware so schon bereits nach 2-3 Jahren erledigt sein.



    Sonntag, 31. Juli 2011 10:47
  • Ich habe zu diesem Konzept nun noch ein Datenmodell in UML angefertigt. Dies sieht nun so aus:


    Im Prinzip ermöglicht das Betriebssystem dem Anwender dann die Erweiterung um firmenfremde Funktionen, die durch die Installation zu einem Teil des Betriebssystems werden.

    Mittwoch, 3. August 2011 10:10
  • Mir fiel gerade auf, daß es unter Windows ja auch das Dateirecht "Ausführen" gibt. Dies ist dann natürlich ein Punkt, der die zentrale Ablage aller Module (EXE/DLL) in einer Datei schon wieder in Frage stellt. Schließlich müßte man hier sonst auch noch wieder ein Rechteattrbut einführen. Dem gegenüber steht der wesentliche Vorteil dieser zentralen Datei der absoluten Sicherheit vor unberechtigten Manipulationen am Bestand der Programme und Bibliotheken.
    Mittwoch, 3. August 2011 11:58
  • Dieses Konzept hätte auch Auswirkungen auf den Aufruf von Programmen in Batch-Scripts. Hier ist es dann aber nicht akzeptabel, beim Programmaufruf die oben eingeführte ID als Zahlenkombination anzugeben. Schließlich soll der Source ja immer noch lesbar sein. Um dieses Problem zu lösen, könnte man sagen, daß IDs in der Programmierung immer durch einen Pfad angegeben werden. Hier einige Beispiele:

     

    • EVENTID.de.uni-bremen.studenten.student1.class1.id1(warning)
      EVENTID
      identifiziert die ID als eine EVENTID. 
      de
      steht dann für Deutschland und ist einfach die Länderkennung, wie sie auch im Internet verwendet wird.
      uni-bremen
      bezeichnet die CompanyID/OrganizationID
      studenten
        bezeichnet die ProductID
      student1
      bezeichnet die Modul1 und ist in der UNI dann eben anders gefüllt als in einer Firma.
      class1
      und id1 sind dann Begriffe, die vom Studenten vergeben werden.
      warning sagt dann, daß dieses EVENT eine Warnung ist. 
    • MODULEID.de.uni-bremen.studenten.student1
    • MODULEID.de.uni-bremen.Project1.Module1
    • STRINGID.us.Microsoft.Windows.Module1.Class1.ID1

    Wenn die Integration dieses Konzepts besser in eine Programmiersprache integriert werden soll, so müßte eine Klasse mit einem solchen Pfad verbunden werden können. Dann braucht innerhalb der Klasse nur noch die letzte ID angegeben werden. Hier ein kleines Beispiel dafür:

    //Projekteinstellung:
    IDPATH=de.uni-bremen.studenten.student1
    //Klasse MyClass
    class MyClass: public BaseClass
    {
      public:
        IDPATH=class1
        EVENTID MyFunc();
    };
    EVENTID MyClass::MyFunc()
    {
      return(id1);
        //Ist dann das selbe wie return(de.uni-bremen.studenten.student1.class1.id1);
    }

    Ein solcher Pfad wird dann je nach Programmiersprache zur Laufzeit (Interpreter) oder zur Compilierungszeit (Compiler) in den entsprechenden Zahlenwert der ID übersetzt. Das heißt dann, daß ein Programmaufruf z.B. wie folgt aussehen würde:

    Execute [MODULEID.]us.Microsoft.Windows.Notepad

    Damit diese Übersetzung möglich ist, müssen diese Namen entweder durch eine H-Datei bekannt gegeben oder im System hinterlegt werden.

    Fortsetzung (max. Artikelgröße erreicht)

    Sonntag, 14. August 2011 11:38