Home · All Classes · Grouped Classes · Annotated · Functions

SXE - Aims and Limitations

• Introduction
• Use-case
• Discussion of Benefits
• Limitations
• Known Issues

Introduction

The primary objective of the first release SXE is to enable the user to download native applications, (which is currently limited to games) and be able to run these with confidence that they will not be able to compromise telephony software and services and cause billable events such as making unauthorized phone calls or sending SMS's.

The secondary objectives of the initial release are to

• maintain the integrity of the Qtopia system and availability of services and functionality
• provide improved performance, functionality and security over VM and other sandboxing models.
• ensure the confidentiality and integrity of user data.
• cause minimal impact and maximum usability for the end-user including performance considerations.

Use-case

To define and circumscribe the security problem that the SXE system is intended to solve the following Use-Case is presented:

Discussion of Benefits

• Native applications will often have better performance, through code optimization and access to hardware.
• Native sandboxing allows the security policy to be tailored to the file systems and application stack, providing stronger and more robust security at the operating system level.
• Previous implementations of MIDP (v1.0) was not strong on security, and even with version 2, security is focused on normal network protocols, with limited ability to protect the file system.
• There are licensing issues with the Java approach.

Limitations

SXE currently, is only intended to ensure the safe execution of downloaded games. Other types of applications may or may not be capable of operating within the sandbox provided. The sandbox will inherently limit functionality and so to further clarify a game is able to

• draw into the application region of the display
• play audio
• have write access to a sandboxed directory
• change the context bar

Known Issues

There are a few open issues (for the greenphone) that have been evaluated and have not been considered as a priority to address for the first release of SXE.

Sandboxed applications can:

• consume all the memory available on the device, the effect of this is somewhat negated with OOM handling
• fill up all the space in /tmp, preventing other applications that use /tmp from operating correctly
• use up all semaphores and shared memory available on the system.
• connect to any socket on the filesystem

The first three issues are effectively denial of service attacks on the system, but the effects of these attacks are minimal since a simple reboot will restore the device back into a normal state. There should be no further problems unless the downloaded malware is run again. There is little to gain in performing such an attack.

Regarding the fourth issue: Explicit protections have been made on the /dev/log socket to prevent untrusted applications trying to spoof security messages. It is permissible to allow untrusted applications to connect to the qws, document server, and valuespace_applayer sockets listened to by qpe, since message verification occurs on the server side. There are other various sockets on the device without these protections, however exploitations of these are believed only to be capable of causing nuisances to the user at best. Nevertheless, resolving this issue is one of the priorities for future releases.