Hosting Wireless Apps Without Compromising Stability & Security

Far and away the top three problems facing wireless operators and Application Service Providers (ASPs) today are integration, integration and integration. Their worst fear is mucking up their service to customers in any way. How do you integrate new data services into a legacy system without compromising its stability and security? In this article I’m introducing a new solution that can prevent rogue application behaviour, such as uncontrolled SMS or MMS blasts or over-consumption of resources leading to an interruption in service.

The Challenge to Mobile Operators and ASPs

To introduce this new solution, I am going to take a step back for one moment to briefly re-hash the environment operators work in and what they need to do to survive. Mobile operator ARPU (average revenue per user) is decreasing rapidly. Increased competition has prompted operators to bundle more attractive voice packages to both acquire new customers and retain their current customers. The holy grail that will save many mobile operators from completely going under is new mobile applications. So, I’ve stated the obvious.

Now for the technical side. In the past mobile operators have spent significant effort certifying new applications to ensure they would not distress the system. The result: high costs and long time to market. As mobile operators struggle with limited budgets to bring new applications into the network, they intend to streamline the process to require as little certification effort as possible.

At the risk of stating the obvious again, the streamlined process poses certain risks to both the mobile operator and the ASP. The potential problems are introduced (intentionally or unintentionally) by the third party applications, which may overconsume resources or in other ways interfere with other applications hosted in the same environment. Since the testing and certification effort is now limited, the potential risk increases dramatically:

• Applications may flood the operator network with spam text- or picture-messages, breaking the first rule of customer service: from minor annoyances to major ones as the network can be brought down.
  
• Applications may over-consume resources on the server (e.g. CPU seconds) and prevent proper operation of other applications.
  
• Applications may attempt a brute-force attack on the network elements within reach, such as a database.
  
• Applications may call functions that are out of the scope of the regular application operation (e.g. Trojans sending sensitive data to a 3rd party).
  

In the past, local solutions such as throttling within messaging gateways or using Virtual Machines to shield applications from each other have been used to address certain risk areas. However, these local solutions create significant administration and configuration overhead without fully solving the problem.

The Solution: an Application Sandbox

Now that we have the issues clarified, meet the solution: the Application Sandbox. Given that mobile operators and ASPs are streamlining the certification process, how about building a “sandbox” that is attached to, but separate from, the legacy system in which engineers can “play” with the new wireless applications? Some of you may say “Java Sandboxes have existed for years” – and I agree. However the solution I’m going to describe extends the Java security features and is also available for other languages, such as PHP.

The overall idea is that the sandbox keeps each application in its own fenced realm, whilst monitoring all potential areas of concern. The Application Sandbox functionality is split into three major components:

• Resource Management
  
• Functionality Management
  
• Application Management
  

Resource Management: Controlling Application Access to Resources

Resource Management controls the applications’ access to resources. Resources can be static or dynamic. Static resources do not change during application operation; examples are disk or database quota and maximum memory limits. Dynamic resources are consumed during application execution and need to be ‘refilled’ from time to time. Examples of dynamic resources are CPU-time and SMS messages. Dynamic resources are also well suited to throttling functions. In this case, applications are only allowed to consume a certain resource amount during any given time, say “10 CPU seconds within one minute” or “3 SMS messages per second”.

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.

About the author:
Roland Schmidt is CTO of Contec Innovations, a provider of an open, carrier-class service delivery platform. Mr. Schmidt is an expert in Internet security and telecommunications gateway solutions, he has led a diverse set of software development and consulting projects, the PHP/JSP Application Sandbox as described above being one of the recent ones.