WO2006056646A1 - Method for the secure interpretation of programs in electronic devices - Google Patents

Method for the secure interpretation of programs in electronic devices Download PDF

Info

Publication number
WO2006056646A1
WO2006056646A1 PCT/FI2005/000504 FI2005000504W WO2006056646A1 WO 2006056646 A1 WO2006056646 A1 WO 2006056646A1 FI 2005000504 W FI2005000504 W FI 2005000504W WO 2006056646 A1 WO2006056646 A1 WO 2006056646A1
Authority
WO
WIPO (PCT)
Prior art keywords
electronic device
interpreted
program
stub executable
interpreted program
Prior art date
Application number
PCT/FI2005/000504
Other languages
French (fr)
Inventor
Lauri Tarkkala
Original Assignee
Nokia Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from FI20041517A external-priority patent/FI20041517A0/en
Application filed by Nokia Corporation filed Critical Nokia Corporation
Priority to EP05817859A priority Critical patent/EP1815381A1/en
Priority to JP2007542018A priority patent/JP4638505B2/en
Publication of WO2006056646A1 publication Critical patent/WO2006056646A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2141Access rights, e.g. capability lists, access control lists, access tables, access matrices
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00Arrangements for software engineering
    • G06F8/60Software deployment
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/451Execution arrangements for user interfaces

Definitions

  • the invention relates to interpreted program ⁇ ming languages. Particularly, the invention relates to a method for the secure interpretation of programs in electronic devices.
  • malware code may cause a variety of nuisances. For example, calls may be set-up to chargeable service numbers without properly inform ⁇ ing the user, information may be gathered and stolen from the mobile terminal, and chargeable purchases may be made on behalf of the user, if the mobile terminal supports some kind of mobile payment system.
  • a secure kernel isolates native programs from each other. This implies that it is not possible to grant capabilities or access to resources to programs that are not isolated from each other. If it would be possible to grant capabilities to applications that were not isolated from each other then there would be no guarantees that the capabilities do not "leak" to malicious code. Essentially, the isolation of applica- tions is a critical underpinning of the capability framework.
  • the invention relates to a method for the se ⁇ cure interpretation programs in an electronic device.
  • the method comprises: providing at least one shared interpreter library and a prototype stub executable in said electronic device, loading an interpreted program in said electronic device, forming a stub executable using said prototype stub executable in said elec- tronic device, associating said stub executable with said interpreted program in said electronic device, assigning at least one second capability to said stub executable, and executing said stub executable in said electronic device.
  • the invention relates also to an electronic device comprising: at least one shared interpreter li ⁇ brary configured to implement an interpreter engine, an installer entity configured to load an interpreted program in said electronic device, to form a stub ex- ecutable using a prototype stub executable, to assign at least one second capability to said stub executa ⁇ ble, to associate said at least one second capability to said stub executable, and an operating system en ⁇ tity configured to execute said stub executable.
  • the invention relates also to a computer pro ⁇ gram comprising code adapted to perform the following steps when executed on a data-processing system: load ⁇ ing an interpreted program, forming a stub executable using a prototype stub executable, associating the stub executable with the interpreted program, assign ⁇ ing at least one second capability to the interpreted program, associating the at least one second capabilities to the stub executable, executing the stub execu ⁇ table, the stub executable indicating to at least one shared interpreter library the interpreted program, and the stub executable invoking at least one function in the shared interpreter library to interpret the in ⁇ terpreted program.
  • the invention relates also to a computer pro ⁇ gram comprising code adapted to perform the following steps when executed on a data-processing system: pro- viding at least one capability associated with said computer program to an interpreted program, obtaining information on an interpreted program from a , secure source assigned to said computer program, indicating to at least one shared interpreter library said inter- preted program, said at least one shared library com ⁇ prising at least one function implementing an inter ⁇ preter engine for interpreting interpreted program code, and invoking at least one function in said shared interpreter library to interpret said inter- preted program.
  • the method further comprises: the stub executable indicat ⁇ ing to said at least one shared interpreter library said interpreted program, the stub executable invoking at least one function in said at least one shared in ⁇ terpreter library to interpret said interpreted pro ⁇ gram, checking whether an external interpreted program code section is referred by the interpreted program, inferring at least one first capability for said ex ⁇ ternal interpreted program code section; and disallow ⁇ ing the execution of said external interpreted program code section if said at least one second capability is not a subset of said at least one first capability.
  • the at least one shared interpreter library is further con ⁇ figured to check whether an external interpreted pro- gram code section is referred by an interpreted pro ⁇ gram, to infer at least one first capability for said external interpreted program code section, and to dis ⁇ allow the execution of said external interpreted pro ⁇ gram code section if at least one second capability is not a subset of said at least one first capability.
  • the se ⁇ cure source is a secure directory in an electronic de ⁇ vice.
  • the secure source may, for example, be the com ⁇ puter program code itself or it may be the directory storing the computer program.
  • the information on the interpreted program may be the file name of the inter ⁇ preted program.
  • the secure source may also be the op ⁇ erating system, which provides to the computer program the filename of the file comprising the computer pro- gram.
  • the term external in ⁇ terpreted program code section refers to an inter ⁇ preted program code section that is obtained outside of the interpreted program itself, for example, from a directory different than the one reserved for the in ⁇ terpreted program in the electronic device.
  • the external interpreted program code section may be read from a shared interpreted library.
  • An external interpreted program code section may also be obtained over-the-air during the interpretation of the inter ⁇ preted program.
  • the term at least one first capability refers to the set of capabilities assigned to the ex- ternal interpreted program code section, for example, a shared interpreted library.
  • the term at least one second capability refers to the set of capabilities of the stub executable.
  • a single capability might comprise a number of individual oper ⁇ ating system, data communication or electronic device management related operations or functions. In other words, a number of functions may have been grouped in a single capability for convenience reason.
  • a program or a piece of program code can have associated with it a set of capabilities.
  • a capability grants access to a resource or function in the electronic device that would be otherwise unavailable to said program or pro ⁇ gram code.
  • the capabilities are policed by the operat- ing system or the functions serving said program in the electronic device.
  • a reli ⁇ ability category is determined for an interpreted pro ⁇ gram code section based on at least one of the loca- tion of a file comprising the interpreted program code section in the file system of the electronic device and whether the interpreted program code section has been received from a trusted remote sender, and the trust level is granted based the reliability category.
  • the exe ⁇ cution of arbitrary data is disabled in the at least one interpreter library. This means, for example, that the functions for the execution of arbitrary data are made inaccessible for the interpreter engine. The at- tempt to call such a function causes an error to be generated in the interpreter engine.
  • the stub executable is executed in a separate process context.
  • the disabling may be per ⁇ formed beforehand as the interpreter engine is com- piled to produce the at least one shared interpreter library. This disabled version is then provided to the electronic device.
  • the ex ⁇ ternal interpreted program code section is loaded in said electronic device, for example, over-the-air from a network server.
  • the external interpreted program code section is a function within a shared interpreted library compris ⁇ ing interpreted program code.
  • the external interpreted program code section may also be formed from arbitrary data by the interpreted program so that the inter- preted program code is passed by the interpreted pro ⁇ gram itself to the interpreter engine.
  • a trust level is granted to the shared interpreted library.
  • the trust level may be granted by the user or by the installer entity automatically. If the installer en ⁇ tity grants the trust level automatically, it may be obtained by inspecting trust level information pro ⁇ vided by a network server. The operator may have signed the trust level information. The signing may also have been performed by a service provider or any other trusted entity.
  • the trust level is used to de ⁇ termine the at least one first capability either in the operating system entity level or in the installer entity level.
  • the load ⁇ ing of the interpreted program comprises the download ⁇ ing of the interpreted program from a network server.
  • the pro ⁇ viding of the at least one shared interpreter library and the prototype stub executable comprises the down ⁇ loading of them from a network server to the elec ⁇ tronic device.
  • the load ⁇ ing of the at least one shared interpreted library comprises the downloading of them from a network server to the electronic device.
  • the in ⁇ terpreted program is identified using a unique identi ⁇ bomb in the electronic device.
  • the unique identifier may be used, for example, by the operating system en- tity and the installer entity to refer to the inter ⁇ preted program and the stub executable.
  • the at least one second capability may be associated by the operat ⁇ ing system entity with the unique identifier.
  • the elec- tronic device comprises a mobile terminal.
  • the electronic device com ⁇ prises a SYMBIANTM operating system device.
  • the electronic device com ⁇ prises a General Packet Radio System terminal or a Universal Mobile Telecommunications System terminal.
  • the com ⁇ puter program is stored on a computer readable medium.
  • the computer readable medium may be a removable memory card, magnetic disk, optical disk or magnetic tape.
  • the elec ⁇ tronic device is a mobile device, for example, a lap ⁇ top computer, a palmtop computer, a mobile terminal or a personal digital assistant (PDA) .
  • the electronic device is a desktop computer or a mainframe computer.
  • the benefits of the invention are related to the improved reliability of loaded interpreted pro ⁇ grams.
  • the invention enables the capabilities defined for executable programs in the native operating system to be applied for interpreted programs and program code per program or program code that are executed within an interpreter which otherwise would be seen as a single arbitrary application in the native operating system with a single set of capabilities.
  • Fig. 1 is a block diagram illustrating an ex ⁇ ample of a directory tree in an electronic device ac- cording to the invention
  • Fig. 2A and Fig. 2B are a flow chart illus ⁇ trating the method for the secure interpretation of programs in one embodiment of the invention.
  • Fig. 3 is a block diagram illustrating an electronic device according to the invention.
  • Figure 1 is a block diagram illustrating an example of a directory tree in an electronic device according to the invention.
  • the electronic device is as illustrated in Figure 3.
  • the electronic device is a SYMBIANTM operat ⁇ ing system device.
  • the directory tree illustrates what files essential to the method are stored in an elec ⁇ tronic device according to the invention and what their mutual relationships are.
  • Figure 1 there is a root node 100, to which subdirectories 101, 102 and
  • the subdirectory 101 stores binary files, which implement an interpreter.
  • the interpreter may be, for example, a Java interpreter, a Perl inter ⁇ preter, A PHP interpreter or a Python interpreter.
  • File 111 comprises the engine for an interpreter, which executes either directly the program source code or a byte code that has been produced using a com ⁇ piler.
  • the program source code or the byte code that is interpreted by the interpreter engine is hereinaf- ter referred to as the interpreted program code.
  • the compiler takes a human readable source code and com ⁇ piles it into a byte code.
  • byte code might be any intermediate language, which may be executed by the interpreter engine.
  • the intermediate language may be in any format optimal for machine execution. It does not necessarily have to comprise operation codes of the size of one byte.
  • file 111 is a Dynamically Linked Library
  • DLL Dynamic Language
  • File 112 is a stub interpreter executable, which when executed, invokes eventually the interpreter engine placed in file 111.
  • File 113 is formed by means of file 112 whenever an interpreted program is installed to the electronic device.
  • a subdirectory 102 comprises a program, which is to be interpreted using the interpreter engine.
  • Subdirectory 102 comprises a file 121, which comprises the interpreted program.
  • the component ⁇ SID> in the subdirectory name represents a Security Identifier (SID) , which has been assigned to the interpreted pro ⁇ gram. The SID identifies uniquely the interpreted pro ⁇ gram and enables capabilities be assigned to the in ⁇ terpreted program.
  • SID Security Identifier
  • a capability represents an operat ⁇ ing system function or a set of operating system func- tions that may be invoked by an application identified using a SID.
  • capabilities include the ca ⁇ pability to set-up and communicate over a remote net ⁇ work, for example, to a remote Internet server, and the capability to access files stored on the elec- tronic device.
  • a single capability may comprise a num ⁇ ber of related functions and operations. For example, all IP socket related functions might comprise a sin- gle capability.
  • Other capabilities may relate to power management, local communication over BLUETOOTHTM or in ⁇ frared and low-level radio protocol operations.
  • a subdirectory 103 comprises a shared Ii- brary, which comprises functions that are to be in ⁇ voked from interpreted programs such as the inter ⁇ preted program stored in file 121.
  • the shared library is stored in a file 131.
  • Subdirectory 132 comprises also a policy file, which governs the policies how the shared library is managed in the electronic device.
  • the policy file would define how to manage the /resource/ ⁇ lang> directory and how to create the lang- ⁇ version->-stub-interpreter.exe for bootstrapping the interpreter for a certain script.
  • the advantage of us- ing a policy definition file is that no interpreter- specific foreign code is executed in the context of the software installation program.
  • the policies of all interpreters can also be cross-referenced and checked for errors and conflicts before they are implemented.
  • the policy support required in this case is also ex ⁇ tremely simple.
  • the shared interpreted library is as ⁇ signed a trust level, in other words, a set of capa ⁇ bilities that are allowed for the functions in the li ⁇ brary.
  • the set of capabilities are either operator de- termined or user determined. In the case of operator determination, the capabilities are indicated to the electronic device as the file is downloaded from a network server. The capabilities are verified, for ex ⁇ ample, so that they are signed using the operator's digital signature. In the case of user determination, the user is prompted to indicate what capabilities are to be allowed for the library.
  • the capabilities as ⁇ signed to the shared interpreted library should re ⁇ flect what functionalities have been tested and are thus considered reliable in the case of the library.
  • a library may be considered safe to down- load files to the electronic device, but may not be allowed to read files in the electronic device.
  • Figures 2A and 2B are a flow chart illustrat ⁇ ing the method for the secure interpretation of pro- grams in one embodiment of the invention.
  • a shared interpreter library com ⁇ prising the main interpreter code, that is, the inter ⁇ preter engine is provided to the electronic device.
  • the shared library may be provided, for example, as part of the native operating system or it may be down ⁇ loaded over the air to the electronic device from a network server as the user requests the downloading of the interpreter.
  • a prototype stub executable com- prising the functions necessary to invoke the inter ⁇ preter engine for the interpretation of a single in ⁇ terpreted program is provided to the electronic de ⁇ vice.
  • the prototype stub executable may be provided, for example, as part of the native operating system or it may be downloaded over the air to the electronic device as the user requests the downloading of the in ⁇ terpreter from the network server.
  • the installation of the shared interpreter library, comprising the main interpreter code, and the prototype stub executable may be performed in a separate installer entity, which stores them to a non-volatile memory in the electronic device.
  • a shared interpreted library is also loaded to the electronic device.
  • the shared library may be loaded to the elec ⁇ tronic device using a removable memory medium such as a magnetic or optical disk or a removable memory card or it may be downloaded over the air to the electronic device.
  • the installation of the shared interpreted Ii- brary may be performed in a separate installer entity, which stores it to a non-volatile memory in the elec ⁇ tronic device.
  • a trust level is granted to a shared interpreted library in the elec ⁇ tronic device. The trust level specifies a set of ca ⁇ pabilities assigned to the shared interpreted library.
  • the granting decision may be based on trust level in ⁇ formation signed by the operator or any other entity trusted by the electronic device.
  • the trust is estab ⁇ lished, for example, by means of Public Key Infra ⁇ structure (PKI) and trust chains.
  • PKI Public Key Infra ⁇ structure
  • the user of the electronic device may also explicitly specify the granting decision via the user interface of the elec ⁇ tronic device.
  • the interpreted program is loaded to the electronic device.
  • the interpreted program is, for example, downloaded over the air.
  • the interpreted program may have been selected by the user from a WWW- page or a WAP-page.
  • the interpreted program is down ⁇ loaded, for example, from a network server to which the electronic device has established a connection.
  • the installing of the interpreted program may be per ⁇ formed by an installer entity.
  • the interpreted program may also be loaded to the electronic device using a removable mem ⁇ ory medium such as a magnetic or optical disk or a re- movable memory card.
  • a unique identifier is assigned to the interpreted program.
  • the interpreted program may use functions in the shared library that may have been downloaded to the electronic device.
  • the unique identifier is obtained from an authority, which is re ⁇ sponsible for allocating unique identifiers for appli ⁇ cations executed in the electronic device.
  • the capabilities to be granted to the interpreted program are determined in the elec- tronic device.
  • the capabilities are de ⁇ termined by analyzing the interpreted program code of the interpreted program or they may be specified in a separate file or data structure provided in associa ⁇ tion with the interpreted program from the network server or from a removable memory medium.
  • a stub executable is formed using the prototype stub executable.
  • the stub executable is formed for invoking the interpreter engine and for de ⁇ termining the interpreted program to the interpreter engine.
  • the stub executable is formed using the proto ⁇ type stub executable.
  • the stub executable may be formed using instructions provided in a separate pol- icy file, which is provided, for example, in associa ⁇ tion with the shared interpreted library or in asso ⁇ ciation with the interpreted program.
  • the forming of stub executable may be performed by an installer en ⁇ tity.
  • the running of other programs from the stub executable is disabled.
  • the disabling is achieved, for example, so that the stub executable ex ⁇ plicitly indicates to the interpreter engine the in ⁇ terpreted program that is to be executed.
  • the inter- preted program is indicated, for example, by providing its filename such as file 121 in Figure 1.
  • the capabilities determined for the interpreted program are assigned to the stub ex ⁇ ecutable formed at step 214 in the electronic device.
  • the stub executable will represent the interpreted program for the operating system security functions. Due to the fact that the stub executable is used to invoke the interpreter engine and to provide the in ⁇ terpreted program to the interpreter engine it is en- sured that no other interpreted program code than the interpreted program or functions in the shared inter ⁇ preted library are executed. In other words, there is no other possibility for interpreted programs to get executed in the interpreter engine than via a stub ex ⁇ ecutable.
  • step 220 the process in charge of inter ⁇ preting the interpreted program by means of the stub executable and the interpreter engine is executed in a separate process context by the operating system of the electronic device. For each interpreted program there is a separate process context.
  • step 222 it is checked by the interpreter engine whether the program is at end. If the program is not at end, the method continues at step 224.
  • step 224 it is checked by the interpreter engine whether external interpreted program code is to be interpreted by it. If this is the case, method con ⁇ tinues at step 226, otherwise the method continues at step 220.
  • An example of an external interpreted pro ⁇ gram code is code included in a shared interpreted li ⁇ brary.
  • Another example of an external interpreted pro ⁇ gram code is code that has been received to the elec ⁇ tronic device during the interpretation of the current code.
  • the trust level of the external interpreted program code is compared to the capabilities of the stub ex- ecutable by the interpreter engine. It is determined that the capabilities of the stub ex- ecutable are a subset of the capabilities associated with the trust level of the external interpreted pro ⁇ gram code, that is, for example, the shared inter ⁇ preted library.
  • a given trust level uniquely specifies the set of capabilities that has been assigned to an external interpreted program code.
  • the trust level is inferred, for example, based on the location of the external interpreted program code in the electronic device file system. For example, if the code is lo ⁇ cated in a trusted directory such as the directory of the interpreted program or a language specific trusted directory, it is granted at least the capabilities of the interpreted program.
  • the interpreter engine considers the trust level to be exceeded.
  • step 228 the interpreter engine checks, if the trust level was exceeded. If it was exceeded, the method continues at step 230. Otherwise the method continues at step 220.
  • FIG. 3 is a block diagram illustrating an electronic device 300 according to the invention.
  • Electronic device 300 comprises a first memory (not shown) and a second memory (not shown) .
  • the first mem ⁇ ory is a volatile RAM work memory and the second mem- ory is a non-volatile memory.
  • the first and the second memories are the same memory, which is non-volatile.
  • the electronic de ⁇ vice also comprises a processor (not shown) .
  • FIG. 3 there is a box 302, which illus- trates the software in the electronic device.
  • the software comprises at least an operating system entity 316, an installer entity 304 and a communication en ⁇ tity 306.
  • the software may also comprise an inter ⁇ preter engine 310 and a stub executable 308 associated with interpreter engine 310.
  • Interpreter engine 310 executes the interpreted program codes for interpreted programs such as interpreted program 312.
  • the inter- preted programs may use at least one function stored in a shared library 314.
  • Shared library 314 comprises functions specified in the interpreted program code executed by interpreter engine 310.
  • Shared library 314 may also comprise functions specified in the native machine code of the electronic device.
  • Stub executable 308 is used to invoke an instance of a given inter ⁇ preted program in interpreter engine 310. No other in ⁇ terpreted programs may be invoked in interpreter en- gine 310 using the same stub executable.
  • Communication entity 306 performs the communication related tasks in the electronic device. It comprises the protocol stacks that are used for the radio interface communi ⁇ cation and in the communication with a remote network such as the Internet. When communication entity 306 receives interpreted program 312 from the remote net ⁇ work, it is provided to an installer entity 304. In ⁇ staller entity 304 stores interpreted program 312 to electronic device non-volatile memory. Installer en- tity 304 creates a stub executable specific to inter ⁇ preted program 312.
  • installer entity uses a policy file in the form ⁇ ing of the necessary files as interpreted program 312 is installed to the non-volatile memory in electronic device 300.
  • Installer entity 304 may also be responsi ⁇ ble for the installing and configuring of shared li ⁇ brary 314 in non-volatile memory when it is downloaded to electronic device 300.
  • installer entity may also be responsible for the installing and config- uring of interpreter engine 310 and a prototype stub in non-volatile memory when the interpreter is down ⁇ loaded to electronic device 300.
  • Operating system en ⁇ tity 316 or installer entity 304 may be responsible for the assigning of trust levels and capabilities to shared libraries and interpreted programs.
  • installer entity 304 is an application executed within electronic device 300.
  • stub executable 308 is an application executed within electronic device 300 under operating system entity 316.
  • Interpreter en ⁇ gine 310 is a dynamically linked library in the native machine code of electronic device 300. Functions are invoked by stub executable 308 from the dynamically linked library.
  • the Microsoft macrovirus problem is an exam ⁇ ple of a worst-case of what the extent of the problem could be. It does not matter if the underlying operat ⁇ ing system is secure if the environments the programs run in are not (e.g. Word, Excel) .
  • the integration means that the significant aspects of the syntax and semantics of the operating system platform security are provided to the inter ⁇ preted program.
  • the following features are required: an interpreted program must have a unique identifica ⁇ tion, an interpreted program must have its own private directory, shared code libraries must have trust lev- els and the trust levels must be managed like individ ⁇ ual programs, an interpreted program must have a capa ⁇ bility set assigned to it, each interpreted program must execute in separate process contexts, and an in- terpreted program must be limited by its capability set .
  • the suggested method for implementing these is based on the following.
  • the main ideas are as fol ⁇ lows: placing an interpreter executable in a DLL /sys/bin/lang- ⁇ version->interpreter.dll (the ⁇ version> part denotes the version of the interpreter) , creating a stub executable /sys/bin/lang- ⁇ version>-stub- interpreter.exe (the ⁇ version> part denotes the ver ⁇ sion of the interpreter) , for each interpreted program is assigned a SID/VID pair as for any other program, the interpreted program files are placed in the direc ⁇ tory /private/ ⁇ SID>/, for each interpreted program X the /sys/bin/lang- ⁇ version->stub-interpreter.exe is copied to /sys/bin/interpreted-program-X.exe and the interpreted-program-X is assigned the capabilities X is to have, the stub-interpreter would always execute a designated program
  • This solution essentially maps interpreted programs onto the native operating system platform se- curity in such a manner that they will seem as native operating system programs.
  • An additional benefit is that it keeps the user experience similar to the case when capabilities are assigned to a native program.
  • This solution does not yet address how to assign trust levels to shared code. This is discussed in the next section.
  • the proposed design does not outright solve how trust levels are assigned to individual pieces of code external to the interpreted program. The problem is troublesome for the following reasons. Most inter- preted languages provide access to the interpreter from within the language (e.g. in Perl or Python via the eval() function) . Therefore any I/O source can be used to provide ready-to-run code (this is actually true for native programs also, but the presence of such code would deny certification) .
  • stub interpreter exe provides a neat way to attach capabilities to programs, but there is no easy way to attach capabilities to arbitrary in ⁇ put using the existing operating system mechanisms.
  • Adjusting capabilities at runtime may require changes to the operating system kernel .
  • a compromise solution is to require interpreters with capabilities to disable loading and running code from other sources than the scripts private directory.
  • SID/VID values are not assigned. SID/VID values are only assigned to binaries under /sys/bin.
  • a policy file format is defined that describes how to manage the interpreted program code that is shared between interpreted programs. The policy file would define the following: • How to manage the /sys/resource/ ⁇ lang> direc ⁇ tory
  • the directory /sys is a directory in which only the installer entity may write. But every program can read that directory.
  • the directories /private/ ⁇ SID> are directories, which may only be read by the installer entity or the program, which resides in that directory. The principle that the electronic device has these two type of directories is essential, not the actual names of the directories.
  • the advantage of using a policy definition file is that no interpreter-specific foreign code is executed in the context of the SWInstall, that is, the software installation program.
  • the policies of all in ⁇ terpreters can also be cross-referenced and checked for errors and conflicts before they are implemented.
  • the policy support required in this case is also ex ⁇ tremely simple.
  • Running code external to the private direc ⁇ tory and thef /sys/resource directory is dis- abled if the program has been granted ANY ca ⁇ pabilities (including User capabilities) .

Abstract

The invention relates to method for the secure interpretation of program in an electronic device. An interpreted program is loaded and a stub executable is formed using a prototype stub executable. The stub executable is associated with the interpreted program. At least one second capability also is assigned to the interpreted program and further to the stub executable. The stub executable invokes at least one function in a shared interpreter library to interpret the interpreted program. The interpreter engine checks whether the interpreted program refers an external interpreted program code section. The interpreted engine infers at least one second capability for the external interpreted program code section. The interpreter engine disallows the execution of said external interpreted program code section if said at least one first capability is not a subset of said at least one second capability.

Description

TITLE OF THE INVENTION
METHOD FOR THE SECURE INTERPRETATION OF PROGRAMS IN ELECTRONIC DEVICES
BACKGROUND OF THE INVENTION
Field of the invention:
The invention relates to interpreted program¬ ming languages. Particularly, the invention relates to a method for the secure interpretation of programs in electronic devices.
Description of the Related Art:
Security is an important factor in electronic communication devices. Nowadays mobile terminals have evolved from simple cellular telephones into multi¬ purpose communicator devices with applications similar to personal computers. The communicator devices come with a wide variety of services such as Internet browsing, E-mail and multimedia calls. One important technology, which is making its way to mobile termi¬ nals are various interpreted languages such as Java, Perl, PHP and Python. These interpreted language fur¬ ther increase the plethora of value-added services and games available in mobile terminals. The software de- veloped using these interpreted languages comprises separate programs and shared libraries. These programs and libraries may be downloaded over the air from a network server to a mobile terminal . The downloading of software mostly occurs by means of a browser pro- vided in the mobile terminal. It is important for the user to be able to trust the applications he or she downloads from the network. It is very easy to sneak malicious code into the mobile terminal, unless proper security procedures are applied in the mobile termi- nal . In a mobile terminal malicious code may cause a variety of nuisances. For example, calls may be set-up to chargeable service numbers without properly inform¬ ing the user, information may be gathered and stolen from the mobile terminal, and chargeable purchases may be made on behalf of the user, if the mobile terminal supports some kind of mobile payment system.
History shows several examples of malicious programs that have been written using interpreted lan¬ guages running within an interpreter on another plat¬ form. These malicious programs have either targeted the interpreted environment, the host environment or both. The malicious programs operation was feasible, because the interpreter's runtime environment did not provide sufficient isolation from other interpreted programs or the host platform. Application isolation in the context of this patent application is defined as the separation of the persistent state and runtime behavior of the programs. Programs may voluntarily share their data or react to the behavior of other programs. Modern features familiar to an expert on the field include data caging, runtime isolation of proc¬ esses, capability framework, process identifiers, In¬ ter-Process Communication (IPC) authentication, trusted computing base, perimeter defense and software installation programs of operating systems.
These features together isolate programs from each other, from the trusted computing base and from sensitive system interfaces. A noteworthy feature in contemporary operating systems is that the policy is enforced at the process boundary and as such the sys¬ tem is based on the isolation of processes and hence programs. The trusted computing base also denies pro¬ grams the ability to increase their privileges.
A secure kernel isolates native programs from each other. This implies that it is not possible to grant capabilities or access to resources to programs that are not isolated from each other. If it would be possible to grant capabilities to applications that were not isolated from each other then there would be no guarantees that the capabilities do not "leak" to malicious code. Essentially, the isolation of applica- tions is a critical underpinning of the capability framework.
The security features mentioned above are in¬ strumental in preventing the damage a malicious or de¬ fective program may do to the platform, to data or to other programs on the system. These features have been designed so that application isolation is provided for native programs. The system specifications do not at the moment suggest how application isolation would be provided for interpreted programs. This invention pro- poses a method by which this is achieved.
SUMMARY OF THE INVENTION:
The invention relates to a method for the se¬ cure interpretation programs in an electronic device. The method comprises: providing at least one shared interpreter library and a prototype stub executable in said electronic device, loading an interpreted program in said electronic device, forming a stub executable using said prototype stub executable in said elec- tronic device, associating said stub executable with said interpreted program in said electronic device, assigning at least one second capability to said stub executable, and executing said stub executable in said electronic device. The invention relates also to an electronic device comprising: at least one shared interpreter li¬ brary configured to implement an interpreter engine, an installer entity configured to load an interpreted program in said electronic device, to form a stub ex- ecutable using a prototype stub executable, to assign at least one second capability to said stub executa¬ ble, to associate said at least one second capability to said stub executable, and an operating system en¬ tity configured to execute said stub executable.
The invention relates also to a computer pro¬ gram comprising code adapted to perform the following steps when executed on a data-processing system: load¬ ing an interpreted program, forming a stub executable using a prototype stub executable, associating the stub executable with the interpreted program, assign¬ ing at least one second capability to the interpreted program, associating the at least one second capabil¬ ity to the stub executable, executing the stub execu¬ table, the stub executable indicating to at least one shared interpreter library the interpreted program, and the stub executable invoking at least one function in the shared interpreter library to interpret the in¬ terpreted program.
The invention relates also to a computer pro¬ gram comprising code adapted to perform the following steps when executed on a data-processing system: pro- viding at least one capability associated with said computer program to an interpreted program, obtaining information on an interpreted program from a, secure source assigned to said computer program, indicating to at least one shared interpreter library said inter- preted program, said at least one shared library com¬ prising at least one function implementing an inter¬ preter engine for interpreting interpreted program code, and invoking at least one function in said shared interpreter library to interpret said inter- preted program.
In one embodiment of the invention, the method further comprises: the stub executable indicat¬ ing to said at least one shared interpreter library said interpreted program, the stub executable invoking at least one function in said at least one shared in¬ terpreter library to interpret said interpreted pro¬ gram, checking whether an external interpreted program code section is referred by the interpreted program, inferring at least one first capability for said ex¬ ternal interpreted program code section; and disallow¬ ing the execution of said external interpreted program code section if said at least one second capability is not a subset of said at least one first capability.
In one embodiment of the invention, the at least one shared interpreter library is further con¬ figured to check whether an external interpreted pro- gram code section is referred by an interpreted pro¬ gram, to infer at least one first capability for said external interpreted program code section, and to dis¬ allow the execution of said external interpreted pro¬ gram code section if at least one second capability is not a subset of said at least one first capability.
In one embodiment of the invention, the se¬ cure source is a secure directory in an electronic de¬ vice. The secure source may, for example, be the com¬ puter program code itself or it may be the directory storing the computer program. The information on the interpreted program may be the file name of the inter¬ preted program. The secure source may also be the op¬ erating system, which provides to the computer program the filename of the file comprising the computer pro- gram.
It should be noted that the term external in¬ terpreted program code section refers to an inter¬ preted program code section that is obtained outside of the interpreted program itself, for example, from a directory different than the one reserved for the in¬ terpreted program in the electronic device. For exam¬ ple, the external interpreted program code section may be read from a shared interpreted library. An external interpreted program code section may also be obtained over-the-air during the interpretation of the inter¬ preted program. The term at least one first capability refers to the set of capabilities assigned to the ex- ternal interpreted program code section, for example, a shared interpreted library. The term at least one second capability refers to the set of capabilities of the stub executable. It should be noted that a single capability might comprise a number of individual oper¬ ating system, data communication or electronic device management related operations or functions. In other words, a number of functions may have been grouped in a single capability for convenience reason. A program or a piece of program code can have associated with it a set of capabilities. A capability grants access to a resource or function in the electronic device that would be otherwise unavailable to said program or pro¬ gram code. The capabilities are policed by the operat- ing system or the functions serving said program in the electronic device.
In one embodiment of the invention, a reli¬ ability category is determined for an interpreted pro¬ gram code section based on at least one of the loca- tion of a file comprising the interpreted program code section in the file system of the electronic device and whether the interpreted program code section has been received from a trusted remote sender, and the trust level is granted based the reliability category. In one embodiment of the invention, the exe¬ cution of arbitrary data is disabled in the at least one interpreter library. This means, for example, that the functions for the execution of arbitrary data are made inaccessible for the interpreter engine. The at- tempt to call such a function causes an error to be generated in the interpreter engine. In one embodiment of the invention, the stub executable is executed in a separate process context. The disabling may be per¬ formed beforehand as the interpreter engine is com- piled to produce the at least one shared interpreter library. This disabled version is then provided to the electronic device. In one embodiment of the invention, the ex¬ ternal interpreted program code section is loaded in said electronic device, for example, over-the-air from a network server. In one embodiment of the invention, the external interpreted program code section is a function within a shared interpreted library compris¬ ing interpreted program code. The external interpreted program code section may also be formed from arbitrary data by the interpreted program so that the inter- preted program code is passed by the interpreted pro¬ gram itself to the interpreter engine.
In one embodiment of the invention, a trust level is granted to the shared interpreted library. The trust level may be granted by the user or by the installer entity automatically. If the installer en¬ tity grants the trust level automatically, it may be obtained by inspecting trust level information pro¬ vided by a network server. The operator may have signed the trust level information. The signing may also have been performed by a service provider or any other trusted entity. The trust level is used to de¬ termine the at least one first capability either in the operating system entity level or in the installer entity level. In one embodiment of the invention, the load¬ ing of the interpreted program comprises the download¬ ing of the interpreted program from a network server.
In one embodiment of the invention, the pro¬ viding of the at least one shared interpreter library and the prototype stub executable comprises the down¬ loading of them from a network server to the elec¬ tronic device.
In one embodiment of the invention, the load¬ ing of the at least one shared interpreted library comprises the downloading of them from a network server to the electronic device. In one embodiment of the invention, the in¬ terpreted program is identified using a unique identi¬ fier in the electronic device. The unique identifier may be used, for example, by the operating system en- tity and the installer entity to refer to the inter¬ preted program and the stub executable. The at least one second capability may be associated by the operat¬ ing system entity with the unique identifier.
In one embodiment of the invention, the elec- tronic device comprises a mobile terminal. In one em¬ bodiment of the invention, the electronic device com¬ prises a SYMBIAN™ operating system device. In one em¬ bodiment of the invention, the electronic device com¬ prises a General Packet Radio System terminal or a Universal Mobile Telecommunications System terminal.
In one embodiment of the invention, the com¬ puter program is stored on a computer readable medium. The computer readable medium may be a removable memory card, magnetic disk, optical disk or magnetic tape. In one embodiment of the invention, the elec¬ tronic device is a mobile device, for example, a lap¬ top computer, a palmtop computer, a mobile terminal or a personal digital assistant (PDA) . In one embodiment of the invention, the electronic device is a desktop computer or a mainframe computer.
The benefits of the invention are related to the improved reliability of loaded interpreted pro¬ grams. The invention enables the capabilities defined for executable programs in the native operating system to be applied for interpreted programs and program code per program or program code that are executed within an interpreter which otherwise would be seen as a single arbitrary application in the native operating system with a single set of capabilities. BRIEF DESCRIPTION OF THE DRAWINGS:
The accompanying drawings, which are included to provide a further understanding of the invention and constitute a part of this specification, illus- trate embodiments of the invention and together with the description help to explain the principles of the invention. In the drawings:
Fig. 1 is a block diagram illustrating an ex¬ ample of a directory tree in an electronic device ac- cording to the invention;
Fig. 2A and Fig. 2B are a flow chart illus¬ trating the method for the secure interpretation of programs in one embodiment of the invention; and
Fig. 3 is a block diagram illustrating an electronic device according to the invention.
DETAILED DESCRIPTION OF THE EMBODIMENTS:
Reference will now be made in detail to the embodiments of the present invention, examples of which are illustrated in the accompanying drawings.
Figure 1 is a block diagram illustrating an example of a directory tree in an electronic device according to the invention. The electronic device is as illustrated in Figure 3. In one embodiment of the invention the electronic device is a SYMBIAN™ operat¬ ing system device. The directory tree illustrates what files essential to the method are stored in an elec¬ tronic device according to the invention and what their mutual relationships are. In Figure 1 there is a root node 100, to which subdirectories 101, 102 and
103 are connected. The subdirectory 101 stores binary files, which implement an interpreter. The interpreter may be, for example, a Java interpreter, a Perl inter¬ preter, A PHP interpreter or a Python interpreter. In subdirectory 101 there are files 111, 112 and 113. File 111 comprises the engine for an interpreter, which executes either directly the program source code or a byte code that has been produced using a com¬ piler. The program source code or the byte code that is interpreted by the interpreter engine is hereinaf- ter referred to as the interpreted program code. The compiler takes a human readable source code and com¬ piles it into a byte code. However, it should be noted that the byte code might be any intermediate language, which may be executed by the interpreter engine. The intermediate language may be in any format optimal for machine execution. It does not necessarily have to comprise operation codes of the size of one byte. In essence file 111 is a Dynamically Linked Library
(DLL) , which comprises functions for the execution of the interpreter engine. File 112 is a stub interpreter executable, which when executed, invokes eventually the interpreter engine placed in file 111. File 113 is formed by means of file 112 whenever an interpreted program is installed to the electronic device. A subdirectory 102 comprises a program, which is to be interpreted using the interpreter engine. Subdirectory 102 comprises a file 121, which comprises the interpreted program. The component <SID> in the subdirectory name represents a Security Identifier (SID) , which has been assigned to the interpreted pro¬ gram. The SID identifies uniquely the interpreted pro¬ gram and enables capabilities be assigned to the in¬ terpreted program. A capability represents an operat¬ ing system function or a set of operating system func- tions that may be invoked by an application identified using a SID. Examples of capabilities include the ca¬ pability to set-up and communicate over a remote net¬ work, for example, to a remote Internet server, and the capability to access files stored on the elec- tronic device. A single capability may comprise a num¬ ber of related functions and operations. For example, all IP socket related functions might comprise a sin- gle capability. Other capabilities may relate to power management, local communication over BLUETOOTH™ or in¬ frared and low-level radio protocol operations.
A subdirectory 103 comprises a shared Ii- brary, which comprises functions that are to be in¬ voked from interpreted programs such as the inter¬ preted program stored in file 121. The shared library is stored in a file 131. Subdirectory 132 comprises also a policy file, which governs the policies how the shared library is managed in the electronic device. The policy file would define how to manage the /resource/<lang> directory and how to create the lang- <version->-stub-interpreter.exe for bootstrapping the interpreter for a certain script. The advantage of us- ing a policy definition file is that no interpreter- specific foreign code is executed in the context of the software installation program. The policies of all interpreters can also be cross-referenced and checked for errors and conflicts before they are implemented. The policy support required in this case is also ex¬ tremely simple. The shared interpreted library is as¬ signed a trust level, in other words, a set of capa¬ bilities that are allowed for the functions in the li¬ brary. The set of capabilities are either operator de- termined or user determined. In the case of operator determination, the capabilities are indicated to the electronic device as the file is downloaded from a network server. The capabilities are verified, for ex¬ ample, so that they are signed using the operator's digital signature. In the case of user determination, the user is prompted to indicate what capabilities are to be allowed for the library. The capabilities as¬ signed to the shared interpreted library should re¬ flect what functionalities have been tested and are thus considered reliable in the case of the library. For example, a library may be considered safe to down- load files to the electronic device, but may not be allowed to read files in the electronic device.
Figures 2A and 2B are a flow chart illustrat¬ ing the method for the secure interpretation of pro- grams in one embodiment of the invention.
At step 202 a shared interpreter library com¬ prising the main interpreter code, that is, the inter¬ preter engine is provided to the electronic device. The shared library may be provided, for example, as part of the native operating system or it may be down¬ loaded over the air to the electronic device from a network server as the user requests the downloading of the interpreter.
At step 204 a prototype stub executable com- prising the functions necessary to invoke the inter¬ preter engine for the interpretation of a single in¬ terpreted program is provided to the electronic de¬ vice. The prototype stub executable may be provided, for example, as part of the native operating system or it may be downloaded over the air to the electronic device as the user requests the downloading of the in¬ terpreter from the network server. The installation of the shared interpreter library, comprising the main interpreter code, and the prototype stub executable may be performed in a separate installer entity, which stores them to a non-volatile memory in the electronic device.
In one embodiment of the invention, a shared interpreted library is also loaded to the electronic device. The shared library may be loaded to the elec¬ tronic device using a removable memory medium such as a magnetic or optical disk or a removable memory card or it may be downloaded over the air to the electronic device. The installation of the shared interpreted Ii- brary may be performed in a separate installer entity, which stores it to a non-volatile memory in the elec¬ tronic device. Optionally, at step 206 a trust level is granted to a shared interpreted library in the elec¬ tronic device. The trust level specifies a set of ca¬ pabilities assigned to the shared interpreted library. The granting decision may be based on trust level in¬ formation signed by the operator or any other entity trusted by the electronic device. The trust is estab¬ lished, for example, by means of Public Key Infra¬ structure (PKI) and trust chains. The user of the electronic device may also explicitly specify the granting decision via the user interface of the elec¬ tronic device.
At step 208 the interpreted program is loaded to the electronic device. The interpreted program is, for example, downloaded over the air. The interpreted program may have been selected by the user from a WWW- page or a WAP-page. The interpreted program is down¬ loaded, for example, from a network server to which the electronic device has established a connection. The installing of the interpreted program may be per¬ formed by an installer entity. In one embodiment of the invention, the interpreted program may also be loaded to the electronic device using a removable mem¬ ory medium such as a magnetic or optical disk or a re- movable memory card.
At step 210 a unique identifier is assigned to the interpreted program. The interpreted program may use functions in the shared library that may have been downloaded to the electronic device. The unique identifier is obtained from an authority, which is re¬ sponsible for allocating unique identifiers for appli¬ cations executed in the electronic device.
At step 212 the capabilities to be granted to the interpreted program are determined in the elec- tronic device. For example, the capabilities are de¬ termined by analyzing the interpreted program code of the interpreted program or they may be specified in a separate file or data structure provided in associa¬ tion with the interpreted program from the network server or from a removable memory medium. There may also be interpreted programs for which no capabilities are granted. In such as case the interpreted program is merely allowed to render information to the display and to interact with the user using the keyboard.
At step 214 a stub executable is formed using the prototype stub executable. The stub executable is formed for invoking the interpreter engine and for de¬ termining the interpreted program to the interpreter engine. The stub executable is formed using the proto¬ type stub executable. The stub executable may be formed using instructions provided in a separate pol- icy file, which is provided, for example, in associa¬ tion with the shared interpreted library or in asso¬ ciation with the interpreted program. The forming of stub executable may be performed by an installer en¬ tity. At step 216 the running of other programs from the stub executable is disabled. The disabling is achieved, for example, so that the stub executable ex¬ plicitly indicates to the interpreter engine the in¬ terpreted program that is to be executed. The inter- preted program is indicated, for example, by providing its filename such as file 121 in Figure 1.
At step 218 the capabilities determined for the interpreted program are assigned to the stub ex¬ ecutable formed at step 214 in the electronic device. The stub executable will represent the interpreted program for the operating system security functions. Due to the fact that the stub executable is used to invoke the interpreter engine and to provide the in¬ terpreted program to the interpreter engine it is en- sured that no other interpreted program code than the interpreted program or functions in the shared inter¬ preted library are executed. In other words, there is no other possibility for interpreted programs to get executed in the interpreter engine than via a stub ex¬ ecutable.
The label "A" represents the point where the method illustrated in Figure 2A continues in Figure 2B.
At step 220 the process in charge of inter¬ preting the interpreted program by means of the stub executable and the interpreter engine is executed in a separate process context by the operating system of the electronic device. For each interpreted program there is a separate process context.
At step 222 it is checked by the interpreter engine whether the program is at end. If the program is not at end, the method continues at step 224.
At step 224 it is checked by the interpreter engine whether external interpreted program code is to be interpreted by it. If this is the case, method con¬ tinues at step 226, otherwise the method continues at step 220. An example of an external interpreted pro¬ gram code is code included in a shared interpreted li¬ brary. Another example of an external interpreted pro¬ gram code is code that has been received to the elec¬ tronic device during the interpretation of the current code.
At step 226 the trust level of the external interpreted program code is compared to the capabili¬ ties of the stub executable by the interpreter engine. It is determined that the capabilities of the stub ex- ecutable are a subset of the capabilities associated with the trust level of the external interpreted pro¬ gram code, that is, for example, the shared inter¬ preted library. A given trust level uniquely specifies the set of capabilities that has been assigned to an external interpreted program code. The trust level is inferred, for example, based on the location of the external interpreted program code in the electronic device file system. For example, if the code is lo¬ cated in a trusted directory such as the directory of the interpreted program or a language specific trusted directory, it is granted at least the capabilities of the interpreted program. If the capabilities of the stub executable are not a subset of the capabilities associated with the trust level, in other words, the stub executable has capabilities not belonging to the set of capabilities specified for the external inter- preted program code, the interpreter engine considers the trust level to be exceeded.
At step 228 the interpreter engine checks, if the trust level was exceeded. If it was exceeded, the method continues at step 230. Otherwise the method continues at step 220.
At step 230 the interpreter engine disallows the program execution. The user may be provided with an appropriate error message and the execution of the stub executable is terminated. Figure 3 is a block diagram illustrating an electronic device 300 according to the invention. Electronic device 300 comprises a first memory (not shown) and a second memory (not shown) . The first mem¬ ory is a volatile RAM work memory and the second mem- ory is a non-volatile memory. In one embodiment of the invention the first and the second memories are the same memory, which is non-volatile. The electronic de¬ vice also comprises a processor (not shown) .
In Figure 3 there is a box 302, which illus- trates the software in the electronic device. The software comprises at least an operating system entity 316, an installer entity 304 and a communication en¬ tity 306. The software may also comprise an inter¬ preter engine 310 and a stub executable 308 associated with interpreter engine 310. Interpreter engine 310 executes the interpreted program codes for interpreted programs such as interpreted program 312. The inter- preted programs may use at least one function stored in a shared library 314. Shared library 314 comprises functions specified in the interpreted program code executed by interpreter engine 310. Shared library 314 may also comprise functions specified in the native machine code of the electronic device. Stub executable 308 is used to invoke an instance of a given inter¬ preted program in interpreter engine 310. No other in¬ terpreted programs may be invoked in interpreter en- gine 310 using the same stub executable. Communication entity 306 performs the communication related tasks in the electronic device. It comprises the protocol stacks that are used for the radio interface communi¬ cation and in the communication with a remote network such as the Internet. When communication entity 306 receives interpreted program 312 from the remote net¬ work, it is provided to an installer entity 304. In¬ staller entity 304 stores interpreted program 312 to electronic device non-volatile memory. Installer en- tity 304 creates a stub executable specific to inter¬ preted program 312. In one embodiment of the inven¬ tion, installer entity uses a policy file in the form¬ ing of the necessary files as interpreted program 312 is installed to the non-volatile memory in electronic device 300. Installer entity 304 may also be responsi¬ ble for the installing and configuring of shared li¬ brary 314 in non-volatile memory when it is downloaded to electronic device 300. Similarly, installer entity may also be responsible for the installing and config- uring of interpreter engine 310 and a prototype stub in non-volatile memory when the interpreter is down¬ loaded to electronic device 300. Operating system en¬ tity 316 or installer entity 304 may be responsible for the assigning of trust levels and capabilities to shared libraries and interpreted programs. In one em¬ bodiment of the invention, installer entity 304 is an application executed within electronic device 300. In one embodiment of the invention, stub executable 308 is an application executed within electronic device 300 under operating system entity 316. Interpreter en¬ gine 310 is a dynamically linked library in the native machine code of electronic device 300. Functions are invoked by stub executable 308 from the dynamically linked library.
In the following text is described one em¬ bodiment of the invention, where the method of the in- vention is applied in SYMBIAN™ operating system envi¬ ronment. The importance of isolating interpreted ap¬ plications from each other and the host platform is relative to the importance of the data manipulated and the functionality provided by these interpreted pro- grams. If only one program is implemented for an in¬ terpreter then application isolation is performed im¬ plicitly.
A case where application isolation becomes critical is when a majority of the applications is im- plemented using a single interpreter. A significant amount of the platform security work would be left re¬ dundant it the interpreter did not apply platform se¬ curity correctly. This could leave a malicious program the ability to target the valuable data of other in- terpreted programs.
The Microsoft macrovirus problem is an exam¬ ple of a worst-case of what the extent of the problem could be. It does not matter if the underlying operat¬ ing system is secure if the environments the programs run in are not (e.g. Word, Excel) .
The integration means that the significant aspects of the syntax and semantics of the operating system platform security are provided to the inter¬ preted program. The following features are required: an interpreted program must have a unique identifica¬ tion, an interpreted program must have its own private directory, shared code libraries must have trust lev- els and the trust levels must be managed like individ¬ ual programs, an interpreted program must have a capa¬ bility set assigned to it, each interpreted program must execute in separate process contexts, and an in- terpreted program must be limited by its capability set .
The suggested method for implementing these is based on the following. The main ideas are as fol¬ lows: placing an interpreter executable in a DLL /sys/bin/lang-<version->interpreter.dll (the <version> part denotes the version of the interpreter) , creating a stub executable /sys/bin/lang-<version>-stub- interpreter.exe (the <version> part denotes the ver¬ sion of the interpreter) , for each interpreted program is assigned a SID/VID pair as for any other program, the interpreted program files are placed in the direc¬ tory /private/<SID>/, for each interpreted program X the /sys/bin/lang-<version->stub-interpreter.exe is copied to /sys/bin/interpreted-program-X.exe and the interpreted-program-X is assigned the capabilities X is to have, the stub-interpreter would always execute a designated program from its private directory, a general purpose shared code is placed in /resource/<lang>/lib, any required native DLLs are placed in /sys/bin, and a file dictating the policy to be used for managing shared code is placed under /resource/<lang>/policy.txt .
This solution essentially maps interpreted programs onto the native operating system platform se- curity in such a manner that they will seem as native operating system programs. An additional benefit is that it keeps the user experience similar to the case when capabilities are assigned to a native program This solution does not yet address how to assign trust levels to shared code. This is discussed in the next section. The proposed design does not outright solve how trust levels are assigned to individual pieces of code external to the interpreted program. The problem is troublesome for the following reasons. Most inter- preted languages provide access to the interpreter from within the language (e.g. in Perl or Python via the eval() function) . Therefore any I/O source can be used to provide ready-to-run code (this is actually true for native programs also, but the presence of such code would deny certification) .
Based on monitoring the external I/O of an interpreter one cannot deduce what input data is used as code and what as data.
Using the stub interpreter exe provides a neat way to attach capabilities to programs, but there is no easy way to attach capabilities to arbitrary in¬ put using the existing operating system mechanisms.
Based on the above it is clear that any sane mechanism for attaching trust levels for general pur- pose code requires support from the actual inter¬ preter. There are two options available for this: de¬ nying the loading/running code that would cause not trusted code to be run with capabilities, the intro¬ duction of lower capabilities at runtime based on what source the code came from.
Adjusting capabilities at runtime may require changes to the operating system kernel . A compromise solution is to require interpreters with capabilities to disable loading and running code from other sources than the scripts private directory.
For shared code libraries in /sys/resource SID/VID values are not assigned. SID/VID values are only assigned to binaries under /sys/bin. A policy file format is defined that describes how to manage the interpreted program code that is shared between interpreted programs. The policy file would define the following: • How to manage the /sys/resource/<lang> direc¬ tory
• How to create the lang-<version->-stub- interpreter.exe for bootstrapping the inter- preter for a certain script
The directory /sys is a directory in which only the installer entity may write. But every program can read that directory. The directories /private/<SID> are directories, which may only be read by the installer entity or the program, which resides in that directory. The principle that the electronic device has these two type of directories is essential, not the actual names of the directories.
The advantage of using a policy definition file is that no interpreter-specific foreign code is executed in the context of the SWInstall, that is, the software installation program. The policies of all in¬ terpreters can also be cross-referenced and checked for errors and conflicts before they are implemented. The policy support required in this case is also ex¬ tremely simple.
The interpreters should have the following features implemented into them:
• The default directory used within the scripts is /private/<SID>. If files are to be glob¬ ally readable/writable, then this must be de¬ clared explicitly.
• Running code external to the private direc¬ tory and thef /sys/resource directory is dis- abled if the program has been granted ANY ca¬ pabilities (including User capabilities) . One may wish to have a special "developer-switch" that disables this feature.
• If User-capabilities have been granted then program code can only be loaded from the pro¬ grams private directory and the shared code directory. • If System-capabilities have been granted then program code can only be loaded from the pro¬ grams private directory.
It is obvious to a person skilled in the art that with the advancement of technology, the basic idea of the invention may be implemented in various ways. The invention and its embodiments are thus not limited to the examples described above; instead they may vary within the scope of the claims.

Claims

CLAIMS :
1. A method for the secure interpretation of a program in an electronic device, the method compris¬ ing: providing at least one shared interpreter library and a prototype stub executable in said electronic de¬ vice; loading an interpreted program in said electronic device; forming a stub executable using said prototype stub executable in said electronic device; associating said stub executable with said inter¬ preted program in said electronic device; assigning at least one second capability to said stub executable; and executing said stub executable in said electronic device.
2. The method according to claim 1, the method further comprising: said stub executable indicating to said at least one shared interpreter library said interpreted pro¬ gram; said stub executable invoking at least one func¬ tion in said at least one shared interpreter library to interpret said interpreted program,- checking whether an external interpreted program code section is referred by the interpreted program; inferring at least one first capability for said external interpreted program code section; and disallowing execution of said external interpreted program code section if said at least one second capa¬ bility is not a subset of said at least one first ca¬ pability.
3. The method according to claim 2, the method further comprising: loading said external interpreted program code section in said electronic device; and executing said stub executable in a separate proc¬ ess context.
4. The method according to claim 2, wherein said loading of said interpreted program code section comprises downloading it from a network server to said electronic device.
5. The method according to claim 2, the method further comprising: granting a trust level to said external inter- preted program code section; and determining the said at least one first capability based on said trust level .
6. The method according to claim 5, the method further comprising: determining a reliability category for an inter¬ preted program code section based on at least one of a location of a file comprising said interpreted program code section in the file system of said electronic de¬ vice and whether said interpreted program code section has been received from a trusted remote sender; and granting said trust level based said reliability category.
7. The method according to claim 1, wherein said loading of said interpreted program comprises the downloading of said interpreted program from a network server.
8. The method according to claim 1, wherein said providing of said at least one shared interpreter library and said prototype stub executable comprises downloading them from a network server to said elec¬ tronic device.
9. The method according to claim 1, wherein said interpreted program is identified using a unique identifier in said electronic device.
10. The method according to claim 1, wherein said electronic device is a mobile terminal .
11. The method according to claim 1, wherein said electronic device is a SYMBIAN™ operating system device.
12. The method according to claim 1, wherein said electronic device is a General Packet Radio Sys¬ tem terminal or a Universal Mobile Telecommunications System terminal .
13. An electronic device comprising: at least one shared interpreter library configured to implement an interpreter engine; an installer entity configured to load an inter¬ preted program in said electronic device, to form a stub executable using a prototype stub executable, to associate said stub executable with said interpreted program, to assign said at least one second capability to said stub executable; and an operating system entity configured to execute said stub executable.
14. The electronic device according to claim 13, wherein said at least one shared interpreter li¬ brary is further configured to check whether an external interpreted program code section is referred by an interpreted program, to infer at least one first capability for said external interpreted program code section, and to disallow execution of said external interpreted program code section if at least one second capability is not a subset of said at least one first capability.
15. The electronic device according to claim 14, wherein said loading of said at least one inter¬ preted program code section comprises downloading it from a network server to said electronic device.
16. The electronic device according to claim 14, wherein said installer entity is further config- ured to load said external interpreted program code section in said electronic device and said operating system entity is further configured to execute said stub executable in a separate process context.
17. The electronic device according to claim 14, wherein said at least one shared interpreter Ii- brary is further configured to grant a trust level to said external interpreted program code section and to determine the said at least one first capability based on said trust level .
18. The electronic device according to claim 13, wherein said loading of said interpreted program comprises downloading said interpreted program from a network server.
19. The electronic device according to claim 13, wherein said installer entity is further config- ured to download said at least one shared interpreter library and said prototype stub executable from a net¬ work server to said electronic device.
20. The electronic device according to claim 13, wherein said operating system entity is further configured to identify said interpreted program using a unique identifier.
21. The electronic device according to claim 13, wherein said electronic device is a mobile termi¬ nal .
22. The electronic device according to claim
13, wherein said electronic device is a SYMBIAN™ oper¬ ating system device.
23. The electronic device according to claim 13, wherein said electronic device is a General Packet Radio System terminal or a Universal Mobile Telecommu¬ nications System terminal.
24. A computer program comprising code adapted to perform the following steps when executed on a data-processing system: loading an interpreted program; forming a stub executable using a prototype stub executable; associating said stub executable with said inter¬ preted program; assigning at least one second capability to said interpreted program; associating said at least one second capability to said stub executable; executing said stub executable; said stub executable indicating to at least one shared interpreter library said interpreted program; and said stub executable invoking at least one func¬ tion in said shared interpreter library to interpret said interpreted program.
25. The computer program according to claim 24, wherein said computer program is stored on a com¬ puter readable medium.
26. The computer program according to claim 25, wherein said computer readable medium is a remov¬ able memory card.
27. The computer program according to claim
25, wherein said computer readable medium is a mag¬ netic or an optical disk.
28. A computer program comprising code adapted to perform the following steps when executed on a data-processing system: providing at least one capability associated with said computer program to an interpreted program; obtaining information on said interpreted program from a secure source assigned to said computer pro- gram; indicating to at least one shared interpreter li¬ brary said interpreted program, said at least one shared library comprising at least one function imple¬ menting an interpreter engine for interpreting inter- preted program code; and invoking at least one function in said shared in¬ terpreter library to interpret said interpreted pro¬ gram.
29. The computer program according to claim 28, wherein said secure source is a secure directory in an electronic device.
30. The computer program according to claim 28, wherein said computer program is stored on a com¬ puter readable medium.
31. The computer program according to claim
30, wherein said computer readable medium is a remov¬ able memory card.
32. The computer program according to claim 30, wherein said computer readable medium is a mag- netic or an optical disk.
PCT/FI2005/000504 2004-11-24 2005-11-24 Method for the secure interpretation of programs in electronic devices WO2006056646A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP05817859A EP1815381A1 (en) 2004-11-24 2005-11-24 Method for the secure interpretation of programs in electronic devices
JP2007542018A JP4638505B2 (en) 2004-11-24 2005-11-24 Safe program interpretation method in electronic devices

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US99680104A 2004-11-24 2004-11-24
US10/996,801 2004-11-24
FI20041517 2004-11-25
FI20041517A FI20041517A0 (en) 2004-11-25 2004-11-25 Procedure for safe interpretation of programs in electronic devices

Publications (1)

Publication Number Publication Date
WO2006056646A1 true WO2006056646A1 (en) 2006-06-01

Family

ID=36497763

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI2005/000504 WO2006056646A1 (en) 2004-11-24 2005-11-24 Method for the secure interpretation of programs in electronic devices

Country Status (3)

Country Link
EP (1) EP1815381A1 (en)
JP (1) JP4638505B2 (en)
WO (1) WO2006056646A1 (en)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2659742C1 (en) 2017-08-17 2018-07-03 Акционерное общество "Лаборатория Касперского" Method for emulating the execution of files comprising instructions, different from machine instructions

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5974549A (en) * 1997-03-27 1999-10-26 Soliton Ltd. Security monitor
US6044467A (en) * 1997-12-11 2000-03-28 Sun Microsystems, Inc. Secure class resolution, loading and definition
US20030093660A1 (en) * 2001-10-17 2003-05-15 Safa John Aram Software Loading
US20040039926A1 (en) * 2000-10-11 2004-02-26 Lambert Martin Richard Methods of providing java tamperproofing

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003202929A (en) * 2002-01-08 2003-07-18 Ntt Docomo Inc Distribution method and distribution system
JP2004272594A (en) * 2003-03-07 2004-09-30 Sony Corp Data use device, data use method and computer program

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5974549A (en) * 1997-03-27 1999-10-26 Soliton Ltd. Security monitor
US6044467A (en) * 1997-12-11 2000-03-28 Sun Microsystems, Inc. Secure class resolution, loading and definition
US20040039926A1 (en) * 2000-10-11 2004-02-26 Lambert Martin Richard Methods of providing java tamperproofing
US20030093660A1 (en) * 2001-10-17 2003-05-15 Safa John Aram Software Loading

Also Published As

Publication number Publication date
JP2008521111A (en) 2008-06-19
JP4638505B2 (en) 2011-02-23
EP1815381A1 (en) 2007-08-08

Similar Documents

Publication Publication Date Title
US7444624B2 (en) Method for the secure interpretation of programs in electronic devices
KR101456489B1 (en) Method and apparatus for managing access privileges in a CLDC OSGi environment
Heuser et al. {ASM}: a programmable interface for extending android security
US7231635B2 (en) Remote incremental program verification using API definitions
US6986132B1 (en) Remote incremental program binary compatibility verification using API definitions
Gong Secure Java class loading
US6883163B1 (en) Populating resource-constrained devices with content verified using API definitions
EP1967981A1 (en) Program execution control method, device, and execution control program
US6981245B1 (en) Populating binary compatible resource-constrained devices with content verified using API definitions
EP2549380A1 (en) Information processing device, virtual machine generation method, and application software distribution system
WO2011138852A1 (en) Information processing device, information processing method, and program distribution system
RU2339076C2 (en) Execution of non-verified programs in radio communication device
JP2008524686A (en) Method for maintaining an application in a computer device
JP2005500608A (en) Application-level access privileges to storage on computer devices
US8200938B2 (en) Computer system and method providing a memory buffer for use with native and platform-independent software code
US20050172286A1 (en) Hosted code runtime protection
US8667512B2 (en) Flexible hierarchical settings registry for operating systems
US20120254969A1 (en) Systems and methods for implementing security services
WO2009059473A1 (en) Java-based terminal system
WO2006056646A1 (en) Method for the secure interpretation of programs in electronic devices
WO2002023331A2 (en) Remote incremental program binary compatibility verification using api definitions
JP2008521111A5 (en)
KR100998923B1 (en) Method and Apparatus for transmitting contents with authorized control of system
AU2001290842B2 (en) Remote incremental program binary compatibility verification using API definitions
AU2001289078B2 (en) Method for remote incremental program verification and installation on resource-constrained devices

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KN KP KR KZ LC LK LR LS LT LU LV LY MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2005817859

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2007542018

Country of ref document: JP

WWE Wipo information: entry into national phase

Ref document number: 200580040204.7

Country of ref document: CN

NENP Non-entry into the national phase

Ref country code: DE

WWP Wipo information: published in national office

Ref document number: 2005817859

Country of ref document: EP