WebOS is based on Linux and uses
several open-source packages. These packages are freely available for
download on Palm’s website (http://opensource.palm.com). 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 (http://code.google.com/p/v8/), 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.
Model-View-Controller
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>
