Mobile Application Security : WebOS Security - Introduction to the Platform

2/24/2011 4:08:14 PM
WebOS is based on Linux and uses several open-source packages. These packages are freely available for download on Palm’s website ( The page has a list of the open-source packages included with WebOS, the original tarballs, and any custom Palm patches. This list transparently shows which open-source components have been used and how they have been modified for the platform. The packages were released to fulfill Palm’s Open Source licensing obligations.

At the time of this writing, the Palm Pre has been released, but the SDK is still in beta and is changing from release to release. For example, the main HTML escaping security setting changed in release 1.0.4. Because the platform’s security model is still changing, any major changes to the model after release 1.2.0 are not included in this article. Expect changes in the future, especially the addition of new security functionality and the adoption of more secure default behavior.

To understand WebOS application security and how to develop secure applications on the platform, you need to know the following items, all of which are discussed in this article:

  • WebOS architecture

  • Developing applications

  • Security testing of the platform and its applications

  • Debugging and disassembly

  • Code security

  • Application packaging

  • Permissions and users controls

  • Secure storage

WebOS System Architecture

The WebOS architecture is very similar to that of a normal desktop PC. At the lowest level, WebOS runs a custom Linux distribution using the Linux 2.6 kernel. The Linux kernel manages devices, schedules applications, and provides general OS functionality (for example, the file system and process scheduling). Unlike many other embedded devices that run Linux, the Linux internals are almost completely abstracted from third-party WebOS applications. However, curious developers are still able to explore the system by connecting to the device after placing it in developer mode.

On top of the kernel, running in user mode, are several system processes and the UI System Manager. This WebOS-specific component is responsible for managing the life cycle of WebOS applications and deciding what to show the user. The UI System Manager is referred to as Luna and lives within /usr/bin/LunaSysMgr. It is actually a modified version of WebKit, the open-source web engine used by several browsers, most notably Safari on Mac OS X and Google Chrome. However, unlike those versions of WebKit, Luna is not used solely for web page rendering. Rather, all third-party WebOS native applications are authored using web technologies (HTML, JavaScript, CSS) and actually execute within Luna. So what appears in Linux as one process is in reality internally running several WebOS processes. Luna’s internal Application Manager controls the life cycle of these processes.

It is important to draw a distinction between WebOS processes, such as the e-mail application, and system processes, such as the Wi-Fi service. The former runs entirely within Luna and is not scheduled by Linux. The Wi-Fi service and others like it are traditional Linux processes scheduled by Linux kernel’s scheduler. All Linux processes, including Luna, run with super-user (a.k.a. root) permissions. This does not mean that all WebOS applications can completely control the device. Quite the contrary: Luna enforces per-application permissions and ensures that malicious applications cannot completely compromise the device. The chink in this sandbox’s armor is that a bug in Luna or its web-rendering engine could be exploited by malicious code to compromise the sandbox and abuse Luna’s super-user permissions.

WebOS uses Google’s V8 JavaScript engine (, a high-performance JavaScript engine that first shipped with Google’s Chrome browser. The V8 runtime creates a sandbox that prevents JavaScript from directly modifying memory or controlling the device’s hardware. For example, WebOS applications are prevented from directly opening files or devices such as /dev/kmem. This sandbox enables multiple processes at different privilege levels to cohabit the same Luna process. However, having applications that aren’t actually allowed to use the phone’s capabilities wouldn’t be that compelling.

The “Mojo” framework provides the bridge between the JavaScript sandbox and the device. Mojo refers broadly to a collection of services and plug-ins that are exposed to JavaScript and may be used by applications to access device functionality. For third-party application developers, Mojo is the window to leveraging the device’s capabilities.

There are two broad categories of extensions provided by Mojo: services and plug-ins. Plug-ins are written in C or C++ and implement the Netscape Plugin API (NPAPI). This API provides a bridge between JavaScript, Webkit, and objects written in other languages. The Camera, for example, needed to be written as a plug-in because it accesses device hardware directly. Because Luna knows how to communicate with plug-ins, Luna can load the plug-ins and display them on the same screen along with traditional Mojo framework UI elements. Each plug-in exposes some JavaScript methods that can be used to change the plug-in’s behavior or receive plug-in events. Third-party developers do not generally use plug-ins directly; instead, they use Mojo APIs that will end up invoking the plug-ins.

Services differ from plug-ins because they execute outside of the main Luna process. Services are long-running programs responsible for carrying out specialized tasks or monitoring critical data points. Services may also be isolated so as to separate native code from Luna and prevent a service process crash from affecting Luna. System services may be written in Java or C. With the current version of the SDK, the service interface is not exposed to legitimate third-party developers. However, portions of the service interface have been reverse engineered by the hobbyist community and third-party services will likely appear soon, even if they are not officially sanctioned by Palm.

Each service has a remote procedure call (RPC) interface that applications can use to communicate with the service. Some of these interfaces are documented, some are not. Palm does not grant permission to use undocumented interfaces. This lack of documentation is not a security boundary, and the system does not stop third-party applications from calling undocumented service methods.

Communication occurs over the “Palm Bus,” a communications bus based on the open-source D-Bus. The bus is a generic communication router that may be used to send and receive messages between applications. Its interface is much easier to use than standard IPC, and the bus manages the grunt work of serialization/deserialization, authorization, and listener registration. System applications can register with the bus to receive messages and access the bus to send messages to other applications. Only Palm applications are currently allowed to register as listeners on the bus. However, all applications use the bus extensively—either directly by using the service API or indirectly by using Mojo APIs that execute D-Bus calls under the covers.

All WebOS applications are identified using the “reverse-dns” naming convention. For example, an application published by iSEC Partners may be called com.isecpartners .webos.SampleApplication. This naming convention first originated with Java applications and is widely used to identify application owners and prevent naming collisions between applications. Not all applications must use this convention. Some applications use the standard D-bus notation), which is the complete path to the executable on disk (for example, /usr/bin/mediaserver). These applications are the extreme exception, and all third-party applications are named using reverse-dns notation.

The naming convention and the Palm Bus work together to play an important role in overall service security. The Palm Bus is divided into two channels: the public channel and the private channel. Not all services listen on both channels. For example, the sensitive SystemManager service only listens on the private channel. The Palm Bus only allows applications under the com.palm.* namespace to send messages to private-channel services. Services that want to be available to all applications, such as the Contacts service, listen on the public channel. Some services listen on both, but expose different service interfaces to each bus. This “permission gradient” is one of the only privilege gradients that exists in WebOS.

A final note on JavaScript and WebOS architecture. You may be familiar with JavaScript from programming web applications. WebOS JavaScript is the same, and the application is exposed to the JavaScript as a Document Object Model (DOM). This makes manipulating the application just like manipulating a web page. WebOS even includes the popular and useful Prototype JavaScript library. Because web developers are already familiar with these technologies, they can quickly learn how to create WebOS applications.

However, there are some subtle but important differences between the WebOS JavaScript execution environment and that of a standard web browser. Most notably, WebOS applications are not restricted by the Same Origin Policy. Regardless of their origin, applications can make requests to any site. Although developers may find this capability useful, malware authors may abuse the lack of a Same Origin Policy to communicate with multiple sites in ways that they cannot do within a web browser. The Same Origin Policy still applies to JavaScript executing in WebOS’s web browser, and the standard web application security model is not changed when simply browsing the Web.


WebOS applications implement the Model-View-Controller (MVC) architectural pattern, a popular design pattern that emphasizes the separation of data access (the model), presentation instructions (the view), and input and business logic (the controller). Segregating components along functional lines makes applications more maintainable and increases the probability that components may be reused.

WebOS adds an additional component to the MVC architecture called an assistant. Assistants coordinate the interaction of the model, view, and controller, and most of an application’s JavaScript code will be implemented within the assistant.

The boundaries between the model, view, and controller are not simply logical. Each type of component has its own directory within the application package. For example, models are stored within the “models” subdirectory, and views within the “views” subdirectory. Additionally, views are HTML files whereas models, controllers, and assistants are all JavaScript. Be aware that JavaScript can be included in any of these components, so take care to prevent script injection into any application context.

Stages and Scenes, Assistants and Views

Every WebOS application is composed of a series of stages and scenes. The stage is the platform on which the entire application executes. Each application must have at least one stage, but it may have many. Generally, only applications that operate in different perspectives will have multiple stages. For example, a Sports application could have two different perspectives: a full-screen perspective and a more minimal perspective that shows updated sports information in the dashboard at the bottom of the screen. A stage is used to implement each of these perspectives.

Scenes are particular screens within stages. For example, the Sports application would show one scene listing all of the football teams. Once the user selects a team, the scene would transition to a detail scene focused solely on the selected team.

Internally, every WebOS application maintains a scene stack. As the user navigates through the application, new scenes are pushed onto and popped off the stack. Users can navigate through the stack using forward and back gestures, a behavior very similar to that of a standard web browser. The most important security detail to know about an application’s scene stack is that scenes from different applications may exist within the same stack.

Working behind the scenes are the assistants, which implement the actual application logic and conduct the heavy lifting (such as making web requests) required to complete the application’s purpose. The assistant is the master of the scene stack and coordinates the controller to push and remove scenes.

Assistants are bound to scenes and the application via filenaming conventions and the sources.json file, which exists in the root of the application’s package. Every application must have at least one scene assistant and one stage assistant. An application assistant is not required, but larger apps that have multiple stages tend to have one. The stage and application assistants are accessible to all the scenes within an application stage and are generally used to coordinate and contain global variables.

Views are HTML pages defining the semantic markup of the application. Standard Cascading Style Sheets (CSS) can be used to change the look and feel of the view. Palm provides WebOS developers with a collection of common controls, known as widgets, to speed development and provide a consistent user experience. Developers specify which widgets to include in their views by inserting special “div” tags into the output HTML document. For example, the following tag includes a button widget:

<div id="MyButton" name="MyButton1" x-mojo-element="Button"></div>
  •  iPhone Application Development : Getting the User’s Attention - Using Alert Sounds and Vibrations
  •  iPhone Application Development : Getting the User’s Attention - Using Action Sheets
  •  jQuery 1.3 : Modifying table appearance (part 4) - Filtering
  •  jQuery 1.3 : Modifying table appearance (part 3) - Collapsing and expanding sections
  •  jQuery 1.3 : Modifying table appearance (part 2) - Tooltips
  •  jQuery 1.3 : Modifying table appearance (part 1) - Row highlighting
  •  Windows Phone 7 Development : Using Culture Settings with ToString to Display Dates, Times, and Text
  •  Mobile Application Security : SymbianOS Security - Persistent Data Storage
  •  Mobile Application Security : SymbianOS Security - Interprocess Communication
  •  Mobile Application Security : SymbianOS Security - Permissions and User Controls
  •  Windows Phone 7 Development : Building a Trial Application (part 3) - Verifying Trial and Full Mode & Adding Finishing Touches
  •  Windows Phone 7 Development : Building a Trial Application (part 2) - Connecting to a Web Service & Adding Page-to-Page Navigation
  •  Windows Phone 7 Development : Building a Trial Application (part 1) - Building the User Interface
  •  jQuery 1.3 : Table Manipulation - Sorting and paging (part 2) : Server-side pagination & JavaScript pagination
  •  jQuery 1.3 : Table Manipulation - Sorting and paging (part 1) : Server-side sorting & JavaScript sorting
  •  Windows Phone 7 Development : Understanding Trial and Full Modes (part 3) - Simulating Application Trial and Full Modes
  •  Windows Phone 7 Development : Understanding Trial and Full Modes (part 2) - Using the Marketplace APIs
  •  Windows Phone 7 Development : Understanding Trial and Full Modes (part 1) - Using the IsTrial Method
  •  Mobile Application Security : SymbianOS Security - Application Packaging
  •  Mobile Application Security : SymbianOS Security - Code Security
    Top 10
    The Hot Five – Q1 2013 (Part 2) - HTC 8X, Asus Padfone , Sony Xperia T
    The Hot Five - Q1 2013 (Part 1) : Apple iPhone 5, Nokia Lumia 920
    DDMF DirectionalEQ Effect Plugin
    Four Of The Best Stereo Systems (Part 4)
    Four Of The Best Stereo Systems (Part 3)
    Four Of The Best Stereo Systems (Part 2)
    Four Of The Best Stereo Systems (Part 1)
    Steinberg Cubase 7 – The Fantastic Success (Part 1)
    Canon EOS C500 and EOS-1DC: 4K Cameras Now!
    Tips And Tricks To Set You Apart From The Tech Crowd (Part 7)
    Most View
    Windows 7 : Keeping Your Family Safe While Using Your Computer (part 1)
    How Not To Build A PC (Part 3)
    Ipad : Using iTap VNC
    Troubleshooting Windows 7 Programs and Features
    Wireless Charging: Advancements Bring New Promise For Smartphone
    Compact Camera Shootout (Part 3) : Canon IXUS125 HS, Fujifilm FinePix F660 EXR, Nikon Coolpix S8200, Panasonic Lumix DMC-SZ1, Samsung WB150F
    10 Ways To Become An Overnight Wine Expert
    Roku 2 XS
    iPhone 3D Programming : Drawing an FPS Counter (part 2) - Rendering the FPS Text
    Jawbone Big Jambox
    Samsung HW-E551 Soundbar - Convincing Cinema Sound
    Windows Vista : Share Files and Printers (part 3) - Share a Printer, Use a Print Server Without Software
    Windows Server 2008 : Install the Hyper-V Role
    Windows 7 : Recovering After a Crash or Other Problem (part 1) - Recovering Using Restore Points
    The Philips Fidelio Docking Speaker
    System Center Configuration Manager 2007 : Architecture Design Planning - Software Update Planning
    Use Strokes Plus Use Strokes Plus To Create Complex Gestures
    Buying Guide: Studio Flash Power Packs
    Nokia 808 Pureview
    Buying Guide: External hard drive - Buffalo DriveStation Velocity 2TB, Freecom Mobile Drive Sq 500GB & Iomega Mac Companion Hard Drive 2TB