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.

Contents

1 Introduction
2 Symbian Platform Security Background
- 2.1 Symbian Security Policy Requirements
  - 2.1.1 Prevention
  - 2.1.2 Detection
  - 2.1.3 Reaction
- 2.2 The Security Architecture
3 Security Architectural Countermeasures
- 3.1 Trusted Computing Platform
  - 3.1.1 Trusted Computing Base
  - 3.1.2 Trusted Computing Environment
- 3.2 Process Capabilities
  - 3.2.1 Mapping system permissions – System Capabilities
  - 3.2.2 Mapping real-world permissions – User Capabilities
  - 3.2.3 Assigning capabilities to a process
  - 3.2.4 Capability Permission lifetime
- 3.3 Process Identification
  - 3.3.1 Secure Identifier (SID)
  - 3.3.2 Vendor Identifier (VID)
  - 3.3.3 Kernel’s & Loader’s role
- 3.4 Data Caging
  - 3.4.1 Caging processes
  - 3.4.2 Removable media
- 3.5 SWInstall – Enhancing perimeter security
  - 3.5.1 Software validation
  - 3.5.2 Capability calculation
  - 3.5.3 Configuring the installer
  - 3.5.4 Installation in place or dual phase installation
- 3.6 Secure backup and restore
  - 3.6.1 Active Backup and Restore for Private Data
  - 3.6.2 Backup and Restore of Executables via Software Install
4 Additional information
- 4.1 References
- 4.2 Glossary

1 Introduction

A -platform security model was introduced in Symbian OS v9. Developers can read -this paper to get a high level view of the model and what it means for how -they implement programs.

Some brief background information about security -and mobile phones is provided in section 2. The document does not describe -what infrastructure is needed to support the security model in the operating -system, such as application signing programs, security incident processes, -etc.

2 Symbian Platform -Security Background

Symbian platform security covers the philosophy, -architecture and implementation of the platform defence mechanisms against -malicious or badly implemented code. The scope of platform security requires -a holistic perspective of some complex system services and their interactions. -This paper focuses on the architectural elements required to support the platform -defence mechanisms. Specifically, we examine a number of architectural countermeasures -that collectively constitute the Symbian Platform Security Architecture. -We also look at the substantial number of issues that the adoption of such -platform security architecture poses.

2.1 -Symbian Security Policy Requirements

A security policy allows -you to determine effective countermeasures to threats in three ways: protection, -detection and reaction. These three aspects need to be enforced by different -mechanisms that are outlined in the following subsections.

2.1.1 -Prevention

There is a need to prevent badly written applications -from doing things they are not intended to do on the platform. This involves -first of all determining whether the application is sufficiently trustworthy -to be installed and then subsequently protecting the platform from errant -behaviour once it is installed. In terms of determining trust, third party -applications are categorised according to the degree of trust associated with -their authors. The binding between trust and authorship is encapsulated within -digital certificates issued by a Certificate Authority (CA). The CA performs -a role within a PKI which is the organisational infrastructure used to establish -and mediate the trust relationships. Individual third party applications are -furthermore granted differing degrees of capability at install time within -the context of the platform environment on the basis of the perceived degree -of trust bestowed upon them by the PKI.

As said in [4], mandatory -security mechanisms may be used both to limit trusted applications to the -minimal set of privileges required for their function and to confine the damage -caused by any misuse of their privileges. For this reason it is important -to understand that the security architecture must be also applied to Symbian -and licensees code even on a closed environment where new code cannot be installed. -As for the MMU (Memory Management Unit) it will bring us several benefits -like decreasing the impact of a flaw, enforcing good design and reducing dependencies -between components.

2.1.2 -Detection

The detection of errant application behaviour on the -platform includes ensuring that incidents are logged and reported promptly. -This means continuous monitoring of relevant incident tracking sources and -first level categorisation of security breaches as being minor, significant -or major. It may also include support of intrusion detection systems on the -platform such as virus scanners. Detection also covers tracking the security -flaws in standards we implement as well as security flaws in the platform -security architecture. Finally it involves the detection of compromises in -the public key infrastructure supporting application signing programs.

2.1.3 Reaction

There -is a need to respond to incidents promptly and effectively. The consequence -of having no coherent response to major incidents may be a catastrophic loss -of confidence in the security of the Symbian platform among our customers -and users. Even if the full response mechanism is out of the scope of the -Symbian platform, the security architecture should provide support to implement -part of it as capability revocation and upgrade mechanisms.

2.2 -The Security Architecture

The main security threat Symbian addresses -with this platform security architecture is to prevent viral distribution -of malicious applications; for this reason hardware attacks are not specifically -addressed.

The architecture focuses in delivering prevention mechanisms. -Detections and reactions rely heavily on services provided by an infrastructure -external to the phone and its operating system and are not addressed in this -document. The basic outline of the security architecture is analogue to a -medieval castle defences. In a similar fashion it employs simple and staggered -layers of security above and beyond the software installer perimeter. The -key threats that the model is trying to address are those that are linked -with unauthorised access to user data and to system services in particular -the phone stack. The phone stack is especially important in the context of -a phone because it will be controlling a permanent data connection to the -Internet. There are two key design drivers lying behind the model:

Firewall protection of -key system servers through the use of capability-based access control. -The capability model is deliberately limited to a small number of capabilities.
Data caging which -creates a protected part of the file system which rogue apps are not able -to access.

There is a certain minimum amount of architectural work that had -to be done to put the security architecture in place. However, there was also -a requirement to minimise the impact of any scheme to the architecture of -the Symbian platform. Adding platform security with minimal impact was hard -to do but this desire had influenced a lot of the architectural ideas.

On -the plus side, the security architecture has some distinct advantages over -other approaches. It offers us the chance to get a competitive advantage by -putting in place the right security architecture for a phone platform. This -in turn would mean that our licensees would see the Symbian platform as a -more attractive option than the competition partly because the premiums they -would have to pay for device security insurance would be lower. In addition, -they will have increased trust that deployment of the Symbian platform in -their products will not ruin their reputation and brand.

All these -points should be borne in mind as we move on to detail the architectural aspects -of the model in the next section.

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.

4 Additional -information

4.1 -References

[1] High Level Requirements for Release 7.0 of the -Symbian Platform v0.04, Mark Wilce, Symbian, March 2001.

[2] “Creating -a Secure WinCE 3.0 Device”, Maricia Alforque, Microsoft Corp., © October 2000, http://msdn.microsoft.com/library/techart/winsecurity.htm

[3] Mobile Station Application Execution Environment (MExE): Functional -Description, Stage 2, 3GPP TS 23.057 v4.0.0, ftp://ftp.3gpp.org/Specs/2000-12/Rel-4/23_series/23057-400.zip

[4] -The -Inevitability of Failure: The Flawed Assumption of Security in Modern -Computing Environments, Loscocco et al, National Security Agency, October -1998, http://www.cs.utah.edu/flux/fluke/html/inevitability.htm

[5] http://www.theregister.co.uk/content/4/17821.html

[6] -Security Analysis of the Palm Operating System and its Weaknesses Against -Malicious Code Threats, Kingpin and Mudge, @Stake, April 2001 formerly at http://www.atstake.com/research/reports/security_analysis_palm_os.pdf but -now at www.quands.info/pdf/security_analysis_palm_os.pdf.

4.2 Glossary

- - - -Term -Meaning - - - - -

API

Application Programming Interface

- - -

Certificate Authority

- - -

DLL

Dynamic Link Library

- - -

executable

A file containing native code: libraries (DLL) and programs (EXE)

- - -

F32

The Symbian Platform File Server

- - -

IPC

Inter Process Communication

- - -

OEM

Original Equipment Manufacturer

- - -

PKI

Public Key Infrastructure

- - -

SWInstall

Software Install – provides service of native application installation.

- - -

User Interface

- - -

UID

Unique Identifier. In the Symbian platform this is a 32-bit word -which is used to uniquely identify an object or its type.

- - - -

+ + + + + +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.

Contents

1 Introduction
2 Symbian Platform Security Background
- 2.1 Symbian Security Policy Requirements
  - 2.1.1 Prevention
  - 2.1.2 Detection
  - 2.1.3 Reaction
- 2.2 The Security Architecture
3 Security Architectural Countermeasures
- 3.1 Trusted Computing Platform
  - 3.1.1 Trusted Computing Base
  - 3.1.2 Trusted Computing Environment
- 3.2 Process Capabilities
  - 3.2.1 Mapping system permissions – System Capabilities
  - 3.2.2 Mapping real-world permissions – User Capabilities
  - 3.2.3 Assigning capabilities to a process
  - 3.2.4 Capability Permission lifetime
- 3.3 Process Identification
  - 3.3.1 Secure Identifier (SID)
  - 3.3.2 Vendor Identifier (VID)
  - 3.3.3 Kernel’s & Loader’s role
- 3.4 Data Caging
  - 3.4.1 Caging processes
  - 3.4.2 Removable media
- 3.5 SWInstall – Enhancing perimeter security
  - 3.5.1 Software validation
  - 3.5.2 Capability calculation
  - 3.5.3 Configuring the installer
  - 3.5.4 Installation in place or dual phase installation
- 3.6 Secure backup and restore
  - 3.6.1 Active Backup and Restore for Private Data
  - 3.6.2 Backup and Restore of Executables via Software Install
4 Additional information
- 4.1 References
- 4.2 Glossary

1 Introduction

A +platform security model was introduced in Symbian OS v9. Developers can read +this paper to get a high level view of the model and what it means for how +they implement programs.

Some brief background information about security +and mobile phones is provided in section 2. The document does not describe +what infrastructure is needed to support the security model in the operating +system, such as application signing programs, security incident processes, +etc.

2 Symbian Platform +Security Background

Symbian platform security covers the philosophy, +architecture and implementation of the platform defence mechanisms against +malicious or badly implemented code. The scope of platform security requires +a holistic perspective of some complex system services and their interactions. +This paper focuses on the architectural elements required to support the platform +defence mechanisms. Specifically, we examine a number of architectural countermeasures +that collectively constitute the Symbian Platform Security Architecture. +We also look at the substantial number of issues that the adoption of such +platform security architecture poses.

2.1 +Symbian Security Policy Requirements

A security policy allows +you to determine effective countermeasures to threats in three ways: protection, +detection and reaction. These three aspects need to be enforced by different +mechanisms that are outlined in the following subsections.

2.1.1 +Prevention

There is a need to prevent badly written applications +from doing things they are not intended to do on the platform. This involves +first of all determining whether the application is sufficiently trustworthy +to be installed and then subsequently protecting the platform from errant +behaviour once it is installed. In terms of determining trust, third party +applications are categorised according to the degree of trust associated with +their authors. The binding between trust and authorship is encapsulated within +digital certificates issued by a Certificate Authority (CA). The CA performs +a role within a PKI which is the organisational infrastructure used to establish +and mediate the trust relationships. Individual third party applications are +furthermore granted differing degrees of capability at install time within +the context of the platform environment on the basis of the perceived degree +of trust bestowed upon them by the PKI.

As said in [4], mandatory +security mechanisms may be used both to limit trusted applications to the +minimal set of privileges required for their function and to confine the damage +caused by any misuse of their privileges. For this reason it is important +to understand that the security architecture must be also applied to Symbian +and licensees code even on a closed environment where new code cannot be installed. +As for the MMU (Memory Management Unit) it will bring us several benefits +like decreasing the impact of a flaw, enforcing good design and reducing dependencies +between components.

2.1.2 +Detection

The detection of errant application behaviour on the +platform includes ensuring that incidents are logged and reported promptly. +This means continuous monitoring of relevant incident tracking sources and +first level categorisation of security breaches as being minor, significant +or major. It may also include support of intrusion detection systems on the +platform such as virus scanners. Detection also covers tracking the security +flaws in standards we implement as well as security flaws in the platform +security architecture. Finally it involves the detection of compromises in +the public key infrastructure supporting application signing programs.

2.1.3 Reaction

There +is a need to respond to incidents promptly and effectively. The consequence +of having no coherent response to major incidents may be a catastrophic loss +of confidence in the security of the Symbian platform among our customers +and users. Even if the full response mechanism is out of the scope of the +Symbian platform, the security architecture should provide support to implement +part of it as capability revocation and upgrade mechanisms.

2.2 +The Security Architecture

The main security threat Symbian addresses +with this platform security architecture is to prevent viral distribution +of malicious applications; for this reason hardware attacks are not specifically +addressed.

The architecture focuses in delivering prevention mechanisms. +Detections and reactions rely heavily on services provided by an infrastructure +external to the phone and its operating system and are not addressed in this +document. The basic outline of the security architecture is analogue to a +medieval castle defences. In a similar fashion it employs simple and staggered +layers of security above and beyond the software installer perimeter. The +key threats that the model is trying to address are those that are linked +with unauthorised access to user data and to system services in particular +the phone stack. The phone stack is especially important in the context of +a phone because it will be controlling a permanent data connection to the +Internet. There are two key design drivers lying behind the model:

Firewall protection of +key system servers through the use of capability-based access control. +The capability model is deliberately limited to a small number of capabilities.
Data caging which +creates a protected part of the file system which rogue apps are not able +to access.

There is a certain minimum amount of architectural work that had +to be done to put the security architecture in place. However, there was also +a requirement to minimise the impact of any scheme to the architecture of +the Symbian platform. Adding platform security with minimal impact was hard +to do but this desire had influenced a lot of the architectural ideas.

On +the plus side, the security architecture has some distinct advantages over +other approaches. It offers us the chance to get a competitive advantage by +putting in place the right security architecture for a phone platform. This +in turn would mean that our licensees would see the Symbian platform as a +more attractive option than the competition partly because the premiums they +would have to pay for device security insurance would be lower. In addition, +they will have increased trust that deployment of the Symbian platform in +their products will not ruin their reputation and brand.

All these +points should be borne in mind as we move on to detail the architectural aspects +of the model in the next section.

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.

4 Additional +information

4.1 +References

[1] High Level Requirements for Release 7.0 of the +Symbian Platform v0.04, Mark Wilce, Symbian, March 2001.

[2] “Creating +a Secure WinCE 3.0 Device”, Maricia Alforque, Microsoft Corp., © October 2000, http://msdn.microsoft.com/library/techart/winsecurity.htm

[3] Mobile Station Application Execution Environment (MExE): Functional +Description, Stage 2, 3GPP TS 23.057 v4.0.0, ftp://ftp.3gpp.org/Specs/2000-12/Rel-4/23_series/23057-400.zip

[4] +The -Inevitability of Failure: The Flawed Assumption of Security in Modern +Computing Environments, Loscocco et al, National Security Agency, October +1998, http://www.cs.utah.edu/flux/fluke/html/inevitability.htm

[5] http://www.theregister.co.uk/content/4/17821.html

[6] +Security Analysis of the Palm Operating System and its Weaknesses Against +Malicious Code Threats, Kingpin and Mudge, @Stake, April 2001 formerly at http://www.atstake.com/research/reports/security_analysis_palm_os.pdf but +now at www.quands.info/pdf/security_analysis_palm_os.pdf.

4.2 Glossary

+ + + +Term +Meaning + + + + +

API

Application Programming Interface

+ + +

Certificate Authority

+ + +

DLL

Dynamic Link Library

+ + +

executable

A file containing native code: libraries (DLL) and programs (EXE)

+ + +

F32

The Symbian Platform File Server

+ + +

IPC

Inter Process Communication

+ + +

OEM

Original Equipment Manufacturer

+ + +

PKI

Public Key Infrastructure

+ + +

SWInstall

Software Install – provides service of native application installation.

+ + +

User Interface

+ + +

UID

Unique Identifier. In the Symbian platform this is a 32-bit word +which is used to uniquely identify an object or its type.

+ + + +

\ No newline at end of file