JP2008521111A5 - - Google Patents

Description

Safe program interpretation method in electronic devices Background of the Invention

(Technical field)
The present invention relates to an interpreted programming language. In particular, the present invention relates to a safe program interpretation method in an electronic device.

(Background technology)
Security is an important factor in electronic communication devices. Modern mobile terminals have evolved from simple mobile phones to multipurpose communication devices with applications similar to personal computers. These communication devices are equipped with various services such as Internet browsing, e-mail, multimedia calls and so on. One important technology for mobile terminals is a variety of interpreted languages such as Java, Perl, PHP, Python, and the like. By using these interpreted languages , the types of value-added services and games that can be used on mobile terminals are dramatically increasing. Software developed using these interpreted languages includes individual programs and shared libraries. These programs and libraries can be downloaded from the network server to the mobile terminal via radio.

  Software download is mainly performed using a browser provided in the mobile terminal. It is important that the user can trust the application downloaded from the network. Unless appropriate security procedures are applied to the mobile terminal, it is very easy to put malicious code on the mobile terminal. Malicious code can cause various problems with mobile terminals. For example, a phone may be set up with a billing service number without proper notification to the user, information may be collected from the mobile device and stolen, and the mobile device supports certain mobile payment systems. If so, there is a risk that the user will be impersonated and make a purchase.

Some examples of malicious programs reported to date have been created using interpreted languages that run in interpreters on other platforms. These malicious programs are a interpretive environment or host environment, or both targets. The reason that malicious programs can operate is that the interpreter's execution environment was unable to properly isolate them from other interpreted programs or host platforms.

In the context of the present application, application isolation is defined as separating the persistent state of the program from the runtime behavior. Each program can spontaneously share each other's data or react to the behavior of other programs.

  Current features known to industry experts include data caging, run-time process isolation, capability framework, process identifier, inter-process communication (IPC) authentication, trusted computing base , Boundary defense, and operating system software installation programs.

  Programs are isolated from each other by linking these functions, isolated from the trusted computing base, and isolated from critical system interfaces. A notable feature of current operating systems is that because the policy is enforced at process boundaries, the system is based on process isolation and therefore program isolation. By using a trusted computing base, the ability of each program to increase its privileges is also denied.

  A secure kernel isolates native programs from each other. In other words, it becomes impossible to grant capabilities or access rights to resources to programs that are not isolated from each other. If capabilities can be granted to applications that are not isolated from each other, there is no guarantee that the capabilities will not "leak" into malicious code. Application isolation is essentially a very important foundation of a capabilities framework.

Each of the security features described above helps in preventing malicious or defective programs from damaging the platform, data, or other programs on the system. These features are designed so that application isolation is applied to native programs. The system specification currently does not suggest a method for applying application isolation to interpreted programs . The present invention proposes a way to achieve this.

The present invention relates to a method for safely interpreting a program in an electronic device. The method, in the electronic device, the step of loading and providing a prototype of the at least one shared interpreter library and executable stub (stub executable), the interpreted program to the electronic device, said electronic device a step of using said prototype executable stub inner forming an executable stub, the execution and associating the executable stub in the electronic device and the interpreted program, at least one second capability It can include assigning to the stub, and executing the executable stub within the electronic device.

The present invention is an electronic device using at least one shared interpreter library configured to implement an interpreter engine, an interpreted program loaded into the electronic device, and using an executable stub prototype. the executable stub is formed, at least one second capability assigned to the executable stub, said at least one second installation entity configured to associate with the executable stub a capability, the executable It also relates to an electronic device comprising an operating system entity configured to execute a stub .

The present invention is a computer program that, when executed on a data processing system, loads an interpreted program , uses an executable stub prototype to form an executable stub , associating an executable stub with the interpreted program, associating at least one second capability and assigning to said interpreted program, and said at least one second said executable stub a capability, the execution performing a stub, the steps of the executable stub shown in at least one shared interpreter library said interpreted program, said executable stub said shared interpreter library Also it relates to a computer program comprising code adapted to implement the steps of interpreting said interpreted program invokes at least one function of the inner.

The present invention provides a computer program, when executed on a data processing system, providing at least one capability associated with the computer program to the interpreted program , and information about the interpreted program as described above. Obtaining from a secure source assigned to the computer program and the interpreted program into at least one shared interpreter library comprising at least one function that implements an interpreter engine that interprets the interpreted program code steps and, adapted is to perform the steps of interpreting said interpreted program invokes at least one function of the shared interpreter in the library showing It was also relates to a computer program that contains the code.

In one embodiment of the invention, the method further comprises the executable stub presenting the interpreted program to the at least one shared interpreter library; and the executable stub in the at least one shared interpreter library. At least one of the steps of calling the function to interpret the interpreted program, a step of checking whether the interpreted program code section for externally referenced by the interpreted program, the external interpreted program a step of inferring at least one first capability related code section, said at least one second capability is at least one first capability If not a subset, and a step to disallow execution of the interpreted program code section of the external.

In one embodiment of the present invention, wherein even at least one shared interpreter library checks whether interpreted program code section for outside are referenced by the interpreter type program, the external interpreted program code - guessing at least one first capability of section, if at least one second capability is not a subset of the at least one first capability, permits the execution of interpreted program code section of the external Configured not to.

In one embodiment of the invention, the secure source is a secure directory within the electronic device. The secure source may be, for example, the computer program code itself or a directory storing the computer program. It said information on said interpreted program may be a file name of the interpreted program. The secure source may be an operating system that provides the computer program with a file name of a file containing the computer program.

The term "external interpreted program code section", the interpreted program itself outside, for example, obtained from the interpreted program directory other than the reserved directory for in the electronic device, interpreted Note that it refers to the program code section. For example, the external interpreted program code section may be read from a shared interpreter library. An external interpreted program code section may be obtained over the air during interpretation of the interpreted program . The term “at least one first capability” refers to a set of capabilities assigned to the external interpreted program code section, eg, a shared interpreter library. The term “at least one second capability” refers to a set of capabilities of the executable stub . Note that a single capability may include several individual operations or functions related to operating system, data communication, or management of electronic devices. In other words, some functions may be grouped into a single capability for convenience. A program or program code fragment may also be associated with a set of capabilities. Capabilities grant access to resources or functions within the electronic device, but if access rights are not granted, the program or program code cannot use those resources or functions. Disappear. The capability is monitored by the operating system or the function serving the program in the electronic device.

In one embodiment of the present invention, reliability category relates interpreted program code section, in at least one position on the file that contains the interpreted program code section, located in the file system of the electronic device To determine whether the interpreted program code section was received from a trusted remote sender, and the trust level is granted based on the trust category.

In one embodiment of the invention, the execution of any data is disabled in the at least one interpreter library. This means, for example, that the interpreter engine will not have access to functions for executing arbitrary data. Any attempt to call such a function will cause an error in the interpreter engine. In one embodiment of the invention, the executable stub is executed in a separate process context. The invalidation may be performed before compiling the interpreter engine to generate the at least one shared interpreter library. The invalidated version is then provided to the electronic device.

In one embodiment of the invention, the external interpreted program code section is loaded into the electronic device from a network server, eg, over the air. In one embodiment of the invention, the external interpreted program code section is a function in a shared interpreter library that includes interpreted program code. Interpreted program code section of the outside, the so interpreted program code is delivered to the interpreter engine from the interpreted program itself, it is formed based on any data by said interpreted program Good.

  In one embodiment of the invention, a trust level is granted to the shared interpreter library. The trust level can be granted automatically by the user or by the installer entity. If the installer entity automatically grants the trust level, the trust level can be obtained by examining trust level information provided from a network server. The trust level information may be signed by an operator. The signature may also be affixed from a service provider or from any other trusted entity. The trust level is used to determine the at least one first capability at the operating system entity level or the installer entity level.

In one embodiment of the present invention, the step of loading the interpreted program includes a step of downloading said interpreted program from a network server.

In one embodiment of the invention, the step of providing the at least one shared interpreter library and a prototype of the executable stub includes downloading them from a network server to the electronic device.

  In one embodiment of the invention, loading the at least one shared interpreter library includes downloading them from a network server to the electronic device.

In one embodiment of the invention, the interpreted program is identified using a unique identifier within the electronic device. The unique identifier can be used, for example, by the operating system entity and the installer entity to refer to the interpreted program and the executable stub . The at least one second capability may be associated with the unique identifier by the operating system entity.

  In an embodiment of the present invention, the electronic device includes a mobile terminal. In one embodiment of the invention, the electronic device comprises a SYMBIAN® operating system device.

  In one embodiment of the invention, the electronic device includes a general packet radio system (GPRS) terminal or a universal mobile telecommunications system (UMTS) terminal.

  In one embodiment of the invention, the computer 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 present invention, the electronic device is a mobile device such as a laptop computer, a palmtop computer, a mobile terminal, a personal digital assistant (PDA), or the like. In one embodiment of the invention, the electronic device is a desktop computer or a mainframe computer.

An advantage of the present invention relates to improving the reliability of loaded interpreted programs . An interpreted program and each program code executed by the interpreter usually appears to be a self-explanatory application for a native operating system having a capability set. According to the present invention, capabilities defined for a program that can be executed by a native operating system can be used for such an interpreted program or program code.

  The accompanying drawings, which form a part of this specification and provide a thorough understanding of the present invention, illustrate embodiments of the present invention and, when read in conjunction with the following detailed description, illustrate the present invention. The principles should be easier to understand.

Detailed Description of Embodiments

  Now, embodiments of the present invention will be described in detail. Illustrative embodiments are illustrated in the accompanying drawings.

  FIG. 1 is a block diagram illustrating an example of a directory tree in an electronic device according to the present invention. The electronic device is as shown in FIG. In one embodiment of the present invention, the electronic device is a SYMBIAN® operating system device. The directory tree shows what files are essential for the method stored on the electronic device according to the present invention and what their interrelationships are. In FIG. 1, a root node 100 exists, and sub-directories 101, 102, and 103 are connected to the root node. The sub directory 101 stores a binary file that implements an interpreter. The interpreter may be, for example, a Java (registered trademark) interpreter, a Perl interpreter, a PHP interpreter, or a Python interpreter. In the sub-directory 101, files 111, 112, and 113 exist. File 111 includes an interpreter engine that directly executes program source code or byte code generated using a compiler.

Program source code or byte code that is interpreted by the interpreter engine is referred to below as " interpreted program code". The compiler interprets human-readable source code and compiles it into byte code. However, it should be noted that the bytecode may be any intermediate language that can be executed by the interpreter engine. The intermediate language may be in a format that is optimal for machine execution. The format does not necessarily include an operation code having a size of 1 byte. File 111 is essentially a dynamic link library (DLL) that contains functions for running the interpreter engine. File 112 is a stub interpreter executable that will call the interpreter engine located in file 111 when it is ultimately executed. The file 113 is formed using the file 112 every time the interpreted program is installed in the electronic device.

Sub-directory 102 contains programs that are interpreted using an interpreter engine. The sub directory 102 includes a file 121 containing an interpreted program . The element <SID> of the sub-directory name represents a security identifier (SID) assigned to the interpreted program . The SID uniquely identifies an interpreter type program . By using this, capability can be assigned to an interpreter type program . Capabilities correspond to operating system functions or sets of operating system functions that can be called from applications identified using SIDs. Examples of capabilities include the ability to set up communication with, for example, a remote Internet server over a remote network, and the ability to access files stored on an electronic device. A single capability can include several related functions and operations. For example, all functions related to IP sockets can include a single capability. Other capabilities include power management, local communications using Bluetooth, or infrared and low level wireless protocol processing.

The sub-directory 103 includes a shared library that includes functions called from an interpreted program such as an interpreted program stored in the file 121. The shared library is stored in the file 131. The sub-directory 132 also includes a policy file that defines policies relating to the manner in which the shared library is managed within the electronic device. The policy file defines how to manage the / resource / <lang> directory and how to create lang- <version> -stub-interpreter.exe that starts the interpreter for a script. The advantage of using a policy definition file is that no interpreter-specific external code is executed in the context of the software installation program. All interpreter policies can be cross-referenced and checked for errors and conflicts before implementing those policies. Also, the policy support required in this case is quite simple.

  A shared interpreter library is assigned a trust level, a set of capabilities that are allowed for functions in the library. The set of capabilities is determined by the operator or determined by the user. If the operator makes a decision, the capability is shown to the electronic device when the file is downloaded from the network server. Capabilities are verified to be signed using, for example, an operator's digital signature. If the user makes a decision, the user is prompted for which capabilities will be allowed for the library. The capabilities assigned to the shared interpreter library will reflect which functions are examined for the library and, as a result, which functions are considered reliable. For example, even if a library is considered safe for downloading files to an electronic device, it may not be allowed to read the files in the electronic device.

2A and 2B are flowcharts showing a safe program interpretation method according to an embodiment of the present invention.
At step 202, a shared interpreter library that includes the main interpreter code, or interpreter engine, is provided to the electronic device. The shared library can be provided, for example, as part of a native operating system, or can be downloaded over the air from a network server to an electronic device when a user requests an interpreter download.

At step 204, an executable stub prototype is provided to the electronic device that includes the functions necessary to invoke an interpreter engine that interprets a single interpreted program . Executable stub prototypes can be provided, for example, as part of a native operating system, or downloaded to an electronic device over the air when a user requests to download an interpreter from a network server it can. The installation of the shared interpreter library, including the main interpreter code and the executable stub prototype , can be performed by a separate installer entity that stores them in non-volatile memory in the electronic device.

In one embodiment of the invention, the shared interpreter library is also loaded on the electronic device. The shared library can be loaded into the electronic device using a removable memory medium, such as a magnetic disk or optical disk or a removable memory card, or downloaded to the electronic device over the air. Installation of a shared interpreter library can be carried out in separate installer entity storing it in the non-volatile memory in an electronic device.

  In step 206, a trust level is optionally granted to the shared interpreter library in the electronic device. The trust level specifies a set of capabilities that are assigned to the shared interpreter library. The determination regarding the granting of the trust level can be made based on trust level information signed by an operator or any other entity trusted by the electronic device. Trust is established using, for example, a public key infrastructure (PKI) or a trust chain. The user of the electronic device can also explicitly specify a decision regarding the granting of the trust level via the electronic device user interface.

At step 208, an interpreted program is loaded into the electronic device. Interpreted programs are downloaded, for example, via the radio. The interpreted program may be selected from the WWW page or WAP page by the user. The interpreted program is downloaded from, for example, a network server with which the electronic device has established a connection. The installation of the interpreted program can be performed by an installer entity. In one embodiment of the present invention, the interpreted program can also be loaded into the electronic device using a removable memory medium such as a magnetic disk or optical disk or a removable memory card.

At step 210, a unique identifier is assigned to the interpreted program . The interpreted program can use the functions in the shared library downloaded to the electronic device. The unique identifier is obtained from the agency responsible for assigning the unique identifier to each application running within the electronic device.

At step 212, the electronic device determines the capabilities to be assigned to the interpreted program . For example, capabilities may be determined by analyzing the interpreted program code interpreted program, or in the form of a separate file or data structure provided with respect to an interpreted program from a network server or a removable memory medium Sometimes specified. There may also be interpreted programs that do not have any capabilities. In such a case, the interpreted program is only allowed to render information on the display device and interact with the user using the keyboard.

At step 214, an executable stub is formed using the executable stub prototype . An executable stub is formed to invoke an interpreter engine and determine an interpreter type program for the interpreter engine. The executable stub is formed using a prototype of the executable stub . Executable stubs can also be formed using instructions contained in a separate policy file provided for example with respect to a shared interpreter library or with respect to interpreted programs . The formation of the executable stub can be performed by the installer entity.

At step 216, execution of other programs from the executable stub is disabled. Invalidation is accomplished , for example, such that an interpreted program to be executed by an executable stub is explicitly shown to the interpreter engine. An interpreted program is indicated by providing its own file name, such as file 121 of FIG.

In step 218, the capabilities determined for the interpreted program are assigned to executable stubs in the electronic device formed in step 214. Executable stubs act as an intermediary for interpreted programs related to operating system security features. Executable stubs are used to invoke the interpreter engine and provide interpreted programs to the interpreter engine, so any interpreted program code other than functions in an interpreted program or shared interpreter library Guaranteed not to be executed. In other words, there is no possibility that an interpreted program will be executed on the interpreter engine without using an executable stub .

The label “A” represents the point where the method shown in FIG. 2A continues to FIG. 2B. At step 220, the process of interpreting the interpreted program using an executable stub and an interpreter engine is performed by the operating system of the electronic device in a separate process context. There is a separate process context for each interpreted program .
In step 222, the interpreter engine checks whether the program is finished. If the program has not ended, the process proceeds to step 224.

In step 224, the interpreter engine checks whether the external interpreted program code should be interpreted. If the external interpreted program code is to be interpreted, go to step 226, otherwise go to step 220. An example of an external interpreter type program code is a code included in a shared interpreter library. Another example of external interpreted program code is code received by an electronic device during interpretation of the current code.

In step 226, the interpreter engine compares the confidence level of the external interpreted program code with the capabilities of the executable stub . It is determined that the capabilities of the executable stub are a subset of the capabilities associated with a level of trust such as external interpreted program code, ie, a shared interpreter library, for example. A given trust level uniquely specifies a set of capabilities assigned to external interpreted program code. The trust level is inferred based on, for example, the location of external interpreted program code in the file system within the electronic device. For example, if the code is placed in a trusted directory such as an interpreted program directory or a language-specific trusted directory, at least the capabilities of the interpreted program are provided. If capabilities of executable stub is not a subset of the capabilities associated with the trust level, i.e., if it has a capability of executable stub it does not belong to the set of capabilities specified for external interpreted program code interpreter The engine is considered to have exceeded the trust level.

At step 228, the interpreter engine checks whether the trust level has been exceeded. If the trust level has been deviated, the process proceeds to step 230;
At step 230, the interpreter engine does not allow execution of the program. At that time, an appropriate error message can be shown to the user, and execution of the executable stub ends.

  FIG. 3 is a block diagram illustrating an electronic device 300 according to the present invention. The electronic device 300 includes a first memory (not shown) and a second memory (not shown). The first memory is a volatile RAM work memory, and the second memory is a non-volatile memory. In one embodiment of the invention, the first and second memories are the same non-volatile memory. The electronic device also includes a processor (not shown).

In FIG. 3, there is a box 302 indicating software in the electronic device. The software comprises at least an operating system entity 316, an installer entity 304, and a communication entity 306. The software may also include an interpreter engine 310 and an executable stub 308 associated with the interpreter engine 310. Interpreter engine 310 executes the interpreted program code, such interpreted programs as such interpreted program 312. The interpreted program can use at least one function stored in the shared library 314. Shared library 314 includes functions specified in interpreted program code executed by interpreter engine 310. The shared library 314 can also include functions specified in the native machine code of the electronic device. Executable stub 308 is used by interpreter engine 310 to invoke an instance of a given interpreted program . The interpreter engine 310 cannot call other interpreted programs using the same executable stub . The communication entity 306 performs communication related tasks in the electronic device. The communication entity 306 is used for radio interface communication and comprises a protocol stack for communicating with a remote network such as the Internet. When the communication entity 306 receives the interpreted program 312 from the remote network, the interpreted program 312 is provided to the installer entity 304. The installer entity 304 stores the interpreted program 312 in a non-volatile memory in the electronic device. The installer entity 304 creates an executable stub specific to the interpreted program 312.

In one embodiment of the present invention, the installer entity uses the policy file in forming the files required when installing the interpreted program 312 in non-volatile memory within the electronic device 300. The installer entity 304 can also be responsible for configuring the shared library 314 by installing the shared library 314 in non-volatile memory when the shared library 314 is downloaded to the electronic device 300. Similarly, the installer entity may be responsible for installing and configuring the interpreter engine 310 and prototype stub in non-volatile memory when the interpreter is downloaded to the electronic device 300. The operating system entity 316 or installer entity 304 can be responsible for assigning trust levels and capabilities to shared libraries and interpreted programs . In one embodiment of the invention, the installer entity 304 is an application that runs within the electronic device 300.

In one embodiment of the invention, the executable stub 308 is an application that runs under the control of an operating system entity 316 in the electronic device 300. The interpreter engine 310 is a dynamic link library in the native machine code of the electronic device 300. Each function is called from the dynamic link library by the executable stub 308.

In the following, an embodiment of the invention is described in which the method of the invention is applied in a SYMBIAN® operating system environment. Importance to isolate the interpreter applications from other interpreted applications and host platforms is related to the importance of the functions provided by the data and their interpreted program operated by their interpreted program. If only one program is implemented for the interpreter, application isolation is performed implicitly.

Application isolation is critical when the majority of applications are implemented using a single interpreter. If the platform security is not correctly applied by the interpreter, most of the platform security features will not be used. This can lead to valuable data from other interpreted programs becoming the target of malicious programs.

  Microsoft's macro virus problem is an example of the worst case of how serious the problem is. If the environment in which the program (for example, Word or Excel) is executed is not safe, it does not matter whether the underlying operating system is safe.

Integration means that important aspects of the syntax and semantics of operating system platform security are provided to interpreted programs . The following functions are required for integration. In other words, the interpreter-type program that must have a unique identifier, be interpreted program must have its own private directory, shared code library must have a trust level First, the trust level must be managed in the same way as individual programs, interpreted programs must have a capability set assigned to them, and each interpreted program must have a separate process context. As well as interpreted programs must be limited by their own capability set.

The proposed method for implementing these functions is based on the following, and the gist is as follows.
Interpreter executable
/sys/bin/lang-<version>-interpreter.dll
(The <version> part indicates the interpreter version.)
Placed in a DLL that, each time the SID / VID pair about any other program is assigned to each interpreted program executable stub
/sys/bin/lang-<version>-stub-interpreter.exe
(<Version> part indicates the version of the interpreter), place each file of the interpreted program in the / private / <SID> / directory, and for each interpreted program X,
/sys/bin/lang-<version>-stub-interpreter.exe
And copy the /Sys/bin/interpreted-program-X.Exe, assigned a capability should have is interpreted program X in interpreted program X, the executable stub will always designated from its own private directory program Execute, place generic shared code in / resource / <lang> / lib, and place any required native DLLs in / sys / bin, used to manage shared code Place the policy definition file under /resource/<lang>/policy.txt.

This solution essentially each interpreted program, in which they are mapped to the native operating system of the platform security in a form visible to the native operating system program. Another advantage is that a user experience similar to that when capabilities are assigned to native programs is maintained. The solution still does not solve how to assign a trust level to shared code. This is discussed in the next section.

The previously proposed design does not completely resolve how to assign a confidence level to individual code outside the interpreted program . The problem becomes a problem for the following reasons. In most interpreted languages , it is possible to access the interpreter within the language (for example, via the eval () function in Perl and Python). It is therefore possible to use any I / O source to provide ready-to-execute code (this is true even for native programs, but the presence of such code does not Will be rejected).

Based on monitoring the external I / O of the interpreter, it can be deduced what input data is used as code and what input data is used as data.
Using a stub interpreter executable provides a concise approach to granting capabilities to a program, but it is easy to attach capabilities to any input using existing operating system mechanisms. Not that.

  From the above considerations, it is clear that any practical mechanism for assigning a trust level to a generic code requires the assistance of an actual interpreter. There are two options available for that. That is, depending on the choice of rejecting its own load / execution for code that will be executed using the capabilities of untrusted code, and what source the code comes from at runtime There are options to introduce lower capabilities.

  It may be necessary to change the operating system kernel by adjusting capabilities at runtime. One compromise is to require an interpreter with the capability to invalidate its own loading and execution for code originating from sources other than the script's private directory.

SID / VID values are not assigned to shared code libraries in / sys / resource. SID / VID values are assigned only to binaries under / sys / bin. A policy file format is defined that describes how to interpret interpreted program code shared between interpreted programs . The policy file defines:
● / sys / resource / <lang> directory management method ● How to create lang- <version> -stub-interpreter.exe that starts the interpreter for a script

  Only the installer entity can write to the / sys directory, but all programs can read the directory. The / private / <SID> directory is a directory that can be read only by an installer entity or a program in the directory. The principle that an electronic device has the above two types of directories rather than the actual names of the directories is essential.

  The advantage of using a policy definition file is that no interpreter-specific external code is executed in the context of SWInstall, a software installation program. All interpreter policies can be cross-referenced and checked for errors and conflicts before implementing those policies. Also, the policy support required in this case is quite simple.

The interpreter should implement the following functionality:
● The default directory used in the script is / private / <SID>. A global readable / writable file must be explicitly declared as such.
● If the program has any capabilities (including user capabilities), execution of code outside the private directory and / sys / resource directory is disabled. It may be desirable to have a special “developer-switch” that disables this feature.
If user capabilities are granted, program code can only be loaded from the program's private directory and shared code directory.
• If system capabilities are granted, program code can only be loaded from the program's private directory.

  It will be appreciated by those skilled in the art that the basic concepts of the present invention can be implemented in various ways as technology advances. Accordingly, the present invention and embodiments of the present invention are not limited to the examples described above but may take a variety of forms within the scope of the following claims.

It is a block diagram which shows an example of the directory tree in the electronic device which concerns on this invention. It is a flowchart which shows the safe interpretation method of the program which concerns on one Embodiment of this invention (the 1). It is a flowchart which shows the safe interpretation method of the program which concerns on one Embodiment of this invention (the 2). It is a block diagram which shows the electronic device which concerns on this invention.