<?xml version="1.0" encoding="utf-8"?>

<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->

<!-- This component and the accompanying materials are made available under the terms of the License 

"Eclipse Public License v1.0" which accompanies this distribution, 

and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->

<!-- Initial Contributors:

    Nokia Corporation - initial contribution.

Contributors: 

-->

<!DOCTYPE concept

  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">

<concept id="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B" xml:lang="en"><title>Symbian

OS v9 Security Architecture</title><prolog><metadata><keywords/></metadata></prolog><conbody>

<p>This documents contains a high level description of the platform security

model implemented in Symbian OS v9.x and beyond. </p>

<section id="GUID-80B8E189-3F47-5684-A6CC-37E30B3A73F5"><title>Contents</title> <ul>

<li id="GUID-372B5FEC-6E92-5EFA-BD15-4CAF14FEDC7B"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-E103331E-23BE-5829-9C2A-795D98AA4A4A">1 Introduction</xref>  </p> </li>

<li id="GUID-3927F321-92C4-5172-859B-206E75C5CAE2"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-C462ED45-0B3F-5BEA-9AF6-D03F6CD7B373">2 Symbian Platform Security Background</xref>  </p> <ul>

<li id="GUID-FBE958D4-B137-5757-AE21-571197439131"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-6B05D4C8-7BBA-5DAF-BEDE-343926A8DC72">2.1 Symbian Security Policy Requirements</xref>  </p> <ul>

<li id="GUID-D9C80AF7-B2A8-59B9-A0A2-8A9CF17B5C47"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-255CAE5E-8342-593E-BCB2-B3257EAB9C13">2.1.1 Prevention</xref>  </p> </li>

<li id="GUID-41874D6C-4EC7-5FF6-A7D8-D2C3F57CFAE5"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-764EA8A8-2768-5B12-8D38-6C031E27F6D3">2.1.2 Detection</xref>  </p> </li>

<li id="GUID-6D68D224-4FAE-5BE5-85AC-C5C0FBBB6511"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-F2B08632-CBBB-5698-B852-5FAFE5A94114">2.1.3 Reaction</xref>  </p> </li>

</ul> </li>

<li id="GUID-C95D8F9E-7FBB-503E-BDD1-D8D19DAFF04A"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-6A22DD08-25C6-58B5-B8DF-B9C94BFBC651">2.2 The Security Architecture</xref>  </p> </li>

</ul> </li>

<li id="GUID-107B388D-16EF-53AC-A431-7FB6B20EF0C9"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-CEC2A903-E69B-5F0F-B1FB-AF13B368B1EF">3 Security Architectural Countermeasures</xref>  </p> <ul>

<li id="GUID-9A5DE41D-AA37-5BE9-91A7-B7A02C2AE3D7"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-9750B6A9-33E5-5470-A505-52646E7D8648">3.1 Trusted Computing Platform</xref>  </p> <ul>

<li id="GUID-EC4EB7C9-3752-5B84-955D-4F44EF40061A"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-BB6A8038-7230-5EF8-A2E7-2F6DB2A69A6D">3.1.1 Trusted Computing Base</xref>  </p> </li>

<li id="GUID-0173F5DE-0C2E-59C3-B2D1-7E671670293D"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-3469D51F-A7E2-54B8-A5EB-CB2842C1A3F3">3.1.2 Trusted Computing Environment</xref>  </p> </li>

</ul> </li>

<li id="GUID-C36D4525-F356-5921-A898-0379A33E38E6"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-CA023029-C0F8-5803-8A38-A6161B3E6A6F">3.2 Process Capabilities</xref>  </p> <ul>

<li id="GUID-4E80D166-0ACA-5210-B626-AF226B22854C"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-1EC03F83-6724-552C-BC95-2DB13C7E632B">3.2.1 Mapping system permissions – System Capabilities</xref>  </p> </li>

<li id="GUID-9EACD773-1344-5EBA-917A-A0FC0EC2B080"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-E10EF8B9-7AC8-521D-B195-6BB7E88BED02">3.2.2 Mapping real-world permissions – User Capabilities</xref>  </p> </li>

<li id="GUID-30F298F8-BE1F-59BF-95F0-27AAD7049B53"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-861A61E2-A364-51B3-B53D-BA8D08874AE4">3.2.3 Assigning capabilities to a process</xref>  </p> </li>

<li id="GUID-63079CA3-44F2-5E4A-8E20-2399A3E7CA92"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-3ED27AA2-9198-59B7-B776-BC43F5FA3119">3.2.4 Capability Permission lifetime</xref>  </p> </li>

</ul> </li>

<li id="GUID-117A47DF-B8E2-5E52-AFEC-649252629CDF"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-F90646D0-321E-5552-9942-BF7A985C46A1">3.3 Process Identification</xref>  </p> <ul>

<li id="GUID-337A27E6-32FE-5C3F-8BF2-A2C4721C8760"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-07FAE266-EB4B-5462-A2A7-6962D4CCED24">3.3.1 Secure Identifier (SID)</xref>  </p> </li>

<li id="GUID-58910FB5-BC54-5FB3-954C-EC705F6F933B"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-088EA3F8-5209-56F4-9B24-90BF819D10E3">3.3.2 Vendor Identifier (VID)</xref>  </p> </li>

<li id="GUID-EC4FC13D-AB17-5C6E-8EC6-4817BE64EE09"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-0F55AE1B-0407-5CD8-A678-D0AE39D81406">3.3.3 Kernel’s &amp; Loader’s role</xref>  </p> </li>

</ul> </li>

<li id="GUID-69F5BEFF-9A5C-5507-BC37-310DB1D31593"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-03558B99-2B98-579C-AD59-CF66BD98F69F">3.4 Data Caging</xref>  </p> <ul>

<li id="GUID-5FA43EF4-5CAD-5D5E-8D28-232348E1E640"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-394AF3B0-FA51-5C99-8FBD-73A707AB177C">3.4.1 Caging processes</xref>  </p> </li>

<li id="GUID-48CB6C12-511F-5878-BE25-A8CD5B2DEADC"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-93AD2587-56D2-5553-84D4-C98FC6BA951C">3.4.2 Removable media</xref>  </p> </li>

</ul> </li>

<li id="GUID-079E308D-3FBA-5B3A-B635-9592B6C91225"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-6478908A-06BB-5FF6-BBFA-4ECE3B815A8A">3.5 SWInstall – Enhancing perimeter security</xref>  </p> <ul>

<li id="GUID-18EEAB03-A6E8-59F4-A585-C35532949458"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-6F7D320F-97C3-5792-9D48-B960489A0A2B">3.5.1 Software validation</xref>  </p> </li>

<li id="GUID-6766B8B5-2C1E-5ED0-8D6E-0B1CE3972268"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-5C6114AC-F485-5720-BB97-9AEAA8F04E75">3.5.2 Capability calculation</xref>  </p> </li>

<li id="GUID-E60A7D50-5287-5E6F-B572-3BE69F2DDA63"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-FAD0881C-EF83-5B0A-BD9E-B18AC6529A4F">3.5.3 Configuring the installer</xref>  </p> </li>

<li id="GUID-077943D6-65F9-5047-A684-F579C4FB7E5A"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-F63BC928-31A0-5FD1-B846-48B678F06BFE">3.5.4 Installation in place or dual phase installation</xref>  </p> </li>

</ul> </li>

<li id="GUID-75C6CD9B-AB63-509B-84D3-9AAFB37DD3AC"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-9527DAD1-61F3-56FA-AA64-0E58FB187495">3.6 Secure backup and restore</xref>  </p> <ul>

<li id="GUID-7A4BABCD-E7DF-54AA-B2D4-25BA58FAAE2E"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-6BADA2AA-519B-5A79-A2FA-EC9B6648BD1F">3.6.1 Active Backup and Restore for Private Data</xref>  </p> </li>

<li id="GUID-0B9BD3E2-CF85-541F-9E11-47AE71F0C4D9"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-D122D4DC-0D32-5252-9B67-B3D66F3737D8">3.6.2 Backup and Restore of Executables via Software Install</xref>  </p> </li>

</ul> </li>

</ul> </li>

<li id="GUID-BC48319D-4B20-5FEF-B5BF-96F5C5EB5AEB"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-830F2821-5614-5083-868C-0D6CEF6D4B0D">4 Additional information</xref>  </p> <ul>

<li id="GUID-359012B4-E556-5AB1-85BB-897CE023C66C"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-CAC87EF9-34AB-5B4B-BF5C-35D96730C12E">4.1 References</xref>  </p> </li>

<li id="GUID-DD6CEA74-A6B9-59DC-A4A3-E96F04EF8C3D"><p><xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-6A8792B7-03AD-505D-892A-1D08ED4C81AB">4.2 Glossary</xref>  </p> </li>

</ul> </li>

</ul> </section>

<section id="GUID-E103331E-23BE-5829-9C2A-795D98AA4A4A"><title>1 Introduction</title> <p>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. </p> <p>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. </p> </section>

<section id="GUID-C462ED45-0B3F-5BEA-9AF6-D03F6CD7B373"><title>2 Symbian Platform

Security Background</title> <p>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 <b>Symbian Platform Security Architecture</b>.

We also look at the substantial number of issues that the adoption of such

platform security architecture poses. </p> <p id="GUID-6B05D4C8-7BBA-5DAF-BEDE-343926A8DC72"><b>2.1

Symbian Security Policy Requirements</b> </p> <p>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. </p> <p id="GUID-255CAE5E-8342-593E-BCB2-B3257EAB9C13"><b>2.1.1

Prevention</b> </p> <p>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. </p> <p>As said in [4], <i>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</i>. 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. </p> <p id="GUID-764EA8A8-2768-5B12-8D38-6C031E27F6D3"><b>2.1.2

Detection</b> </p> <p>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. </p> <p id="GUID-F2B08632-CBBB-5698-B852-5FAFE5A94114"><b>2.1.3 Reaction</b> </p> <p>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. </p> <p id="GUID-6A22DD08-25C6-58B5-B8DF-B9C94BFBC651"><b>2.2

The Security Architecture</b> </p> <p>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. </p> <p>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: </p> <ul>

<li id="GUID-DCA4E741-016D-5B4F-A1FF-9D3E4B1A7D41"><p> <b>Firewall protection</b> of

key system servers through the use of <b>capability-based access control</b>.

The capability model is deliberately limited to a small number of capabilities. </p> </li>

<li id="GUID-6A5211F8-DAA6-54BB-B091-9B74DD352D64"><p> <b>Data caging </b> which

creates a protected part of the file system which rogue apps are not able

to access. </p> </li>

</ul> <p>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. </p> <p>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. </p> <p>All these

points should be borne in mind as we move on to detail the architectural aspects

of the model in the next section. </p> </section>

<section id="GUID-CEC2A903-E69B-5F0F-B1FB-AF13B368B1EF"><title>3 Security

Architectural Countermeasures</title> <p>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. </p> <p>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: </p> <ul>

<li id="GUID-F2DB9FD3-4D02-50BD-93E5-97D575BC4A20"><p>The very nature of the

Symbian platform is to be mono-user. </p> </li>

<li id="GUID-74DA1B3D-737D-5B90-93B6-89CB4CD56876"><p>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. </p> </li>

<li id="GUID-893338DD-7249-5DB8-97A8-BBA773048CFC"><p>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. </p> </li>

</ul> <p>To avoid any confusion while reading this document, please pay attention

to the following definitions: </p> <ul>

<li id="GUID-A3CF9AE1-1550-5CF1-9F59-7C1818C0ABB5"><p>An <b>executable</b> is

a file containing Symbian executable code. This can be a library (DLL) or

a program (EXE). </p> </li>

<li id="GUID-91387A05-431F-514D-905A-AA7DC5AEDB4F"><p>A <b>program</b> is

an executable that once, loaded will trigger the creation of a <b>process.</b>  </p> </li>

<li id="GUID-C1949968-5B03-56A6-BEE1-D37AF8C43B70"><p>A <b>library</b> is

an executable that is linked to another executable or that processes can dynamically

load. </p> </li>

</ul> <p id="GUID-9750B6A9-33E5-5470-A505-52646E7D8648"><b>3.1 Trusted Computing

Platform</b> </p> <p id="GUID-BB6A8038-7230-5EF8-A2E7-2F6DB2A69A6D"><b>3.1.1

Trusted Computing Base</b> </p> <p>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. </p> <p>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. </p> <p id="GUID-3469D51F-A7E2-54B8-A5EB-CB2842C1A3F3"><b>3.1.2

Trusted Computing Environment</b> </p> <p> <i>“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</i>  </p> <p>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. </p> <p>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. </p> <p id="GUID-CA023029-C0F8-5803-8A38-A6161B3E6A6F"><b>3.2

Process Capabilities</b> </p> <p>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 <i>system</i> 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. </p> <p>The key features

of the process capability model are: </p> <ul>

<li id="GUID-B3DA2817-97C8-55A7-8462-C1498772EFC2"><p>It is primarily focused

around Symbian platform system servers and client-server IPC interactions

between processes. </p> </li>

<li id="GUID-2A22A61B-BAAD-5CA7-974B-7D6FCFD11BF0"><p>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. </p> </li>

<li id="GUID-257E42BE-1E6F-5863-BE26-8EF23C4C642B"><p>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. </p> </li>

<li id="GUID-CDAF1309-850A-5130-856D-62535F086776"><p>Not all servers would

have to handle client capabilities. </p> </li>

<li id="GUID-54441D51-F433-55DC-B4E8-F3BE32BE56C8"><p>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. </p> </li>

</ul> <p id="GUID-1EC03F83-6724-552C-BC95-2DB13C7E632B"><b>3.2.1 Mapping system

permissions – System Capabilities</b> </p> <p> <i>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.</i>  </p> <p> <b> Tcb </b> 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. </p> <p> <b> CommDD </b> Grants direct

access to all communication device drivers, including phone baseband software. </p> <p> <b> PowerMgmt </b> 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. </p> <p> <b> MultimediaDD </b> Grants

direct access to all multimedia device drivers </p> <p> <b> ReadDeviceData </b> Grants

read access to device, network operator, and phone manufacturer confidential

settings or data. </p> <p> <b> WriteDeviceData </b> 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. </p> <p> <b> Drm </b> Grants access to rights-protected

content </p> <p> <b> TrustedUI </b> Grants the right to create a trusted UI

session, and therefore to display dialogs in a secure UI environment. </p> <p> <b> ProtServ </b> Grants

the right to a server to register within the protected name space – to limit

scope for malware to spoof sensitive system servers. </p> <p> <b> DiskAdmin </b> Grants

access to disk administration operations that affect more than one file or

one directory (or overall filesystem integrity/behaviour, etc). </p> <p> <b> NetworkControl </b> 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. </p> <p> <b> AllFiles </b> Grants

read access to entire file system. Grants write access to other processes'

private directories. </p> <p> <b> SwEvent </b> Grants the right to generate

software key & pen events and to capture any of them regardless of the

foreground status of the application </p> <p> <b> SurroundingsDD </b> Grants

access to device drivers that provide input information about the surroundings

of the device. </p> <p id="GUID-E10EF8B9-7AC8-521D-B195-6BB7E88BED02"><b>3.2.2

Mapping real-world permissions – User Capabilities</b> </p> <p>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: </p> <p> <b> NetworkServices </b>  <b>  </b> 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. </p> <p> <b> LocalServices </b>  <b>  </b> 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. </p> <p> <b> ReadUserData </b> Grants read access to data belonging

to the phone user. This capability supports the <i>confidentiality </i> of<i>  </i> 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. </p> <p> <b> WriteUserData </b> Grants write access to user data.

This capability supports the management of the <i>integrity </i> 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. </p> <p> <b> Location </b> 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. </p> <p> <b> UserEnvironment </b> 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. </p> <p>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. </p> <p>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. </p> <p id="GUID-861A61E2-A364-51B3-B53D-BA8D08874AE4"><b>3.2.3

Assigning capabilities to a process</b> </p> <p>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. </p> <ol id="GUID-8770138F-B858-570C-98F0-8CAF365AA656">

<li id="GUID-D41EEC0F-FFBC-57BA-91C7-72312512AC6A"><p> <b> The capabilities

of a process never change.</b>  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. </p> </li>

<li id="GUID-732F0118-3C18-50A0-9D57-A7136F39B0CE"><p> <b> A process cannot

load a DLL with less capability than itself.</b>  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. </p> </li>

</ol> <p>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. </p> <p id="GUID-3ED27AA2-9198-59B7-B776-BC43F5FA3119"><b>3.2.4

Capability Permission lifetime</b> </p> <p>There are two possible alternatives

for interpretation of the presence of a user-exposed capability at capability-aware

servers: </p> <p> <b>Blanket permission</b>: 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. </p> <ul>

<li id="GUID-A56156C5-3B8C-5566-8F74-BAC190C849C9"><p> <b>Single action permission</b>:

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. </p> </li>

</ul> <p>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. </p> <p>The advantages of this design are: </p> <ul>

<li id="GUID-76BB16EB-7469-515F-9F30-040AE2A91950"><p>To maintain the time

of check as close as the time of use as possible (to avoid any TOCTOU flaws) </p> </li>

<li id="GUID-567F2967-2988-5652-B4A2-9A9B8C2ED6B5"><p>To avoid the server

storing capability-related information for a process. </p> </li>

</ul> <p>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. </p> <p id="GUID-F90646D0-321E-5552-9942-BF7A985C46A1"><b>3.3

Process Identification</b> </p> <p>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. </p> <p id="GUID-07FAE266-EB4B-5462-A2A7-6962D4CCED24"><b>3.3.1

Secure Identifier (SID)</b> </p> <p>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. </p> <p>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. </p> <p id="GUID-088EA3F8-5209-56F4-9B24-90BF819D10E3"><b>3.3.2

Vendor Identifier (VID)</b> </p> <p>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. </p> <p id="GUID-0F55AE1B-0407-5CD8-A678-D0AE39D81406"><b>3.3.3 Kernel’s &amp; Loader’s

role</b> </p> <p>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. </p> <p id="GUID-03558B99-2B98-579C-AD59-CF66BD98F69F"><b>3.4

Data Caging </b> </p> <p id="GUID-394AF3B0-FA51-5C99-8FBD-73A707AB177C"><b>3.4.1

Caging processes </b> </p> <p id="GUID-9C9307AE-4B3C-5CE8-B66C-FE3E40A2C1C4"><b>3.4.1.1

Location-based concept</b> </p> <p>Data caging involves separating code from

data in the file system such that a simple trusted path is created on the

platform. </p> <ul>

<li id="GUID-C7AB7740-5EEA-5513-8FEC-6F96C7E52AB2"><p>A new <codeph>/sys</codeph> directory

hierarchy is created, with all executable code residing in the <codeph>/sys/bin</codeph> subdirectory.

The central idea is that by “caging” non-TCB processes into their own part

of the file system, the <codeph>/sys </codeph> 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 <codeph>/sys</codeph> sub-tree.

In addition, the loader would disallow any attempt to execute code residing

elsewhere than <codeph>/sys/bin</codeph>. </p> </li>

<li id="GUID-D710C501-9913-565A-9BD1-FCE531AA7BC5"><p>A new <codeph>/resource</codeph> 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. </p> </li>

<li id="GUID-4C6FB170-58EF-580B-B787-3E27DA422CAF"><p>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 <codeph>/private/&lt;app_SID&gt;</codeph>,

where SID is a Secure Identifier used to distinguish between the <codeph>/private</codeph> sub-directories.

Applications can, for example, use their sub-tree to hold various private

data files. </p> </li>

</ul> <p>Directories not under <codeph>/sys</codeph> or <codeph>/private</codeph> or <codeph>/resource</codeph> 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 <codeph>/sys/bin</codeph>.

In that sense, data caging is a simpler and more robust. </p><table id="GUID-1F570514-0235-4164-9EE4-93C2748768F0"><title>Data

caging – capabilities for data caging</title>

<tgroup cols="11"><colspec colname="col1"/><colspec colname="col2"/><colspec colname="col3"/><colspec colname="col4"/><colspec colname="col5"/><colspec colname="col6"/><colspec colname="col7"/><colspec colname="col8"/><colspec colname="col9"/><colspec colname="col10"/><colspec colname="col11"/>

<tbody>

<row>

<entry/>

<entry nameend="col3" namest="col2"><filepath>/resource</filepath></entry>

<entry nameend="col5" namest="col4"><filepath>/sys</filepath></entry>

<entry nameend="col7" namest="col6"><filepath>/private/ownSID</filepath></entry>

<entry nameend="col9" namest="col8"><filepath>/private/anyOther</filepath></entry>

<entry nameend="col11" namest="col10"><filepath>/anyOther</filepath></entry>

</row>

<row>

<entry>Capabilities  </entry>

<entry>Read</entry>

<entry>Write</entry>

<entry>Read</entry>

<entry>Write</entry>

<entry>Read</entry>

<entry>Write</entry>

<entry>Read</entry>

<entry>Write</entry>

<entry>Read</entry>

<entry>Write</entry>

</row>

<row>

<entry>None</entry>

<entry>Yes</entry>

<entry>No</entry>

<entry>No</entry>

<entry>No</entry>

<entry>Yes</entry>

<entry>Yes</entry>

<entry>No</entry>

<entry>No</entry>

<entry>Yes</entry>

<entry>Yes</entry>

</row>

<row>

<entry>AllFiles</entry>

<entry>Yes</entry>

<entry>No</entry>

<entry>Yes</entry>

<entry>No</entry>

<entry>Yes</entry>

<entry>Yes</entry>

<entry>Yes</entry>