OSNews

Within the Application Sandbox, applications are limited to specified resources. For example, quota functions can enforce file limits, and memory allocation functions can enforce memory limits. Most Operating Systems and databases provide means to configure these parameters, and even PHP and Java provide stubs that can be used to control memory management per application.

Controlling dynamic resources is more difficult than controlling static resources since multiple instances of the application may consume the same type of resource (e.g. Apache or Tomcat threads). Here either the independent resource controllers must be synchronized (e.g. CPU time) or a central function must be used to monitor and control resource usage (e.g. SMS messaging).

Either way, - static or dynamic - the resource controllers provide means of alerting the ASP of misuse.

Resource throttling is like controlling the flow of a water from a bucket. For CPU usage throttling, the bucket has a certain volume and rate of inflow. The water unit represents a CPU second, the inflow rate defines how quickly the resource is replenished, the water level in the bucket defines the maximum available CPU seconds currently available (for usage bursts) and the overall bucket volume defines the maximum burst size. For messaging throttling, the amount of water in the bucket represents the number of buffered messages, the bucket volume is the maximum number of buffered messages and the 'diameter' of the outflow determines the maximum available transmission rate.

Functionality Management: Limiting Application Access to Functionality
Functionality Management limits the applications' access to functions provided by the OS and other services. Limiting access to certain sections in the file tree is well supported by the OS (permissions, ACLs), but it's usually difficult to restrict access to functionality provided by OS libraries or services. For example, you might want to restrict access to the TCP stack to prevent the application from connecting to local services or to a 3rd-party host. Completely blocking the functionality may not be possible. It may be desirable to allow TCP-connection establishment only to selected systems and services.

Another example is database access. The application needs to be able to connect using certain username and password pairs, but must be prevented from executing brute-force database attacks. In this case, the functions cannot simply be disabled for a particular application. The function parameters must be verified and approved at runtime before granting access to the function. This is usually achieved by using a wrapper function with a parameter check and by preventing direct access to the original function.

Application Management: Supporting the System Administrator
Application Management supports the system administrator across the full application lifecycle (installation, configuration, operation, maintenance, de-commissioning). One of the main tasks is Sandbox configuration per application. Obviously, Resource Management and Functionality Management require in-depth knowledge of the different features and parameters to configure. It would be easy to misconfigure them due to lack of training or knowledge. To simplify configuration and to reduce the risk of misconfiguration, Application Management introduces pre-defined Resource Templates and Functionality Templates. These templates have names such as "high-traffic, memory-intensive resource use" or "untrusted, single-DB-logon" and reduce the risks of introducing security holes.

A note to the implementation of the Application Sandbox. We first implemented a sandbox for PHP as the application environment of choice. Here, some static limits and functionality restrictions can be made using php.ini (or the application specific .htaccess file), but control of dynamic resources and fine-grain functionality control (like the parameter checks described above) were not available. The modular structure of PHP provided the ideal basis for application specific function wrappers, without requiring a single change in the PHP framework or the PHP modules. Creation of an application Sandbox for Java proved more difficult, even though the existing security framework was more mature. For Java, some modifications in the Jakarta Tomcat's servlet container source code were required to provide the full solution.

Conclusion
With the introduction of the Application Sandbox and its features as described above the mobile service provider (and fixed-line ASPs) can finally host applications without worries, opening their network to the vast variety of applications developed by the Open Source Community or commercial entities without the need for prior verification and without potentially risking the application or network service quality.