WO2006056646A1 - Procede destine a interpreter de façon securisee des programmes dans des dispositifs electroniques - Google Patents

Procede destine a interpreter de façon securisee des programmes dans des dispositifs electroniques 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
English (en)
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/fi
Application filed by Nokia Corporation filed Critical Nokia Corporation
Priority to EP05817859A priority Critical patent/EP1815381A1/fr
Priority to JP2007542018A priority patent/JP4638505B2/ja
Publication of WO2006056646A1 publication Critical patent/WO2006056646A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring 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/53—Monitoring 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing 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/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements 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/44—Arrangements for executing specific programs
    • G06F9/451—Execution 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) .

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

L'invention concerne un procédé destiné à interpréter de façon sécurisée un programme dans un dispositif électronique. Un programme interprété est chargé et un module de remplacement exécutable formé au moyen d'un module de remplacement exécutable prototype. Le module de remplacement exécutable est associé au programme interprété. Au moins une seconde capacité est également attribuée au programme interprété, puis au module de remplacement exécutable. Le module de remplacement exécutable appelle au moins une fonction dans une bibliothèque d'interprétation partagée afin d'interpréter le programme interprété. Le moteur d'interprétation vérifie si le programme interprété se réfère à une section de code ce programme interprété externe. Le moteur interprété suppose au moins une seconde capacité pour le code de section de programme interprété externe. Le moteur d'interprétation empêche l'exécution de la section de code de programme interprété externe si la première capacité ne consiste pas en un sous-ensemble de la seconde.
PCT/FI2005/000504 2004-11-24 2005-11-24 Procede destine a interpreter de façon securisee des programmes dans des dispositifs electroniques WO2006056646A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP05817859A EP1815381A1 (fr) 2004-11-24 2005-11-24 Procede destine a interpreter de façon securisee des programmes dans des dispositifs electroniques
JP2007542018A JP4638505B2 (ja) 2004-11-24 2005-11-24 電子デバイス内の安全なプログラム解釈方法

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US99680104A 2004-11-24 2004-11-24
US10/996,801 2004-11-24
FI20041517A FI20041517A0 (fi) 2004-11-25 2004-11-25 Menetelmä elektroniikkalaitteiden ohjelmien turvalliseen tulkintaan
FI20041517 2004-11-25

Publications (1)

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

Family

ID=36497763

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FI2005/000504 WO2006056646A1 (fr) 2004-11-24 2005-11-24 Procede destine a interpreter de façon securisee des programmes dans des dispositifs electroniques

Country Status (3)

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

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
RU2659742C1 (ru) * 2017-08-17 2018-07-03 Акционерное общество "Лаборатория Касперского" Способ эмуляции исполнения файлов, содержащих инструкции, отличные от машинных

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 (ja) * 2002-01-08 2003-07-18 Ntt Docomo Inc 配信方法および配信システム
JP2004272594A (ja) * 2003-03-07 2004-09-30 Sony Corp データ利用装置及びデータ利用方法、並びにコンピュータ・プログラム

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 (ja) 2008-06-19
EP1815381A1 (fr) 2007-08-08
JP4638505B2 (ja) 2011-02-23

Similar Documents

Publication Publication Date Title
US7444624B2 (en) Method for the secure interpretation of programs in electronic devices
KR101456489B1 (ko) ＣＬＤＣ ＯＳＧｉ 환경에서 어플리케이션의 접속 권한을관리하는 방법 및 장치
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 (fr) Dispositif, méthode de contrôle d exécution de programme et programme de contrôle d exécution
US6981245B1 (en) Populating binary compatible resource-constrained devices with content verified using API definitions
EP2549380A1 (fr) Dispositif de traitement d'informations, procédé de génération de machine virtuelle, et système de distribution de logiciel d'application
WO2011138852A1 (fr) Dispositif de traitement d'informations, procédé de traitement d'informations et système de distribution de programmes
RU2339076C2 (ru) Выполнение неверифицированных программ в операционной среде устройства радиосвязи
JP2008524686A (ja) コンピュータ装置においてアプリケーションを保守する方法
JP2005500608A (ja) コンピュータ装置上の記憶領域へのアプリケーションレベルのアクセス特権
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
US8732811B2 (en) Systems and methods for implementing security services
WO2009059473A1 (fr) Système de terminal basé sur java
EP1815381A1 (fr) Procede destine a interpreter de façon securisee des programmes dans des dispositifs electroniques
WO2002023331A2 (fr) Verification incrementielle a distance de la compatibilite binaire d'un programme au moyen de definitions ipa
JP2008521111A5 (fr)
KR100998923B1 (ko) 시스템의 관리 권한이 설정된 컨텐츠의 전송 방법 및 장치
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