Symbian +OS v9 Security Architecture

This documents contains a high level description of the platform security +model implemented in Symbian OS v9.x and beyond.

3 Security +Architectural Countermeasures

It is inherently difficult to work +out how to partition a holistic architecture such as that required to support +platform wide security. The approach we have taken here is to present a series +of different views on the architectural countermeasures from various perspectives +each of which highlight a particular functional element within the system. +The security architecture is a combination of these elements.

The +main concept of all the security countermeasures described below is to control +what a process can do rather than what a user can do. This approach is quite +different to well-known operating systems as Unix. The main reasons for which +we made this choice are:

The very nature of the +Symbian platform is to be mono-user.
The Symbian platform +provides services through independent server processes. They always run and +are not attach to a user session. As long as power is supplied, the Symbian +platform is always on even if no user is logged on.
The Symbian platform +is aimed to be used in devices used by a large public with no technology knowledge. +When installing software, the user may not have the skills to decide what +permissions to grant to an application. Furthermore, with always-connected +devices, the consequences of a wrong or malevolent decision may impact a domain +much larger than the device itself.

To avoid any confusion while reading this document, please pay attention +to the following definitions:

An executable is +a file containing Symbian executable code. This can be a library (DLL) or +a program (EXE).
A program is +an executable that once, loaded will trigger the creation of a process.
A library is +an executable that is linked to another executable or that processes can dynamically +load.

3.1 Trusted Computing +Platform

3.1.1 +Trusted Computing Base

A trusted computing base is a basic architectural +requirement for robust platform security. The trusted computing base would +consist of a number of architectural elements that cannot be subverted and +that guarantee the integrity of the device. It is important to keep this base +as small as possible and to apply the principle of least privilege to ensure +system servers and applications do not have to be given privileges they do +not need to function. On closed devices, the TCB consists of the Symbian platform +kernel and F32, on open devices the software installer (SWInstall) is also +required. All these processes are system-wide trusted and have therefore full +access to the device. This trusted core would run with a “Tcb” system capability +not available to other platform code.

There is one other important +element of the trusted computing base, namely the hardware. One important +recent paper [6] has outlined a hardware design that does not take operating +system security into account. In particular, with devices that hold trusted +computing base functionality in flash ROM, it is necessary to provide a secure +boot loader to ensure that it is not possible to subvert the trusted computing +base with a malicious ROM image. Providing such a secure boot loader is explicitly +excluded from the scope of this architecture, and it is a requirement on the +base port for specific hardware platforms to provide for this.

3.1.2 +Trusted Computing Environment

“There are always system components +<…> that must be able to read and write at all levels <…>. The practical +outcome is that an uncomfortably large part of the operating system (plus +utilities, plus windowing system, plus database) often ends up in the trusted +computing base” Ross Anderson

Beyond the core, other system components +are granted restricted orthogonal system capability and constitute the Trusted +Computing Environment, for instance, these include servers providing sockets, +telephony, certificate management, database access, and windowing services. +Each server just has the capabilities it requires, for instance the windowing +server is not granted phone stack access and the communications servers is +not granted direct access to keyboard events. These system capabilities are +only available to third party code that is appropriately signed. By limiting +the number and combination of system capabilities allocated to any single +component, a limit is placed on the potential damage that can be caused by +any vulnerability or misuse of privileges.

This is a very natural +evolution of the client/server system architecture that has been widely utilised +in the operating system since its very inception, and aligns well with the +strengths of that architecture.

3.2 +Process Capabilities

A capability is an access token that corresponds +to a permission to undertake a sensitive action or group of actions. The Symbian +platform security architecture purpose is to control access to sensitive system +resources. The most important resource that requires access control is the +kernel executive itself and a system capability is required by a client +to access certain functionality through the kernel API. All other resources +reside in user-side servers accessed via inter-process communication (IPC) +(eg. the telephony server). A limited number of basic capabilities are defined +to police specific client actions on the servers. For example, possession +of the “network services” capability allows a client to place phone calls +via the telephony server. It is the responsibility of the server to police +client access to the resources that it provides.

The key features +of the process capability model are:

It is primarily focused +around Symbian platform system servers and client-server IPC interactions +between processes.
Capabilities are associated +with processes not threads. Threads in the same process share the same address +space and memory access permissions. This means that any data being used by +one thread can be read and modified by all other threads in the same process. +In addition, threads in the same process can write to each other’s stacks +and thereby divert one another’s execution path.
When the code is not +running, capabilities are stored inside of executables. Capabilities stored +in executables are not modifiable, as they would be stored during installation +in a location that is only accessible by the Trusted Computing Base. See subsection +3.4 for the details on how this works.
Not all servers would +have to handle client capabilities.
The only cryptography +involved in this scheme is at the software installation stage where certificates +are checked off against the appropriate root certificates, if necessary, before +code is granted any requested capabilities. In some scenarios it is possible +for third party developers to dispense with the use of certificates altogether, +in which case users would be responsible for granting the requisite capabilities. +The subsection 3.5 goes into the details of this.

3.2.1 Mapping system +permissions – System Capabilities

System permissions are never +exposed to the user and are therefore mandatory. Without it, a process cannot +perform a protected operation. One of the main goals of this architecture +for the Symbian platform is to protect what is really vital for the integrity +of the System and to minimise the number of critical operations. For this +reason, some Symbian components have been designed to avoid the need to restrict +access to some operations without, of course, compromising their integrity.

Tcb Used +by the Trusted Computing Base only, it gives access to the location executables +are stored and therefore they can change their capabilities. Only the Symbian +platform kernel, the file server (including the loader), and the software +installer are granted this privilege.

CommDD Grants direct +access to all communication device drivers, including phone baseband software.

PowerMgmt Grants +the right to kill any process in the system, to switch the machine into standby +state, wake it up again or power it down completely.

MultimediaDD Grants +direct access to all multimedia device drivers

ReadDeviceData Grants +read access to device, network operator, and phone manufacturer confidential +settings or data.

WriteDeviceData Grants write access to +settings that control the behaviour of the device. Note this is NOT necessarily +symmetric with ReadDeviceData, and in practice is required significantly more +often than that capability.

Drm Grants access to rights-protected +content

TrustedUI Grants the right to create a trusted UI +session, and therefore to display dialogs in a secure UI environment.

ProtServ Grants +the right to a server to register within the protected name space – to limit +scope for malware to spoof sensitive system servers.

DiskAdmin Grants +access to disk administration operations that affect more than one file or +one directory (or overall filesystem integrity/behaviour, etc).

NetworkControl Grants +the right to modify or access network protocol controls, in a way that might +affect more than one client application or transport connection / session.

AllFiles Grants +read access to entire file system. Grants write access to other processes' +private directories.

SwEvent Grants the right to generate +software key & pen events and to capture any of them regardless of the +foreground status of the application

SurroundingsDD Grants +access to device drivers that provide input information about the surroundings +of the device.

3.2.2 +Mapping real-world permissions – User Capabilities

The process +of identified these capabilities was a lengthy and involved one. First we +attempted to identify those accesses that require policing and then tried +to map those requirements into something that is meaningful for a user. In +addition, more capabilities means greater complexity and complexity is widely +recognised as being the chief enemy of security. A solution based on capabilities +should therefore seek to minimise the overall number deployed. These map fairly +broadly onto the main threats which are unauthorised access to the outside +world and preserving the confidentiality/integrity of user data. We assert +that any permission requirement can be expressed in terms of some combination +of those. In a sense, these capabilities represent orthogonal groupings because +they police different kinds of access together. The capabilities identified +today are as follows:

NetworkServices Grants +access to remote services without any restriction on its physical location. +Typically, this location is unknown to the phone user. Also such services +may incur cost for the phone user. This typically implies routed protocols. +Voice calls, SMS, internet services are good examples of such network services. +They are supported by GSM, CDMA and all IP transport protocols including Bluetooth +profiles over IP.

LocalServices Grants access +to remote services in the close vicinity of the phone. The location of the +remote service is well-known to the phone user.In most cases, such services +will not incur cost for the phone user. This typically implies a non-routed +protocol. An application with this capability can normally send or receive +information through Serial port, USB, IR and point-to-point Bluetooth profiles. +Examples of services are IR beaming with the user's PC, Bluetooth gaming, +file transfer.

ReadUserData Grants read access to data belonging +to the phone user. This capability supports the confidentiality of user +data. Today, Contacts, messages and calendar data are always seen as user +confidential data. For other content types such as images or sounds, it may +depend on context, and ultimately be up to the application owning the data +to define.

WriteUserData Grants write access to user data. +This capability supports the management of the integrity of user data. +Note that this capability is not necessarily symmetric with ReadUserData. +For instance, one may wish to prevent rogue applications from deleting music +tracks but may not wish to restrict read access to them.

Location Grants +access to the live location of the device. This capability supports the management +of user’s privacy regarding the phone location. Location information protected +by this capability can include map co-ordinates and street address, but not +regional or national scale information.

UserEnvironment Grants +access to live confidential information about the user and his/her immediate +environment.This capability also protects the user's privacy. Examples are +audio, picture and video recording, biometrics (such as blood pressure) recording.

We +acknowledge that user-exposed capabilities are relatively coarse-grained but +the assertion is that expanding on these levels is undesirable at this time, +for reasons previously given. Only these capabilities may be exposed to users +during software installation of unsigned code as discussed in section 3.5.

Security +policies requiring Tcb and system capabilities are always mandatory. Their +strict control ensures the integrity of Symbian Trusted Computing Platform. +However the way servers check user-exposed capabilities or interpret them +may be fully flexible and even user-discretionary, for example allowing user +prompting if a sensitive action fails due to lack of capability.

3.2.3 +Assigning capabilities to a process

The association of a run-time +capability with a process requires a modification to Symbian executable loader +behaviour. The loader must transform the static capability settings associated +with individual executables into a run-time capability that the kernel can +use to police IPC and user/kernel interface. There are two fundamental rules +that govern the way the loader must work. They seem simple in their description +but have far-reaching security consequences as they bring to light the trust +relationship between DLLs and EXEs.

The capabilities +of a process never change. There is no way of adding capabilities to +a process, nor of removing capabilities from a process. All DLL code runs +at the capability level of the process that loads it.
A process cannot +load a DLL with less capability than itself. The need for this constraint +follows from the fact that all DLL code runs at the capability level of the +loading process and therefore must be at least as trusted at the loading process. +DLL capabilities only reflect the level of trust that the loading process +can place in them; they don’t actually authorise anything.

What this implies is that it is the EXE that ultimately holds the +responsibility for what happens within the process which is created from it. +The capabilities allocating to the EXE grant a level of authorisation to the +process to perform its roles and responsibilities. As part of its execution, +it may use shared library code. It must not be allowed to use library code +that is less trusted than it itself is. This is expressed, in terms of capabilities, +in rule 2. However, regardless of what library code it uses, the process will +never gain authorisation to perform actions beyond those originally entrusted +to it: this is rule 1. The consequence of this is, the more capable a process, +the more restrictions will be placed on the DLLs it may load; conversely an +process with no capability is free to use any shared library on the system, +at its own discretion.

3.2.4 +Capability Permission lifetime

There are two possible alternatives +for interpretation of the presence of a user-exposed capability at capability-aware +servers:

Blanket permission: Capability is granted as a one +off act. If the capability is not present when the process is created, the +request fails. All access requiring system capability will be policed this +way. For example, the file server will just fail any clients attempting to +access functionality in the event that they don't possess this capability. +The capability would persist as long as the application is installed or until +revoked. Revocation mechanisms would be introduced in several steps as they +may require extra public key infrastructure from licensees and network operators.

Single action permission: +Capability is checked upon each sensitive API call to the server. This means +that one each access to the sensitive API call, a security notifier is thrown +asking the user if they wish to grant that action. The permission only lasts +for the duration of the corresponding sensitive action.

The user perception of the kind of permission must not be confused +with when a server will check a required capability. For instance, an application +may be granted NetworkServices as blanket permission but the telephony server +will check NetworkServices capability at each relevant call made by this application. +But as the user will not be asked to make a decision (to grant or not to grant +NetworkServices for this call), this security check is transparent to the +user.

The advantages of this design are:

To maintain the time +of check as close as the time of use as possible (to avoid any TOCTOU flaws)
To avoid the server +storing capability-related information for a process.

The great majority of Symbian platform servers behave in blanket +permission mode. The reason behind this design decision is the majority of +Symbian platform servers provide low level services where the intent and the +context of an application’s requests are to some degree unknown. Therefore +it would be difficult to ask the user a question with enough understandable +information to let her make a well-informed decision.

3.3 +Process Identification

Symbian Platform Security model is essentially +based on capability to reduce the need of identifying applications. It allows +servers to control access to their APIs without knowing their requesters and +therefore avoid the need of maintaining an access control list. However in +some circumstances, it is necessary to identify an application uniquely (see +data caging below) and even its source i.e. the vendor. To satisfy these needs +the two following concepts have been introduced.

3.3.1 +Secure Identifier (SID)

Each executable contains a secure identifier. +It is guaranteed to be locally unique (i.e. in the phone where it is installed) +however there is a subset of restricted SIDs where a global uniqueness can +be guaranteed. The restricted SID space will be explicitly reserved for signed +applications and each SID from this range will be cross-referenced to Vendor +ID to ensure that each individual SID is authorised to use that particular +Vendor ID.

The SID can be explicitly specified for a particular executable +or the UID can be used instead. However those two identifiers are always different +entities in the kernel implementation. It is proposed that SIDs will come +from a specified range of UID values, and that Symbian will provide a new +mechanism to allocate suitable values.

3.3.2 +Vendor Identifier (VID)

Executables can contain a vendor identifier +that allows unique identification of the source of the executable. It is expected +that the VID will be used for genuine cases like restricting a tentative server +API from a specific vendor to its applications. While there is a potential +danger that this VID would be used for anti-competitive purposes only, we +recognise that there are enough real cases where it would be useful, and that +it would therefore be better for the platform to deliver a standard framework +rather than risking developers to implement their own solutions. To prevent +stealth of vendors’ identity, the software installer will reject the installation +of executables with VIDs delivered in an unsigned installation package.

3.3.3 Kernel’s & Loader’s +role

As for capabilities, the kernel is responsible for holding +both the application and vendor identity for each process. When a process +is created, these properties are read from the associated program, held in +kernel’s memory and are guaranteed not to change during its lifetime. However, +unlike capabilities, there is no rules model to be followed regarding shared +library. Each process is free to load shared libraries with any value of Secure +ID and Vendor ID, regardless of the identifier values in the EXE from which +the process was created. For this reason, capabilities are the core of the +security architecture; process identifiers are intended for use in tandem +with, rather than as a replacement for, capabilities.

3.4 +Data Caging

3.4.1 +Caging processes

3.4.1.1 +Location-based concept

Data caging involves separating code from +data in the file system such that a simple trusted path is created on the +platform.

A new /sys directory +hierarchy is created, with all executable code residing in the /sys/bin subdirectory. +The central idea is that by “caging” non-TCB processes into their own part +of the file system, the /sys directory becomes hidden to +them. The kernel and file server would check that a client process had Tcb +or AllFiles capability before allowing any access to the /sys sub-tree. +In addition, the loader would disallow any attempt to execute code residing +elsewhere than /sys/bin.
A new /resource directory +is created, which is public, but read-only for non-TCB processes. The purpose +is to allow read-only files to be publicly shared without compromising their +integrity.
All executable applications +have got access to their own restricted area of the file system, which consists +of the sub-tree below the secure directory /private/<app_SID>, +where SID is a Secure Identifier used to distinguish between the /private sub-directories. +Applications can, for example, use their sub-tree to hold various private +data files.

Directories not under /sys or /private or /resource are +public and can be read from and written to by any program. This allows the +use of standard file system hierarchies that may be available on removable +media. In essence, data caging involves caging processes by default into their +own small part of the file system. This means that there is default protection +of per-application and per-server data from other processes. Without data +caging, it would become necessary to introduce access control lists into the +file system to prevent rogue apps bypassing the capability model and simply +reading databases directly from files. In addition, the scheme affords further +protection against the threat of malicious replacement of executables in /sys/bin. +In that sense, data caging is a simpler and more robust.

Data +caging – capabilities for data caging + + + + +/resource +/sys +/private/ownSID +/private/anyOther +/anyOther + + +Capabilities +Read +Write +Read +Write +Read +Write +Read +Write +Read +Write + + +None +Yes +No +No +No +Yes +Yes +No +No +Yes +Yes + + +AllFiles +Yes +No +Yes +No +Yes +Yes +Yes +Yes +Yes +Yes + + +TCB +Yes +Yes +No +Yes +Yes +Yes +No +No +Yes +Yes + + +AllFiles+TCB +Yes +Yes +Yes +Yes +Yes +Yes +Yes +Yes +Yes +Yes + + + +

Note that data caging is not a huge conceptual leap from the previous +version of the Symbian platform. Historically only the kernel had an unrestricted +view of the real machine running the Symbian platform. Each Symbian platform +process had its own view of the processor’s address space that was independent +of all other processes. This was arranged and policed by the kernel and MMU +hardware.

For simplicity it has been decided that the filing system +is not aware of the meaning of “private user data”. A file cannot be flagged +as so. It is the responsibility of each process dealing with user data to +manage ReadUserData and WriteUserData capabilities. Furthermore in case of +databases, the file itself can contain user private and public data and therefore +trying to assign a level of privacy to a file is not obvious.

3.4.1.2 +Import directory concept

Many Symbian frameworks support the concept +of plug-ins: they allow new code to contribute to existing native frameworks. +Application recognisers are a good example of such plug-ins. In order to be +identified as valid plug-ins they often provide a resource file that must +be read by process users. When the process user is unique, it makes to place +this resource file under its private directory. However, following the rules +previously stated that should be impossible. To conciliate both points of +view without compromising security, the rules described below have been defined:

If an import directory +exists immediately under the private path of a process, Software Install is +allowed to put files in it from any installation package file.
If there is no import +directory immediately under the private path of a process, Software Install +rejects the installation of any file not extracted from this process installation +package.
A process having an +import directory under its private directory accepts that these files might +be malevolent and are not part of its own installation package. The correct +level of trust that can be given to those files is process dependent.
The creation of an import +directory is under the responsibility of the process developer.

3.4.1.3 Sharing +files and data

To help share data across processes, current operating +system features have been enhanced and new ones have been implemented. File +handles and memory chunks can be shared between processes. These methods can +be used to get temporary access to a specific file or memory area that is +otherwise private. The recipient of the shared handle will only be able to +use the file in the mode chosen by the file opener. Also a highly efficient +public & subscribe service has been implemented to enable secure asynchronous, +fast distribution of data.

3.4.2 +Removable media

Executables installed by the device on removable +media will be hashed. This hash as well as the executable’s capability set +are securely stored on the device. At load time, the loader verifies the hash +before accepting to perform the operation. If the verification fails, the +executable will not be loaded. If the executable is unknown (no associated +hash), the executable is loaded without any capability and its SID and VID +are assigned to unknown.

Although it is out of the scope of Symbian +Secure Architecture, some hardware features can increase the level of security +of removable media when off the device. For instance, a password-protected +card will prevent a desktop rogue application to get or modify information +stored on card without the consent of the user.

As a result Symbian +Secure Architecture does not guarantee integrity and confidentiality of files +stored under ‘/private’ and /resource when off the device. Each program should +decide what integrity checks are appropriate and what level of confidentiality +they may provide.

3.5 +SWInstall – Enhancing perimeter security

The software installer +has been changed substantially to support the process capability model and +data caging. In addition, SWInstall now conforms to an appropriate Public +Key Infrastructure. As different manufacturers and network operators may have +different security policy, SWInstall has been redesigned to support a number +of different security policies.

3.5.1 +Software validation

A SIS file may contain zero or more signatures, +and the set of capabilities that it needs. The software installer verifies +each signature and constructs a certificate chain back to a trusted root. +A configuration setting controls whether the software installer will check +the revocation status of the certificate using OCSP. In addition, it is possible +to mark SW Install root certificates as 'mandatory' certificates. If a mandatory +certificate exists, then all installable packages must be signed with it, +or installation fails. This enables the holder of the associated key to hold +a 'veto' over what software may be installed.

3.5.2 +Capability calculation

Each SW Install root certificate is associated +with a set of the capabilities that it is allowed to grant, called ‘meta-capabilities’. +The installer calculates the largest set of capabilities that the installable +may be granted as the union of the meta-capabilities associated with all successfully +validated signatures.

A configuration setting determines which additional +capabilities the user is allowed to grant if the set of permitted capabilities +is less than the capabilities requested in the SIS file.The installer will +never install software with less than its requested set of capabilities: it +is either installed with all of them, or it is not installed at all.

3.5.3 Configuring the installer

At +product build time, all configuration settings may be freely determined. In +the field configuration settings may be altered to a more limited degree. +For instance, the device manufacturer may decide or not to let the user the +freedom to grant some capabilities at install time. It should be noted that +a key feature of the scheme is that install packages don’t necessarily have +to be signed in order to be installed and granted capabilities. This is something +that OEMs may not want to permit but at least we provide the option should +the system integrator (manufacturer or potentially network operator) want +to permit such an installation option. This might be an attractive option +for developers wishing to avoid the hassle of code signing.

3.5.4 +Installation in place or dual phase installation

Symbian installation +package files include a SISSignedController element which contains +the information needed to install the files, together with a separate hash +for each of the installable files. This is signed, and this signature is verified +at installation time against one of the root certificates always present on +the device. The integrity of the SISSignedController, and, by extension, of +the hashes of the files in the archive, is therefore guaranteed by its signature, +and Software Install keeps the SISSignedController for each installation on +the device. For secure installation of executables provided on removable media, +where the executables don’t need to be installed, the SISSignedController +part of the installation can be provided on the card by itself, enabling Software +Install’s standard authentication and other security measure to proceed as +normal.

3.6 Secure +backup and restore

Symbian is primarily concerned with the integrity +of the backup, not with the confidentiality of any data that might be stored +within it. Confidentiality of data, both during the transfer to the host computer +and also on the host once backed-up, is out of the scope of the Symbian Security +Architecture described in this document.

The security architecture +needs to consider three different types of files in the context of backup +and restore.

Public files are +those stored in public directories. They can’t pose any threats to the integrity +of the platform, and no special security measures need to be taken from the +point of view of Platform Security when they are backed up and restored. They +can be backed up using the traditional method of backup, known as passive +backup. This requires no extra code on the part of the Symbian platform +or on the part of any applications that might create or own public files.
Private files are +those belonging to particular applications which store them in the /private/ file +hierarchy. The Symbian platform itself can’t know what these files are or +what their sensitivity level might be, so the backup and restore policy regarding +them is left under the control of each individual owning application. Applications +can either specify in their resource files which private directories or files +that they want copied via passive backup. Alternatively, they may make use +of the active backup facilities provided by the secure platform. This +enables those applications that wish to take advantage of them to backup and +restore their private files securely, and are discussed in section 3.6.1 below.
Executable binaries are +those stored in the /sys/bin/ directory. Were these to be +restored from a backup in the same way as a simple restore of public files, +this would represent a significant threat to the security of the device as +Software Install would be fully bypassed and there would be no way of guaranteeing +that executables had not been interfered with while they were stored off the +secure device. The solution to this problem, discussed further in section +3.6.2 below, is to use Software Install’s own mechanisms to back up executables +and ensure their integrity on restore.

3.6.1 Active Backup +and Restore for Private Data

A process that owns private data +and wants to use active backup and restore has to be able to provide all of +the data that they wish to backup, and has to be able to receive the data +for restore. In order to minimise the code and maintenance overheads, a standard +set of reference functions will be provided in the OS that externalise from +a directory tree and internalise to a directory tree. A process using active +backup should use these functions to externalise its data on a stream for +backup and signal when it has finished. For restoration it will internalise +from a similar stream. The functions provided should be adequate for most +data owning processes. Any processes which want more selective access will +have to implement their own functions.

3.6.2 +Backup and Restore of Executables via Software Install

As described +in 3.5.4 each +installation package file includes a SISSignedController with all the +information needed to install the files in the SIS archive and the integrity +of the SISSignedController is guaranteed by its signature. Since the only +way to install something in \sys\bin is via Software Install, +the stored SISSignedController elements can therefore be used during a backup +operation to recreate versions of the SIS files originally used to install +every executables present in \sys\bin. During the corresponding +restore operation, the SISSignedController can once again be used to verify +the integrity of the executable being restored and the validity of its digital +signature against one of the root certificates always present on the device.