Symbian
is a single-user operating system. This makes sense considering the use
case of a mobile phone. A small embedded device that a single user
carries with them on their person. Because there is only one user,
permissions must be enforced elsewhere. There is no concept of a “root”
user or an unprivileged user. Rather, each process has an immutable set
of capabilities indicating what actions the process is allowed to
perform.
Capabilities Overview
Twenty capabilities are
defined within the Symbian platform. These are maintained within a
64-bit-wide field in the executable image header, thus allowing for
future expansion. These capabilities can be divided into four
categories: User, System, Restricted, and Manufacturer.
User capabilities
are directly meaningful to the user of the mobile phone. A mobile phone
user is expected to be able to make reasonable decisions regarding these
capabilities. Users can grant untrusted applications (unsigned,
self-signed, or not chained to a trust root) the ability to make use of
these capabilities. These are listed in Table 1.
Table 1. User Capabilities
| Capability | Permission Granted |
|---|
| Location | Access to physical location data. (GPS, cell triangulation, etc.) |
| LocalServices | Access to local services. Generally do not incur cost. (IrDA, Bluetooth, serial, etc.) |
| NetworkServices | Access to network services. Potentially incur cost. (All IP protocols, telephony services, SMS, MMS, etc.) |
| UserEnvironment | Access to devices that measure the local environment. (Microphone, camera, biometrics, etc.) |
| ReadUserData | Read user private data. (Contacts, messages, calendar, etc.) |
| WriteUserData | Write user private data. (Contacts, messages, calendar, etc.) |
System capabilities may be
of use to a wide variety of potential distributed applications.
However, they are not directly meaningful to end users. What is the
difference between SurroundingsDD and Location or UserEnvironment? As
such, these capabilities cannot be granted by a user to untrusted
applications. An installer must be signed through the Symbian Signed
program. Any of the available signing options will suffice: Open Signed, Express Signed, or Certified Signed. Table 2 provides a listing of the System capabilities.
Table 2. System Capabilities
| Capability | Permission Granted |
|---|
| ReadDeviceData | Read access to confidential device settings. (List of installed applications, lock PIN code, etc.) |
| WriteDeviceData | Write access to confidential device settings. (Time zone, lock PIN code, etc.) |
| PowerMgmt | Kill arbitrary processes, power off peripherals, or enter standby. |
| ProtServ | Register an IPC server whose name contains a “!” character. Limits the risk of impersonation by less trusted processes. |
| SurroundingsDD | Low-level access to location-awareness devices (GPS, biometrics, etc.) |
| SwEvent | Simulate user interaction events such as keypresses. |
| TrustedUI | Create a trusted UI session. Requires the SwEvent permission for interaction. (Perform silent installation of packages.) |
The Restricted capabilities found in Table 3
may still be of use to a wide variety of potential applications. Due to
the potential disruptive impact to the operating environment were they
to be abused, applications requiring these capabilities must undergo
more scrutiny. As such, an installer cannot be Express Signed. Open
Signed Offline is allowed because it is intended only for development
purposes.
Table 3. Restricted Capabilities
| Capability | Permission Granted |
|---|
| CommDD | Low-level access to communications device drivers. (Wi-Fi, Bluetooth, serial, etc.) |
| MultimediaDD | Low-level access to multimedia device drivers. (Camera, speakers, video, etc.) |
| DiskAdmin | Perform low-level disk administration tasks. (File system mount/unmount.) |
| NetworkControl | Modify network connection settings. |
Manufacturer capabilities
provide the ultimate degree of access to the mobile phone. For example,
with the TCB capability a process could modify what capabilities another
process is created with by adjusting them within the executable image.
Very few applications require such privileges. Those that do (for
example, whole disk encryption
or data backup) must request permission from individual device
manufacturers in addition to the scrutiny placed on applications that
request Restricted capabilities. The three Manufacturer capabilities are
listed in Table 4.
Table 4. Manufacturer Capabilities
| Capability | Permission Granted |
|---|
| AllFiles | Read access to the entire file system. Write access to \private subdirectories. |
| DRM | Access to DRM protected content. |
| TCB | Read access to \sys. Write access to \sys and \resource. |
Executable Image Capabilities
The capabilities for an
executable are stored within the image file header. This defines the
capabilities that a successfully loaded process will possess. It is the
responsibility of the software install process to validate that the
capabilities an install package’s executables possess do not exceed
those allowed based on the assigned trust level.
The capabilities for a
dynamic library are also defined within the file header. However, they
do not have a direct impact on the capabilities of the resultant
process. They indicate what capabilities the library is allowed to
execute with, not necessarily those that it will execute with. In order
to be successfully loaded into a live process, the dynamic link library
(DLL) must have a set of capabilities comprising a superset of the
capabilities required by the executable image. As a result, most
general-use shared libraries are defined with an almost complete set of
capabilities—all except for manufacturer capabilities.
Process Capabilities
Capabilities are an
immutable property of running processes on the Symbian platform—neither
able to increase nor decrease privileges. When a process is created, the
loader first reads the set of capabilities requested by the executable.
It then validates that this is a subset of the capabilities each linked
DLL is allowed to execute with, as can be seen in Figure 1.
Otherwise, the process will fail to start with the message “Unable to
execute file for security reasons.” This is performed for all
dynamically linked libraries throughout the dependency tree.
Capabilities Between Processes
Processes
are the basic unit of trust on the Symbian platform. Threads executing
within the same process will all have the same capabilities. As such,
capabilities have no meaning within a single process, only across
processes. Any API call that requires a particular capability in fact
communicates with another process through the client/server mechanism
mediated by the operating system kernel.
The capabilities, Secure
ID, and Vendor ID of a client are provided to the server with each
message to allow for appropriate security decision making. A simple
server may require that a client have a certain capability to establish a
session, one of intermediate complexity may require different
capabilities for each function, and a complex server could use dynamic
criteria to enforce an appropriate policy.
This provides a layered
approach to defining and creating APIs, and explains why a process does
not need the CommDD capability when accessing network functionality. For
example, a client makes an API call to open a network socket. The ESOCK
component validates that the client has the NetworkServices capability
and calls the requisite device access functions on behalf of the client.
The kernel validates that ESOCK has the CommDD capability and performs
the appropriate action. Put another way, capabilities protect APIs and
not resources.
When implementing a
custom server component, the onus falls on the programmer to perform
appropriate validation of connecting clients. This can include verifying
the Vendor ID, Secure ID, and the set of capabilities. It is critical
that custom components do not expose an unprivileged API that acts as a
simple proxy for other privileged APIs.
