Symbian3/SDK/Source/GUID-9E4D75C0-D797-5541-8E52-3C6D154CC74A.dita
changeset 0 89d6a7a84779
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/Symbian3/SDK/Source/GUID-9E4D75C0-D797-5541-8E52-3C6D154CC74A.dita	Thu Jan 21 18:18:20 2010 +0000
@@ -0,0 +1,87 @@
+<?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-9E4D75C0-D797-5541-8E52-3C6D154CC74A" xml:lang="en"><title>ECom
+and the Platform Security Architecture</title><prolog><metadata><keywords/></metadata></prolog><conbody>
+<p>The Symbian Platform Security Architecture is designed to provide defences
+against malicious or badly implemented code. The following aspects of platform
+security are particularly relevant to the ECom plug-in architecture: </p>
+<ul>
+<li id="GUID-299B3BF1-9A55-5CCC-AA77-49F4EBE07ABD"><p>The <i>platform security
+capability model</i>, which protects processes from loading and using DLLs
+that are less secure than the process itself. </p> </li>
+<li id="GUID-92E6F90B-EFE0-5026-AA61-1C068376C21C"><p>Control over software
+installation, so that insecure software cannot disrupt legitimately installed
+software. </p> </li>
+<li id="GUID-2DE8CE05-57EE-582F-80F8-BAEB82B38FAB"><p>Control over which processes
+have access to particular files. </p> </li>
+</ul>
+<p>For more information on the Platform Security Architecture, see <i>Symbian
+OS v9 Security Architecture</i> in the <xref href="GUID-9E4D75C0-D797-5541-8E52-3C6D154CC74A.dita">Platform
+security</xref> section. </p>
+<section><title>ECom and the platform security capability model</title> <p>The
+Platform Security Architecture protects processes against loading and using
+DLLs that are less secure than the processes themselves. This is done using
+platform security capabilities assigned to the process and the DLL. The rule
+applied is that the DLL must have the same or greater capabilities than the
+process in which it is loaded. </p> <p>With ECom, a plug-in is a DLL that
+is loaded into a client process when an interface implementation provided
+by that DLL is instantiated. If the plug-in DLL has lower capabilities than
+the loading process, then a "permission denied" (-46) error is returned. See <xref href="GUID-8A7B837D-4069-5364-A596-686EEBAE351D.dita">How to troubleshoot plug-in
+loading errors</xref> for details of how to investigate this error. </p> <p>Providers
+of plug-in DLLs must consider the following with respect to platform security
+capabilities: </p> <ul>
+<li id="GUID-FB693866-59D7-56DD-9FF4-07AB3CDDA9F7"><p>If you give a plug-in
+DLL no capabilities, it can only be used by client processes that also have
+no capabilities. </p> </li>
+<li id="GUID-8FA6F9BF-9631-5110-8121-219041C07C4A"><p>If you intend a plug-in
+to work only with one client program, such as a particular server, then the
+documentation for that program should tell you what capabilities it needs. </p> </li>
+<li id="GUID-494937B7-AF39-5222-A97E-5F7478A4EC9E"><p>If you want a plug-in
+to be usable by any program (apart from the kernel and the file server), then
+the capability setting <codeph>All -Tcb</codeph> may be what you require.
+Note, however, programs with such high platform security capabilities require
+signing and authorisation to be installed by users on phones. See <xref href="https://www.symbiansigned.com/" scope="external">Symbian Signed</xref> for details. </p> </li>
+<li id="GUID-B5CD618B-F202-553A-BB5F-F1DF9AF70B58"><p> <i> Custom resolver</i> plug-ins
+are a special case. They are loaded by a server process in ECom itself, and
+so must be trusted by that server. This requires that you give the plug-in
+the <codeph>ProtServ</codeph> capability. See <xref href="GUID-E10A3336-9C4C-59A5-B94F-6CECA92FFB9F.dita">How
+to provide a custom resolver</xref> for more details on writing resolvers. </p> </li>
+</ul> <p>Platform security also allows you to specify that clients should
+only use plug-in implementations supplied by a particular company. See <xref href="GUID-7F4692A0-1801-5D91-8F28-06075AC45DE2.dita">How to filter implementations
+by vendor ID</xref> for more details. </p> </section>
+<section><title>Installation and upgrade controls</title> <p>Under Platform
+Security, the Software Installer program controls what software is installed
+to the device. It enables programs originally delivered in ROM, including
+ECom plugins, to be upgraded securely. </p> <p>Before platform security, applications
+could chose to use only ROM-based plug-ins. This guaranteed that the plug-ins
+were secure, but did not allow upgrades. Alternatively, both ROM-based and
+installed plug-ins were used, which allowed upgrades, but also risked the
+use of possibly insecure plug-ins. </p> <p>Platform security improves this
+situation, as it allows clients to access securely both ROM-based plug-ins
+and any installed upgrades to those plug-ins. For more information for how
+clients can do this, see <xref href="GUID-08007041-CE18-5B1C-9AE6-042EBBFD1AB6.dita">Using
+the ROM-only resolver</xref>. </p> <p>Providers of ROM-based plug-ins should
+see <xref href="GUID-93F53961-9DA3-5D01-A881-D28E0EBF8B3C.dita">How to upgrade
+ROM-based plug-ins securely</xref>. </p> </section>
+<section><title>File locations</title><p>The Platform Security architecture
+tightly controls access to executable code by: <ul>
+<li><p>requiring that all such code, including plug-in DLLs, is located under
+a directory <filepath>\sys\bin</filepath></p></li>
+<li><p>restricting access to that directory to a small number of key system
+processes. </p></li>
+</ul></p><p>The registration resource file for a plug-in must be readable
+by ECom, but should not be alterable after installation. For this reason,
+registration resource files are always installed to the read-only directory <filepath>\resource\plugins</filepath>.</p><p>To
+build plug-in code to these locations, set the target type in the project
+file to <codeph>PLUGIN</codeph>. For more information, see the <xref href="GUID-641A276D-F618-50CE-BA5A-658DCC26BAB5.dita">Creating an Implementation
+Project File</xref> section.  </p> </section>
+</conbody></concept>
\ No newline at end of file