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.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- Designing Electronics with Linux
- Elliptic Curve Cryptography
- Getting Help With Linux
- Remote Compilation Using ssh and make
- Mediated Reality: University of Toronto RWM Project
- Writing Real-Time Device Drivers for Telecom Switches, Part 1
- NLE Video Editors
- Memory Leak Detection in Embedded Systems
- Linux Powers Four-Wall 3-D Display
- ViaVoice and XVoice: Providing Voice Recognition
19 min 12 sec ago
- Kernel Problem
10 hours 21 min ago
- BASH script to log IPs on public web server
14 hours 48 min ago
18 hours 24 min ago
- Reply to comment | Linux Journal
18 hours 57 min ago
- All the articles you talked
21 hours 20 min ago
- All the articles you talked
21 hours 23 min ago
- All the articles you talked
21 hours 25 min ago
1 day 1 hour ago
- Keeping track of IP address
1 day 3 hours ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?