SXE - Aims and Limitations

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.