WO2018023368A1

WO2018023368A1 - Enhanced security using scripting language-based hypervisor

Info

Publication number: WO2018023368A1
Application number: PCT/CN2016/092848
Authority: WO
Inventors: Junyong Ding; Richard Tao-Hwa Chow; Michael Mccool; Enrico BUDIANTO
Original assignee: Intel Corporation
Priority date: 2016-08-02
Filing date: 2016-08-02
Publication date: 2018-02-08

Abstract

Various systems and methods for providing multiple secure code execution environments within a single instance of a language runtime are described herein. A system for providing a code execution environment includes a processor subsystem; and a memory coupled to the processor subsystem, the memory including instructions, which when executed by the processor subsystem, cause the processor subsystem to: obtain source code for executing a process; search the source code for a scope violation; rewrite the source code to change a name corresponding to the scope violation with a replacement name; search the source code for a restricted function call; rewrite the source code to change the restricted function call to call a proxy for the restricted function call, and rewrite the source code to insert instrumentation to monitor and limit resource consumption.

Description

[Title established by the ISA under Rule 37.2] ENHANCED SECURITY USING SCRIPTING LANGUAGE-BASED HYPERVISOR

TECHNICAL FIELD

Embodiments described herein generally relate to software execution operations in a computer system, and in particular, to the execution of commands with scripting languages such as JavaScript, Python, and the like that are deployed in computer systems.

BACKGROUND

Scripting languages such as JavaScript have been widely deployed in a number of HTML5 client applications (e.g., WebView, Windows 8 Metro Apps) , server-side applications (Node. js) , and emerging Internet-of-Things applications. JavaScript development is modular in nature, and it is common practice to utilize multiple third-party components and libraries within a JavaScript scripting deployment and within a single application. Such third-party components and libraries are commonly executed by the JavaScript interpreter with the same privilege as other scripting code directly included in the script, leading to security issues when these components and libraries are malicious or vulnerable.

In some cases, a single device may also execute multiple JavaScript applications from different, mutually untrustworthy sources. Running these JavaScript applications with separate interpreters may be resource-intensive or unpractical； however, running them on a single interpreter (as is commonly done today) exposes an application to attack by other applications being run by the same interpreter. Such security issues are not unique to JavaScript, as other scripting languages such as Python support modules from multiple sources but also lack mechanisms for strong confinement and isolation.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. Some embodiments are illustrated by way of example, and not limitation, in the figures of the accompanying drawings in which:

FIG. 1 illustrates a data and control flow for implementation of a secure code execution environment, according to an example；

FIG. 2 illustrates an operational flow for operation of a secure code execution environment, according to an example；

FIG. 3 illustrates a control and data flow of communications between applications operating in a secure code execution environment, according to an example；

FIG. 4 illustrates a control and data flow for handling a function call in a secure code execution environment, according to an example；

FIG. 5 depicts an overview of secure update process for a secure code execution environment, according to an example；

FIG. 6 is a flowchart illustrating a method of providing a secure code execution environment, according to an example； and

FIG. 7 illustrates a block diagram for an example computer system architecture upon which any one or more of the techniques (e.g., operations, processes, methods, and methodologies) discussed herein may be performed, according to an example.

DETAILED DESCRIPTION

In the following description, methods, configurations, and related apparatuses are disclosed to mutually isolate the execution of multiple scripting modules running inside a single scripting language interpreter. Specifically, the following description includes various examples of methods and device configurations for the execution of the JavaScript scripting language, to manage the import, access, and execution of included scripting applications or modules in a contained environment. This contained environment is designed so that different code modules that are imported and combined may have controlled access to APIs, data access, and resource consumption, with access controls and limitations fully configurable by supervisory code. In some of the examples, the contained environment is structured so that the code modules and the security controls are provided in the same scripting language—allowing security mechanisms to be implemented without modification to a runtime or the scripting engine itself.

In existing deployments of JavaScript, external (and untrusted) scripting modules may run with the same level of privilege as code directly written for the JavaScript interpreter. For example, the use of the “import” statement may be used to import functions, objects, or primitives from an external script. JavaScript engines do not include a confinement mechanism or like way to sandbox respective scripting modules, leading to security issues when code associated with the imported functions, objects, or primitives are executed.

Existing workarounds for security issues with such interpreted scripting languages have not adequately addressed security in JavaScript programming use cases. Although traditional client-side web browsers may operate isolated respective web applications with mechanisms provided by the browser (for instance, isolating respective web applications located in iframes) , such features are not provided in JavaScript platforms.

One workaround may include executing respective JavaScript applications in different processes and relying on the operating system to provide the secure isolation. For example, each untrusted component may be operated and isolated in a trusted execution environment (TEE) established by the operating system or hardware. This approach is not practical because typical JavaScript programs may use tens or even hundreds of external modules. Thus, the use of separate TEEs would greatly increase resource consumption because each code module would require a separate TEE and copy of the JavaScript interpreter.

Likewise, as another workaround approach, untrusted components could be operated and isolated with use of separate JavaScript engines. However, a significant performance overhead would be involved in supporting multiple JavaScript interpreters. Similar heavyweight approaches, such as executing JavaScript applications in different virtual machines or in different filesystem container deployments, result in the same challenges. Each of these approaches is also counter to the initial attraction of the JavaScript programming model having a simple program-once, run-anywhere model.

Other security approaches, such as whitelisting provided by programs such as

Embedded Control, may be used to prevent executables and scripts that are not included on a whitelist from running. However, such solutions do not provide fine-grained control of modules in a single application. For instance, if Node. js is on a whitelist, than any Node code may run, all with the same privileges as Node. js. Additionally, the Caja compiler enables secure embedding of third-party HTML, CSS, and JavaScript in a website, but uses an iframe to securely load its code and is unable to manage communication between embedded scripts.

The presently disclosed techniques provide a language-based hypervisor that may execute untrusted worker code (which may include modules or nested applications) inside one or more secure containers supported entirely within a single instance of a scripting language runtime. The secure containers allow execution of untrusted worker code while controlling the resource consumption, access to application programming interfaces (APIs) , and data access of this code to prevent attacks on other parts of the system, including both unauthorized data and API access and denial-of-service attacks.

The language-based hypervisor and worker code may be written in the same language (e.g., JavaScript) and run together as one process on top of a single language interpreter or runtime. The following provides examples of how secure containers generally may be implemented at the language level without modification to the runtime itself. Thus, the present techniques provide a useful augmentation for modular ecosystems such as the Node. js environment, and enable control of scenarios that involve inter-component communication. The present techniques also enable privileged code to run safely—according to user-defined policies. The techniques described herein further enable the use of existing modular code that can be augmented with additional information describing security policies for the modules making up that code, allowing existing modular code to run but with enhanced security.

The following terminology is defined for use of the presently described techniques. However, it will be apparent that the definition of the following terms may include other examples for other scripting languages and programming paradigms.

1. Worker: applications or modules code executed in a container. Examples could be a Node. js-based web server or database module. This code is potentially untrusted. A worker may access certain privileged resources (e.g., a specific part of a file system) if allowed by the developer/operator of the system. There may be one or more workers running on the system (e.g., in separate threads) .

2. Container: an execution environment created by the language-based hypervisor. The container is designed such that workers do not have access to global objects, data from other containers, or language-based hypervisor objects. A container serves as the primary isolation mechanism between workers.

3. Language-based hypervisor (LBH) : privileged code that configures containers and manages worker execution and use of privileged APIs (e.g., inter-worker communication, secure update, file system access, etc. ) . The LBH is the first code executed after a runtime is booted up.

4. Runtime: software that interprets and executes applications running on top of it, for instance, the Node. js V8 engine. Workers, containers, and the LBH all run on a program runtime. The program runtime processes this code in a way defined by the specification of the language used.

5. Policy: A definition or other statement of which privileged actions each worker is allowed to perform and the resource usage limitations for each worker. For instance, the policy may state which objects belonging to Worker A are accessible by Worker B, and whether Worker C is allowed to access the file system or network. All privileged actions by workers are specified through a policy and enforced by the LBH.

6. Device: the actual hardware on which the runtime, workers, containers, and the LBH are running. Some examples are IoT devices, computing device clients, servers, smartphones, and smartwatches.

As discussed in the following examples, the LBH and the workers may be written in the same language and executed together as one process on top of a single language interpreter or runtime. JavaScript is provided as a particular example of how the LBH may be implemented at the language level, without modification to the runtime itself. Thus, this configuration enables the use of a lightweight, secure (and dynamic) deployment of the LBH with the same scripting environment used to deploy the workers. It is to be understood that JavaScript is not the only language in which the technique described herein can be applied； it is also applicable to other scripting or interpreted languages including Python, EMCAScript and its variations, and the like.

The deployment of the LBH may be provided as follows: scripting code is generated for one or more workers and policies are defined. The LBH scripting code runs first and spawns containers for the workers. Worker code is put into the containers and execution of the workers begins. Meanwhile, the LBH monitors code execution in the containers, making sure that privileged actions in the containers are monitored and handled properly according to defined policy. In summary, the mechanisms for this monitoring and enforcement of access restrictions can be accomplished without modifying the runtime by (a) modifying the objects (code and data) that the executing worker code has access to and (b) rewriting the worker code before it is executed to embed monitoring code.

FIG. 1 illustrates a data and control flow for implementation of a secure code execution environment, according to an example. The techniques involved in FIG. 1 include: code rewriting to include appropriate instrumentation, call interception, and data access modifications and uses primitives that are energy-efficient and provably secure.

As an initial step, the untrusted worker code for one or more applications 135 (e.g., including an app 145) is rewritten by an LBH 105 (e.g., rewritten into app'155) to enforce isolation, to insert additional code to monitor resource limits, and to allow the LBH 105 to resume control if resource limits are reached. The untrusted worker code of app'155 is then run in an execution context (a container 115) that provides only the accesses to code and data set by the policy defined by the LBH 105. Code for the LBH 105 is executed first to ensure that the execution context (e.g., policy, namespacing) for each worker application or module is generated properly.

As depicted in FIG. 1, the process of setting up a secure, encapsulated environment (e.g., the container 115) for a worker app (e.g., the app 145) starts with bootstrap code. In operation 110, the LBH 105 starts and sets up the environment to operate the LBH 105 and the container 115. In operation 120, the LBH 105 translates the privileges and resource limits for each worker (e.g., app 145) into policy code 125. In operation 130, the LBH 105 creates a container 115 (including the policy code 125) for each worker. In operation 140, the LBH 105 rewrites the worker code (e.g., rewritten from app 145 into app'155) so that (a) each worker holds no reference to the external privileged context, a process called reference cleanup； (b) each worker holds no global objects or shared variables with other worker applications； and (c) potentially resource-intensive operations are monitored. The policy code may also contain code to monitor the worker code’s use of any APIs that it has been granted access to, in order to limit or restrict usage according to the policy. For example, a worker may be granted access to the file system, but may be restricted to only access certain directories or only create files of a certain size by the policy code. In operation 150, each worker’s re-written code (e.g., app'155) is then executed inside its container (e.g., container 115) . In operation 160, the LBH 105 monitors worker execution for policy enforcement using both the monitoring code embedded during the rewriting and modified forms of the APIs provided to the workers as part of the container.

As discussed herein, an LBH for a JavaScript implementation may be designed as a container-based solution, having each container confine a piece of JavaScript code and isolating itself from being accessed by any other JavaScript code (in a similar fashion as an iFrame used for HTML5-based web applications) . The system may include a privileged container, which serves as a piece of JavaScript code that is responsible for carrying out privileged instructions (e.g., secure updates, secure outgoing communication) on behalf of worker applications, as well as to store and protect sensitive information. An LBH may have one privileged container with one-way access to the non-privileged ones. Applications running within a non-privileged container do not have access outside their own container aside from specific APIs defined by the code running in the privileged container.

FIG. 2 illustrates an operational flow for operation of a secure code execution environment, according to an example. Specifically, FIG. 2 depicts steps for creating containers (e.g., privileged container 205, container 235) to execute an application (e.g., confined application 245) using the LBH. The process is managed by a bootstrap code 215, which is the first JavaScript logic executed once an application boots up.

As illustrated in FIG. 2, the bootstrap code 215 first sets up a privileged (e.g., secure, trusted) container 205 (operation 210) . The bootstrap code 215 then creates a virtual execution environment for a container 235 in which the original application is going to be placed and executed (operation 230) . During this phase, the bootstrap code 215 makes sure that once the application in the container runs, it holds no reference to the privileged container 205, using a reference code cleanup 225 (operation 220) . Once the reference code cleanup 225 is complete, the code then executes the application in the container 235 (operation 240) . The process of establishing the container 235 may include a pre-deployment analysis, to ensure that the confined application 245 will be placed in an execution environment separated from other containers.

In an example, the techniques may be used to increase security for workers. First, LBH provides an API that may be used by workers to carry out secure communication with services running on an external device (e.g., a web server, other IoT devices, etc. ) .

The presently described examples relate to JavaScript and a JavaScript runtime. As a specific example, the techniques may be used with the Node. js runtime. In Node. js, the described secure containers act as an isolation primitive for either entire JavaScript applications or modules within an single application, similar to the concept of iframes in web applications, whereas the LBH provides a way to provide a way to flexibly set policy and support trusted code. However, the approach provided by the presently described examples apply generally to any program runtime (such as Python and Java) that includes the following properties:

Code instrumentation: The runtime provides a mechanism for the LBH to arbitrarily re-write (e.g., modify, change, update) the code of worker modules before execution of the worker modules.

Access control: The runtime provides a mechanism for the LBH to define and enforce capabilities for objects (e.g., LBH may create objects for which a worker may only execute certain functions or access certain data fields) .

Isolation: The runtime provides a mechanism for the LBH to segregate all worker code and variables from other workers and LBH objects/variables from workers (i.e., a worker may only access functions and data that are made accessible in its initial execution context) .

Based on these program runtime properties and a policy defined by code running in the LBH for what workers are allowed to do, secure containers may be designed to satisfy the following properties:

Intended Functionality. The workers have the same functionality compared to those running outside the secure container, except for what is prohibited by a policy set by code running in the LBH for each secure container. If a particular function is prohibited by the policy, the policy may provide code to define what happens, such as throwing an exception that may only be caught by the LBH. Additionally, all language features are available to the workers running inside each secure container (e.g., fully ECMAScript 5 and 6 compliant for JavaScript) ； all privileged APIs are available (but potentially substituted or redefined with another version by the LBH) ； and multiple secure containers may be present under the same LBH and may have policies unique to each. In an example, one exception not handled is worker code that generates global variables dynamically. These dynamically created variables will not be available to the worker.

Restricted Access. Workers have no access to program data or surrounding context other than that explicitly provided. Specifically, the workers do not have general access to data held by the LBH or to other workers other than the access granted by the LBH (and in the case of other workers, also by that worker. ) The LBH may offer certain services to the workers, such as: calling a function or allocating an object residing in another secure container, including nested calls； providing communication channels allow cooperating workers to exchange data even if they are running in different secure containers； and providing secure external communications, such as with external web servers or sockets (with possible packet filtering and connection constraints provided by code in the LBH) .

Execution Management. The LBH may manage execution of workers, through techniques such as: providing a secure update to worker code, and monitoring resource consumption of each worker (e.g., to mitigate Denial-of-Service attacks caused by one worker overusing resources) . Resources that may be monitored may include but are not limited to memory consumption, CPU usage, storage space consumption, and communication bandwidth.

In an example, isolation and access control may be provided using containers and policy definitions within a JavaScript implementation of the secure code execution environment. The LBH may implement isolation between several containers in several ways, as described further below. First, worker objects in one container may be inaccessible by other workers, to implement application code confinement. Second, worker objects in two containers may communicate using a messaging interface, as allowed by policy. Third, developers may define the set of privileged APIs (e.g., file system, child process) available to a worker object.

To enforce this kind of isolation in a fine-grained manner, an identifier is associated to a container. This identifier is used to identify which container must be isolated from what, or, which access may be given to a container. This concept is similar to the use of a web origin with client-side web agents to isolate content coming from two web sites, as well as being similar to the use of a package name in the Android operating system. (In Android, for example, the entire policy defined in the manifest file is associated with the package name, and thus, its isolation mechanism regarding API access applies to any programs running under that package name. )

In an example, the use of an identifier (referred to as a globally unique container identification, “GUCID” ) in the secure code execution environment is unique to each container and is public to enable communication between containers. This identifier may be used with a global namespace of such identifiers and, for instance, in the case of Node. js, the Node. js’s package name may be used as the GUCID.

An LBH policy mechanism may be based on the GUCID. For example, when a container with GUCID “APP1” would like to send message to a container with GUCID “APP2” , the LBH may only allow such communication if the following policy definition exists on the LBH’s core. (The following provides only an example, as a particular implementation may have different ways to define policies, including a dynamic API, or use a different syntax in a policy definition file) :

{container_gucid: ’APP2’ , accept_communication: [ ‘APP1’ , …] }

A policy definition may establish access to JavaScript sensitive APIs in a similar fashion, such as by a developer deciding which APIs are accessible to a container identified by its GUCID. For example, a policy definition for container with GUCID “APP1” may be given access to a function readFile that is part of the module ‘fs’ in Node. js and access to all functions of the ‘path’ module:

{container_gucid: ’APP1’ , api_list: { ‘fs’ : [ ‘readFile’ ] , ’path’ : [*] } }

Designing a secure JavaScript container requires careful system design to block all possible ways to break out of a container. In the following sections, possible ways of escaping containers and the technical mechanisms to mitigate such vulnerabilities are discussed.

In an example, application code confinement may be provided among containers in the secure code execution environment. One of the key challenges of building a logical container for worker applications is providing a mechanism to ensure memory safety. The JavaScript engine runs all loaded scripts in the same execution environment and therefore provides no built-in notion of memory or process separation between two pieces of code. However, existing JavaScript language features may be leveraged as follows to provide memory safety.

The first step is to apply separate namespacing by putting two pieces of code in two different function wrappers. The following example of JavaScript code shows how those pieces of code may be transformed:

The function wrapper acts as a container for the application and offers namespacing for non-global objects in the code. However, this technique is not sufficient to protect JavaScript code running in the container from being accessed by a malicious application running in another container. For example, malicious code could access all the properties of the object using the keyword this. Such an outcome is harmful because a malicious application could enumerate all functions, get the source code, or even execute the targeted functions:

To mitigate this problem, the name of the function wrapper associated may be randomized to each application and for each LBH instance. This way, a worker application cannot directly call functions belonging to other worker applications since the names of these functions are not known. Second, all JavaScript code inside the container may be prevented from accessing the properties of variable LBHobj above using an ECMAScript feature called Object. defineProperty. This feature defines accessibility of a property in an object. This may be used to ensure a worker application cannot, for example, iterate through the LBHobj object to find names of functions or variables. For example, if a flag value of enumerable is set to false for a property p, such property p will not be visible to the other scripts during the enumeration process (e.g., enumerate properties using for-in) .

Finally, global variables may be removed from worker applications. Global variables may be used by the attacker as a channel to influence the value of non-global objects being used in application container or in a secure component —this way the notion of isolation between two containers cannot be guaranteed. To handle this problem, variable names used in the applications may be randomized before being deployed. In addition, every function call can be edited so that it is tied to the local this context. This is done by using Function. prototype. apply instead of a direct function call. This patching may be done statically during pre-deployment phase and therefore will not affect the overall performance of the applications.

Table 1, as depicted below, illustrates two ways of defining a function in JavaScript, using a function declaration (left column) or an object’s method (right column) .

TABLE 1

A function’s this keyword behaves differently in JavaScript compared to other languages, which is determined by how a function is called. There are two kinds of functions in JavaScript –functions defined via (i) function declaration or (ii) an object’s method (as shown in Table 1) . In case (i) , the this object inside the function refers to the global object, whereas in case (ii) the this object will be set to the object the method is called on. Use of the LBH requires that workers do not have a reference to the global scope, which may be achieved by declaring a function using an explicit function declaration.

To solve this issue, the LBH instrumentation may locate any function call in the worker’s source code or use of the explicit function execution API call “apply” and replace it with Function. prototype. apply. Function. prototype. apply does the same thing as a function call or use of “apply” , except that now the this object within the called function will be forced to point to the local context, instead of the global one.

However, the process of randomizing variable names and removing global variables will not work for dynamically created global variables. Global variables in general are not a recommended practice, but dynamically creating variables may occur with obfuscated JavaScript code. JavaScript obfuscation may use JavaScript functions such as eval and new Function () to dynamically create JavaScript objects. JavaScript that dynamically creates global variables will not be handled by the randomization and global variable removal process, which is done statically on the source code. Local variables created by obfuscated code are local to the application in the container due to the scoping rules in JavaScript and hence will not affect any code running in other containers.

To prevent global variables from being created dynamically, the global object (e.g., GLOBAL in Node. js) may be frozen using the standard Object. freeze function. This way, code in the container is prevented from adding new properties to the GLOBAL object, which is necessary to make the variable globally accessible. Hence, although all security isolation properties continue to hold, workers that depend on dynamically creating global variables and sharing them between modules without explicit API calls will not work properly.

The code re-writing process also may be called recursively on strings passed to eval and new Function () . In this example, eval and new Function () may be replaced with versions that convert the global objects to local objects.

In an additional example, external reference clean up may be used to provide further security and isolation. In JavaScript, there are three ways to access objects outside the worker’s environment. The first is through the access of global variables or external variables that are accessible due to scoping rule. The second is via the this object. The third way is through the arguments. callee. caller property, which essentially gives access to the object of calling function. The first two cases may be addressed using variable name randomization and removal of global variables (as discussed above) . Attackers that make use of arguments. callee. caller property in a vulnerable application, however, may still have access to all the functions preceding the attacker's function.

Table 2 demonstrates a technique used to mitigate external references using the arguments. callee. caller property. During rewriting, one line is inserted at the top of the body of each function definition, assigning null to arguments. callee, so that the rest of the code cannot access external references. This technique enforces security isolation, but workers that depend on the arguments. callee object will not work properly.

TABLE 2

In some examples, the LBH may provide workers with APIs to use transport layer security (TLS) , which provides secure communication and server authentication based on a certificate store. The LBH may store and manage the certificate store. Shim code in the LBH may be used to extend the existing API module, if present, for creating an external HTTP request (e.g., XMLHttpRequest for Pebble. js) and adds logic for TLS before actually sending the data to the other end. For a platform where TLS support is provided (e.g., https module in Node. js) , this feature will not be enabled. However, the LBH may still monitor worker TLS connections for conformance to other policies, such as resource consumption.

In some examples, the JavaScript interpreter (including the LBH and the worker modules) may be executed within a TEE, such as with use of an

Software Guard Extensions (SGX) secure enclave. The use of a TEE does not, by itself, protect the JavaScript program from untrusted modules or from other JavaScript programs that the interpreter is running. However, the execution of a JavaScript interpreter within a TEE serves a different purpose –to protect the entire JavaScript program and data that it is using from outside programs.

In a further example, a messaging interface may be used for communications between applications operating in the secure code execution environment. Inter-application communication is a feature that is commonly used for a larger application that contains many disparate-but-connected JavaScript modules —each module performing a specific operation. For example, an IoT gateway application that performs data analytics may need to separate some of its modules for data acquisition, data processing, and data presentation when running in an IoT device. These modules, however, may still need to collaborate with each other (e.g., data acquisition module needs to pass the sensed information to data processing module for analysis) and therefore inter-application communication is needed. Such inter-application communication has been implemented on web browsers via HTML5’s window. postMessage but does not exist as part of in-built JavaScript or Node. js features.

In an example, the secure code execution environment may provide an API to carry out inter-application communication between two confined applications in a container via an object named message. The object message may include two functions: 1) pooler () to register a callback function used to receive the message from another application and 2) sendMessage () to send a message to another application. An example of this communication is provided in the following scenario.

FIG. 3 illustrates a control and data flow of communications between applications operating in a secure code execution environment, according to an example. In FIG. 3, the dotted lines denote steps to register a listener function and the dashed lines denote steps to send an inter-application message. The application container that receives a message (container 345) registers a callback function into a trusted container’s pool (container 335) . When another application (App2 325) wishes to send a message to the application (App1 315) , the trusted container 345 checks the target and origin of the message, picks the corresponding listener function, and attaches the message that is being sent.

Specifically, as depicted in FIG. 3, when a message M is to be transmitted from App2 325 to App1 315, App1 315 has to register (via pooler () ) a specific function object that will receive the message from App2 325 to the LBH (operation 310) . The LBH manages access to the function object and stores the reference to the function object in its memory space. Once the receiving function on the receiving end has been registered, App2 325 calls function sendMessage () whenever M is to be sent to App1 315 and specifies the receiver of the message (thus, the message will not be broadcast to all containers) . In this fashion, the LBH mediates the communication from App2 to App1 (operation 320) .

To specify which container will be the target of the message, App2 325 needs to specify the GUCID of App1 315, which is “APP1” in this example. Once sendMessage () is invoked, the LBH ensures that developers allow App2 to access App1 (operation 330) , and such verification may be performed using a pre-defined policy. If the policy matches, the LBH invokes an upcall that is a function call 355 from the trusted area to the non-trusted area (operation 340) in order to pass the message from App2 315. The message will be sent as part of arguments of the registered function callbacks, i.e., for foo function 365.

In a further example, application monitoring may be performed in the secure code execution environment. For example, applications may be monitored for the use of privileged APIs and the usage of resources (e.g., to prevent a denial of service by consuming an excessive amount of some shared but finite resources. Examples of such resources include memory, CPU time, disk space, and network bandwidth) .

Certain JavaScript environments such as Node. js let the application access certain resources on the platform (e.g., file system, native code execution) through pre-defined APIs. Those APIs (for instance, included in the execution environment via a function require in Node. js) will return to the application an object that the application may use to access the resources.

In an example, the concept of least privilege is applied to every application running in a container, meaning that: 1) each application must be allowed to access certain resources only for certain amount of time, and 2) each application may only access resources that it is supposed to access, and nothing else (e.g., as is normally defined through a policy) . The use of these privilege and access control concepts to preserve resources is further demonstrated in the following examples.

FIG. 4 illustrates a control and data flow for handling a function call in a secure code execution environment, according to an example. Specifically, FIG. 4 illustrates the operations used to obtain an object to access platform resources. The scenario (a) with container 415 and

operations

420, 430 illustrates steps taken when an application would like to have access to the file system； the scenario with

container 415'and operations

420, 430 illustrate steps taken when this access is not allowed.

In the scenario (b) with container 415, the request to access the file system (operation 410) will be redirected to a secure container 435 in order to verify whether such access to a particular app (app 425) is legitimate (operation 420) . If so, the secure container creates an object according to the request (operation 430) and sends it back to the requesting application (to app 425, as shown in operation 440) .

In the scenario with container 415', an object “membrane” is applied where access to the file system is not allowed for the application (app 425') . In this case, the receiving applications (such as app 425') do not have direct access to the requested object on the file system； instead, as a result of the verification and creation operations 420'and 430'in the secure container 435', the applications receive the wrapped object that is under full control of the secure container (operation 440') .

In a JavaScript-based application, a script is not allowed to directly access platform resources or execute native code. The only way of accessing such resources are through JavaScript APIs. Thus, the presently disclosed secure code execution environment redefines existing sensitive JavaScript APIs. The redefined functions intercept every JavaScript object creation via the APIs. For each API invocation, the application will make a downcall to the trusted container for getting an access to the resources (as shown in FIG. 4, operation 410) . The trusted container will then decide whether such access is legitimate and, if so, creates the object and return it to the requesting application (as shown in FIG. 4,

operations

420, 430, 440) . As a result, the application has access to the resources via the JavaScript object created by the trusted containers.

Such an approach has two potential issues. First, how can the trusted container revoke access to resources？ Access to resources which is given through object reference must be revocable, in other words, once the object is given to the worker application, the reference to the object should be able to be withdrawn at any time by the trusted container. Second, how does the trusted container make sure that the worker application does not have access to more resources than it is supposed to have？ In order to mitigate these issues, an object membrane (e.g., as implemented in operations 420', 430', 440'of FIG. 4) may be applied, based on an object capability model. Thus, certain objects to be protected may be wrapped in a “membrane” (consisting of intermediate code that substitutes for the original API and mediates interaction with the API) and the secure code execution environment does not allow untrusted applications have direct references to the original object. Instead, such wrapped objects come with a set of “proxy objects” that control access to the original objects.

When there is another script that wants to access such objects, such script can only access the wrapped objects via the proxy objects. The proxy objects have the capability to decide how long the object reference be given since the proxy code possesses the capability to revoke access from the application to the targeted objects at any time, as well as to inspect whatever operation that the script is being done on the object.

Technically, all JavaScript objects created by certain security sensitive APIs (e.g., fileSystem, exec) may be wrapped, to only allow the confined applications to access these objects via proxy objects. This is done through redefinition of the “require” function that is used to invoke such APIs. In order to provide this security, all these objects’ creation will take place at the trusted container context, and the resulted object will be returned via the proxy object back to the application.

In a further example, the secure code execution environment may be configured to prevent Denial of Service (DOS) and related resource exhaustion attacks. DOS attacks are based on "using up" finite resources so that other applications cannot run. Resources may include network bandwidth, file system storage space, memory and CPU time. As network bandwidth and file system storage space may be handled with modifications to APIs to monitor usage of these specific resources, a focus on memory and CPU time, which are harder to monitor, follows.

In an example, memory and CPU consumption may be monitored by rewriting the code to insert "instrumentation" calls at the start of every function and loop. CPU and memory may grow in unbounded ways when there is iteration or recursion. The instrumentation calls need to compare current execution time and memory use against the limits for the container and throw an exception (which cannot be caught by the untrusted code) to terminate the untrusted code when those limits are exceeded. This controls excessive use of memory or CPU in user-written code. It is also possible to use large amounts of memory or CPU by giving certain arguments to API calls, but these can be controlled by proxy functions wrapping those APIs as noted above.

In a further example, the secure code execution environment may be operated to manage usage of CPU Time resources with use of a policy. An assumption may be made that all language statements and API calls may complete execution using a bounded amount of time. This assumption may be checked by proxy code, in particular by monitoring potentially "Turing complete" APIs like regex pattern matchers (e.g., pathological constructs that use exponential space and time during conversion from NFAs to DFAs, or lengthy regex match strings) , parsers (non-terminating recursive grammars could potentially be specified, which would fail to terminate given the right input to parse...) , database interfaces (e.g. with certain SQL commands) , and the like. Note that in general it is impossible, because the halting problem is undecidable, to prove whether some of these inputs to APIs will result in non-terminating computations. However, to prevent DOS attacks, a conservative approach can be taken and all input with the potential to consume resources beyond the limit set by the policy can be rejected.

Potential overhead for instrumentation to implement the policy may be optimized/implemented by reducing the frequency of checks. For example, instrumentation code may maintain counters to only check limits the nth time it is called. These counters could be global (e.g., per container) or local (e.g., per instrumentation call) . The counters could also check limits randomly with some probability to avoid attackers with knowledge of the checks from working around them. Additionally, a worst-case analysis of resource consumption along all possible execution paths may be performed between instrumentation calls to determine how often to check. It would also be possible to use static analysis to eliminate checks； for instance, if it can be proven that a loop will only ever execute a specific number of times, the checks for termination of that loop can be eliminated.

The instrumentation to implement the policy also may be optimized/implemented by reducing the frequency of checks, performing conservative termination analysis (including in pre-deployment) . The instrumentation need not be included in every function, just in those that are part of some potentially non-terminating recursion. Likewise not every loop supports an indefinite number of iterations, as many are provably bounded. A conservative analysis with potential false positives may be used since the halting problem is in general undecidable. Further, in the case that a clever attacker might spread a mutual recursion over several modules, whole-program analysis may be performed.

Finally, another approach to invoke for resource usage may be based on a simple “watchdog” timer. This timer may be used to simply stop the worker execution if time has passed a defined threshold. Other variations to these and like monitoring techniques may be implemented.

In a further example, the secure code execution environment may be operated to manage usage of memory resources with use of a policy. For memory consumption, the secure code execution environment may rely on the runtime to provide a “hook” and use instrumentation to check memory consumption. This may not be available on all platforms, but is available on Node. js, for instance. As an alternative approach, the engine performing the checks may use a watchdog timer callback. As another alternative approach, the worker code may be rewritten to check total memory consumption before and after each potential memory-allocating event (with suitable optimizations, as with monitoring of CPU usage, to reduce the total overhead) . CPU and memory instrumentation sites may also be combined.

In a further example, a secure update may be used for implementing updates in the secure code execution environment. Such a feature may be particularly useful when updating source code on remote devices. For instance, FIG. 5 depicts an overview of secure update process 500 according to an example. It is assumed that the platform holds a public key of the operator performing the update. At operation 510, the operator signs the update, which includes one or more source code files, using a private key. At operation 520, after receiving the update from the operator, LBH checks the integrity using the operator’s public key and signature. At operation 530, if the signature is valid, then the LBH accesses and replaces the content of the specific file (s) with the source code files provided by the operator. At operation 540, the LBH restarts.

FIG. 6 is a flowchart illustrating a method 600 of providing a secure code execution environment, according to an example. At operation 610, source code for executing a process is obtained at a processor-based system.

At operation 620, the source code is searched for a scope violation. A scope violation is a reference to a variable, function, or other object that is referenced outside of the scope of the calling function or object’s scope.

At operation 630, the source code is rewritten to change a name corresponding to the scope violation with a replacement name. The replacement name may be an arbitrary name, such as a random string.

At operation 640, the source code is searched for a restricted function call. Restricted functions calls include, but are not limited to system calls, function calls to access network resources, function calls to access file system resources, function calls to administer or configure a machine, or the like.

At operation 650, the source code is rewritten to change the restricted function call to call a proxy for the restricted function call. The proxy may be an arbitrary function name, which when called, is handled by a proxy service, such as the LBH. The proxy is a function that may be used to first check the state of the calling function and permit or deny the restricted function to be initiated based on the state of the calling function. The proxy may also be used to enforce various other policies for a function, an application, or a process. Policies may be used to restrict access to other applications, machine resources, file systems, network resources, or the like.

In an embodiment, the source code defines a first software application. In such an embodiment, the method 600 includes constructing a first container and placing the first software application in the first container. The container may include various software constructs, as described in this document. Thus, in a further embodiment, the first container is a method of a software language object. In another embodiment, the first container is a function wrapper.

In an embodiment, a name of the function wrapper is a randomly assigned string.

In an embodiment, the source code defines a second software application, and in such an embodiment, the method 600 includes rewriting the second software application to modify scope violations and change restricted function calls to proxy calls. In a further embodiment, the method 600 includes administering messaging between the revised first and revised second software applications.

In an embodiment, the method includes receiving from the first software application a callback function to register, the callback function used to receive a message from another application； trapping a send message function from the second software application, the send message function including the first software application as a destination for a message in the send message function； and invoking the callback function with the message from the second software application.

In an embodiment, the method 600 includes trapping a function call from the first software application； checking a policy regarding the function call and the first software application； and conditionally permitting the function call to execute based on the policy. In a further embodiment, the function call is a system function call. In another embodiment, checking the policy comprises accessing a policy store to determine an access right for the first software application, and permitting the function call to execute based on the access right.

In another embodiment, checking the policy comprises monitoring a resource usage of the first software application and permitting the function call to execute based on the resource usage. In a further embodiment, the resource usage is one of memory consumption, processor utilization, storage space consumption, or communication bandwidth.

In an embodiment, rewriting the source code to change the name corresponding to the scope violation with the replacement name includes identifying a variable name in the source code and replacing the identified variable name with a randomly assigned string. In a further embodiment, the variable name is a reference to a global variable.

Thus, as discussed herein, the LBH is a framework that, given a set of JavaScript applications (or modules) S ＝ {A1, A2, ..., AN} runs on the same device, will transform S into a packaged application P that consist of S and additional JavaScript logic to isolate applications in S from each other. During pre-deployment phase, LBH may statically analyze applications in S to 1) detect and remove any global instances in the applications and 2) determine the JavaScript APIs that are being used by them. Such an analysis is important to build an API policy that indicates which APIs are being used by the application —during deployment the policy ensures that only those APIs are allowed to be accessed and no others. (This can be done by reusing existing JavaScript static analysis tools, among other techniques) .

After statically analyzing the applications, LBH rewrites the applications in S to perform certain operations. First, LBH generates shim code to redefine functions that perform external module inclusion (e.g., redefining and wrapping the existing require function) . This guarantees that access to resources via JavaScript APIs is always obtained via downcall to the trusted container —hence enforcing the notion of least privilege. Secondly, the LBH rewrites the application to redefine all JavaScript functions used to carry out certain sensitive operations, such as creating outgoing HTTP requests； an example is XMLHttpRequest () . By redefining such functions, any outgoing request will now be equipped with a token to guarantee integrity and authority of the request —proxy code added through rewriting will make sure the trusted container intercepts each outgoing request and associates each such request with the required token.

Finally, rewriting application code may also be used for code updates. In order for the updated code to execute, the code is executed within the application’s context (e.g., via eval () ) . Once the in-application rewriting for S is done, the LBH then may auto-generate the logic for trusted container, bootstrapper, and inter-application messaging. LBH may also generate code for a JavaScript container, which is a function wrapper with empty content. As a final step, LBH copies the rewritten application code in S and places it into its corresponding container. This step, however, requires an intervention from a developer to figure out the execution order of the applications. If developers do not set a particular execution order, LBH will then set the execution order according to their order in S. The LBH also randomly generates a security token for this device, which is useful for secure outgoing communication. At this point, the whole process results in a packaged application P that is ready to be deployed into a device.

FIG. 7 is a block diagram illustrating a machine in the example form of a computer system 700, within which a set or sequence of instructions may be executed to cause the machine to perform any one of the methodologies discussed herein, according to an example embodiment. The machine may be an personal computer (PC) , a tablet PC, a hybrid tablet/notebook PC, a personal digital assistant (PDA) , a mobile telephone or smartphone, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein. Similarly, the term “processor-based system” shall be taken to include any set of one or more machines that are controlled by or operated by a processor (e.g., a computer) to individually or jointly execute instructions to perform any one or more of the methodologies discussed herein.

Example computer system 700 includes at least one processor 702 (e.g., a central processing unit (CPU) , a graphics processing unit (GPU) or both, processor cores, compute nodes, etc. ) , a main memory 704 and a static memory 706, which communicate with each other via an interconnect 708 (e.g., a link, a bus, etc. ) . The computer system 700 may further include a video display unit 710, an input device 712 (e.g., an alphanumeric keyboard) , and a user interface (UI) control device 714 (e.g., a mouse, button controls, etc. ) . In one embodiment, the video display unit 710, input device 712 and UI navigation device 714 are incorporated into a touch screen display. The computer system 700 may additionally include a storage device 716 (e.g., a drive unit) , a signal generation device 718 (e.g., a speaker) , an output controller 732 (e.g., for control of actuators, motors, and the like) , a power management controller 734, a network interface device 720 (which may include or operably communicate with one or more antennas 730, transceivers, or other wireless communications hardware) , and one or more sensors 726 (e.g., cameras) , such as a global positioning system (GPS) sensor, compass, accelerometer, location sensor, or other sensor.

The storage device 716 includes a machine-readable medium 722 on which is stored one or more sets of data structures and instructions 724 (e.g., software) embodying or utilized by any one or more of the methodologies or functions described herein. The instructions 724 may also reside, completely or at least partially, within the main memory 704, static memory 706, and/or within the processor 702 during execution thereof by the computer system 700, with the main memory 704, static memory 706, and the processor 702 also constituting machine-readable media.

While the machine-readable medium 722 is illustrated in an example embodiment to be a single medium, the term “machine-readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more instructions 724. The term “machine-readable medium” shall also be taken to include any tangible medium that is capable of storing, encoding or carrying instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure or that is capable of storing, encoding or carrying data structures utilized by or associated with such instructions. The term “machine-readable medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media. Specific examples of machine-readable media include non-volatile memory, including but not limited to, by way of example, semiconductor memory devices (e.g., electrically programmable read-only memory (EPROM) , electrically erasable programmable read-only memory (EEPROM) ) and flash memory devices； magnetic disks such as internal hard disks and removable disks； magneto-optical disks； and CD-ROM and DVD-ROM disks.

The instructions 724 may further be transmitted or received over a communications network 728 using a transmission medium via the network interface device 720 utilizing any one of a number of transfer protocols (e.g., HTTP) . Examples of communication networks include a local area network (LAN) , a wide area network (WAN) , the Internet, mobile telephone networks, plain old telephone (POTS) networks, and wireless data networks (e.g., Wi-Fi, 2G/3G, and 4G LTE/LTE-A or WiMAX networks) . The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding, or carrying instructions for execution by the machine, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software.

Embodiments used to facilitate and perform the techniques described herein may be implemented in one or a combination of hardware, firmware, and software. Embodiments may also be implemented as instructions stored on a machine-readable storage device, which may be read and executed by at least one processor to perform the operations described herein. A machine-readable storage device may include any non-transitory mechanism for storing information in a form readable by a machine (e.g., a computer) . For example, a machine-readable storage device may include read-only memory (ROM) , random-access memory (RAM) , magnetic disk storage media, optical storage media, flash-memory devices, and other storage devices and media.

It should be understood that the functional units or capabilities described in this specification may have been referred to or labeled as components or modules, in order to more particularly emphasize their implementation independence. Such components may be embodied by any number of software or hardware forms. For example, a component or module may be implemented as a hardware circuit comprising custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A component or module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. Components or modules may also be implemented in software for execution by various types of processors. An identified component or module of executable code may, for instance, comprise one or more physical or logical blocks of computer instructions, which may, for instance, be organized as an object, procedure, or function. Nevertheless, the executables of an identified component or module need not be physically located together, but may comprise disparate instructions stored in different locations which, when joined logically together, comprise the component or module and achieve the stated purpose for the component or module.

Indeed, a component or module of executable code may be a single instruction, or many instructions, and may even be distributed over several different code segments, among different programs, and across several memory devices or processing systems. In particular, some aspects of the described process (such as code rewriting and code analysis) may take place on a different processing system (e.g., in a computer in a data center) , than that in which the code is deployed (e.g., in a computer embedded in a sensor or robot) . Similarly, operational data may be identified and illustrated herein within components or modules, and may be embodied in any suitable form and organized within any suitable type of data structure. The operational data may be collected as a single data set, or may be distributed over different locations including over different storage devices, and may exist, at least partially, merely as electronic signals on a system or network. The components or modules may be passive or active, including agents operable to perform desired functions.

Additional examples of the presently described method, system, and device embodiments include the following, non-limiting configurations. Each of the following non-limiting examples may stand on its own, or may be combined in any permutation or combination with any one or more of the other examples provided below or throughout the present disclosure.

Example 1 is a system for providing a code execution environment, the system comprising: a processor subsystem； and a memory coupled to the processor subsystem, the memory including instructions, which when executed by the processor subsystem, cause the processor subsystem to: obtain source code for executing a process； search the source code for a scope violation； rewrite the source code to change a name corresponding to the scope violation with a replacement name； search the source code for a restricted function call； and rewrite the source code to change the restricted function call to call a proxy for the restricted function call.

In Example 2, the subject matter of Example 1 optionally includes wherein the source code defines a first software application, and wherein the instructions include instructions, which when executed by the processor subsystem, cause the processor subsystem to: construct a first container； and place the first software application in the first container.

In Example 3, the subject matter of Example 2 optionally includes wherein the first container is a method of a software language object.

In Example 4, the subject matter of any one or more of Examples 2–3 optionally include wherein the first container is a function wrapper.

In Example 5, the subject matter of Example 4 optionally includes wherein a name of the function wrapper is a randomly assigned string.

In Example 6, the subject matter of any one or more of Examples 2–5 optionally include wherein the source code defines a second software application, and wherein the instructions include instructions, which when executed by the processor subsystem, cause the processor subsystem to rewrite the second software application to modify scope violations and change restricted function calls to proxy calls.

In Example 7, the subject matter of Example 6 optionally includes wherein the memory includes instructions, which when executed by the processor subsystem, cause the processor subsystem to administer messaging between the revised first and revised second software applications.

In Example 8, the subject matter of any one or more of Examples 6–7 optionally include instructions, which when executed by the processor subsystem, cause the processor subsystem to: receive from the first software application a callback function to register, the callback function used to receive a message from another application； trap a send message function from the second software application, the send message function including the first software application as a destination for a message in the send message function； and invoke the callback function with the message from the second software application.

In Example 9, the subject matter of any one or more of Examples 2–8 optionally include instructions, which when executed by the processor subsystem, cause the processor subsystem to: trap a function call from the first software application； check a policy regarding the function call and the first software application； and conditionally permit the function call to execute based on the policy.

In Example 10, the subject matter of Example 9 optionally includes wherein the function call is a system function call.

In Example 11, the subject matter of any one or more of Examples 9–10 optionally include wherein the instructions to check the policy comprise instructions to: access a policy store to determine an access right for the first software application； and permit the function call to execute based on the access right.

In Example 12, the subject matter of any one or more of Examples 9–11 optionally include wherein the instructions to check the policy comprise instructions to: monitor a resource usage of the first software application； and permit the function call to execute based on the resource usage.

In Example 13, the subject matter of Example 12 optionally includes wherein the resource usage is one of: memory consumption, processor utilization, storage space consumption, or communication bandwidth.

In Example 14, the subject matter of any one or more of Examples 1–13 optionally include wherein the instructions to rewrite the source code to change the name corresponding to the scope violation with the replacement name comprise instructions to: identify a variable name in the source code； and replace the identified variable name with a randomly assigned string.

In Example 15, the subject matter of Example 14 optionally includes wherein the variable name is a reference to a global variable.

Example 16 is a method of providing a secure code execution environment, the method comprising: obtaining at a processor-based system, source code for executing a process； searching the source code for a scope violation； rewriting the source code to change a name corresponding to the scope violation with a replacement name； searching the source code for a restricted function call； and rewriting the source code to change the restricted function call to call a proxy for the restricted function call.

In Example 17, the subject matter of Example 16 optionally includes wherein the source code defines a first software application, and wherein the method comprises: constructing a first container； and placing the first software application in the first container.

In Example 18, the subject matter of Example 17 optionally includes wherein the first container is a method of a software language object.

In Example 19, the subject matter of any one or more of Examples 17–18 optionally include wherein the first container is a function wrapper.

In Example 20, the subject matter of Example 19 optionally includes wherein a name of the function wrapper is a randomly assigned string.

In Example 21, the subject matter of any one or more of Examples 17–20 optionally include wherein the source code defines a second software application, and wherein the method comprises rewriting the second software application to modify scope violations and change restricted function calls to proxy calls.

In Example 22, the subject matter of Example 21 optionally includes administering messaging between the revised first and revised second software applications.

In Example 23, the subject matter of any one or more of Examples 21–22 optionally include receiving from the first software application a callback function to register, the callback function used to receive a message from another application； trapping a send message function from the second software application, the send message function including the first software application as a destination for a message in the send message function； and invoking the callback function with the message from the second software application.

In Example 24, the subject matter of any one or more of Examples 17–23 optionally include trapping a function call from the first software application； checking a policy regarding the function call and the first software application； and conditionally permitting the function call to execute based on the policy.

In Example 25, the subject matter of Example 24 optionally includes wherein the function call is a system function call.

In Example 26, the subject matter of any one or more of Examples 24–25 optionally include wherein checking the policy comprises: accessing a policy store to determine an access right for the first software application； and permitting the function call to execute based on the access right.

In Example 27, the subject matter of any one or more of Examples 24–26 optionally include wherein checking the policy comprises: monitoring a resource usage of the first software application； and permitting the function call to execute based on the resource usage.

In Example 28, the subject matter of Example 27 optionally includes wherein the resource usage is one of: memory consumption, processor utilization, storage space consumption, or communication bandwidth.

In Example 29, the subject matter of any one or more of Examples 16–28 optionally include wherein rewriting the source code to change the name corresponding to the scope violation with the replacement name comprises: identifying a variable name in the source code； and replacing the identified variable name with a randomly assigned string.

In Example 30, the subject matter of Example 29 optionally includes wherein the variable name is a reference to a global variable.

Example 31 is an apparatus comprising means for performing any of the methods of Examples 16-30.

Example 32 is at least one machine-readable medium including instructions, which when executed by a machine, cause the machine to: obtain source code for executing a process； search the source code for a scope violation； rewrite the source code to change a name corresponding to the scope violation with a replacement name； search the source code for a restricted function call； and rewrite the source code to change the restricted function call to call a proxy for the restricted function call.

In Example 33, the subject matter of Example 32 optionally includes wherein the source code defines a first software application, and wherein the instructions include instructions, which when executed by the machine, cause the machine to: construct a first container； and place the first software application in the first container.

In Example 34, the subject matter of Example 33 optionally includes wherein the first container is a method of a software language object.

In Example 35, the subject matter of any one or more of Examples 33–34 optionally include wherein the first container is a function wrapper.

In Example 36, the subject matter of Example 35 optionally includes wherein a name of the function wrapper is a randomly assigned string.

In Example 37, the subject matter of any one or more of Examples 33–36 optionally include wherein the source code defines a second software application, and wherein the instructions include instructions, which when executed by the machine, cause the machine to rewrite the second software application to modify scope violations and change restricted function calls to proxy calls.

In Example 38, the subject matter of Example 37 optionally includes instructions, which when executed by the machine, cause the machine to administer messaging between the revised first and revised second software applications.

In Example 39, the subject matter of any one or more of Examples 37–38 optionally include instructions, which when executed by the machine, cause the machine to: receive from the first software application a callback function to register, the callback function used to receive a message from another application； trap a send message function from the second software application, the send message function including the first software application as a destination for a message in the send message function； and invoke the callback function with the message from the second software application.

In Example 40, the subject matter of any one or more of Examples 33–39 optionally include instructions, which when executed by the machine, cause the machine to: trap a function call from the first software application； check a policy regarding the function call and the first software application； and conditionally permit the function call to execute based on the policy.

In Example 41, the subject matter of Example 40 optionally includes wherein the function call is a system call.

In Example 42, the subject matter of any one or more of Examples 40–41 optionally include wherein the instructions to check the policy comprise instructions to: access a policy store to determine an access right for the first software application； and permit the function call to execute based on the access right.

In Example 43, the subject matter of any one or more of Examples 40–42 optionally include wherein the instructions to check the policy comprise instructions to: monitor a resource usage of the first software application； and permit the function call to execute based on the resource usage.

In Example 44, the subject matter of Example 43 optionally includes wherein the resource usage is one of: memory consumption, processor utilization, storage space consumption, or communication bandwidth.

In Example 45, the subject matter of any one or more of Examples 32–44 optionally include wherein the instructions to rewrite the source code to change the name corresponding to the scope violation with the replacement name comprise instructions to: identify a variable name in the source code； and replace the identified variable name with a randomly assigned string.

In Example 46, the subject matter of Example 45 optionally includes wherein the variable name is a reference to a global variable.

Example 47 is an apparatus, comprising: means for obtaining source code for executing a process； means for searching the source code for a scope violation； means for rewriting the source code to change a name corresponding to the scope violation with a replacement name； means for searching the source code for a restricted function call； and means for rewriting the source code to change the restricted function call to call a proxy for the restricted function call.

In Example 48, the subject matter of Example 47 optionally includes wherein the source code defines a first software application, and wherein the apparatus comprises: means for constructing a first container； and means for placing the first software application in the first container.

In Example 49, the subject matter of Example 48 optionally includes wherein the first container is a method of a software language object.

In Example 50, the subject matter of any one or more of Examples 48–49 optionally include wherein the first container is a function wrapper.

In Example 51, the subject matter of Example 50 optionally includes wherein a name of the function wrapper is a randomly assigned string.

In Example 52, the subject matter of any one or more of Examples 48–51 optionally include wherein the source code defines a second software application, and wherein the apparatus comprises means for rewriting the second software application to modify scope violations and change restricted function calls to proxy calls.

In Example 53, the subject matter of Example 52 optionally includes means for administering messaging between the revised first and revised second software applications.

In Example 54, the subject matter of any one or more of Examples 52–53 optionally include means for receiving from the first software application a callback function to register, the callback function used to receive a message from another application； means for trapping a send message function from the second software application, the send message function including the first software application as a destination for a message in the send message function； and means for invoking the callback function with the message from the second software application.

In Example 55, the subject matter of any one or more of Examples 48–54 optionally include means for trapping a function call from the first software application； means for checking a policy regarding the function call and the first software application； and means for conditionally permitting the function call to execute based on the policy.

In Example 56, the subject matter of Example 55 optionally includes wherein the function call is a system function call.

In Example 57, the subject matter of any one or more of Examples 55–56 optionally include wherein the means for checking the policy comprises: means for accessing a policy store to determine an access right for the first software application； and means for permitting the function call to execute based on the access right.

In Example 58, the subject matter of any one or more of Examples 55–57 optionally include wherein the means for checking the policy comprises: means for monitoring a resource usage of the first software application； and means for permitting the function call to execute based on the resource usage.

In Example 59, the subject matter of Example 58 optionally includes wherein the resource usage is one of: memory consumption, processor utilization, storage space consumption, or communication bandwidth.

In Example 60, the subject matter of any one or more of Examples 47–59 optionally include wherein the means for rewriting the source code to change the name corresponding to the scope violation with the replacement name comprises: means for identifying a variable name in the source code； and means for replacing the identified variable name with a randomly assigned string.

In Example 61, the subject matter of Example 60 optionally includes wherein the variable name is a reference to a global variable.

In the above Detailed Description, various features may be grouped together to streamline the disclosure. However, the claims may not set forth every feature disclosed herein as embodiments may feature a subset of said features. Further, embodiments may include fewer features than those disclosed in a particular example. Thus, the following claims are hereby incorporated into the Detailed Description, with a claim standing on its own as a separate embodiment.

Claims

A system for providing a code execution environment, the system comprising:

a processor subsystem； and

a memory coupled to the processor subsystem, the memory including instructions, which when executed by the processor subsystem, cause the processor subsystem to:

obtain source code for executing a process；

search the source code for a scope violation；

rewrite the source code to change a name corresponding to the scope violation with a replacement name；

search the source code for a restricted function call； and

rewrite the source code to change the restricted function call to call a proxy for the restricted function call.
The system of claim 1, wherein the source code defines a first software application, and wherein the instructions include instructions, which when executed by the processor subsystem, cause the processor subsystem to:

construct a first container； and

place the first software application in the first container.
The system of claim 2, wherein the first container is a method of a software language object.
The system of claim 2, wherein the first container is a function wrapper.
The system of claim 4, wherein a name of the function wrapper is a randomly assigned string.
The system of claim 2, wherein the source code defines a second software application, and wherein the instructions include instructions, which when executed by the processor subsystem, cause the processor subsystem to rewrite the second software application to modify scope violations and change restricted function calls to proxy calls.
The system of claim 6, wherein the memory includes instructions, which when executed by the processor subsystem, cause the processor subsystem to administer messaging between the revised first and revised second software applications.
The system of claim 6, comprising instructions, which when executed by the processor subsystem, cause the processor subsystem to:

receive from the first software application a callback function to register, the callback function used to receive a message from another application；

trap a send message function from the second software application, the send message function including the first software application as a destination for a message in the send message function； and

invoke the callback function with the message from the second software application.
The system of claim 2, comprising instructions, which when executed by the processor subsystem, cause the processor subsystem to:

trap a function call from the first software application；

check a policy regarding the function call and the first software application； and

conditionally permit the function call to execute based on the policy.
The system of claim 9, wherein the function call is a system function call.
The system of claim 9, wherein the instructions to check the policy comprise instructions to:

access a policy store to determine an access right for the first software application； and

permit the function call to execute based on the access right.
The system of claim 9, wherein the instructions to check the policy comprise instructions to:

monitor a resource usage of the first software application； and

permit the function call to execute based on the resource usage.
The system of claim 12, wherein the resource usage is one of: memory consumption, processor utilization, storage space consumption, or communication bandwidth.
The system of claim 1, wherein the instructions to rewrite the source code to change the name corresponding to the scope violation with the replacement name comprise instructions to:

identify a variable name in the source code； and

replace the identified variable name with a randomly assigned string.
The system of claim 14, wherein the variable name is a reference to a global variable.
A method of providing a secure code execution environment, the method comprising:

obtaining at a processor-based system, source code for executing a process；

searching the source code for a scope violation；

rewriting the source code to change a name corresponding to the scope violation with a replacement name；

searching the source code for a restricted function call； and

rewriting the source code to change the restricted function call to call a proxy for the restricted function call.
The method of claim 16, wherein the source code defines a first software application, and wherein the method of comprises:

constructing a first container； and

placing the first software application in the first container.
The method of claim 17, wherein the first container is a method of a software language object.
The method of claim 17, wherein the first container is a function wrapper.
The method of claim 19, wherein a name of the function wrapper is a randomly assigned string.
The method of claim 17, wherein the source code defines a second software application, and wherein the method comprises rewriting the second software application to modify scope violations and change restricted function calls to proxy calls.
The method of claim 16, wherein rewriting the source code to change the name corresponding to the scope violation with the replacement name comprises:

identifying a variable name in the source code； and

replacing the identified variable name with a randomly assigned string.
The method of claim 22, wherein the variable name is a reference to a global variable.
At least one machine readable medium including instructions, which when executed by a computing system, cause the computing system to perform any of the methods of claims 16-23.
An apparatus comprising means for performing any of the methods of claims 16-23.