Home · All Namespaces · All Classes · Grouped Classes · Modules · Functions codeless banner

SXE - Aims and Limitations


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


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

A device end-user:
  • browses for a package
  • downloads the package
  • installs it on the device.

The package may, without the users knowledge, contain flawed or malicious software.

After installation the user expects to run the program and obtain the package's promised functionality.

For telephony enabled devices the network provider expects the telephony software and service will not be compromised by malicious software knowingly installed by the user.

Discussion of Benefits


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

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:

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.

Copyright © 2009 Nokia Trademarks
Qt Extended 4.4.3