Mobile CodeGeorg Lukas
2003-01-29
georg@op-co.deSeminar "Ubiquitous Computing"
http://ivs.cs.uni-magdeburg.de/EuK/Lehre/Wintersemester0203/SemUbiquComputingWS02.html
GL.pngbg.pngGliederungWozu Mobile Code?Motivation + EinführungParadigmenund Kuchen backen!Mobile Code SystemsSicherheitsaspekteausgewählte ProgrammiersprachenJAVA, bei Zeit auch Telescript und Safe-TclZusammenfassungFragen / DiskussionEinführungWozu Mobile Code?Motivationrasantes Wachstum von Computernetzen (Internet, Firmen-Intranets)trotz Krisenstimmunggünstige Geräte mit NetzanbindungAPs, DSL-Router, SetTop-Boxendrahtlose Netzeschlanke EndsystemeSkalierbarkeit von Client-/Server begrenztKonfigurierbarkeit für unterschiedliche Ansprüche erforderlichRemote-Wartung von N devices vs. Status-Übersicht für DAUKombination bestehender Methoden und ParadigmenCORBA: RPC und OOPFlexibilität nicht hinreichendkein Einfluss auf Ausführungsortmehr Vert. Syst. als MCSBedarf an Plattform- und Architektur-überschreitenden Technologien-> Code MobilityCode Mobility"Code-Mobilität ist die Fähigkeit, die Bindung zwischen
Code-Fragmenten und dem Ort der Ausführung dynamisch zu verändern" - Carzaniga, Picco und VignaCode auf Host, Ausführung auf anderem Hosthöhere Flexibilität im Software-Designeinfachere Administration durch zentrale SpeicherungAnwendungen existieren bereitsälteste davon:PostScript (1984)SQL (1989)...Beschränkungen auf Sprach- und Systemebenespäter MCS-Strukturierung, meist nur Teile implementiertwissenschaftliche Forschung nur wenig ausgeprägtBasis-Terminologie fehlt / ist ungenauunklare / überlagerte Bezeichnungenmobile agentletzter Vortrag: Agenten auf Marktplätzen mit ReputationThread / Code-Fragment / KI: "intelligenter" Agentcode mobility / mobile code / mobile computations / mobile object systems / program mobilityCode-Mobilitäteigene Verwendung: MC=Code CM=eigenschaft MCS=systemePräsentationsziel: objektive analytische Betrachtung des Gebiets-> Abgrenzung VS vs. MCSTypische Verteilte SystemeAbstraktion autonomer Rechner zu einem SystemMigration von Prozessen oder Objektenmeist transparentLoad-BalancingFehlertoleranz...durch RedundanzNetze mit kleinem UmfangHomogenitäthohe Bandbreite(bekannte durchschnittliche Latenzzeiten)geschützte UmgebungMobile Code-Einsatzgebietecode mobility im internet-Umfanginternet != Internet, ausgedehnte Netzeheterogene Hostsunterschiedliche AutoritätenHost-Besitzerunterschiedliche VertrauensebenenVertrauen ggü. Gegenstelle != Vertrauen ggü. MitMunbekannte BandbreitenVerlust der Kommunikation möglichlocation awarenessAbstraktion des Ausführungsortsstarker Einfluss auf Design und ImplementierungCode-Mobilität unter Programmierer-KontrolleMechanismen zum Verschicken und Anfordern von CodeUnterstützung durch Laufzeitumgebungvor Editor, MCS-Auswahl:Software-Design-> Paradigmen-AuswahlParadigmenKonzeptAuswahl von ParadigmenVor- und Nachteile für eigene Anwendung abwägenBetrachtung der SkalierbarkeitBerücksichtigung der InteraktionskostenKomponentencode components (enthalten Know-How für Berechnungen)resource components (repräsentieren Daten oder Geräte)computational components (können Code ausführen)InteraktionenEreignisse zwischen zwei oder mehr KomponentenSitesbeherbergen Komponentenunterstützen Ausführung von computational componentsintuitiver Begriff für Ausführungsortsite-lokale Interaktionen "günstiger" als zwischen sitesAusführung erfordert Anwesenheit auf einer Site:Code-Komponente mit dem Know-Howalle benötigten Ressourcen-Komponentenzuständige Rechenkomponente--> Vorstellung typischer ParadigmenA und B sind computational componentsA braucht Ergebnis einer BerechnungAlice und Bob / comutational comp.Rezept=Code, Herd, Zutaten=RessourcenClient-Server / Code on DemandClient-Server (CS)keine Code-Mobility, aber verbreitet und bekanntAlice möchte Kuchen, Bob hat Rezept, Zutaten und HerdClient A benötigt Ergebnis einer BerechnungServer B besitzt Code und RessourcenA fordert bei B Ergebnis anB führt Berechnung ausB liefert Ergebnis an A zurückServer-Schnittstelle statischEngpässe beim Server möglichCode On Demand (COD)Alice hat Zutaten und Herd, Bob hat RezeptA hat Ressourcen- und Rechen-Komponente, B den CodeA fordert von B den Code anB schickt Code zu AA führt Code aus und erhält das Ergebniszentrale Speicherung von Codeeinfache WartungRemote Evaluation / Mobile AgentRemote Evaluation (REV)Alice hat Rezept, Bob hat Zutaten und HerdA hat Code-Komponente, Ressourcen befinden sich bei BA schickt Code zu BB führt Code ausB liefert Ergebnis an A zurückangelehnt an Client-Serverflexiblere Verarbeitung der Daten möglichhöhere Belastung für BMobile Agent (MA)Alice hat Rezept und Teil d. Zutaten, Bob hat HerdA hat Code-Komponente, benötigt aber eine Ressource von BRessource kann nicht zu A transportiert werdenkommt der Berg nicht zum Prophet...A bewegt sich mit benötigten eigenen Komponenten zu BA führt bei B den eigenen Code aus und benutzt B's Komponente"fire and forget"-Strategieeffizientere Bandbreitennutzunggute Technologie nicht hinreichend für gutes DesignVerbindung zwischen Technologie und Designalle Sprachen benutzbarstarke Mobility in C -> eigener Interpreter, Sicherung und Übertragung des ZustandsMobile-Code-SystemeMCS-Grundlagen"Mobile Code-Systeme sind Sprachen und Umgebungen, die Mechanismen zum Unterstützen von Code-Mobilität anbieten"CE: Computational Environment"Rechenumgebung"Plattform für EUs und Ressourcenbildet locationCode muss Ausführungsort kennen (location awareness)Abstraktion von Netzwerkprotokollen, MigrationsmechanismenEU: Executing UnitProzess oder Threadläuft in einem CEZusammensetzung:code segmentdata space (Ressourcen-Referenzen)lokale Variablen, Referenzenexecution state (Kontrolldaten, Stack, ...)VM-Daten über ProzessRessourcenElemente, die von mehreren EUs gemeinsam verwendet werden könnenDateien, Peripherie-Gerätealles was shared werden mussBestandteil eines CEsnicht zwingend auf selbem CEZusammenhang zwischen CEs, EUs und RessourcenCE_EU.pngSchichten: CE auf OS auf HostExecution Units und Ressourcen auf CERes.-Referenzen (grün) über CE-Grenzen hinwegRes.-SharingCode-Mobility-Mechanismenmobile_code1.pngGliederungskriterien für MCSsUnterstützung für welche der Mechanismen?schwache Mobilität: Übertragung von CodeVersenden / Empfangen: aktive Seite verschickt/führt ausstandalone: ganze ProgrammeFragmente: Objekte/Befehlsfolgenstarke Mobilität: Migration laufender ProzesseMigration / Clonenproaktiv: selbst bewegen; reaktiv: bewegt werdenBindungen nach Migration ungültigRessourcen-Management erforderlich-> Ressourcen-ManagementRessourcen-ManagementAufgabe: Ressourcen-Verfügbarkeit nach MigrationSystem muss entscheiden, abhängig von:Anwendungsseitige Ressourcen-Bindungüber Typ (durch gleichwertige Ressource ersetzbar)durch beliebige Ressource gleichen Typs ersetzbarsinnvoll für Ressourcen, die auf jedem CE vorhanden sindlokale Konfiguration, Temporärspeicherüber Wert (durch identische Ressource ersetzbar)bei Migration durch Ressource mit gleichem Wert und Typ ersetzbarDuplikation anwendbarProgramm-Konfigurationüber Namen (Ressource eindeutig bestimmt)eindeutig bestimmte Ressourcebei Migration nicht durch gleichwertige Ressource ersetzbarDatei, Nutzer-InterfaceRessourcen mit eingeschränkter "Bewegungsfreiheit"transferrable / not transferrabletechn. Möglich (Datei vs. Drucker)transferrable: free / fixedfixed = nicht sinnvoll / wünschenswert (vertraulich?)daraus resultierend:Verfahrensweisen bei Migration:verwerfenwiederherstellen (als Netzwerkbindung)Re-Bindingmit Res. gleichen Typsduplizieren / verschiebenRessourcen zusammen mit Code bewegenArt von Ressourcen und Bindungen oft durch Sprache / Implementierung begrenzt oder vorgegebenKlassifizierung von MCS danach-> bei Auswahl auch zu beachten: SicherheitSicherheit von Mobile CodeSicherheitsanforderungen an MCSsMobile Code nicht immer aus zuverlässigen QuellenEinschränkbarkeit der AusführungsafetyBugs in Anwendungen dürfen unabhängige Software nicht beeinflussenBetriebssystemebeneEinschränkungen durch Programmiersprache und ObjektcodeLaufzeitüberprüfung (z.b. Array-Grenzen)securitySicherheit gegenüber Mißbrauchsafety notwendig, aber nicht hinreichendvier Eigenschaften nach Russel und Gangemi:VertraulichkeitIntegritätVerfügbarkeitAuthentizitätSchichten der Sicherheit 1Sicherheit betrifft alle Schichten eines Systemsentwickler-aufwand vs. cracker-aufwandKommunikationVernetzte Rechnersafety: robustes Protokoll, sicher gegen Fehlersecurity:Datenverbindungen über nicht vertrauenswürdige HostsAbhören / Manipulation möglichBenutzung kryptographischer Protokolle (SSL, IPSec)Verfügbarkeit kann selten garantiert werdenBetriebssystem-EbeneHardware-SpeicherschutzIsolation unterschiedlicher Prozesse voneinanderSystemaufrufe als einziges Interfacestark Plattform-abhängigfür unterschiedliche Sprachen nutzbarauf embedded systems/PDAs evtl. nicht verfügbarSchichten der Sicherheit 2abstrakte MaschineErsatz für Hardware-Speicherschutzunabhängig von Betriebssystem/HardwareVerwendung von Interpreter / Zwischencodeerhöhter VerarbeitungsaufwandProgrammierspracheFestlegung auf eine sichere SpracheVerlust der SprachunabhängigkeitEinschränkung der an Zeigern möglichen Operationenautomatisches Speichermanagementmemory-leaks, zugriff auf free()d, double-free-exploitsCode-Überprüfung zur Compile-ZeitManipulation im Nachhinein möglichkryptographische Signaturen zur AbsicherungCompiler-signiert? -> manipuliere CompilerProgrammierer-signiert? -> VertrauenBenutzung von sicherem Zwischencodezwischencode darf nicht mehr als sourcenach MCS und Sicherheit: -> Sprachbeispiele, JAVAProgrammiersprachenJAVAklassenbasierte objektorientierte Spracheseit 1995 von Sun Microsystems entwickeltEinsatz von Zwischencode (Bytecode)Interpretation durch CE (JVM)class loader: dynamisches Laden und Linken von Klassenautomatisches oder explizites Ladenautomatisch = nicht im Namespaceexplizit = Programmanforderungkeine Unterstützung für starke Code-MobilitätManagement verteilter Ressourcen nicht erforderlichIntegration in Webseiten: Empfang von Code-Fragmenten (Klassen)krups.jpgJavaOS - Betriebssystem in JAVAJavaStation - s. Abbildungwenig effizient(J)VM-Einsatz in embedded systemsJAVA 2safety:keine unsicheren Sprachelemente (Zeigerarithmetik, uneingeschränkte Typumwandlungen)Integration von ExceptionsKlassen-Verwendung kontrollierbar (abstract, final)Sichtbarkeit von Attributen (private, default, protected, public)Bytecode-Überprüfung durch die JVM beim Ladenautomatisches Speichermanagementrange checks zur LaufzeitArrays, Stringssecurity:Durchsetzung auf Sprachebene und durch JVMSecurityManager zwischen Applets und lokalem Systemclass loader verbietet Ableitung systemkritischer Klassenu.a. java.* und sun.*Sicherheitssystem auf Applets ausgelegtUnterschied zwischen lokalen und über Netz bezogenen KlassenUnterstützung signierter Bytecode-Archive--> Telescript + Safe-Tcl oder --> ZusammenfassungTelescriptklassenbasierte objektorientierte SpracheEntwickelt 1996 von General Magicspezialisiert auf KommunikationZiel: realisierung virtueller Marktplätzestarke code mobilityportable Zwischensprache Low Telescriptverwendete Konstrukte:agent: EU mit starker Code-Mobilityplace: verschachtelbare EU, "Aufenthaltsort" für agentsengine: CE, assoziiert mit einem EnginePlaceTeleSphere: Netz aus allen Telescript-enginesMigration bzw. Clonen von agents mit go / sendTelescript 2Ressourcennutzung immer einem User zugeordnetagent-Funktion nicht von Besitzer-Präsenz abhängigsafety:transparente Sicherung der Objekte durch enginesagents werden durch permits beschränkt:age, extent, prioritysecurity:Einsatz von tickets für agent-Migrationengine kann ankommende agents ablehnenFesthalten der agents durch ein place nicht möglichagent kann nur mit seiner engine und darüber mit anderen lokal präsenten agents kommunizierenSafe-Tclbasiert auf Tclprozedurale Script-SpracheZiele: einfach, portabel, mächtigEffizienz nebensächlichkeine eigene Code-MobilityEinsatzgebiet: aktive E-Mail, WebseitenMIME-Erweiterung, Ausführung des Inhalts:delivery-timereceipt-timeactivation-time(bei Webseiten unmittelbar nacheinander)Safe-Tcl 2safety:alle Variablen haben den Typ Stringkeine Zeigernur zwei Gültigkeitsbereiche: lokal/globalsecurity:Safe-Tcl Untermenge der Tcl-Befehlekeine unsicheren FunktionenErsatz zu generischer Fkt. durch spezielle--> ZusammenfassungZusammenfassungBedarf an Code MobilityÜberblick über Paradigmenund KuchenAnalyse von Mobile Code SystemsAspekte der Sicherheitsafety und security auf allen SchichtenBeispielanalyseHerangehensweise bei Entwicklung mobiler Applikationen:DesignBewertung und Auswahl von Programmiersprachenabhängig von Bedarf, SicherheitskriterienUmsetzung...fertig ;-)...das warsaufschlussreich und interessant?QuellenA. Fugetta, G.P. Picco, G. Vigna, "Understanding Code Mobility", IEEE Transactions on Software Engineering, Vol. 24, No. 5, Mai 1998, S. 342ff.T. Thorn, "Programming Languages for Mobile Code", ACM Computing Surveys, Vol. 29, No. 3, Sept. 1997, S. 213ff.D. Russell, G.T. Gangemi Sr., "Computer Security Basics", 1991, O'Reilly & Associates Inc., Sebastopol, CA.A. Carzaniga, G.P. Picco, G. Vigna, "Designing Distributed Applications with Mobile Code Paradigms", Proc. 19th Conf. Software Eng. (ICSE'97), R. Taylor, ed., ACM Press 1997, S. 22-32Präsentation (incl.
Source): http://op-co.de/mobilecode/Fragen?