Home · All Namespaces · All Classes · Grouped Classes · Modules · 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 Qt Extended 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: To prevent spoofing of security messages, specific protections in the kernel can be applied to the /dev/log socket preventing all processes other than qpe from writing to it, as is the case for the greenphone. Other sockets such as the qws and document server sockets which are listened to by qpe may be safely connected to by untrusted applications since there are server side message verification protocols in place. The valuespace_layer socket, also listened to by qpe however does not have any message verification mechanisms in place; the potential for exploit depends upon how the valuespace is used. Various other sockets won't have protections, in the case of the greenphone it is believed that the possible exploitations would only cause nuisances to the user at worst. Having the valuespace_applayer socket protected by message verification and having proper access control in place for sockets in general are issues to be addressed in future releases.