programming languages for mobile code

Programming Languages for Mobile CodeTOMMY THORN

Inria/Irisa

Sun’s announcement of the programming language Java more than anythingpopularized the notion of mobile code, that is, programs traveling on aheterogeneous network and automatically executing upon arrival at thedestination. We describe several classes of mobile code and extract their commoncharacteristics, where security proves to be one of the major concerns. With thesecharacteristics as reference points, we examine six representative languagesproposed for mobile code. The conclusion of this study leads to ourrecommendations for future work, illustrated by examples of ongoing research.

Categories and Subject Descriptors: A.1 [General Literature]: Introduction andSurvey; D.3.2 [Programming Languages]: Language Classifications—object-oriented languages; C.2.4 [Computer-Communication Networks]: DistributedSystems—distributed applications; D.4.6 [Operating Systems]: Security andProtection—access controls

General Terms: Languages, Security

Additional Key Words and Phrases: Distribution, formal methods, Java, Limbo,mobile code, network programming, Objective Caml, Obliq, object orientation,portability, Safe-Tcl, safety, security, Telescript

1. WHY MOBILE CODE?

The expression “mobile code” has vari-ous different meanings in the literature.Just to take three examples, let us citethe following.

—The term mobile code describes anyprogram that can be shipped un-changed to a heterogeneous collectionof processors and executed with iden-tical semantics on each processor[Adl-Tabatabai et al. 1996].

—Mobile code is an approach where pro-grams are considered as documents,and should therefore be accessible,transmitted, and displayed (i.e., eval-

uated) as any other document [Rouaix1996].

—Mobile agents are code-containing ob-jects that may be transmitted be-tween communicating participants ina distributed system [Knabe 1996].

In this survey we refer to mobile codeas software that travels on a heteroge-neous network, crossing protection do-mains, and automatically executed uponarrival at the destination. Protectiondomains can be as big as a corporatenetwork and as small as a personalhand-held digital assistant. We believethat this characterization is generalenough to encompass most usages and

This work was performed under the auspices of Dyade (an R&D joint venture between Bull and Inria).Author’s address: T. Thorn, Inria/Irisa, Campus de Beaulieu, 35042 Rennes Cedex, France; email:^[email protected]&.Permission to make digital / hard copy of part or all of this work for personal or classroom use is grantedwithout fee provided that the copies are not made or distributed for profit or commercial advantage, thecopyright notice, the title of the publication, and its date appear, and notice is given that copying is bypermission of the ACM, Inc. To copy otherwise, to republish, to post on servers, or to redistribute tolists, requires prior specific permission and / or a fee.© 1997 ACM 0360-0300/97/0300–0213 $03.50

ACM Computing Surveys, Vol. 29, No. 3, September 1997

precise enough to exhibit the distinctivefeatures of this technique. For example,it excludes the cases where code isloaded from a shared disk or down-loaded (manually) from the Web.

Mobile code supports a flexible formof distributed systems where the desirednonlocal computations need not be knownin advance at the execution site. The ad-vantages of this model are many, includ-ing:

—Efficiency. When repeated interac-tions with a remote site are needed, itcan be more effective to send the com-putation to the remote site and tointeract locally. This is especially thecase when the latency of the networkis high and the interactions consist ofmany small messages.

—Simplicity and flexibility. The main-tenance of a network can be muchsimpler when the applications are lo-cated on a server and clients them-selves install them on their sites ondemand. Installing new or updatedsoftware becomes independent of thenature and number of clients. In somecases, it is even impossible to know inadvance all the pieces of code thatwill be needed at a given site.

—Storage. Loading code on demandrather than having all programs du-plicated on all sites can significantlyreduce the total storage requirement.

We start with a short review of someof the most well-known examples of ap-plications using mobile code.

—PostScripty is a page-description lan-guage designed by Adobe Systems.PostScript is remarkable in that it isalso a stack-based programming lan-guage and is associated with a largestandard library suitable for pagerendering. Printing on a PostScriptprinter consists of composing a pro-gram describing the pages to beprinted and sending this program tothe printer. The printer then executesthis program and prints pages as a

side effect. This example is a goodillustration of some of the benefitsthat motivate mobile code: the algo-rithmic description of a complex im-age can be made very compact andgeneral, independent of printer spe-cifics such as resolution and numberof available colors. Also, PostScriptprinters off-load some of the workburden from the printing host. Thiscompactness, expressiveness, and de-vice independence have made Post-Script a de facto standard today.

—Database technology is another areawhere a form of mobile code has longbeen used advantageously. The size ofa typical database makes it infeasibleto transmit it in entirety to a client;thus any database operation must becommunicated to and performed bythe database server. Today, mostcommercial databases support theANSI standard query language SQLfor database access. SQL offers a com-pact notation for expressing complexoperations on multiple database rela-tions.

—Documents with embedded executablecontents transmitted on the networkare another kind of mobile code. Mul-timedia documents in the AndrewSystem [Hansen 1990] can include ex-ecutable scripts written in an object-oriented script language. These en-riched documents can be sent aselectronic mail or posted as news arti-cles. The scripts are executed underuser control and can present interac-tive dialogues and use graphical facil-ities. A similar extension for the In-ternet multimedia standard MIMEhas been proposed. This extension en-ables the use of embedded executablecontent written in Safe-Tcl [Boren-stein 1994], a restricted variant of thescript language Tcl.The usefulness of mobile code has alsobeen realized for the World WideWeb. One of the problems with theWeb is that interactive pages are im-practical in general due to networklatencies. Even when latencies are

y PostScript is a registered trademark of AdobeSystems Incorporated.

214 • Tommy Thorn


not a problem, the content and ap-pearance of Web pages are con-strained by what is expressible withthe HTML language. Allowing embed-ded executable contents removes theconstraints of HTML and network la-tency. Among the many existing pro-posals, the most well known is proba-bly Java by Sun Microsystems.

—Finally, a fourth class of applicationsof mobile code addresses the problemof software distribution and installa-tion, traditionally known to be costlyand difficult. Lucent Technologies hasdeveloped Inferno [Lucent 1996], amobile-code-enabled network operat-ing system aimed mostly at mediaproviders and telecommunicationcompanies. Customer’s decoder-boxesor portable telephones running In-ferno can be extended dynamicallywith software in response to their re-quests. In the same spirit, but in adifferent context, Sun has proposedthe use of Java-capable network com-puters to replace workstations in cor-porate networks. The benefit here isthe low cost of maintaining an Intra-net (a local network using Internettechnologies) of network computersthat download all applications on de-mand from an application server.

It should be noted that there are sub-tle differences in the usage of mobilecode in the preceding four applications;in the PostScript and the database mod-els, it is the sender of mobile code thattakes the initiative of the communica-tion, whereas in the Java and Lucentmodels, the execution site takes the ini-tiative to load the mobile code. We comeback to this distinction when we presentprogramming languages for mobilecode.

In this survey we first identify thespecial concerns for mobile code andtheir impact on programming lan-guages. In Section 3 we focus on the twomost important issues: safety and secu-rity. With this background, we examine,in Section 4, six representative lan-guages that have been proposed for mo-

bile code. Section 5 draws the lessons ofthis study and compares the languagesstudied. We conclude the article by giv-ing our perspective on the current stateof mobile code programming languagesand point out directions for future re-search.

2. PROGRAMMING LANGUAGECONCERNS

From the application classes of mobilecode listed in the introduction, we canextract a number of common needs interms of programming languages.

—The need for portability. Inherent inthe idea of mobile code is the notion ofheterogeneous execution sites. It isnot possible to have a specific versionof the code for every possible architec-ture, thus the need for portability.The portability issue also has an im-pact on the kind of services the appli-cation can expect from the executinghost, for example, trying to write to afile might not be meaningful on ahand-held telephone.

—The need for safety. We use the word“safety” here in the sense that a bugin a safe application should not affectthe execution of other independentparts of the environment. Limited as-sumptions can be made on code im-ported from an unknown source,which means that it cannot be trusteda priori to be safe, and special protec-tion must be provided. Notice thatthis definition addresses the safetyfrom an operating system point ofview. Safety can also be imposed byappropriate restrictions at the pro-gramming-language level. For exam-ple, free access to memory can beeliminated through a disciplinedpointer model and systematic check-ing of the bounds for array accesses.

—The need for security. As the mobilecode crosses protection domains, spe-cial care must be taken to protectagainst security threats presented bymobile applications. The boundary be-tween safety and security concerns is

Languages for Mobile Code • 215


not always clearcut. Safety is mostlyconcerned with the behavior of sys-tems in the presence of bugs, but as alack of safety can be exploited forsecurity breaches, safety becomes anecessary (but not sufficient) prereq-uisite for security.We distinguish between four securityproperties [Russell and Gangemi1991].

Confidentiality, also known as secrecy:it concerns the absence of leakage ofprivate information (which often oc-curs through a covert channel, i.e., achannel that is not explicitly intendedfor communication).

Integrity, also known as accuracy: pri-vate data should not be modifiable byunauthorized parties.

Availability, the negation of which isdenial of service: the attacker deniesnormal use of shared resources, forexample, by overloading them.

Authenticity guarantees that the iden-tity of a communication partner canbe trusted.

—The need for efficiency. Efficiency isalmost always an issue for program-ming languages and their implemen-tations. The special need here is for aminimal overhead for the measurestaken to ensure portability, safety,and security.

Portability and efficiency are issuesthat have been studied in the program-ming language community for quite along while. The safety and security is-sues are well known in the context ofoperating systems, but safety and, espe-cially, security are issues that have notreceived enough attention so far in thearea of programming languages. Secu-rity and safety problems take a newdimension in the context of mobile code.For this reason, we focus on these is-sues in the next section.

3. SAFETY AND SECURITY ISSUES

Safety and security concern many as-pects of a system. We distinguish four

levels at which to address these issues:the communication level, the operating-system level, the abstract-machinelevel, and the programming-languagelevel.

3.1 The Communication Level

In a top-level view of a computer sys-tem, we consider a collection of comput-ers connected with some networkingtechnology. Safety concerns here re-quire a robust protocol implementationthat can withstand a faulty or maliciouscommunication partner.

For networks like the Internet, wheredata can pass through untrusted inter-mediate hosts, the communication itselfcannot be assumed to be secret or au-thentic. Therefore secure protocolsbased on cryptographic techniques areemployed to guarantee confidentiality,integrity, and authentication, even onsuch networks. This is included in thenew Internet protocol, IPv6 [Huitema1996], but many proposals are also lay-ered on the top of existing protocols.Secure HTTP [Rescorla and Schiffman1996] and the Secure Socket Layer[Freier et al. 1996] are two examples.Availability is also an issue, but dealingwith it is very difficult. This difficulty isillustrated by the many denial of serviceattacks on the Internet (see, e.g., Fox[1996]).

3.2 The Operating-System Level

Safety and security at the communica-tion level is not sufficient in general.Handling safety and security is also aprimary concern at the operating-sys-tem level.

Safety is generally ensured throughthe use of hardware memory protection.This isolates a process from the rest ofthe system, leaving operating-systemcalls as the only accessible interface. Asno assumptions need to be made on thenature of the process, this leaves a greatdegree of freedom to the implementa-tion, for example, to choose any pro-gramming language available. For mo-

216 • Tommy Thorn


bile code, it has the problem of beingvery dependent on the operating systemand the hardware, and thus not porta-ble. Even when using memory protec-tion is possible, it may not always bedesirable.

—Memory protection means that allcommunications have to cross a pro-tection boundary, for example, usinga system call mechanism, and thiscan be expensive.

—Many smaller systems, for example,personal digital assistants (PDAs), donot have the hardware needed.

—Requiring the use of memory protec-tion makes embedding the mobilecode environment in another applica-tion much more complicated and oftenimpossible.

Confidentiality and integrity can beachieved by controlling processes’ accessto information and communicationchannels. Complete control of covertchannels is very hard and rarely at-tempted in nonclassified systems. Aform of availability can be attained byusing limits on resources, such as diskspace, number of processes, and mem-ory usage, and using preemptive sched-uling and timeout in locks. Authentica-tion is usually established through aninitial identification of the user (e.g.,using a password scheme) and main-tained by data structures of the operat-ing system, protected from tamperingfrom user-level processes.

3.3 The Abstract-Machine Level

The safety guarantees obtained throughthe use of hardware memory protectioncan also be realized using an abstractmachine. Using a language-independentabstract machine retains all the lan-guage independence of the operatingsystem solution, but does not have theportability problems. In the simplestversion, the protection boundaries areenforced by an interpreter, performingall the needed checks at run-time.

In the Omniware model [Adl-Taba-

tabai et al. 1996] the overhead of inter-pretation is eliminated through soft-ware fault isolation (SFI). Code for theOmniware abstract machine is trans-lated almost directly into native ma-chine code, but all memory accesses aretranslated to code that checks for ac-cesses outside a given boundary.

The self-certified code (SCC) [Neculaand Lee 1996] technique goes even fur-ther and eliminates the overhead of theprotection as well. Self-certified code isthe pair of machine object code and ma-chine-checkable formal proof. The proofdemonstrates that the object code re-spects the execution site’s published(low-level) safety policy. This policycomprises a set of proof-formation rules,along with a set of preconditions. Thecorrectness proof can easily be verifiedautomatically and ensures that the coderespects the (low-level) safety and cantherefore run without run-time checks.

3.4 The Programming-Language Level

Another way to obtain the requiredsafety is to sacrifice the language inde-pendence and use programs written in asafe programming language. Most mod-ern programming languages guaranteeagainst low-level errors through mecha-nisms such as typing, restricted point-ers,1 automatic memory management,and array bounds checking. It is possi-ble to go even further and use the lan-guage scope and access rules to protectthe interface of resources. The gain hereis that the security implementation,such as resource management and con-trol, can be written in the source lan-guage and used as a library.

As an optimization, the high-levelprogram can be compiled and type-checked before being shipped as mobilecode. The question then arises as to howto make sure that the object code isreally a nontampered output of a correct

1 Restricted pointers are like references knownfrom, for example, Standard ML. The only validoperations on a pointer variable are dereferencingand assignment.



compiler. Three techniques have beenproposed.

—Using cryptographic signatures to re-duce the problem to one of trustingthe author. As we already trust majorsoftware producers enough to runtheir applications, this can be seen asa continuation of current practice.

—Using cryptographic signatures totrust compilers. The idea is to shipthe source to one of a small number oftrusted compilation sites for compila-tion and certification.

—Compiling to an intermediate lan-guage that can be (type) checked toverify the same constraints as are im-posed on the source language. Thesuccess of this approach depends onthe intermediate language being suit-able for efficient verification and per-mitting an efficient abstract machine.

These techniques are not exclusive.For example, combining the first twoseems easily feasible as they requiremuch of the same technology and infra-structure. Likewise, the abstract ma-chine can include operating-system as-pects and can be more or less language-dependent. For instance, depending onthe context, we can consider the systemlibraries either as part of the abstractmachine or as part of the language. Thelanguages examined in the following alluse combinations of these levels, al-though this is generally not made ex-plicit.

4. PROGRAMMING LANGUAGES FORMOBILE CODE

We focus here on a list of representativelanguages for mobile code. Space consid-erations prevent us from presenting allthe relevant languages. Among theother programming languages for mo-bile code, let us mention JavaScript[Netscape 1997] and VisualBasic. Theinterested reader is referred to the bib-liography for a more extensive overviewof the field.

The first four languages studied,

Java, Limbo, Objective Caml, and Obliq,are general-purpose languages, in-tended for general application develop-ment. The last two, Safe-Tcl and Tele-script, are special-purpose languages.We expect Java to be the best knownlanguage amongst these, and thereforegive it a more detailed treatment anduse it as the reference point for theother languages.

4.1 Java

Java is a class-based object-orientedlanguage created by Sun Microsystems,with an emphasis on portability andsecurity [Arnold and Gosling 1996; Gos-ling et al. 1996]. As an example of howto use Java for mobile code, JavaSofthas created the applet model. Appletsare small applications that are auto-matically downloaded and executedupon visiting a Web page containingthem.

The Language

For clarity, we distinguish three levelsin the presentation of Java: the lan-guage level, the abstract-machine level,and the library level.

Language level. The language isbased on a simplified variant of C11with all unsafe and most complicatedlanguage features removed. The fea-tures that have been removed includeunsafe operations such as pointer arith-metic, unrestricted casts, unions, andfeatures leading to unmaintainable pro-grams such as the C preprocessor, un-structured gotos, operator overloading,and multiple inheritance. Automaticmemory management has been added,guaranteeing against pointer errors dueto manual memory management andmaking usage of dynamic memory muchsimpler. Array and string types arebuilt in with range check of all accesses.Exception handling has also beenadded, favoring the creation of robustprograms. Finally, for concurrency,Java provides threads and serialized

218 • Tommy Thorn


methods, using a mutex-locking on thecorresponding object.

Java includes a novel notion of inter-face types. Interfaces define a collectionof abstract methods and constants withtheir associated types. A class can bedeclared to implement an interface, inwhich case it must implement all theabstract methods of the interface. Any-where a value of an interface type isexpected, a value of a class implement-ing this interface can be used. Inter-faces are useful for a number of pur-poses: they can be used to hide theimplementation of a class and to groupclasses with common functionality with-out forcing them into a class hierarchy.

Java also uses a notion of package. Apackage groups a number of class andinterface definitions. Unlike most mod-ule systems, Java packages are open-ended and can be extended with defini-tions not envisioned by their originalcreator.

The default visibility of class and at-tribute definitions can be changed witha visibility modifier keyword. A classcan be declared final, preventing deri-vation of subclasses of itself, abstract,preventing creation of instances, andprivate, limiting the scope of the classdeclaration to the containing package.Attributes have four (ordered) levels ofvisibility: private, default, protected,and public. Private attributes are onlyvisible from within the object itself, thatis, not in objects of a subclass or otherobjects of the same class. The defaultvisibility extends visibility of the at-tribute to the package in which it isdefined. Protected attributes further ex-tend the visibility to subclasses of thedefining class, potentially defined in an-other package. Finally, public attributesare visible everywhere.

Abstract machine level. The JavaVirtual Machine (JVM) is a language-dependent abstract machine that isclose enough to Java that its object codecan be checked to respect the languagesemantics. In addition to these static(load-time) verifications, the JVM must

implement dynamic checks to guaranteethe safety of the language. These arebounds checking on array and stringaccesses, checking casts to a more spe-cific type, invoking methods on nullpointers, and the like.

Library level. Complementing thelanguage, a library provides general-purpose data structures, support forgraphical user interfaces, and access tonetwork communication. Applicationswritten using these libraries run un-changed on a wide range of platforms,including Unix, Windows, and Macin-tosh.

Security

The Java language, as described, is amodern “safe” language, guaranteeingthat type and access rules are alwaysrespected. This in turn enables a low-level security policy to be expressedwithin the language itself. The visibilityrules for classes and attributes play acrucial role in this respect. Indeed, theinterface to local resources is providedby libraries, protected by the scope andvisibility rules. Most resources requir-ing dynamic access control, such as thefile system or access to the network, arecontrolled by a centralized securitymonitor, called the SecurityManager.The SecurityManager has an abstracttype that cannot be instantiated by anapplet. All security-related methods aredeclared final, so that applications andapplets are forced to use the appropri-ate code. Without this protection, mali-cious applets could redefine the methodin a subclass, potentially circumventingthe security invariants. A final classenjoys even stronger protection, in thatthe inability to create subclasses alsoimplies the inability to define newmethods with access to protected at-tributes.

Linking

The loading of classes over the networkis done by an object of the class Class-Loader. This object is created during



startup and cannot be replaced by ap-plets afterwards (it is part of the Secu-rityManager state). As attributes with adefault or protected visibility are fullyaccessible within the package of theirdefinition, these two visibilities wouldbe of little use if applets could introduceclasses freely in any package and thusavoid the intended protection. To pre-vent this, the ClassLoader protects afixed set of packages from being ex-tended by applets. The exact set is notspecified, but includes java and sun. TheClassLoader also maintains a uniquename space for each network source,separate from the name space forclasses coming from the local file sys-tem. Network sources are currently dis-tinguished based only on their symbolicaddress.

Classes can be loaded from the localfile system if they are present in a direc-tory specified in the CLASSPATH vari-able. This variable is part of the Javaenvironment configuration and can bechanged by the user before launchingthe network browser or Java client, butcannot be accessed or modified by anapplet.

As class files loaded through the net-work cannot be trusted to be untam-pered with and the abstract machineruns with few type checks, the bytecodeis passed through a bytecode verifierthat checks that the object code respectsthe Java semantics: it ensures that thebytecode is in a valid format, that point-ers are not forged, that access rules areenforced, that the operand stack is usedconsistently with respect to the types,and that the parameters passed havethe expected types.

Applications

There is no single well-identified appli-cation area for the language: any dis-tributed and portable application cantake advantage of Java. Sun and Oracleemphasize Java’s capabilities as a gen-eral-purpose language for corporate In-tranets of disk-less network computers.Most commonly encountered applets are

animations, games, demonstrations,and interactive multimedia educationalprograms; but major software houseshave already demonstrated complete of-fice application suites written as ap-plets.

Moving beyond applets, let us men-tion some of the more substantial offer-ings (some are currently under develop-ment) [JavaSoft 1996]:

—JavaOS, a complete operating systemwritten in Java, offering portabilityand extensibility;

—Jeeves, a framework for extendiblenetwork servers;

—Java Management API, a frameworkfor management of heterogeneousnetworks;

—Java Electronic Commerce Frame-work, a software point-of-sale termi-nal accessible by any Java-enabledbrowser;

—Java Beans, a component architecturefor reusable software components;

—Java Database Access API, a uniforminterface to relational databases; and

—Java RMI, an API for implementingremote method invocation. This willease the creation of client-server ap-plications and permit the creation ofmore traditional distributed systems.

Reflections

Java is a promising language with atremendous market acceptance. Much ofthis popularity stems from its uniquecombination of characteristics: close toC11, safe, portable, and concurrent, aswell as supplying a rich base library.

Since the first presention of Java, anumber of “safety” bugs have been dis-covered [Dean et al. 1996]. It is of con-cern that many of the sources of thebugs can be attributed to the vaguenature of the definition of Java. Al-though the core language seems simple,many details are in fact quite subtle.

For example, in Java the integrity ofthe security depends upon applets notbeing able to instantiate subclasses of

220 • Tommy Thorn


critical classes, like ClassLoader. Thiscondition is checked at run-time by theconstructor (a special method devoted toinitializing the object upon construc-tion), which throws an exception in caseof violation. If the applet can catch thisexception within the constructor, it hassucceeded the instantiation, althoughthe object will only be partially initial-ized. The subtle restriction imposed onthe constructor to avoid these situationswas checked by the compiler, but notenforced by the bytecode verifier in anearly version of Java [Dean et al. 1996].

Java’s current security implementa-tion can only be seen as a first step, asit has a number of shortcomings. Forexample, as noted in Billon [1996], itcurrently does not scale beyond simpleapplets. Many of the prospective appli-cations for Java, such as the ones men-tioned in the following, require addi-tional local libraries. Unfortunately,there is currently no way to protectuser-defined libraries from redefinitionsand extensions from applets. Only thesystem-defined fixed set of packages isprotected. The fact that packages inJava are always extensible makes itimpossible to guarantee the security ofa package based on its source alone; thesemantics of the ClassLoader must betaken into account as well. This seemsagainst the spirit of Java’s language-based security, and can be a seriousproblem considering that the Class-Loaders of the major Java applet envi-ronments available today do not haveidentical semantics [Billon 1996].

We strongly believe that a formal ap-proach to security in Java could helpavoid most of these weaknesses andwould result in a much cleaner andcoherent design. Work on formalizingJava is underway, and progress hasbeen made recently on formal studies ofJava’s type system [Drossopoulou andEisenbach 1996].

4.2 Limbo

The technologies of three major indus-tries, entertainment, computing, and

telecommunication, are converging. In-ferno [Lucent Technologies 1996] by Lu-cent Technologies (Bell Labs Innova-tions) is a network operating systemdesigned to suit the constraints andneeds of this environment. Inferno isintended to be flexible enough to beemployed on devices as diverse as intel-ligent telephones, hand-held computers,personal digital assistants, televisionset-top boxes,2 home video game con-soles, and inexpensive network comput-ers. It can also be used on servers suchas Internet servers, financial servers,and video-on-demand servers.

The design of Inferno is based largelyon Plan 9, a network operating system,also from Lucent Technologies, whichemphasizes portability, versatility, andan “economical” implementation. Eco-nomical here refers to the computingresources required; Inferno can runwithin little memory and does not re-quire virtual memory hardware. Porta-bility has two dimensions in Inferno.The operating system itself can run onthe bare hardware, or on top of an exist-ing operating system such as Unix,Windows-NT, or Plan 9. In the lattercase, the services provided by Infernoare interfaced to the native services ofthe underlying operating system. Thesecond dimension is the portability ofInferno applications. Applications arewritten in Limbo, an integral part ofInferno, and are compiled to a binaryformat that is portable between all In-ferno implementations. Inferno providesa unified file system interface to operat-ing system services, which hides thefact that the service can be local orremote.

The Language

As for Java, it is useful to distinguishbetween three levels of Limbo: the lan-guage level, the abstract machine level,and the library level.

2 A set-top box is the consumer receiver and de-coder for the (usually scrambled) television sig-nals distributed typically by satellite or cable.



Language level. Limbo is a “safe” im-perative language. Its main inspirationis C, but it includes in addition declara-tions as in Pascal, abstract data types,first-class modules, first-class channels,automatic memory management, andpreemptive scheduled threads. It ex-cludes pointer arithmetic and casts.

Abstract data types (ADT) declare ob-jects with variable, constant, and func-tion fields. There is no notion of inheri-tance for ADTs and no visibilitydeclaration for ADT members. Recur-sive structures are subject to a few sim-ple syntactic constraints to guaranteethat cyclic data cannot be created (re-cursive fields cannot be assigned).Fields declared cyclic do not suffer fromthis constraint. The reason for this par-ticularity is the way Limbo’s garbagecollection handles cycles (see the follow-ing).

The declaration of a module identifiesthe types of exported functions and con-tains the exported declarations of ADTs,simple type declarations, and constants.In order to use a module, it must beinstantiated by loading an implementa-tion of the module (at run-time). Theloading is done with the built-in func-tion load that takes a module type and apath to the module implementation andreturns the instantiated module (or nullif unsuccessful). This allows the pro-gram to choose among several imple-mentations of a given module at run-time.

The channels of Limbo allow the com-munication of any value of its declaredtype. A channel can be connected di-rectly to another process or, through alibrary call, to a named destination.Channels are the only built-in primi-tives for interprocess communication,but more complicated mechanisms canbe built upon them.

Limbo’s garbage collection is based onreference counting and reclaims thememory of noncyclic data immediately,once the last reference to them disap-pears. Reference counting has the limi-tation that it cannot reclaim cyclic data,

so cyclic data are treated in a specificway and are eventually reclaimed.

Abstract machine level. Limbo pro-grams are compiled to a RISC-like ab-stract machine called Dis, designed forjust-in-time compilation to efficient na-tive code by the Limbo run-time system.Dis does not impose language con-straints; for example, Dis code need notbe type checkable. Lucent claims thatDis is well suited for real microproces-sors and reports excellent performanceof their implementation.

Library level. Limbo provides a richlibrary of standard modules, includingmodules for network communication, se-cure and encrypted communication, andgraphics.

To reflect the different uses of In-ferno, two user interface libraries areavailable. One, based on Tk [Ousterhout1994], is intended for “traditional” win-dow-based user interfaces. The otherprovides ready-made interface compo-nents for typical embedded applications,such as interactive TV. The specializeddesign allows for a minimal memoryrequirement.

Security

Safety in Inferno is achieved through asafe language with restricted pointersand automatic memory management.Pointers can point to any object butcannot point to inside arrays, and thereis no pointer arithmetic or arbitrarypointer type conversion. This safety isnot enforced by the abstract machine,though. Instead, Inferno relies on appli-cations being signed by trusted authori-ties who guarantee their validity andbehavior.

Security management in Inferno isinspired by the Plan 9 operating sys-tems; all resources are accessed as files,including data, network communicationchannels, and the executable modulesthat constitute the applications. All re-sources available to an application ap-pear exclusively in the name space ofthat application. Applications cannot

222 • Tommy Thorn


arbitrarily manipulate this name spacethemselves, but must, for security sen-sitive resources, call the modules thatprovide them.

Linking

The built-in support for dynamic linkingof modules provides type-safe linking atthe user level. Another (type-safe) wayto provide a module is to transmit it ona channel of the appropriate type. Cur-rently, certain data types, such as mod-ules, cannot be exported outside a ma-chine [Pike 1997].

Applications

The application domain for Inferno isfocused towards applications for serviceproviders. In such environments, only afew, usually fixed, sets of authoritiesneed to be trusted, which justifies theuse of cryptographic signatures.

Reflections

Lucent’s use of an operating system ba-sis provides a clear separation of re-sponsibilities among the language, theabstract operating system, and the run-time environment. This separation re-duces the complexity of verifying secu-rity consistency and eases the isolationof security breaches. The module systemof Limbo enables a clean and type-safeway to implement dynamic loading.

4.3 Objective Caml

Objective Caml (O’Caml) [Leroy 1997] isa functional language in the ML tradi-tion, originating from Caml, a languagedeveloped at Inria that is widely used ineducation. O’Caml has been used as alanguage for mobile code in the develop-ment of the MMM [Rouaix 1996b,1996a] Web browser, also developed atInria. MMM adds the possibility of dy-namically linking and executing O’Camlapplets accessed through the Web.MMM provides a number of hooks forthe applets; for example, applets canadd elements to the user menu, include

new content decoders, or change thehandling of link activation. Applets canaccess parts of the browser internals,such as the cache and browser naviga-tion values.

The Language

O’Caml includes imperative features,such as references and assignment, anda class-based object system, all inte-grated within a functional core. Themain characteristics of O’Caml and itsimplementation are:

—Strong, static polymorphic typ-ing. The static typing property en-sures that “well-typed programs can-not go wrong”; that is, they cannotterminate with a type error. All typeerrors are caught during compilation.Primitives’ errors, like division byzero, are not considered type errors,but are handled through the excep-tion mechanism.Polymorphic typing allows types to beparameterized over a number of typevariables. This makes possible a type-safe construction of general functions.For example, a function calculatingthe length of a list is not dependenton the type of the list elements. Withpolymorphic typing, it can be definedonce (with type a list 3 int, where a isa type variable) and then used forevery kind of list.O’Caml offers automatic type recon-struction, as is usual with languagesin the ML family. For documentationand debugging purposes, it is oftenuseful to manually annotate key func-tions with their type.

—A powerful module system. O’Camloffers a rich higher-order module sys-tem in which modules have signa-tures, providing the names and typesof exported elements. O’Caml permitshigher-order modules through the no-tion of functors. A functor can be in-stantiated by applying it to moduleswith the same signatures as its for-mal arguments. The unit for separatecompilation is the file, which implic-



itly defines a module of the samename.

—First-class (higher-order) functions.Functions can be passed to otherfunctions or returned as results. Theycan be anonymous (defined using thelambda notation of lambda calculus),and can refer to variables outsidetheir own definition (free variables).Higher-order functions are at theheart of functional languages, and arethus not specific to O’Caml.

O’Caml includes support for concur-rency through threads and mutexes (al-though applets do not support the use ofthreads) and class-based object orienta-tion through an extension of the typingdiscipline. An object is an instance of astatic class, which can be the specializa-tion of multiple superclasses. In thecase of name classes, only the last entryis visible, but the shadowed name canstill be accessed. This is a simple solu-tion, but it entails an asymmetry inwhich inheriting from A and B is differ-ent from inheriting from B and A.O’Caml supports a small number of vis-ibility modifiers for classes and objectattributes: a class can be declared vir-tual, preventing instances from beingcreated, and closed, preventing sub-classes from being derived. Attributescan be declared private, making theminaccessible outside the methods of thedefining class.

Security

MMM applets are only allowed to usesafe variants of the standard libraries.A safe library imports everything ex-ported from the unsafe original, but itonly re-exports a selected subset. Enti-ties considered to be safe are re-ex-ported directly, but sensitive structuresare exported as abstract data types; fordangerous functions, wrappers are ex-ported that check the capabilities of theapplet (a wrapper for a function is an-other function with the same signaturethat may perform extra computationsbefore and after calling the original).

The capabilities of an applet are repre-sented by an abstract data type withone function to access the encapsulatedcapabilities and another one to ask theuser for extended privileges.

As MMM applets are transmitted inobject form, the question of how to trustthe binary object code arises. UnlikeJava, the object code is not verified be-fore execution, but is instead associatedwith a cryptographic checksum of theinterfaces of the imported modules. Forprotection from unsafe compilers, theMMM designers suggest employingtrusted compilation sites to certify thatthe object code is the result of a correctcompilation.

Linking

O’Caml includes library support for dy-namic linking object files. As there is noway to access the loaded entities, dy-namically loaded modules are responsi-ble themselves for registering the func-tions they export. The dynamic linkingused for applets constrains the use ofthe primitives that are considered dan-gerous.

All applets consist of exactly one (po-tentially big) module, which may con-tain nested modules. As the applets areself-contained and only allowed to use afixed set of development modules, theycannot interfere with one another, thusavoiding the complications of separatename spaces for applets.

Applications

Applications for MMM include browserextensions, decoders for new contentstypes, animations, games, and the like.The advantage of O’Caml is a richerlanguage, with support for several pro-gramming paradigms: functional, im-perative, and object-oriented.

Reflections

In Java, since all standard library func-tions can potentially be called by anapplet, they must all be secured. WithMMM, only functions exported by the

224 • Tommy Thorn


safe libraries need to be checked. Themajor drawback of MMM is the need fortrusted compilation sites.

4.4 Obliq

Obliq [Cardelli 1995] of DEC SystemResearch Center is a lexically scoped,dynamically typed, prototype-based lan-guage, designed for distributed object-oriented computations. Computations inObliq are network-transparent; that is,they depend neither on the allocationsite nor on the computation site, but thedistribution is managed explicitly at thelanguage level.

The Language

To support network transparency, Obliqextends the static scope to the network:free variables of transmitted computa-tions can refer to objects from the originsite. The language has three main char-acteristics.

—Any value can be transmitted be-tween hosts, including closures andobject references. Objects themselvesare local to a site and are not consid-ered as values, but object migrationcan be programmed with a combina-tion of closure transmission, aliasing,and object cloning (see the following).

—Obliq belongs to a class of object-ori-ented languages called prototypebased. In prototype-based languagesthere are no classes, and objects arecreated by copying (cloning) existingobjects (the prototypes). Obliq uses asimple variant of prototyping, calledembedded prototyping, which avoidsall the complications of delegation-based prototyping [Malenfant 1995].In embedded prototyping, all themethods valid on an object are con-tained in the object itself; that is, theyare not searched for in a list of super-classes.

—Obliq is dynamically typed. Type er-rors are caught cleanly and propa-gated to the origin site.

An object in Obliq is a collection ofattributes (named values). A simplepoint object p can be written {x 5. 3,y 5. 4}. There are four basic operationson objects.

Selection/invocation: using the value ofan attribute or invoking a method, forexample, p.x and display.plot(p).

Updating/overriding: changing thevalue or the method bound to an at-tribute, for example, p.x ,2 4 anddisplay.plot ,2 lineto. Notice that it islegal to change a value into a methodand a method into a value.

Cloning: creating a shallow copy of anobject. The immediate values of at-tributes are copied, but structuredvalues introduce sharing. For exam-ple, array elements are shared be-tween the clone and the original ob-ject. Cloning is generalized to supportmixing several objects with disjointnames. Using the given examples,clone(p,display) produces an objectwith at least the attributes x, y, andplot.

Aliasing: mechanism of aliases redirect-ing attributes to attributes in otherobjects. All selections and updates onan aliased field are done on the redi-rection target. For redirected methodinvocation, the “self” object is the ob-ject containing the redirected target,not the object containing the alias. Analias itself can redirect to anotheralias. Objects consisting only ofaliases are called surrogates (alsoknown as proxies in other languages).For examples of aliasing and redirec-tion, consider {x 5. alias x of p1} andredirect p2 to p end. The latter makesall attributes of p2 aliases of the cor-responding attribute of p.

Objects can be protected against modifi-cation, aliasing, and cloning from out-side the object using the protected key-word. Safe interfaces to objects can beconstructed through a combination ofprotection and surrogates.

Concurrency is inherent in Obliq; pro-cesses can execute independently on



distinct servers and processes canspawn new threads locally. To handleconcurrent accesses, Obliq supports se-rializing objects. An object is serializedif at most one thread can access anobject or run one of its methods at anygiven time. This is realized using a mu-tex on the object, which is acquiredwhen one of its methods is invoked andreleased when the method returns. Toavoid trivial deadlocks, operations andmethod calls from within the object it-self are not subject to locking. For de-tails, see Cardelli [1995].

Lexical scoping hides named valuesfrom outside a given block and run-timetyping ensures that these scope rulesare enforced. Extending the lexicalscope to the network makes it possibleto use scope rules to address securityissues, such as information hiding; aprocedure executing on a foreign serverhas only access to its own parametersand free variables. Communications be-tween two independent servers aremeditated by a shared global nameserver, which allows servers to importand export local values. To have a pro-cedure executed on a distant server, thename server is asked for the engineobject accepting procedures. For exam-ple, remote invocation can be pro-grammed as follows (on the client side):

let mydisp 5 net_import(“display”, Namer);mydisp.plot(p);

Here the name server, Namer, is askedfor the value registered with the namedisplay. After this call, mydisp is a refer-ence to the display object, either locallyor on a remote server, and is treatedlike any other object. For example, wecan invoke the method plot with a vari-able p. This example assumes that someprocess has exported display with

net_export(“display”, display)

Object migration can be programmedusing a combination of closure trans-mission, cloning, and surrogates. Thefollowing example is taken fromCardelli [1995].

let migrateProc 5 proc(obj, engineName)

let engine 5 net_importEngine(engineName, Namer);

let remoteObj 5 engine(proc(arg)clone(obj) end);

redirect obj to remoteObj end;remoteObj;

end;

To migrate an object obj to an engine,we first ask a name server for a refer-ence to the engine. Next, we remotelyexecute on this engine (engine(. . . )) acloning operation of obj, resulting in aremote object.3 Finally, all attributes ofobj are made aliases for the correspond-ing attributes of the remote object (redi-rect obj to remoteObj end).

The distributed object model is closelybased on (and implemented with) theModula-3 network objects [Birrell et al.1993].

Security

Besides the basic use of scope to controlwhat is exported, no special provisionfor security in Obliq is made at the timeof writing [Cardelli 1995].

Linking

Transmitted closures can use functionsfrom the basic library, but do not other-wise gain access to names from the re-ceiving site. Names are explicitly ex-ported by passing them as parametersto the received closure.

Applications

Obliq is an academic project, and thecollection of example applications issmall. Examples include a user-inter-face toolkit, algorithm animation, 3Dgraphics, and its use as the basis of theVisual Obliq distributed applicationbuilder.

3 Note that the engine-specific information sup-plied as parameter arg to the migrated closure isnot used here.

226 • Tommy Thorn


Reflections

Using network-wide scope for distrib-uted applications leads to an elegantand powerful model of programming. Asobject migration can be expressedwithin the language, it is possible toprogram autonomous traveling agentsin Obliq. This is not possible in themodel employed by Java and O’Caml.Without further experimental results,however, it is difficult to evaluate theadvantages and drawbacks. It seemsthat this model could be inefficient,leading to many small messages to betransmitted: one for each access to aremote object. Also, Obliq seems to re-quire a much tighter coupling of hoststo support a distributed garbage collec-tion.

4.5 Telescript

Telescript [General Magic 1996] of Gen-eral Magic is an object-oriented class-based language designed for networkprogramming. Telescript is intended notas a general-purpose language but as aspecialized language for communica-tion, just as PostScript is a language forprinting. The system is based on a num-ber of metaphors from the real world.The central concept in Telescript is theagent, which autonomously travels onthe Telesphere (a Telescript network ofengines) doing business on behalf of itsowner. The engine is a Telescript inter-preter with a collection of built-inclasses and an engine place. Enginesprovide persistence of objects, even inthe presence of a system crash. Placesare stationary processes that can acceptincoming traveling agents. Users cancreate their own places nested withinother existing places. Resource usagecan be tracked and charged to the re-sponsible user.

The Language

The Telescript language itself is class-based and includes run-time typing.Classes can inherit from a single super-class and any number of mix-ins, ab-

stract classes that cannot be instanti-ated. Mix-ins can themselves inheritfrom other mix-ins.

Use of classes can be restricted in twoways: a sealed class cannot be special-ized, and an abstract class cannot beinstantiated. Attributes of objects canbe either private or public. Private at-tributes can only be accessed from theclass itself and its subclasses, whereaspublic attributes are unrestricted. Theoperator protect, a novelty of Telescript,turns object references into protectedreferences. A protected reference cannotbe used to modify an object.

Agents are processes with a number ofproperties.

—The telename is the pair of an author-ity and a process identity that to-gether name a process. The authorityidentifies the (usually human) Tele-script user.

—The owner is the process that will ownfuture created objects (except pro-cesses, which own themselves). Thisis usually the current process, but itcan be temporarily changed. Objectsnot owned by any process are garbagecollected.

—The sponsor is the process whose au-thority will be attached to andcharged for new created objects.

—The client is the object whose coderequests the current operation.

—The permit specifies the capabilitiesof the current process. A permit has anumber of process parameters:—the age is the maximum life in sec-

onds,—the extent is the maximum size of

memory allowed to the process,—the priority is used to determine

when to schedule the process forexecution, and

—the Boolean parameters canCreate,canGo, canGrant, and canDenyspecify whether the process can cre-ate new processes, travel, raise thepermission level of other processes,and lower the permission level ofother processes, respectively.



Agents are sent by invoking their gooperation with a ticket, specifying thedestination place and possibly the routeto this address. If the destination ac-cepts the agent’s authority and permits,the agent is sent together with its ob-jects to the place and resumes executionwithin the new place. The effective ca-pabilities of a process are computed asthe intersection (minimum) of the fourpermits process, local, regional, andtemporary. The local permit is imposedby the place entered, the regional per-mit is imposed by the engine, and thetemporary permit can be imposed by thelanguage construction restrict. In thefollowing we give an example (takenfrom General Magic [1996]) of how toexecute a method from an untrustedobject, using a temporary permit.

paranoid :5 Permit( );paranoid.canCreate 5 false;paranoid.canDeny 5 false;paranoid.canGo 5 false;paranoid.canGrant 5 false;paranoid.age 5 *.age 1 2;paranoid.extent 5 *.size 1 1000;try {

restrict paranoid {yourObject.yourSuspect-Call( );

};catch failed: PermitViolated{ . . . };catch . . .

}

First we create an new empty permit,named paranoid, which we initializewith very restrictive permissions. Weset the maximal age to current plus twoseconds and then allow it to allocate1,000 bytes of storage. The suspiciouscall, yourObject.yourSuspectCall( ), isthen executed in a try block using theparanoid permit. The try block enablesus to catch violations, such as code run-ning too long or using too much space.

Four built-in mix-ins are available forfurther protections on classes:

—unmoved: objects of this class cannotbe taken along with a traveling agent;

—uncopied: objects of this class cannotbe copied;

—copyrighted: objects of this class canonly be instantiated if authorized by aCopyright Enforcer object; and

—protected: objects of this class cannotbe modified.

Security

As is apparent from the preceding, secu-rity is an overall consideration that af-fects most of the Telescript language.The permission model is elaborate andapplies to resource consumption as well(the model can thus address denial ofservice issues).

Linking

Mobile processes in Telescript are runin a separate domain and can only in-teract directly with the engine in whichthey run. All interprocess access is me-diated by the engine.

Applications

Telescript is envisioned to make possi-ble an electronic marketplace where us-ers can launch their agents to searchand reserve tickets, inspect currencies,and the like.

Reflections

The Telescript system includes a num-ber of features to restrict the actions ofagents, but they seem to suffer from alack of systematic design. It is not clearhow to be convinced of the consistencyof the implemented security restric-tions.

A positive aspect of Telescript is thatit tries to deal with denial of serviceattacks. Telescript agents have theirown initiative to travel and are thusmore powerful than Java applets, but ina sense, also more dangerous: they canbe hard or impossible to control oncelaunched. An interesting aspect of Tele-script is that the user does not have tobe connected to the network while hisagent is acting. The agent can finish its

228 • Tommy Thorn


business and return to the user once hereconnects to the network.

4.6 Safe-Tcl

The idea of executable contents hadbeen realized in the context of electronicmail before the arrival of the WorldWide Web. We present Safe-Tcl, themost popular among several similarproposals. First Virtual Holdings pro-poses Safe-Tcl as an extension toMIME, the Internet multimedia mailstandard [Borenstein 1994]. The MIMEstandard defines a standard encodingfor enriched mail; that is, mail withmore than just ASCII text. MIME mailconsists of several parts, each of whichcan have a different contents type. Thesimplest contents type is just the ASCIItext, but contents types include severalpopular formats for pictures and sound.Safe-Tcl is proposed as an executablecontents type of MIME, and thus as thestandard language for executable con-tents within email.

Reflecting the store and forward na-ture of electronic mail, three differentexecution phases are distinguished: de-livery-time, receipt-time, and activa-tion-time. Delivery-time is when themail leaves the sender, receipt-time iswhen the mail arrives at the destina-tion, and activation-time is when theuser reads the mail. It is specified in theMIME header in which of the threephases the program is intended to beexecuted. (These three phases coincidefor Web pages.)

The Language

Safe-Tcl is, as the name implies, basedon Tcl [Ousterhout 1994], a proceduralscript language designed to be simple,portable, easily embedded, and power-ful. Efficiency was a minor design issue.For simplicity, every value in Tcl isrepresented as a string, including pro-grams themselves. Scope rules are verysimple in Tcl; there are only two scopelevels: local (to a function) and global.

Security

Tcl is already a safe language in thesense that there is no notion of pointers,casts, or unchecked array accesses. Theaim of Safe-Tcl is to be a safe and secureprogramming language. To achieve this,every language construction and primi-tive of Tcl was carefully examined.Primitives considered to be too danger-ous or general were replaced by a collec-tion of more specific ones. For example,the file system access functions wereremoved and replaced by an isolatedglobal configuration space. This space isaccessed using two functions: SafeTcl_setconfigdata and SafeTcl_getconfig-data. The former associates a string to akey, and the latter returns the stringassociated with a key. A rich but safegraphical user interface was a majorconcern in the design of Safe-Tcl. Thishas likewise been achieved by replacingprimitives that are too general withmore specific ones.

Linking

As the Safe-Tcl environment is likely tohave a great deal of its implementationin Tcl, two interpreters are used: oneonly for Safe-Tcl, running the untrustedapplications, the other for full unre-stricted Tcl. The untrusted applicationcan interact directly only with the Safe-Tcl interpreter.

Applications

Typical applications reported for Safe-Tcl include advanced user dialogues forordering and voting. Safe-Tcl has alsobeen used experimentally for applets inthe SurfIt! Web browser [Ball 1996].

Reflections

Safe-Tcl’s inherent limitations in termsof efficiency place it in a weak positionin the competition. On the other hand,the Safe-Tcl language is much smallerthan any of the preceding five, known tobe easy to embed, and requires only asmall amount of storage.



5. REVIEW AND COMPARISON

The main features of the languages pre-sented in Section 4 are summarized inTable I. Let us now review them anduse them as the basis for a comparativestudy.

—Object orientation. In the context ofmobile code, objects are a conveniententity in which to encapsulate dataand programs to be sent on the net-work. They also serve as entities forgrouping information with the sameaccess restrictions.

—Concurrency. In a distributed context,the notion of simultaneous and inde-pendent computations is a naturalone. For Java and O’Caml, support forconcurrency is rudimentary; multiplethreads of control and correspondingserialization are supported (O’Camlapplets do not support concurrency,though). Limbo and Telescript add arich support for network communica-tion. Limbo includes channels as first-class values. Concurrency is also in-herent in Obliq.

—Mobility. We can distinguish two dif-ferent models of mobility.—We call code fetching (noted by

“Fetch” in Table I) the model usedby Java, O’Caml, and Limbo inwhich the user downloads the codeto be executed. The initiative iswith the receiver of the code.

—Mobile agents (Obliq and Tele-script) are processes that can beprogrammed to migrate themselves,so the initiative is with the mobilecode itself. We denote this model“Agent” in Table I.

—Safety. All of the studied languagesare “safe” in the sense that accessboundaries expressed in the languageare enforced. This is an essentialproperty for a language if securityissues are to be expressed using lan-guage constructs. Enforcing safety in-volves ruling out pointer arithmetics,checking array bounds, using auto-matic memory management, disallow-ing arbitrary casts, and dynamicallychecking casts that promote objects tomore specialized classes.

—Security model. The implementationsof access control can be roughly clas-sified in two categories: the operating-system approach and the program-ming-language-based approach(noted, respectively, as “OS” and “PL”in Table I). In the former, the capabil-ities of applets are hardwired into therun-time system of the language, andin the latter, they are programmed inthe language using protection fea-tures such as scope and visibilityrules:—Java has trusted libraries with ac-

cess to native code functions. Thetrusted libraries are protectedthrough a mixture of language con-structs and sensitive functions callupon a (protected) security monitor(the SecurityManager) to check dy-namic access control.

—O’Caml uses the module system torestrict applets’ use of libraries to afixed safe subset. This subset pro-vides a supervised interface to theunderlying operating system. Thesecurity monitor uses a variable ofan abstract data type to represent

Table I. Programming Language Features

Language OO Concurrency Mobility Safety Securitymodel

Trust in the objectcode

Java u u Fetch u PL Verified object codeO’Caml u Some Fetch u PL Signed object codeLimbo u Fetch u OS Signed object codeObliq u u Agent u PL No provisionTelescript u u Agent u PL Secure networkSafe-Tcl Fetch u OS Not applicable

230 • Tommy Thorn


its capabilities.—Limbo provides all available re-

sources as files in an applet-specificfile-system hierarchy, separatedfrom other applets. New resourcesare obtained through system mod-ules. Limbo offers no support forprotecting user-written modules.

—Obliq has the language constructsnecessary to program access controlin the language. Examples on howto do this are given in Cardelli[1995], but there is very little detailon how this is exploited by theObliq system itself.

—In Telescript, capabilities are repre-sented by protected permission ob-jects.

—Safe-Tcl offers a fixed and re-stricted functionality through thebuilt-in functions.

—Trust in the object code. The safety ofobject code is based either on trust or(in the case of Java) on verification.In the case of O’Caml and Limbo, thetrust is based on a cryptographic sig-nature of a trusted authority. Tele-script agents are trusted based ontheir origin as the network is “secure”and sender addresses can be trustedto be correct.

As the security policy for the object-oriented languages is implemented us-ing objects, it is interesting to comparethe possibilities for restricting access topart of the objects in the different lan-guages. Table II summarizes the visibil-ity rules for the four object-oriented lan-guages studied in Section 4. We haveincluded a column for Limbo, whosefirst-class modules can be comparedwith classes.

6. PERSPECTIVES

The informal treatment of both lan-guage and security aspects is a majordrawback of all the languages studied.Mobile code is executed within a com-plete environment (the run-time envi-ronment of the language, the Webbrowser, the operating system, the net-work, etc.), so arguing about securityenforcement is meaningless without aclear specification of the separation ofthe responsibilities among the variousentities of the environment (what entityis assumed to ensure what property?). Anumber of the flaws discussed in Deanet al. [1996] can be seen as a conse-quence of the lack of such a clear sepa-ration. For example, in Java, classes

Table II. Class and Attribute Protection and Keyword Used

Protection offered Java O’Camla Obliqb Telescript Limbo

Class protectionNo subclasses final protected sealedSubclasses cannot add methods closedNo instances abstract virtual protected abstractVisible only in same package private NAc NA NANo outside updates protectedNo aliases NA NA protected NAMutual exclusion serialize

Attribute protectionNo restriction public defaulta default public exportedVisible only in the same package

or in subclassesprotected NA NA NA NA

Visible in subclasses default NA private NAVisible only in the defining class private private NA defaultRuntime protected reference protectMutual exclusion synchronized

a Visibility in O’Caml can furthermore be restricted using the module system.b Object used as prototypes play the role of classes in Obliq. The restrictions apply only to operationsfrom outside the object.c Not applicable.



loaded from the local file system aremore trusted than classes loadedthrough the network, and thus theformer have access to more dangerousoperations. Here the integrity of thesystem depends on both the local oper-ating system and on the Java system.One attack exploited a flaw that made itpossible to load classes from anywherein the file system [Dean et al. 1996]. Forthis attack to succeed, it must be possi-ble for the attacker to upload a filesomewhere on the victim’s file system.This can often be done in a variety ofways, depending on the local operatingsystem. Another attack allowed appletsto connect to arbitrary hosts. The attacksucceeded due to a weakness in theJava library, where an external nameservice was implicitly assumed to betrustworthy, which in fact it was not.

Current work on mobile code does nottake enough account of the researchdone in programming language seman-tics [Nielson and Nielson 1992; Schmidt1986], formal methods in software engi-neering, like VDM [Bjørner 1991a,b], Z[Spivey 1988], RAISE [Brock andGeorge 1990], and B [Lano 1996], for-mal models of security [Bell and LaPa-dula 1973; Landwehr 1981; McLean1994], or research on static programanalysis [Banatre et al. 1994; Denningand Denning 1977; Mizuno and Schmidt1992; Volpano et al. 1996]. As a startingpoint, a semantic definition of the lan-guage would provide an important in-sight and emphasize the weak parts ofits definition with respect to security.Such a definition would also make pos-sible formal statements for the securityclaims made by the proponents of thelanguage. Having a semantics for thelanguage would not be enough, though.Security is a global property, so a secu-rity model must take into account allaspects of the system supporting theexecution of the code. This includes inparticular the hardware, the operatingsystem, the abstract machine, the mod-ule libraries, the security manager, andthe browser. A security weakness in

just one of these endangers the securityof the whole system.

Existing research into formal meth-ods for security [Bell and LaPadula1973; Landwehr 1981; McLean 1994]provides a strong foundation on whichsuch a model should be build. The chal-lenge consists of integrating the differ-ent levels mentioned in a coherent anduseful way. The formal model will beuseful only if it can support the expres-sion of the global security policy and itsdecomposition to highlight its impact onthe various components of the system.One of the components is the executionmodel of the mobile code language,which would then be characterized pre-cisely in terms of security requirements.This, in turn, would provide the neces-sary formal basis for both static anddynamic verifications in the languagefor mobile code.

Several efforts have recently been un-dertaken that suggest promising ave-nues for future research to provide aformal basis for mobile code verifica-tion. Among them, let us mention:

—Mizuno and Schmidt [1992] derive asecurity flow analysis as an abstractinterpretation of an enriched denota-tional semantics. The analysis is com-positional; individual modules can beanalyzed separately and the results(symbolic expressions) can be com-bined to obtain an analysis of theentire system.

—Banatre et al. [1994] present the de-velopment of a static analysis for in-formation flow in a simple guardedcommand language. The information-flow logic is based on a noninterfer-ence property. The analysis is thenderived through successive refine-ments of the proof system into a com-plete algorithm for information-flowanalysis.

—Volpano et al. [1996] present a soundtype system for secure flow analysis.The multiple sensitivity level of Den-ning’s lattice model is formulated as asubtyping relation that can be stati-cally checked. The soundness of their

232 • Tommy Thorn


system is formulated as a noninterfer-ence property of well-typed programs.

—Necula and Lee [1996] present a tech-nique for safely loading binary exten-sions into an operating-system kernel.The technique is based on pairing theobject code with a machine-checkableproof that the object code respects thepublished safety policy of the operat-ing system. The proof, formulated interms of a simple type system, is ver-ified together with the object code bya type checker in the operating sys-tem. If it is found to be correct, thecode is allowed to execute without anydynamic check whatsoever.Their approach represents the bestthat can be achieved in terms of per-formance (no more overhead is in-curred after the type checking) with-out being dependent on cryptographicsignatures. The major problems withtheir technique is the burden of proofgeneration, which is manual, and thefact that each safety policy potentiallyrequires its own proof.

—Borgia et al. [1996] present a struc-tural operational semantics for theFacile language based on the notion ofproved transition systems. Facile is aconcurrent functional language basedon the p-calculus, a basic languagefor mobile processes. The semanticscan be used to extract causal depen-dencies, as demonstrated by its use todebug a mobile agent system. Thiswork is very promising, and it will beinteresting to see how well it scales tomobile code programming languages.

The advantage of the preceding con-tributions on program analysis or typ-ing [Banatre et al. 1994; Mizuno andSchmidt 1992; Volpano et al. 1996] isthat they lead to mechanical verifica-tions. Their limitation is that they de-scribe individual security analyses forprograms without considering their in-tegration in the general context (includ-ing the network, operating system, ab-stract machine, etc.). As a consequence,the properties of the programs verifiedby the analyses are not linked to a

general security policy for the wholesystem. On the other hand, the ap-proach of Necula and Lee [1996] can beseen as a more ambitious attempt, butit relies on mostly manual proof con-struction. One challenge for future workis probably to find an appropriate inte-gration of automatic and interactiveproof techniques.

APPENDIX. LANGUAGE EXAMPLES

To give the reader a feel of the differentlanguages we present examples forJava, Limbo, O’Caml, and Safe-Tcl. Un-fortunately, realistic examples would bemuch too long for this article. We omitObliq and Telescript, as we feel thereare already sufficient examples of theirtreatment.

A.1 Java

Figure 1 shows the source of a smallapplet example illustrating the use oftwo user interface primitives: buttonsand labels.

1–2 The two import statementsmake all classes from thepackage applet and awt (ab-stract windows toolkit) avail-able under their unqualifiedclass name. In this example,we use the class Applet fromthe package applet and theclasses Button and Label fromthe package awt.

4–6 The Applet class constitutes aframework for applets and allapplets are a specialization ofthe Applet class. The appletin this example, HelloWorld,has two graphics items, apush button and a label.These are declared as the pri-vate variables push and lab ofclass Button and Label, re-spectively.

8–11 The system initializes appletsby calling init. The first thingto do is to call the init definedin the superclass. A new But-ton instance, initialized to



carry the label “Push me,” iscreated in line 10. This in-stance is assigned to the localattribute push. This instanceis added to the scene4

through the method add, de-fined in the class Container(not shown) in the packagejava.awt.Applet is a special-ization of Container.

14–17 Button events are deliveredto Applet objects by callingtheir action method. For thisexample, it is not necessaryto check which button waspressed, as there is only one;thus the two arguments,event and arg, are ignored.The applet responds to thebutton press by removing thebutton from the scene (line15) and changing the mes-sage in the label (line 16).remove is a method of Con-tainer like add, and setText(line 16) is a method of theclass Label.

A.2 Limbo

Figure 2 shows a Limbo example thatuses a channel to report activations of abutton, illustrating communication be-tween Tk and Limbo.

1 The head of the module de-clares that what follows con-stitutes the module Hello.Module names begin with up-percase letters.

3– 5 The signature of modules Drawand Tk are included from thefiles “draw.m” and “tk.m”. Thetk: Tk statement declares an in-stance named tk of the moduleTk (initialized to nil). Typesand constants exported frommodules can be accessed di-rectly from the signature of themodule, but functions and vari-ables require a module in-stance. As this example onlyuses the type Context frommodule Draw, there is no needto make an instance.

7–9 The signature of this moduleexports only one function, init.By convention, programs capa-ble of being executed from the

4 As in C, assignments are expressions with thevalue of their left-hand side.

Figure 1. Source of Java applet HelloWorld.

234 • Tommy Thorn


top-level shell have a functioncalled init with the signature: afunction taking a graphics con-text (type Context from moduleDraw) and a list of string argu-ments. The graphics contextprovides a reference to a win-dow system, necessary to cre-ate new windows.

11–12 The implementation of theinit function starts by loadingthe implementation of mod-ule Tk and creating the in-stance tk. By convention, eachmodule declaration includes apathname constant thatpoints to the code for themodule; this is the second pa-rameter Tk2.PATH of theload statement.

13 The variable t is declared andinitialized to a reference tothe top-level window.

14 The string channel ccmd isdeclared and instantiated. Inthis example, a message onthis channel signals the ter-mination of the application.

15 The namechan call associates

the Limbo channel with a Tkstring, thus bridging the twolanguages. Messages sent ontcmd from the Tk languageappear on ccmd.

16–18 These three lines are calls tothe Tk graphics library tocreate a button that sendsthe string “bye” on tcmd(ccmd) upon a mouse press.The pack command places thebutton .b on the top level win-dow, and update makes it ap-pear on the screen.

19–20 The last thing to do is to waitfor a message on the channel.The value received is ignored.

A.3 O’Caml

Figure 3 shows the complete source ofan MMM timer applet.

1 The open statement importsall publicly exported identifi-ers from the module.

2–5 Safestd is a safe subset of thestandard library, containingbasic primitives, such as

Figure 2. Limbo example.



string_of_int in the following.The module Safemmm givesrestricted access to internalsof the MMM browser. Herewe only need it to create atop-level window. Safetk con-tains the graphics toolkitfunction widgets.

7 The applet is a top-level func-tion f with three arguments ofno relevance for this example.

8–9 Creates a top-level windowand sets the title to “TimeWeb.”

10 Applies constructor Text tostring “00:00:00,” creating aninitialized text label 1 (agraphic element). Text is im-ported from the module Tk.

11–17 Defines a function to formatthe current local time as astring and update the label 1.

The ˆ operator is for stringconcatenation.

19–23 The tim function updates thetext label continuously (witha small pause). Winfo.exists 1checks that the window isstill present (the user can de-lete it externally using thewindow manager). If the win-dow has been removed, theapplet stops. The function ad-d_timer registers a thunk (afunction of type ( ) 3 Unit)for execution after a givennumber of milliseconds. Thecall to add_timer itself re-turns immediately.

24–25 The updating is started andthe label is installed in thetop-level window. The list FillFill_X are options to pack,making the label take all

Figure 3. O’Caml applet source.

236 • Tommy Thorn


available space in the win-dow.

27 The final step is to registerthe applet function, establish-ing the connection betweenO’Caml and MMM.

A.4 Safe-Tcl

Figure 4 gives the partial source of aSafe-Tcl example application. In Tcl,the first word of the line is always thename of a command and the rest of theline contains the arguments, separatedby spaces. The backslash at the end ofthe line allows long statements to bebroken across several lines. The squarebrackets group subexpressions. Thecurly brackets group arguments: every-thing up to but excluding the matchingclosing curly brackets is considered oneargument. Optional arguments are pre-ceded by a keyword with a leading dash(–), imitating the Unix command-lineconvention. Variables are accessed withthe dollar operator ($). String concate-nation is implicit everywhere; for exam-ple, $win.m is the contents of the win

variable followed immediately by thestring “.m”.

1–9 We define a function, order-shirt, which queries the userfor size information, usingthe SafeTcl_getline function.The result is wrapped up inthe body of a mail by SafeTcl_makebody and sent [email protected] (bySafeTcl_ sendmessage).

11 The conditional checkswhether it is running in aTk-capable client.

12 Creates a top-level windowand stores it in the variablewin. The command set assignsvariables to values.

13–18 Equips the window with aleading message and two but-tons, one of which activatesthe previously defined order-shirt upon button press. Thebuilt-in commands messageand button create a messagepanel and a button graphicelement, respectively.

Figure 4. SafeTcl applet source.



19–20 The pack command groupsthe graphics elements to-gether. The pady 20 argu-ment specifies a vertical fill-ing factor.

REFERENCES

ADL-TABATABAI, A., LANGDALE, G., LUCCO, S., ANDWAHBE, R. 1996. Efficient and language-in-dependent mobile programs. In Proceedings ofthe SIGPLAN ’96 Conference on ProgrammingLanguage Design and Implementation.

ARNOLD, K., AND GOSLING, J. 1996. The JavaProgramming Language. Sun Microsystems.

BALL, S. 1996. The SurfIt! browser. Availableat http://pastime.anu.edu.au/SurfIt.

BANATRE, J., BRYCE, C., AND LE METAYER, D.1994. Compile-time detection of informationflow in sequential programs. In Proceedings ofthe European Symposium on Research inComputer Security, No. 875 in Lecture Notesin Computer Science. Springer-Verlag, NewYork.

BELL, D., AND LAPADULA, L. 1973. Secure com-puter system: Mathematical foundations andmodel. Tech. Rep. M74–244, MITRE Corp.

BILLON, J.-P. 1996. Java security: Weaknessesand solutions. Available at http://www.dya-de.fr/actions/VIP/JS_pap2.html.

BIRRELL, A. D., NELSON, G., OWICKI, S., AND WOB-BER, E. 1993. Network objects. In Proceed-ings of the 14th Symposium on OperatingSystems Principles.

BJØRNER, D. 1991a. Software Architectures andProgramming Systems Design; Volume I:Specification Principles—the VDM Approach.Addison-Wesley/ACM Press.

BJØRNER, D. 1991b. Software Architectures andProgramming Systems Design; Volume II: Im-plementation Principles—the VDM Approach.Addison-Wesley/ACM Press.

BORENSTEIN, N. S. 1994. Email with a mind ofits own. Available at ftp://ftp.fv.com/pub/code/other/safe-tcl.tar.gz, 1994.

BORGIA, R., DEGANO, P., PRIAMI, C., LETH, L., ANDTHOMSEN, B. 1996. Understanding mobileagents via a non-interleaving semantics forFacile. In Proceedings of SAS ’96, Vol. 1145 ofLecture Notes in Computer Science, Springer-Verlag, 98–112.

BROCK, S., AND GEORGE, C. W. 1990. The RAISEmethod manual. Tech. Rep. LACOS/CRI/DOC/3, CRI: Computer Resources Interna-tional.

CARDELLI, L. 1995. A language with distributedscope. In Proceedings of the 22nd Symposiumon Principles of Programming Languages(Jan.), ACM Press, New York, 286–297.Available at http://www.research.digital.com/SRC/personal/Luca_Cardelli/Obliq/Obliq.html.

DEAN, D., FELTEN, E. W., AND WALLACH, D. S.1996. Java security: From HotJava toNetscape and beyond. In IEEE Symposium onSecurity and Privacy (Oakland, CA).

DENNING, D., AND DENNING, P. 1977. Certifi-cation of programs for secure informationflow. Commun. ACM 20, 7.

DROSSOPOULOU, S., AND EISENBACH, S. 1996.Proving the soundness of the Java type sys-tem. Tech. Rep., Imperial College, Oct.

FOX, R. 1996. Internet sabotage. Commun.ACM 39, 11 (Nov.), 9.

FREIER, A. O., KARLTON, P., AND KOCHER, P. C.1996. The SSL protocol. Available at http://home.netscape.com/eng/ssl3/index.html,March.

GENERAL MAGIC. 1996. The Telescript homepage. Available at http://www.genmagic.com/Telescript.

GOSLING, J., JOY, B., AND STEELE, G. 1996. TheJava Language Specification. Sun Microsys-tems.

HANSEN, W. J. 1990. Enhancing documentswith embedded programs: How Ness extendsinsets in the Andrew toolkit. In Proceedings ofIEEE Computer Society 1990 InternationalConference on Computer Languages, (New Or-leans, March) IEEE Computer Society Press,Los Alamitos, CA, 23–32.

HUITEMA, C. 1996. IPv6: The New Internet Pro-tocol. Prentice Hall, Englewood Cliffs, NJ.

JAVASOFT. 1996. JavaSoft products. Availableat http://www.javasoft.com/nav/read/products.html.

KNABE, F. 1996. An overview of mobile agentprogramming. In Proceedings of the Fifth LO-MAPS Workshop on Analysis and Verificationof Multiple-Agent Languages. (Stockholm,Sweden, June) No. 1192 in Lecture Notes inComputer Science, Springer-Verlag, New York.

LANDWEHR, C. E. 1981. Formal models for com-puter security. ACM Comput. Surv. 13, 3,247–278.

LANO, K. 1996. The B Language and Method.Springer-Verlag.

LEROY, X. 1997. Objective Caml. Available athttp://pauillac.inria.fr/ocaml/.

LUCENT TECHNOLOGIES. 1996. The Inferno homepage. Available at http://inferno.bell-labs.com/inferno/index.html.

MALENFANT, J. 1995. On the semantic diversityof delegation-based programming languages.In Proceedings of OOPSLA ’95.

MCLEAN, J. 1994. Security models. In Encyclo-pedia of Software Engineering, J. Mariniak,Ed., John Wiley & Sons, New York.

MIZUNO, M., AND SCHMIDT, D. A. 1992. A secu-rity flow control algorithm and its denota-tional semantics correctness proof. FormalAspects Comput. 4, 6A, 727–754.

238 • Tommy Thorn


NECULA, G. C., AND LEE, P. 1996. Safe kernelextensions without run-time checking. In Sec-ond Symposium on Operating Systems Designand Implementation. Available at http://fox-net.cs.cmu.edu/people/petel/papers/osdi.ps.

NETSCAPE. 1997. JavaScript language specifica-tion. Available at http://developer.netscape.com/library/documentation/index.html.

NIELSON, H. R., AND NIELSON, F. 1992. Seman-tics with Applications, a Formal Introduction.Wiley Professional Computing. John Wileyand Sons, New York.

OUSTERHOUT, J. K. 1994. Tcl and the Tk Tool-kit. Addison-Wesley, Reading, MA.

PIKE, R. 1997. Private communication.RESCORLA, E., AND SCHIFFMAN, A. 1996. The se-

cure hypertext transfer protocol. Available atftp://ds.internic.net/internet-drafts/draft-ietf-wts-shttp-03.txt, July.

ROUAIX, F. 1996a. MMM browser home page.Available at http://pauillac.inria.fr/;rouaix/mmm/.

ROUAIX, F. 1996b. A Web navigator with ap-plets in Caml. In Proceedings of the FifthInternational World-Wide Web Conference(Paris, May). Elsevier Science B. V.

RUSSELL, D., AND GANGEMI, G. T., SR. 1991.Computer Security Basics. O’Reilly & Associ-ates, Inc., Sebastopol, CA.

SCHMIDT, D. A. 1986. Denotational Semantics:A Methodology for Language Development. Al-lyn and Bacon, Needham Heights, MA.

SPIVEY, J. M. 1988. Understanding Z: A Speci-fication Language and Its Formal Semantics.Cambridge University Press, New York.

VOLPANO, D., SMITH, G., AND IRVINE, C. 1996. Asound type system for secure flow analysis.J. Comput. Sec. 4(3).

Received December 1996; accepted May 1997

