Security in Qtopia Phones
No one wants an insecure system, especially on a mobile or VoIP phone. Both users and operators want to feel confident that their phones won't be used secretly to send thousands of spam messages or viruses or to transfer huge files. Linux in the mobile space opens doors to everyone—including developers of malicious code. A locked-down and secure system does not necessarily mean the source code is closed.
The last thing people want on their phones is a malware application that secretly sends their details somewhere or launches a DOS attack using their costly GPRS account. Together with the Linux Intrusion Detection System (LIDS), Trolltech's Safe Execution Environment (SXE) delivers a safe environment in which to allow untrusted applications to be executed. Without SXE and LIDS, an unsuspecting user could install an unknown package. This could launch Qtopia's QCop, which handles Qtopia's interprocess communication (IPC) with LD_PRELOAD set to its own libc library. This means that its own code is loaded instead of the known libc in the system, which could have disastrous results on the user's data, or worse, disrupt emergency communications.
Trolltech has an answer.
Trolltech recently announced the GPL version of Qtopia that includes SXE, as well as telephony libraries needed for GSM and VoIP-enabled phones. Trolltech has spent many person-hours developing SXE to help ensure that both operators and users are confident about installing native compiled applications. I say person-hours here because the lead developer for much of SXE's life was Sarah Smith—Trolltech's first female developer.
SXE is a little like a firewall. It prevents applications from accessing unauthorized services and hardware through domain controls. It goes beyond just plain sandboxing applications, which can blindly deny programs access to system resources. It applies policy rules for each program component and IPC. Qtopia applications send an IPC or QCop message when they want to open a window or send an SMS.
Upon installation, an application specifies what security domains are needed to function and is sandboxed by Qtopia. If the program is executed and then tries to access services beyond what it has been awarded, a security breach is logged, and the application is terminated and disabled. A dialog and SMS message are issued to the user regarding the breach. LIDS can complete the safe environment by controlling access to hardware, system-level services, programs and files.
The Qtopia Greenphone is an example of a working SXE and LIDS implementation, and this article discusses Qtopia version 4.3.0. The Qtopia open-source version, announced recently for the FIC's open-source Neo phone, also would benefit from SXE and a LIDS-enabled kernel.
Although sales of the Greenphone have been discontinued, support and development for it has not—neither has development of SXE for Qtopia. In this article, I use the Greenphone mainly as an example.
Trolltech is advising people interested in an open Qtopia phone, to purchase an FIC Neo 1973, as it has ported Qtopia to that device and plans on supporting an SDK in the same light as the Greenphone SDK, scheduled to be released with the 4.3.1 release.
An SXE application starts with a developer creating a Qtopia application and packaging it in a Qpkg, which is based on the Itsy Package, but has a few security issues resolved. Namely, Qtopia does not allow an application install to run arbitrary scripts, but also, the package must specify which domains it needs access to in order to run. Qtopia then allows (or denies) that package only those domains that it requests.
An SXE domain is simply a name for an allowed access rights policy. Some of the default domains and their access rights in Qtopia are:
docapi: user documents.
pim: Personal Information Management data.
window: graphic display.
graphics: full-screen graphics display.
net: access to WAP, GSM and GPRS.
Qtopia uses many more domains, and some of them, such as the base domain, should never be allowed access by any untrusted application. Operators or integrators can use the default Qtopia domains or create their own.
The third-party developer then specifies, in the package control file, in which domains the application needs to function. Much like a legacy ipkg, a qpk is simply a gzipped tarball of the file structure where the application lives, a desktop file much like those used in KDE and GNOME, plus a control file that specifies parameters, such as the application's name, maintainer, domain, file size and so forth.
The Greenphone SDK makes this easy with the use of the gph script, which can configure, compile, build the package and install or run it on the Greenphone. The developer needs to know only which domains the application is going to use. Starting a debug build of Qtopia in SXE_DISCOVERY_MODE, with SXE logging turned on, can help log these domain requests and subsequent denials. There is a significant performance decrease while running in discovery mode. It is only for the debugging process and not a final release. The developer then can add the appropriate domains to the application's .pro file.
- Red Hat OpenStack Platform
- Transitioning to Python 3
- Tech Tip: Really Simple HTTP Server with Python
- Stepping into Science
- Linux Journal December 2016
- CORSAIR's Carbide Air 740
- A Better Raspberry Pi Streaming Solution
- Custom checks and notifications for Nagios
- Radio Free Linux
- The Tiny Internet Project, Part II