|
1 <?xml version="1.0" encoding="utf-8"?> |
|
2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> |
|
3 <!-- This component and the accompanying materials are made available under the terms of the License |
|
4 "Eclipse Public License v1.0" which accompanies this distribution, |
|
5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> |
|
6 <!-- Initial Contributors: |
|
7 Nokia Corporation - initial contribution. |
|
8 Contributors: |
|
9 --> |
|
10 <!DOCTYPE concept |
|
11 PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> |
|
12 <concept id="GUID-1E7AA950-06C2-599C-BCC2-12BB99306E1B" xml:lang="en"><title>Symbian |
|
13 OS v9 Security Architecture</title><prolog><metadata><keywords/></metadata></prolog><conbody> |
|
14 <p>This documents contains a high level description of the platform security |
|
15 model implemented in Symbian OS v9.x and beyond. </p> |
|
16 <section id="GUID-80B8E189-3F47-5684-A6CC-37E30B3A73F5"><title>Contents</title> <ul> |
|
17 <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> |
|
18 <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> |
|
19 <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> |
|
20 <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> |
|
21 <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> |
|
22 <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> |
|
23 </ul> </li> |
|
24 <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> |
|
25 </ul> </li> |
|
26 <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> |
|
27 <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> |
|
28 <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> |
|
29 <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> |
|
30 </ul> </li> |
|
31 <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> |
|
32 <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> |
|
33 <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> |
|
34 <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> |
|
35 <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> |
|
36 </ul> </li> |
|
37 <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> |
|
38 <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> |
|
39 <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> |
|
40 <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> |
|
41 </ul> </li> |
|
42 <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> |
|
43 <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> |
|
44 <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> |
|
45 </ul> </li> |
|
46 <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> |
|
47 <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> |
|
48 <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> |
|
49 <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> |
|
50 <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> |
|
51 </ul> </li> |
|
52 <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> |
|
53 <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> |
|
54 <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> |
|
55 </ul> </li> |
|
56 </ul> </li> |
|
57 <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> |
|
58 <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> |
|
59 <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> |
|
60 </ul> </li> |
|
61 </ul> </section> |
|
62 <section id="GUID-E103331E-23BE-5829-9C2A-795D98AA4A4A"><title>1 Introduction</title> <p>A |
|
63 platform security model was introduced in Symbian OS v9. Developers can read |
|
64 this paper to get a high level view of the model and what it means for how |
|
65 they implement programs. </p> <p>Some brief background information about security |
|
66 and mobile phones is provided in section 2. The document does not describe |
|
67 what infrastructure is needed to support the security model in the operating |
|
68 system, such as application signing programs, security incident processes, |
|
69 etc. </p> </section> |
|
70 <section id="GUID-C462ED45-0B3F-5BEA-9AF6-D03F6CD7B373"><title>2 Symbian Platform |
|
71 Security Background</title> <p>Symbian platform security covers the philosophy, |
|
72 architecture and implementation of the platform defence mechanisms against |
|
73 malicious or badly implemented code. The scope of platform security requires |
|
74 a holistic perspective of some complex system services and their interactions. |
|
75 This paper focuses on the architectural elements required to support the platform |
|
76 defence mechanisms. Specifically, we examine a number of architectural countermeasures |
|
77 that collectively constitute the <b>Symbian Platform Security Architecture</b>. |
|
78 We also look at the substantial number of issues that the adoption of such |
|
79 platform security architecture poses. </p> <p id="GUID-6B05D4C8-7BBA-5DAF-BEDE-343926A8DC72"><b>2.1 |
|
80 Symbian Security Policy Requirements</b> </p> <p>A security policy allows |
|
81 you to determine effective countermeasures to threats in three ways: protection, |
|
82 detection and reaction. These three aspects need to be enforced by different |
|
83 mechanisms that are outlined in the following subsections. </p> <p id="GUID-255CAE5E-8342-593E-BCB2-B3257EAB9C13"><b>2.1.1 |
|
84 Prevention</b> </p> <p>There is a need to prevent badly written applications |
|
85 from doing things they are not intended to do on the platform. This involves |
|
86 first of all determining whether the application is sufficiently trustworthy |
|
87 to be installed and then subsequently protecting the platform from errant |
|
88 behaviour once it is installed. In terms of determining trust, third party |
|
89 applications are categorised according to the degree of trust associated with |
|
90 their authors. The binding between trust and authorship is encapsulated within |
|
91 digital certificates issued by a Certificate Authority (CA). The CA performs |
|
92 a role within a PKI which is the organisational infrastructure used to establish |
|
93 and mediate the trust relationships. Individual third party applications are |
|
94 furthermore granted differing degrees of capability at install time within |
|
95 the context of the platform environment on the basis of the perceived degree |
|
96 of trust bestowed upon them by the PKI. </p> <p>As said in [4], <i>mandatory |
|
97 security mechanisms may be used both to limit trusted applications to the |
|
98 minimal set of privileges required for their function and to confine the damage |
|
99 caused by any misuse of their privileges</i>. For this reason it is important |
|
100 to understand that the security architecture must be also applied to Symbian |
|
101 and licensees code even on a closed environment where new code cannot be installed. |
|
102 As for the MMU (Memory Management Unit) it will bring us several benefits |
|
103 like decreasing the impact of a flaw, enforcing good design and reducing dependencies |
|
104 between components. </p> <p id="GUID-764EA8A8-2768-5B12-8D38-6C031E27F6D3"><b>2.1.2 |
|
105 Detection</b> </p> <p>The detection of errant application behaviour on the |
|
106 platform includes ensuring that incidents are logged and reported promptly. |
|
107 This means continuous monitoring of relevant incident tracking sources and |
|
108 first level categorisation of security breaches as being minor, significant |
|
109 or major. It may also include support of intrusion detection systems on the |
|
110 platform such as virus scanners. Detection also covers tracking the security |
|
111 flaws in standards we implement as well as security flaws in the platform |
|
112 security architecture. Finally it involves the detection of compromises in |
|
113 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 |
|
114 is a need to respond to incidents promptly and effectively. The consequence |
|
115 of having no coherent response to major incidents may be a catastrophic loss |
|
116 of confidence in the security of the Symbian platform among our customers |
|
117 and users. Even if the full response mechanism is out of the scope of the |
|
118 Symbian platform, the security architecture should provide support to implement |
|
119 part of it as capability revocation and upgrade mechanisms. </p> <p id="GUID-6A22DD08-25C6-58B5-B8DF-B9C94BFBC651"><b>2.2 |
|
120 The Security Architecture</b> </p> <p>The main security threat Symbian addresses |
|
121 with this platform security architecture is to prevent viral distribution |
|
122 of malicious applications; for this reason hardware attacks are not specifically |
|
123 addressed. </p> <p>The architecture focuses in delivering prevention mechanisms. |
|
124 Detections and reactions rely heavily on services provided by an infrastructure |
|
125 external to the phone and its operating system and are not addressed in this |
|
126 document. The basic outline of the security architecture is analogue to a |
|
127 medieval castle defences. In a similar fashion it employs simple and staggered |
|
128 layers of security above and beyond the software installer perimeter. The |
|
129 key threats that the model is trying to address are those that are linked |
|
130 with unauthorised access to user data and to system services in particular |
|
131 the phone stack. The phone stack is especially important in the context of |
|
132 a phone because it will be controlling a permanent data connection to the |
|
133 Internet. There are two key design drivers lying behind the model: </p> <ul> |
|
134 <li id="GUID-DCA4E741-016D-5B4F-A1FF-9D3E4B1A7D41"><p> <b>Firewall protection</b> of |
|
135 key system servers through the use of <b>capability-based access control</b>. |
|
136 The capability model is deliberately limited to a small number of capabilities. </p> </li> |
|
137 <li id="GUID-6A5211F8-DAA6-54BB-B091-9B74DD352D64"><p> <b>Data caging </b> which |
|
138 creates a protected part of the file system which rogue apps are not able |
|
139 to access. </p> </li> |
|
140 </ul> <p>There is a certain minimum amount of architectural work that had |
|
141 to be done to put the security architecture in place. However, there was also |
|
142 a requirement to minimise the impact of any scheme to the architecture of |
|
143 the Symbian platform. Adding platform security with minimal impact was hard |
|
144 to do but this desire had influenced a lot of the architectural ideas. </p> <p>On |
|
145 the plus side, the security architecture has some distinct advantages over |
|
146 other approaches. It offers us the chance to get a competitive advantage by |
|
147 putting in place the right security architecture for a phone platform. This |
|
148 in turn would mean that our licensees would see the Symbian platform as a |
|
149 more attractive option than the competition partly because the premiums they |
|
150 would have to pay for device security insurance would be lower. In addition, |
|
151 they will have increased trust that deployment of the Symbian platform in |
|
152 their products will not ruin their reputation and brand. </p> <p>All these |
|
153 points should be borne in mind as we move on to detail the architectural aspects |
|
154 of the model in the next section. </p> </section> |
|
155 <section id="GUID-CEC2A903-E69B-5F0F-B1FB-AF13B368B1EF"><title>3 Security |
|
156 Architectural Countermeasures</title> <p>It is inherently difficult to work |
|
157 out how to partition a holistic architecture such as that required to support |
|
158 platform wide security. The approach we have taken here is to present a series |
|
159 of different views on the architectural countermeasures from various perspectives |
|
160 each of which highlight a particular functional element within the system. |
|
161 The security architecture is a combination of these elements. </p> <p>The |
|
162 main concept of all the security countermeasures described below is to control |
|
163 what a process can do rather than what a user can do. This approach is quite |
|
164 different to well-known operating systems as Unix. The main reasons for which |
|
165 we made this choice are: </p> <ul> |
|
166 <li id="GUID-F2DB9FD3-4D02-50BD-93E5-97D575BC4A20"><p>The very nature of the |
|
167 Symbian platform is to be mono-user. </p> </li> |
|
168 <li id="GUID-74DA1B3D-737D-5B90-93B6-89CB4CD56876"><p>The Symbian platform |
|
169 provides services through independent server processes. They always run and |
|
170 are not attach to a user session. As long as power is supplied, the Symbian |
|
171 platform is always on even if no user is logged on. </p> </li> |
|
172 <li id="GUID-893338DD-7249-5DB8-97A8-BBA773048CFC"><p>The Symbian platform |
|
173 is aimed to be used in devices used by a large public with no technology knowledge. |
|
174 When installing software, the user may not have the skills to decide what |
|
175 permissions to grant to an application. Furthermore, with always-connected |
|
176 devices, the consequences of a wrong or malevolent decision may impact a domain |
|
177 much larger than the device itself. </p> </li> |
|
178 </ul> <p>To avoid any confusion while reading this document, please pay attention |
|
179 to the following definitions: </p> <ul> |
|
180 <li id="GUID-A3CF9AE1-1550-5CF1-9F59-7C1818C0ABB5"><p>An <b>executable</b> is |
|
181 a file containing Symbian executable code. This can be a library (DLL) or |
|
182 a program (EXE). </p> </li> |
|
183 <li id="GUID-91387A05-431F-514D-905A-AA7DC5AEDB4F"><p>A <b>program</b> is |
|
184 an executable that once, loaded will trigger the creation of a <b>process.</b> </p> </li> |
|
185 <li id="GUID-C1949968-5B03-56A6-BEE1-D37AF8C43B70"><p>A <b>library</b> is |
|
186 an executable that is linked to another executable or that processes can dynamically |
|
187 load. </p> </li> |
|
188 </ul> <p id="GUID-9750B6A9-33E5-5470-A505-52646E7D8648"><b>3.1 Trusted Computing |
|
189 Platform</b> </p> <p id="GUID-BB6A8038-7230-5EF8-A2E7-2F6DB2A69A6D"><b>3.1.1 |
|
190 Trusted Computing Base</b> </p> <p>A trusted computing base is a basic architectural |
|
191 requirement for robust platform security. The trusted computing base would |
|
192 consist of a number of architectural elements that cannot be subverted and |
|
193 that guarantee the integrity of the device. It is important to keep this base |
|
194 as small as possible and to apply the principle of least privilege to ensure |
|
195 system servers and applications do not have to be given privileges they do |
|
196 not need to function. On closed devices, the TCB consists of the Symbian platform |
|
197 kernel and F32, on open devices the software installer (SWInstall) is also |
|
198 required. All these processes are system-wide trusted and have therefore full |
|
199 access to the device. This trusted core would run with a “Tcb” system capability |
|
200 not available to other platform code. </p> <p>There is one other important |
|
201 element of the trusted computing base, namely the hardware. One important |
|
202 recent paper [6] has outlined a hardware design that does not take operating |
|
203 system security into account. In particular, with devices that hold trusted |
|
204 computing base functionality in flash ROM, it is necessary to provide a secure |
|
205 boot loader to ensure that it is not possible to subvert the trusted computing |
|
206 base with a malicious ROM image. Providing such a secure boot loader is explicitly |
|
207 excluded from the scope of this architecture, and it is a requirement on the |
|
208 base port for specific hardware platforms to provide for this. </p> <p id="GUID-3469D51F-A7E2-54B8-A5EB-CB2842C1A3F3"><b>3.1.2 |
|
209 Trusted Computing Environment</b> </p> <p> <i>“There are always system components |
|
210 <…> that must be able to read and write at all levels <…>. The practical |
|
211 outcome is that an uncomfortably large part of the operating system (plus |
|
212 utilities, plus windowing system, plus database) often ends up in the trusted |
|
213 computing base” Ross Anderson</i> </p> <p>Beyond the core, other system components |
|
214 are granted restricted orthogonal system capability and constitute the Trusted |
|
215 Computing Environment, for instance, these include servers providing sockets, |
|
216 telephony, certificate management, database access, and windowing services. |
|
217 Each server just has the capabilities it requires, for instance the windowing |
|
218 server is not granted phone stack access and the communications servers is |
|
219 not granted direct access to keyboard events. These system capabilities are |
|
220 only available to third party code that is appropriately signed. By limiting |
|
221 the number and combination of system capabilities allocated to any single |
|
222 component, a limit is placed on the potential damage that can be caused by |
|
223 any vulnerability or misuse of privileges. </p> <p>This is a very natural |
|
224 evolution of the client/server system architecture that has been widely utilised |
|
225 in the operating system since its very inception, and aligns well with the |
|
226 strengths of that architecture. </p> <p id="GUID-CA023029-C0F8-5803-8A38-A6161B3E6A6F"><b>3.2 |
|
227 Process Capabilities</b> </p> <p>A capability is an access token that corresponds |
|
228 to a permission to undertake a sensitive action or group of actions. The Symbian |
|
229 platform security architecture purpose is to control access to sensitive system |
|
230 resources. The most important resource that requires access control is the |
|
231 kernel executive itself and a <i>system</i> capability is required by a client |
|
232 to access certain functionality through the kernel API. All other resources |
|
233 reside in user-side servers accessed via inter-process communication (IPC) |
|
234 (eg. the telephony server). A limited number of basic capabilities are defined |
|
235 to police specific client actions on the servers. For example, possession |
|
236 of the “network services” capability allows a client to place phone calls |
|
237 via the telephony server. It is the responsibility of the server to police |
|
238 client access to the resources that it provides. </p> <p>The key features |
|
239 of the process capability model are: </p> <ul> |
|
240 <li id="GUID-B3DA2817-97C8-55A7-8462-C1498772EFC2"><p>It is primarily focused |
|
241 around Symbian platform system servers and client-server IPC interactions |
|
242 between processes. </p> </li> |
|
243 <li id="GUID-2A22A61B-BAAD-5CA7-974B-7D6FCFD11BF0"><p>Capabilities are associated |
|
244 with processes not threads. Threads in the same process share the same address |
|
245 space and memory access permissions. This means that any data being used by |
|
246 one thread can be read and modified by all other threads in the same process. |
|
247 In addition, threads in the same process can write to each other’s stacks |
|
248 and thereby divert one another’s execution path. </p> </li> |
|
249 <li id="GUID-257E42BE-1E6F-5863-BE26-8EF23C4C642B"><p>When the code is not |
|
250 running, capabilities are stored inside of executables. Capabilities stored |
|
251 in executables are not modifiable, as they would be stored during installation |
|
252 in a location that is only accessible by the Trusted Computing Base. See subsection |
|
253 3.4 for the details on how this works. </p> </li> |
|
254 <li id="GUID-CDAF1309-850A-5130-856D-62535F086776"><p>Not all servers would |
|
255 have to handle client capabilities. </p> </li> |
|
256 <li id="GUID-54441D51-F433-55DC-B4E8-F3BE32BE56C8"><p>The only cryptography |
|
257 involved in this scheme is at the software installation stage where certificates |
|
258 are checked off against the appropriate root certificates, if necessary, before |
|
259 code is granted any requested capabilities. In some scenarios it is possible |
|
260 for third party developers to dispense with the use of certificates altogether, |
|
261 in which case users would be responsible for granting the requisite capabilities. |
|
262 The subsection 3.5 goes into the details of this. </p> </li> |
|
263 </ul> <p id="GUID-1EC03F83-6724-552C-BC95-2DB13C7E632B"><b>3.2.1 Mapping system |
|
264 permissions – System Capabilities</b> </p> <p> <i>System permissions are never |
|
265 exposed to the user and are therefore mandatory. Without it, a process cannot |
|
266 perform a protected operation. One of the main goals of this architecture |
|
267 for the Symbian platform is to protect what is really vital for the integrity |
|
268 of the System and to minimise the number of critical operations. For this |
|
269 reason, some Symbian components have been designed to avoid the need to restrict |
|
270 access to some operations without, of course, compromising their integrity.</i> </p> <p> <b> Tcb </b> Used |
|
271 by the Trusted Computing Base only, it gives access to the location executables |
|
272 are stored and therefore they can change their capabilities. Only the Symbian |
|
273 platform kernel, the file server (including the loader), and the software |
|
274 installer are granted this privilege. </p> <p> <b> CommDD </b> Grants direct |
|
275 access to all communication device drivers, including phone baseband software. </p> <p> <b> PowerMgmt </b> Grants |
|
276 the right to kill any process in the system, to switch the machine into standby |
|
277 state, wake it up again or power it down completely. </p> <p> <b> MultimediaDD </b> Grants |
|
278 direct access to all multimedia device drivers </p> <p> <b> ReadDeviceData </b> Grants |
|
279 read access to device, network operator, and phone manufacturer confidential |
|
280 settings or data. </p> <p> <b> WriteDeviceData </b> Grants write access to |
|
281 settings that control the behaviour of the device. Note this is NOT necessarily |
|
282 symmetric with ReadDeviceData, and in practice is required significantly more |
|
283 often than that capability. </p> <p> <b> Drm </b> Grants access to rights-protected |
|
284 content </p> <p> <b> TrustedUI </b> Grants the right to create a trusted UI |
|
285 session, and therefore to display dialogs in a secure UI environment. </p> <p> <b> ProtServ </b> Grants |
|
286 the right to a server to register within the protected name space – to limit |
|
287 scope for malware to spoof sensitive system servers. </p> <p> <b> DiskAdmin </b> Grants |
|
288 access to disk administration operations that affect more than one file or |
|
289 one directory (or overall filesystem integrity/behaviour, etc). </p> <p> <b> NetworkControl </b> Grants |
|
290 the right to modify or access network protocol controls, in a way that might |
|
291 affect more than one client application or transport connection / session. </p> <p> <b> AllFiles </b> Grants |
|
292 read access to entire file system. Grants write access to other processes' |
|
293 private directories. </p> <p> <b> SwEvent </b> Grants the right to generate |
|
294 software key & pen events and to capture any of them regardless of the |
|
295 foreground status of the application </p> <p> <b> SurroundingsDD </b> Grants |
|
296 access to device drivers that provide input information about the surroundings |
|
297 of the device. </p> <p id="GUID-E10EF8B9-7AC8-521D-B195-6BB7E88BED02"><b>3.2.2 |
|
298 Mapping real-world permissions – User Capabilities</b> </p> <p>The process |
|
299 of identified these capabilities was a lengthy and involved one. First we |
|
300 attempted to identify those accesses that require policing and then tried |
|
301 to map those requirements into something that is meaningful for a user. In |
|
302 addition, more capabilities means greater complexity and complexity is widely |
|
303 recognised as being the chief enemy of security. A solution based on capabilities |
|
304 should therefore seek to minimise the overall number deployed. These map fairly |
|
305 broadly onto the main threats which are unauthorised access to the outside |
|
306 world and preserving the confidentiality/integrity of user data. We assert |
|
307 that any permission requirement can be expressed in terms of some combination |
|
308 of those. In a sense, these capabilities represent orthogonal groupings because |
|
309 they police different kinds of access together. The capabilities identified |
|
310 today are as follows: </p> <p> <b> NetworkServices </b> <b> </b> Grants |
|
311 access to remote services without any restriction on its physical location. |
|
312 Typically, this location is unknown to the phone user. Also such services |
|
313 may incur cost for the phone user. This typically implies routed protocols. |
|
314 Voice calls, SMS, internet services are good examples of such network services. |
|
315 They are supported by GSM, CDMA and all IP transport protocols including Bluetooth |
|
316 profiles over IP. </p> <p> <b> LocalServices </b> <b> </b> Grants access |
|
317 to remote services in the close vicinity of the phone. The location of the |
|
318 remote service is well-known to the phone user.In most cases, such services |
|
319 will not incur cost for the phone user. This typically implies a non-routed |
|
320 protocol. An application with this capability can normally send or receive |
|
321 information through Serial port, USB, IR and point-to-point Bluetooth profiles. |
|
322 Examples of services are IR beaming with the user's PC, Bluetooth gaming, |
|
323 file transfer. </p> <p> <b> ReadUserData </b> Grants read access to data belonging |
|
324 to the phone user. This capability supports the <i>confidentiality </i> of<i> </i> user |
|
325 data. Today, Contacts, messages and calendar data are always seen as user |
|
326 confidential data. For other content types such as images or sounds, it may |
|
327 depend on context, and ultimately be up to the application owning the data |
|
328 to define. </p> <p> <b> WriteUserData </b> Grants write access to user data. |
|
329 This capability supports the management of the <i>integrity </i> of user data. |
|
330 Note that this capability is not necessarily symmetric with ReadUserData. |
|
331 For instance, one may wish to prevent rogue applications from deleting music |
|
332 tracks but may not wish to restrict read access to them. </p> <p> <b> Location </b> Grants |
|
333 access to the live location of the device. This capability supports the management |
|
334 of user’s privacy regarding the phone location. Location information protected |
|
335 by this capability can include map co-ordinates and street address, but not |
|
336 regional or national scale information. </p> <p> <b> UserEnvironment </b> Grants |
|
337 access to live confidential information about the user and his/her immediate |
|
338 environment.This capability also protects the user's privacy. Examples are |
|
339 audio, picture and video recording, biometrics (such as blood pressure) recording. </p> <p>We |
|
340 acknowledge that user-exposed capabilities are relatively coarse-grained but |
|
341 the assertion is that expanding on these levels is undesirable at this time, |
|
342 for reasons previously given. Only these capabilities may be exposed to users |
|
343 during software installation of unsigned code as discussed in section 3.5. </p> <p>Security |
|
344 policies requiring Tcb and system capabilities are always mandatory. Their |
|
345 strict control ensures the integrity of Symbian Trusted Computing Platform. |
|
346 However the way servers check user-exposed capabilities or interpret them |
|
347 may be fully flexible and even user-discretionary, for example allowing user |
|
348 prompting if a sensitive action fails due to lack of capability. </p> <p id="GUID-861A61E2-A364-51B3-B53D-BA8D08874AE4"><b>3.2.3 |
|
349 Assigning capabilities to a process</b> </p> <p>The association of a run-time |
|
350 capability with a process requires a modification to Symbian executable loader |
|
351 behaviour. The loader must transform the static capability settings associated |
|
352 with individual executables into a run-time capability that the kernel can |
|
353 use to police IPC and user/kernel interface. There are two fundamental rules |
|
354 that govern the way the loader must work. They seem simple in their description |
|
355 but have far-reaching security consequences as they bring to light the trust |
|
356 relationship between DLLs and EXEs. </p> <ol id="GUID-8770138F-B858-570C-98F0-8CAF365AA656"> |
|
357 <li id="GUID-D41EEC0F-FFBC-57BA-91C7-72312512AC6A"><p> <b> The capabilities |
|
358 of a process never change.</b> There is no way of adding capabilities to |
|
359 a process, nor of removing capabilities from a process. All DLL code runs |
|
360 at the capability level of the process that loads it. </p> </li> |
|
361 <li id="GUID-732F0118-3C18-50A0-9D57-A7136F39B0CE"><p> <b> A process cannot |
|
362 load a DLL with less capability than itself.</b> The need for this constraint |
|
363 follows from the fact that all DLL code runs at the capability level of the |
|
364 loading process and therefore must be at least as trusted at the loading process. |
|
365 DLL capabilities only reflect the level of trust that the loading process |
|
366 can place in them; they don’t actually authorise anything. </p> </li> |
|
367 </ol> <p>What this implies is that it is the EXE that ultimately holds the |
|
368 responsibility for what happens within the process which is created from it. |
|
369 The capabilities allocating to the EXE grant a level of authorisation to the |
|
370 process to perform its roles and responsibilities. As part of its execution, |
|
371 it may use shared library code. It must not be allowed to use library code |
|
372 that is less trusted than it itself is. This is expressed, in terms of capabilities, |
|
373 in rule 2. However, regardless of what library code it uses, the process will |
|
374 never gain authorisation to perform actions beyond those originally entrusted |
|
375 to it: this is rule 1. The consequence of this is, the more capable a process, |
|
376 the more restrictions will be placed on the DLLs it may load; conversely an |
|
377 process with no capability is free to use any shared library on the system, |
|
378 at its own discretion. </p> <p id="GUID-3ED27AA2-9198-59B7-B776-BC43F5FA3119"><b>3.2.4 |
|
379 Capability Permission lifetime</b> </p> <p>There are two possible alternatives |
|
380 for interpretation of the presence of a user-exposed capability at capability-aware |
|
381 servers: </p> <p> <b>Blanket permission</b>: Capability is granted as a one |
|
382 off act. If the capability is not present when the process is created, the |
|
383 request fails. All access requiring system capability will be policed this |
|
384 way. For example, the file server will just fail any clients attempting to |
|
385 access functionality in the event that they don't possess this capability. |
|
386 The capability would persist as long as the application is installed or until |
|
387 revoked. Revocation mechanisms would be introduced in several steps as they |
|
388 may require extra public key infrastructure from licensees and network operators. </p> <ul> |
|
389 <li id="GUID-A56156C5-3B8C-5566-8F74-BAC190C849C9"><p> <b>Single action permission</b>: |
|
390 Capability is checked upon each sensitive API call to the server. This means |
|
391 that one each access to the sensitive API call, a security notifier is thrown |
|
392 asking the user if they wish to grant that action. The permission only lasts |
|
393 for the duration of the corresponding sensitive action. </p> </li> |
|
394 </ul> <p>The user perception of the kind of permission must not be confused |
|
395 with when a server will check a required capability. For instance, an application |
|
396 may be granted NetworkServices as blanket permission but the telephony server |
|
397 will check NetworkServices capability at each relevant call made by this application. |
|
398 But as the user will not be asked to make a decision (to grant or not to grant |
|
399 NetworkServices for this call), this security check is transparent to the |
|
400 user. </p> <p>The advantages of this design are: </p> <ul> |
|
401 <li id="GUID-76BB16EB-7469-515F-9F30-040AE2A91950"><p>To maintain the time |
|
402 of check as close as the time of use as possible (to avoid any TOCTOU flaws) </p> </li> |
|
403 <li id="GUID-567F2967-2988-5652-B4A2-9A9B8C2ED6B5"><p>To avoid the server |
|
404 storing capability-related information for a process. </p> </li> |
|
405 </ul> <p>The great majority of Symbian platform servers behave in blanket |
|
406 permission mode. The reason behind this design decision is the majority of |
|
407 Symbian platform servers provide low level services where the intent and the |
|
408 context of an application’s requests are to some degree unknown. Therefore |
|
409 it would be difficult to ask the user a question with enough understandable |
|
410 information to let her make a well-informed decision. </p> <p id="GUID-F90646D0-321E-5552-9942-BF7A985C46A1"><b>3.3 |
|
411 Process Identification</b> </p> <p>Symbian Platform Security model is essentially |
|
412 based on capability to reduce the need of identifying applications. It allows |
|
413 servers to control access to their APIs without knowing their requesters and |
|
414 therefore avoid the need of maintaining an access control list. However in |
|
415 some circumstances, it is necessary to identify an application uniquely (see |
|
416 data caging below) and even its source i.e. the vendor. To satisfy these needs |
|
417 the two following concepts have been introduced. </p> <p id="GUID-07FAE266-EB4B-5462-A2A7-6962D4CCED24"><b>3.3.1 |
|
418 Secure Identifier (SID)</b> </p> <p>Each executable contains a secure identifier. |
|
419 It is guaranteed to be locally unique (i.e. in the phone where it is installed) |
|
420 however there is a subset of restricted SIDs where a global uniqueness can |
|
421 be guaranteed. The restricted SID space will be explicitly reserved for signed |
|
422 applications and each SID from this range will be cross-referenced to Vendor |
|
423 ID to ensure that each individual SID is authorised to use that particular |
|
424 Vendor ID. </p> <p>The SID can be explicitly specified for a particular executable |
|
425 or the UID can be used instead. However those two identifiers are always different |
|
426 entities in the kernel implementation. It is proposed that SIDs will come |
|
427 from a specified range of UID values, and that Symbian will provide a new |
|
428 mechanism to allocate suitable values. </p> <p id="GUID-088EA3F8-5209-56F4-9B24-90BF819D10E3"><b>3.3.2 |
|
429 Vendor Identifier (VID)</b> </p> <p>Executables can contain a vendor identifier |
|
430 that allows unique identification of the source of the executable. It is expected |
|
431 that the VID will be used for genuine cases like restricting a tentative server |
|
432 API from a specific vendor to its applications. While there is a potential |
|
433 danger that this VID would be used for anti-competitive purposes only, we |
|
434 recognise that there are enough real cases where it would be useful, and that |
|
435 it would therefore be better for the platform to deliver a standard framework |
|
436 rather than risking developers to implement their own solutions. To prevent |
|
437 stealth of vendors’ identity, the software installer will reject the installation |
|
438 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 |
|
439 role</b> </p> <p>As for capabilities, the kernel is responsible for holding |
|
440 both the application and vendor identity for each process. When a process |
|
441 is created, these properties are read from the associated program, held in |
|
442 kernel’s memory and are guaranteed not to change during its lifetime. However, |
|
443 unlike capabilities, there is no rules model to be followed regarding shared |
|
444 library. Each process is free to load shared libraries with any value of Secure |
|
445 ID and Vendor ID, regardless of the identifier values in the EXE from which |
|
446 the process was created. For this reason, capabilities are the core of the |
|
447 security architecture; process identifiers are intended for use in tandem |
|
448 with, rather than as a replacement for, capabilities. </p> <p id="GUID-03558B99-2B98-579C-AD59-CF66BD98F69F"><b>3.4 |
|
449 Data Caging </b> </p> <p id="GUID-394AF3B0-FA51-5C99-8FBD-73A707AB177C"><b>3.4.1 |
|
450 Caging processes </b> </p> <p id="GUID-9C9307AE-4B3C-5CE8-B66C-FE3E40A2C1C4"><b>3.4.1.1 |
|
451 Location-based concept</b> </p> <p>Data caging involves separating code from |
|
452 data in the file system such that a simple trusted path is created on the |
|
453 platform. </p> <ul> |
|
454 <li id="GUID-C7AB7740-5EEA-5513-8FEC-6F96C7E52AB2"><p>A new <codeph>/sys</codeph> directory |
|
455 hierarchy is created, with all executable code residing in the <codeph>/sys/bin</codeph> subdirectory. |
|
456 The central idea is that by “caging” non-TCB processes into their own part |
|
457 of the file system, the <codeph>/sys </codeph> directory becomes hidden to |
|
458 them. The kernel and file server would check that a client process had Tcb |
|
459 or AllFiles capability before allowing any access to the <codeph>/sys</codeph> sub-tree. |
|
460 In addition, the loader would disallow any attempt to execute code residing |
|
461 elsewhere than <codeph>/sys/bin</codeph>. </p> </li> |
|
462 <li id="GUID-D710C501-9913-565A-9BD1-FCE531AA7BC5"><p>A new <codeph>/resource</codeph> directory |
|
463 is created, which is public, but read-only for non-TCB processes. The purpose |
|
464 is to allow read-only files to be publicly shared without compromising their |
|
465 integrity. </p> </li> |
|
466 <li id="GUID-4C6FB170-58EF-580B-B787-3E27DA422CAF"><p>All executable applications |
|
467 have got access to their own restricted area of the file system, which consists |
|
468 of the sub-tree below the secure directory <codeph>/private/<app_SID></codeph>, |
|
469 where SID is a Secure Identifier used to distinguish between the <codeph>/private</codeph> sub-directories. |
|
470 Applications can, for example, use their sub-tree to hold various private |
|
471 data files. </p> </li> |
|
472 </ul> <p>Directories not under <codeph>/sys</codeph> or <codeph>/private</codeph> or <codeph>/resource</codeph> are |
|
473 public and can be read from and written to by any program. This allows the |
|
474 use of standard file system hierarchies that may be available on removable |
|
475 media. In essence, data caging involves caging processes by default into their |
|
476 own small part of the file system. This means that there is default protection |
|
477 of per-application and per-server data from other processes. Without data |
|
478 caging, it would become necessary to introduce access control lists into the |
|
479 file system to prevent rogue apps bypassing the capability model and simply |
|
480 reading databases directly from files. In addition, the scheme affords further |
|
481 protection against the threat of malicious replacement of executables in <codeph>/sys/bin</codeph>. |
|
482 In that sense, data caging is a simpler and more robust. </p><table id="GUID-1F570514-0235-4164-9EE4-93C2748768F0"><title>Data |
|
483 caging – capabilities for data caging</title> |
|
484 <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"/> |
|
485 <tbody> |
|
486 <row> |
|
487 <entry/> |
|
488 <entry nameend="col3" namest="col2"><filepath>/resource</filepath></entry> |
|
489 <entry nameend="col5" namest="col4"><filepath>/sys</filepath></entry> |
|
490 <entry nameend="col7" namest="col6"><filepath>/private/ownSID</filepath></entry> |
|
491 <entry nameend="col9" namest="col8"><filepath>/private/anyOther</filepath></entry> |
|
492 <entry nameend="col11" namest="col10"><filepath>/anyOther</filepath></entry> |
|
493 </row> |
|
494 <row> |
|
495 <entry>Capabilities </entry> |
|
496 <entry>Read</entry> |
|
497 <entry>Write</entry> |
|
498 <entry>Read</entry> |
|
499 <entry>Write</entry> |
|
500 <entry>Read</entry> |
|
501 <entry>Write</entry> |
|
502 <entry>Read</entry> |
|
503 <entry>Write</entry> |
|
504 <entry>Read</entry> |
|
505 <entry>Write</entry> |
|
506 </row> |
|
507 <row> |
|
508 <entry>None</entry> |
|
509 <entry>Yes</entry> |
|
510 <entry>No</entry> |
|
511 <entry>No</entry> |
|
512 <entry>No</entry> |
|
513 <entry>Yes</entry> |
|
514 <entry>Yes</entry> |
|
515 <entry>No</entry> |
|
516 <entry>No</entry> |
|
517 <entry>Yes</entry> |
|
518 <entry>Yes</entry> |
|
519 </row> |
|
520 <row> |
|
521 <entry>AllFiles</entry> |
|
522 <entry>Yes</entry> |
|
523 <entry>No</entry> |
|
524 <entry>Yes</entry> |
|
525 <entry>No</entry> |
|
526 <entry>Yes</entry> |
|
527 <entry>Yes</entry> |
|
528 <entry>Yes</entry> |
|
529 <entry>Yes</entry> |
|
530 <entry>Yes</entry> |
|
531 <entry>Yes</entry> |
|
532 </row> |
|
533 <row> |
|
534 <entry>TCB</entry> |
|
535 <entry>Yes</entry> |
|
536 <entry>Yes</entry> |
|
537 <entry>No</entry> |
|
538 <entry>Yes</entry> |
|
539 <entry>Yes</entry> |
|
540 <entry>Yes</entry> |
|
541 <entry>No</entry> |
|
542 <entry>No</entry> |
|
543 <entry>Yes</entry> |
|
544 <entry>Yes</entry> |
|
545 </row> |
|
546 <row> |
|
547 <entry>AllFiles+TCB</entry> |
|
548 <entry>Yes</entry> |
|
549 <entry>Yes</entry> |
|
550 <entry>Yes</entry> |
|
551 <entry>Yes</entry> |
|
552 <entry>Yes</entry> |
|
553 <entry>Yes</entry> |
|
554 <entry>Yes</entry> |
|
555 <entry>Yes</entry> |
|
556 <entry>Yes</entry> |
|
557 <entry>Yes</entry> |
|
558 </row> |
|
559 </tbody> |
|
560 </tgroup> |
|
561 </table> <p>Note that data caging is not a huge conceptual leap from the previous |
|
562 version of the Symbian platform. Historically only the kernel had an unrestricted |
|
563 view of the real machine running the Symbian platform. Each Symbian platform |
|
564 process had its own view of the processor’s address space that was independent |
|
565 of all other processes. This was arranged and policed by the kernel and MMU |
|
566 hardware. </p> <p>For simplicity it has been decided that the filing system |
|
567 is not aware of the meaning of “private user data”. A file cannot be flagged |
|
568 as so. It is the responsibility of each process dealing with user data to |
|
569 manage ReadUserData and WriteUserData capabilities. Furthermore in case of |
|
570 databases, the file itself can contain user private and public data and therefore |
|
571 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 |
|
572 Import directory concept</b> </p> <p>Many Symbian frameworks support the concept |
|
573 of plug-ins: they allow new code to contribute to existing native frameworks. |
|
574 Application recognisers are a good example of such plug-ins. In order to be |
|
575 identified as valid plug-ins they often provide a resource file that must |
|
576 be read by process users. When the process user is unique, it makes to place |
|
577 this resource file under its private directory. However, following the rules |
|
578 previously stated that should be impossible. To conciliate both points of |
|
579 view without compromising security, the rules described below have been defined: </p> <ul> |
|
580 <li id="GUID-B457A88B-AABA-5F44-B054-A9C2873D3693"><p>If an import directory |
|
581 exists immediately under the private path of a process, Software Install is |
|
582 allowed to put files in it from any installation package file. </p> </li> |
|
583 <li id="GUID-9A510686-D67A-5B1C-8FC7-F47FE9D64D38"><p>If there is no import |
|
584 directory immediately under the private path of a process, Software Install |
|
585 rejects the installation of any file not extracted from this process installation |
|
586 package. </p> </li> |
|
587 <li id="GUID-3E197C12-3108-50CF-95EA-28E70C95F51A"><p>A process having an |
|
588 import directory under its private directory accepts that these files might |
|
589 be malevolent and are not part of its own installation package. The correct |
|
590 level of trust that can be given to those files is process dependent. </p> </li> |
|
591 <li id="GUID-2DAF2C55-178F-573F-860E-CFD7C6149A1A"><p>The creation of an import |
|
592 directory is under the responsibility of the process developer. </p> </li> |
|
593 </ul> <p id="GUID-C79F6795-744F-5ED0-8F3F-5720FF1BE229"><b>3.4.1.3 Sharing |
|
594 files and data</b> </p> <p>To help share data across processes, current operating |
|
595 system features have been enhanced and new ones have been implemented. File |
|
596 handles and memory chunks can be shared between processes. These methods can |
|
597 be used to get temporary access to a specific file or memory area that is |
|
598 otherwise private. The recipient of the shared handle will only be able to |
|
599 use the file in the mode chosen by the file opener. Also a highly efficient |
|
600 public & subscribe service has been implemented to enable secure asynchronous, |
|
601 fast distribution of data. </p> <p id="GUID-93AD2587-56D2-5553-84D4-C98FC6BA951C"><b>3.4.2 |
|
602 Removable media</b> </p> <p>Executables installed by the device on removable |
|
603 media will be hashed. This hash as well as the executable’s capability set |
|
604 are securely stored on the device. At load time, the loader verifies the hash |
|
605 before accepting to perform the operation. If the verification fails, the |
|
606 executable will not be loaded. If the executable is unknown (no associated |
|
607 hash), the executable is loaded without any capability and its SID and VID |
|
608 are assigned to unknown. </p> <p>Although it is out of the scope of Symbian |
|
609 Secure Architecture, some hardware features can increase the level of security |
|
610 of removable media when off the device. For instance, a password-protected |
|
611 card will prevent a desktop rogue application to get or modify information |
|
612 stored on card without the consent of the user. </p> <p>As a result Symbian |
|
613 Secure Architecture does not guarantee integrity and confidentiality of files |
|
614 stored under ‘/private’ and /resource when off the device. Each program should |
|
615 decide what integrity checks are appropriate and what level of confidentiality |
|
616 they may provide. </p> <p id="GUID-6478908A-06BB-5FF6-BBFA-4ECE3B815A8A"><b>3.5 |
|
617 SWInstall – Enhancing perimeter security</b> </p> <p>The software installer |
|
618 has been changed substantially to support the process capability model and |
|
619 data caging. In addition, SWInstall now conforms to an appropriate Public |
|
620 Key Infrastructure. As different manufacturers and network operators may have |
|
621 different security policy, SWInstall has been redesigned to support a number |
|
622 of different security policies. </p> <p id="GUID-6F7D320F-97C3-5792-9D48-B960489A0A2B"><b>3.5.1 |
|
623 Software validation</b> </p> <p>A SIS file may contain zero or more signatures, |
|
624 and the set of capabilities that it needs. The software installer verifies |
|
625 each signature and constructs a certificate chain back to a trusted root. |
|
626 A configuration setting controls whether the software installer will check |
|
627 the revocation status of the certificate using OCSP. In addition, it is possible |
|
628 to mark SW Install root certificates as 'mandatory' certificates. If a mandatory |
|
629 certificate exists, then all installable packages must be signed with it, |
|
630 or installation fails. This enables the holder of the associated key to hold |
|
631 a 'veto' over what software may be installed. </p> <p id="GUID-5C6114AC-F485-5720-BB97-9AEAA8F04E75"><b>3.5.2 |
|
632 Capability calculation</b> </p> <p>Each SW Install root certificate is associated |
|
633 with a set of the capabilities that it is allowed to grant, called ‘meta-capabilities’. |
|
634 The installer calculates the largest set of capabilities that the installable |
|
635 may be granted as the union of the meta-capabilities associated with all successfully |
|
636 validated signatures. </p> <p>A configuration setting determines which additional |
|
637 capabilities the user is allowed to grant if the set of permitted capabilities |
|
638 is less than the capabilities requested in the SIS file.The installer will |
|
639 never install software with less than its requested set of capabilities: it |
|
640 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 |
|
641 product build time, all configuration settings may be freely determined. In |
|
642 the field configuration settings may be altered to a more limited degree. |
|
643 For instance, the device manufacturer may decide or not to let the user the |
|
644 freedom to grant some capabilities at install time. It should be noted that |
|
645 a key feature of the scheme is that install packages don’t necessarily have |
|
646 to be signed in order to be installed and granted capabilities. This is something |
|
647 that OEMs may not want to permit but at least we provide the option should |
|
648 the system integrator (manufacturer or potentially network operator) want |
|
649 to permit such an installation option. This might be an attractive option |
|
650 for developers wishing to avoid the hassle of code signing. </p> <p id="GUID-F63BC928-31A0-5FD1-B846-48B678F06BFE"><b>3.5.4 |
|
651 Installation in place or dual phase installation</b> </p> <p>Symbian installation |
|
652 package files include a <i>SISSignedController</i> element which contains |
|
653 the information needed to install the files, together with a separate hash |
|
654 for each of the installable files. This is signed, and this signature is verified |
|
655 at installation time against one of the root certificates always present on |
|
656 the device. The integrity of the SISSignedController, and, by extension, of |
|
657 the hashes of the files in the archive, is therefore guaranteed by its signature, |
|
658 and Software Install keeps the SISSignedController for each installation on |
|
659 the device. For secure installation of executables provided on removable media, |
|
660 where the executables don’t need to be installed, the SISSignedController |
|
661 part of the installation can be provided on the card by itself, enabling Software |
|
662 Install’s standard authentication and other security measure to proceed as |
|
663 normal. </p> <p id="GUID-9527DAD1-61F3-56FA-AA64-0E58FB187495"><b>3.6 Secure |
|
664 backup and restore </b> </p> <p>Symbian is primarily concerned with the integrity |
|
665 of the backup, not with the confidentiality of any data that might be stored |
|
666 within it. Confidentiality of data, both during the transfer to the host computer |
|
667 and also on the host once backed-up, is out of the scope of the Symbian Security |
|
668 Architecture described in this document. </p> <p>The security architecture |
|
669 needs to consider three different types of files in the context of backup |
|
670 and restore. </p> <ol id="GUID-EB24EA75-D1CC-5792-8EEB-0F12AA327006"> |
|
671 <li id="GUID-DC0AAA67-0969-5AA0-8DCF-0822DD6FF33E"><p> <i>Public files</i> are |
|
672 those stored in public directories. They can’t pose any threats to the integrity |
|
673 of the platform, and no special security measures need to be taken from the |
|
674 point of view of Platform Security when they are backed up and restored. They |
|
675 can be backed up using the traditional method of backup, known as <i>passive |
|
676 backup</i>. This requires no extra code on the part of the Symbian platform |
|
677 or on the part of any applications that might create or own public files. </p> </li> |
|
678 <li id="GUID-DC14C663-D4A9-58EA-B0A6-0E14CFB732F9"><p> <i>Private files</i> are |
|
679 those belonging to particular applications which store them in the <codeph>/private/</codeph> file |
|
680 hierarchy. The Symbian platform itself can’t know what these files are or |
|
681 what their sensitivity level might be, so the backup and restore policy regarding |
|
682 them is left under the control of each individual owning application. Applications |
|
683 can either specify in their resource files which private directories or files |
|
684 that they want copied via passive backup. Alternatively, they may make use |
|
685 of the <i>active backup</i> facilities provided by the secure platform. This |
|
686 enables those applications that wish to take advantage of them to backup and |
|
687 restore their private files securely, and are discussed in section 3.6.1 below. </p> </li> |
|
688 <li id="GUID-6B7B6670-9F95-5DA1-8945-BF79052A3509"><p> <i>Executable binaries</i> are |
|
689 those stored in the <codeph>/sys/bin/</codeph> directory. Were these to be |
|
690 restored from a backup in the same way as a simple restore of public files, |
|
691 this would represent a significant threat to the security of the device as |
|
692 Software Install would be fully bypassed and there would be no way of guaranteeing |
|
693 that executables had not been interfered with while they were stored off the |
|
694 secure device. The solution to this problem, discussed further in section |
|
695 3.6.2 below, is to use Software Install’s own mechanisms to back up executables |
|
696 and ensure their integrity on restore. </p> </li> |
|
697 </ol> <p id="GUID-6BADA2AA-519B-5A79-A2FA-EC9B6648BD1F"><b>3.6.1 Active Backup |
|
698 and Restore for Private Data</b> </p> <p>A process that owns private data |
|
699 and wants to use active backup and restore has to be able to provide all of |
|
700 the data that they wish to backup, and has to be able to receive the data |
|
701 for restore. In order to minimise the code and maintenance overheads, a standard |
|
702 set of reference functions will be provided in the OS that externalise from |
|
703 a directory tree and internalise to a directory tree. A process using active |
|
704 backup should use these functions to externalise its data on a stream for |
|
705 backup and signal when it has finished. For restoration it will internalise |
|
706 from a similar stream. The functions provided should be adequate for most |
|
707 data owning processes. Any processes which want more selective access will |
|
708 have to implement their own functions. </p> <p id="GUID-D122D4DC-0D32-5252-9B67-B3D66F3737D8"><b>3.6.2 |
|
709 Backup and Restore of Executables via Software Install</b> </p> <p>As described |
|
710 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 |
|
711 installation package file includes a <i>SISSignedController</i> with all the |
|
712 information needed to install the files in the SIS archive and the integrity |
|
713 of the SISSignedController is guaranteed by its signature. Since the only |
|
714 way to install something in <codeph>\sys\bin</codeph> is via Software Install, |
|
715 the stored SISSignedController elements can therefore be used during a backup |
|
716 operation to recreate versions of the SIS files originally used to install |
|
717 every executables present in <codeph>\sys\bin</codeph>. During the corresponding |
|
718 restore operation, the SISSignedController can once again be used to verify |
|
719 the integrity of the executable being restored and the validity of its digital |
|
720 signature against one of the root certificates always present on the device. </p> </section> |
|
721 <section id="GUID-830F2821-5614-5083-868C-0D6CEF6D4B0D"><title>4 Additional |
|
722 information</title> <p id="GUID-CAC87EF9-34AB-5B4B-BF5C-35D96730C12E"><b>4.1 |
|
723 References</b> </p> <p>[1] High Level Requirements for Release 7.0 of the |
|
724 Symbian Platform v0.04, Mark Wilce, Symbian, March 2001. </p> <p>[2] “Creating |
|
725 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 |
|
726 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] |
|
727 The -Inevitability of Failure: The Flawed Assumption of Security in Modern |
|
728 Computing Environments, Loscocco et al, National Security Agency, October |
|
729 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] |
|
730 Security Analysis of the Palm Operating System and its Weaknesses Against |
|
731 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 |
|
732 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"> |
|
733 <tgroup cols="2"><colspec colname="col0"/><colspec colname="col1"/> |
|
734 <thead> |
|
735 <row> |
|
736 <entry>Term</entry> |
|
737 <entry>Meaning</entry> |
|
738 </row> |
|
739 </thead> |
|
740 <tbody> |
|
741 <row> |
|
742 <entry><p>API </p> </entry> |
|
743 <entry><p>Application Programming Interface </p> </entry> |
|
744 </row> |
|
745 <row> |
|
746 <entry><p>CA </p> </entry> |
|
747 <entry><p>Certificate Authority </p> </entry> |
|
748 </row> |
|
749 <row> |
|
750 <entry><p>DLL </p> </entry> |
|
751 <entry><p>Dynamic Link Library </p> </entry> |
|
752 </row> |
|
753 <row> |
|
754 <entry><p>executable </p> </entry> |
|
755 <entry><p>A file containing native code: libraries (DLL) and programs (EXE) </p> </entry> |
|
756 </row> |
|
757 <row> |
|
758 <entry><p>F32 </p> </entry> |
|
759 <entry><p>The Symbian Platform File Server </p> </entry> |
|
760 </row> |
|
761 <row> |
|
762 <entry><p>IPC </p> </entry> |
|
763 <entry><p>Inter Process Communication </p> </entry> |
|
764 </row> |
|
765 <row> |
|
766 <entry><p>OEM </p> </entry> |
|
767 <entry><p>Original Equipment Manufacturer </p> </entry> |
|
768 </row> |
|
769 <row> |
|
770 <entry><p>PKI </p> </entry> |
|
771 <entry><p>Public Key Infrastructure </p> </entry> |
|
772 </row> |
|
773 <row> |
|
774 <entry><p>SWInstall </p> </entry> |
|
775 <entry><p>Software Install – provides service of native application installation. </p> </entry> |
|
776 </row> |
|
777 <row> |
|
778 <entry><p>UI </p> </entry> |
|
779 <entry><p>User Interface </p> </entry> |
|
780 </row> |
|
781 <row> |
|
782 <entry><p>UID </p> </entry> |
|
783 <entry><p>Unique Identifier. In the Symbian platform this is a 32-bit word |
|
784 which is used to uniquely identify an object or its type. </p> </entry> |
|
785 </row> |
|
786 </tbody> |
|
787 </tgroup> |
|
788 </table> </section> |
|
789 </conbody></concept> |