Initial contribution of the Adaptation Documentation.
<?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 & 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 & 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/<app_SID></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>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
</row>
<row>
<entry>TCB</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>No</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>No</entry>
<entry>No</entry>
<entry>Yes</entry>
<entry>Yes</entry>
</row>
<row>
<entry>AllFiles+TCB</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
<entry>Yes</entry>
</row>
</tbody>
</tgroup>
</table> <p>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. </p> <p>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. </p> <p id="GUID-89E1EC84-A373-53AF-A586-D5FF635B0B62"><b>3.4.1.2
Import directory concept</b> </p> <p>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: </p> <ul>
<li id="GUID-B457A88B-AABA-5F44-B054-A9C2873D3693"><p>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. </p> </li>
<li id="GUID-9A510686-D67A-5B1C-8FC7-F47FE9D64D38"><p>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. </p> </li>
<li id="GUID-3E197C12-3108-50CF-95EA-28E70C95F51A"><p>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. </p> </li>
<li id="GUID-2DAF2C55-178F-573F-860E-CFD7C6149A1A"><p>The creation of an import
directory is under the responsibility of the process developer. </p> </li>
</ul> <p id="GUID-C79F6795-744F-5ED0-8F3F-5720FF1BE229"><b>3.4.1.3 Sharing
files and data</b> </p> <p>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. </p> <p id="GUID-93AD2587-56D2-5553-84D4-C98FC6BA951C"><b>3.4.2
Removable media</b> </p> <p>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. </p> <p>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. </p> <p>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. </p> <p id="GUID-6478908A-06BB-5FF6-BBFA-4ECE3B815A8A"><b>3.5
SWInstall – Enhancing perimeter security</b> </p> <p>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. </p> <p id="GUID-6F7D320F-97C3-5792-9D48-B960489A0A2B"><b>3.5.1
Software validation</b> </p> <p>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. </p> <p id="GUID-5C6114AC-F485-5720-BB97-9AEAA8F04E75"><b>3.5.2
Capability calculation</b> </p> <p>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. </p> <p>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. </p> <p id="GUID-FAD0881C-EF83-5B0A-BD9E-B18AC6529A4F"><b>3.5.3 Configuring the installer</b> </p> <p>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. </p> <p id="GUID-F63BC928-31A0-5FD1-B846-48B678F06BFE"><b>3.5.4
Installation in place or dual phase installation</b> </p> <p>Symbian installation
package files include a <i>SISSignedController</i> 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. </p> <p id="GUID-9527DAD1-61F3-56FA-AA64-0E58FB187495"><b>3.6 Secure
backup and restore </b> </p> <p>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. </p> <p>The security architecture
needs to consider three different types of files in the context of backup
and restore. </p> <ol id="GUID-EB24EA75-D1CC-5792-8EEB-0F12AA327006">
<li id="GUID-DC0AAA67-0969-5AA0-8DCF-0822DD6FF33E"><p> <i>Public files</i> 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 <i>passive
backup</i>. 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. </p> </li>
<li id="GUID-DC14C663-D4A9-58EA-B0A6-0E14CFB732F9"><p> <i>Private files</i> are
those belonging to particular applications which store them in the <codeph>/private/</codeph> 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 <i>active backup</i> 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. </p> </li>
<li id="GUID-6B7B6670-9F95-5DA1-8945-BF79052A3509"><p> <i>Executable binaries</i> are
those stored in the <codeph>/sys/bin/</codeph> 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. </p> </li>
</ol> <p id="GUID-6BADA2AA-519B-5A79-A2FA-EC9B6648BD1F"><b>3.6.1 Active Backup
and Restore for Private Data</b> </p> <p>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. </p> <p id="GUID-D122D4DC-0D32-5252-9B67-B3D66F3737D8"><b>3.6.2
Backup and Restore of Executables via Software Install</b> </p> <p>As described
in <xref href="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B.dita#GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B/GUID-F63BC928-31A0-5FD1-B846-48B678F06BFE">3.5.4</xref> each
installation package file includes a <i>SISSignedController</i> 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 <codeph>\sys\bin</codeph> 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 <codeph>\sys\bin</codeph>. 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. </p> </section>
<section id="GUID-830F2821-5614-5083-868C-0D6CEF6D4B0D"><title>4 Additional
information</title> <p id="GUID-CAC87EF9-34AB-5B4B-BF5C-35D96730C12E"><b>4.1
References</b> </p> <p>[1] High Level Requirements for Release 7.0 of the
Symbian Platform v0.04, Mark Wilce, Symbian, March 2001. </p> <p>[2] “Creating
a Secure WinCE 3.0 Device”, Maricia Alforque, Microsoft Corp., © October 2000, <xref href="http://msdn.microsoft.com/library/techart/winsecurity.htm" scope="external">http://msdn.microsoft.com/library/techart/winsecurity.htm</xref> </p> <p>[3] Mobile Station Application Execution Environment (MExE): Functional
Description, Stage 2, 3GPP TS 23.057 v4.0.0, <xref href="ftp://ftp.3gpp.org/Specs/2000-12/Rel-4/23_series/23057-400.zip" scope="external">ftp://ftp.3gpp.org/Specs/2000-12/Rel-4/23_series/23057-400.zip</xref> </p> <p>[4]
The -Inevitability of Failure: The Flawed Assumption of Security in Modern
Computing Environments, Loscocco et al, National Security Agency, October
1998, <xref href="http://www.cs.utah.edu/flux/fluke/html/inevitability.htm" scope="external">http://www.cs.utah.edu/flux/fluke/html/inevitability.htm</xref> </p> <p>[5] <xref href="http://www.theregister.co.uk/content/4/17821.html" scope="external">http://www.theregister.co.uk/content/4/17821.html</xref> </p> <p>[6]
Security Analysis of the Palm Operating System and its Weaknesses Against
Malicious Code Threats, Kingpin and Mudge, @Stake, April 2001 formerly at <xref href="http://www.atstake.com/research/reports/security_analysis_palm_os.pdf" scope="external">http://www.atstake.com/research/reports/security_analysis_palm_os.pdf</xref> but
now at <xref href="http://www.quands.info/pdf/security_analysis_palm_os.pdf" scope="external">www.quands.info/pdf/security_analysis_palm_os.pdf</xref>. </p> <p id="GUID-6A8792B7-03AD-505D-892A-1D08ED4C81AB"><b>4.2 Glossary</b> </p> <table id="GUID-60365022-B96D-50EA-BA49-94AB5AD85CD5">
<tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/>
<thead>
<row>
<entry>Term</entry>
<entry>Meaning</entry>
</row>
</thead>
<tbody>
<row>
<entry><p>API </p> </entry>
<entry><p>Application Programming Interface </p> </entry>
</row>
<row>
<entry><p>CA </p> </entry>
<entry><p>Certificate Authority </p> </entry>
</row>
<row>
<entry><p>DLL </p> </entry>
<entry><p>Dynamic Link Library </p> </entry>
</row>
<row>
<entry><p>executable </p> </entry>
<entry><p>A file containing native code: libraries (DLL) and programs (EXE) </p> </entry>
</row>
<row>
<entry><p>F32 </p> </entry>
<entry><p>The Symbian Platform File Server </p> </entry>
</row>
<row>
<entry><p>IPC </p> </entry>
<entry><p>Inter Process Communication </p> </entry>
</row>
<row>
<entry><p>OEM </p> </entry>
<entry><p>Original Equipment Manufacturer </p> </entry>
</row>
<row>
<entry><p>PKI </p> </entry>
<entry><p>Public Key Infrastructure </p> </entry>
</row>
<row>
<entry><p>SWInstall </p> </entry>
<entry><p>Software Install – provides service of native application installation. </p> </entry>
</row>
<row>
<entry><p>UI </p> </entry>
<entry><p>User Interface </p> </entry>
</row>
<row>
<entry><p>UID </p> </entry>
<entry><p>Unique Identifier. In the Symbian platform this is a 32-bit word
which is used to uniquely identify an object or its type. </p> </entry>
</row>
</tbody>
</tgroup>
</table> </section>
</conbody></concept>