Symbian3/PDK/Source/GUID-9E4D75C0-D797-5541-8E52-3C6D154CC74A.dita
changeset 1 25a17d01db0c
child 3 46218c8b8afa
equal deleted inserted replaced
0:89d6a7a84779 1:25a17d01db0c
       
     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-9E4D75C0-D797-5541-8E52-3C6D154CC74A" xml:lang="en"><title>ECom
       
    13 and the Platform Security Architecture</title><prolog><metadata><keywords/></metadata></prolog><conbody>
       
    14 <p>The Symbian Platform Security Architecture is designed to provide defences
       
    15 against malicious or badly implemented code. The following aspects of platform
       
    16 security are particularly relevant to the ECom plug-in architecture: </p>
       
    17 <ul>
       
    18 <li id="GUID-299B3BF1-9A55-5CCC-AA77-49F4EBE07ABD"><p>The <i>platform security
       
    19 capability model</i>, which protects processes from loading and using DLLs
       
    20 that are less secure than the process itself. </p> </li>
       
    21 <li id="GUID-92E6F90B-EFE0-5026-AA61-1C068376C21C"><p>Control over software
       
    22 installation, so that insecure software cannot disrupt legitimately installed
       
    23 software. </p> </li>
       
    24 <li id="GUID-2DE8CE05-57EE-582F-80F8-BAEB82B38FAB"><p>Control over which processes
       
    25 have access to particular files. </p> </li>
       
    26 </ul>
       
    27 <p>For more information on the Platform Security Architecture, see <i>Symbian
       
    28 OS v9 Security Architecture</i> in the <xref href="GUID-9E4D75C0-D797-5541-8E52-3C6D154CC74A.dita">Platform
       
    29 security</xref> section. </p>
       
    30 <section><title>ECom and the platform security capability model</title> <p>The
       
    31 Platform Security Architecture protects processes against loading and using
       
    32 DLLs that are less secure than the processes themselves. This is done using
       
    33 platform security capabilities assigned to the process and the DLL. The rule
       
    34 applied is that the DLL must have the same or greater capabilities than the
       
    35 process in which it is loaded. </p> <p>With ECom, a plug-in is a DLL that
       
    36 is loaded into a client process when an interface implementation provided
       
    37 by that DLL is instantiated. If the plug-in DLL has lower capabilities than
       
    38 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
       
    39 loading errors</xref> for details of how to investigate this error. </p> <p>Providers
       
    40 of plug-in DLLs must consider the following with respect to platform security
       
    41 capabilities: </p> <ul>
       
    42 <li id="GUID-FB693866-59D7-56DD-9FF4-07AB3CDDA9F7"><p>If you give a plug-in
       
    43 DLL no capabilities, it can only be used by client processes that also have
       
    44 no capabilities. </p> </li>
       
    45 <li id="GUID-8FA6F9BF-9631-5110-8121-219041C07C4A"><p>If you intend a plug-in
       
    46 to work only with one client program, such as a particular server, then the
       
    47 documentation for that program should tell you what capabilities it needs. </p> </li>
       
    48 <li id="GUID-494937B7-AF39-5222-A97E-5F7478A4EC9E"><p>If you want a plug-in
       
    49 to be usable by any program (apart from the kernel and the file server), then
       
    50 the capability setting <codeph>All -Tcb</codeph> may be what you require.
       
    51 Note, however, programs with such high platform security capabilities require
       
    52 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>
       
    53 <li id="GUID-B5CD618B-F202-553A-BB5F-F1DF9AF70B58"><p> <i> Custom resolver</i> plug-ins
       
    54 are a special case. They are loaded by a server process in ECom itself, and
       
    55 so must be trusted by that server. This requires that you give the plug-in
       
    56 the <codeph>ProtServ</codeph> capability. See <xref href="GUID-E10A3336-9C4C-59A5-B94F-6CECA92FFB9F.dita">How
       
    57 to provide a custom resolver</xref> for more details on writing resolvers. </p> </li>
       
    58 </ul> <p>Platform security also allows you to specify that clients should
       
    59 only use plug-in implementations supplied by a particular company. See <xref href="GUID-7F4692A0-1801-5D91-8F28-06075AC45DE2.dita">How to filter implementations
       
    60 by vendor ID</xref> for more details. </p> </section>
       
    61 <section><title>Installation and upgrade controls</title> <p>Under Platform
       
    62 Security, the Software Installer program controls what software is installed
       
    63 to the device. It enables programs originally delivered in ROM, including
       
    64 ECom plugins, to be upgraded securely. </p> <p>Before platform security, applications
       
    65 could chose to use only ROM-based plug-ins. This guaranteed that the plug-ins
       
    66 were secure, but did not allow upgrades. Alternatively, both ROM-based and
       
    67 installed plug-ins were used, which allowed upgrades, but also risked the
       
    68 use of possibly insecure plug-ins. </p> <p>Platform security improves this
       
    69 situation, as it allows clients to access securely both ROM-based plug-ins
       
    70 and any installed upgrades to those plug-ins. For more information for how
       
    71 clients can do this, see <xref href="GUID-08007041-CE18-5B1C-9AE6-042EBBFD1AB6.dita">Using
       
    72 the ROM-only resolver</xref>. </p> <p>Providers of ROM-based plug-ins should
       
    73 see <xref href="GUID-93F53961-9DA3-5D01-A881-D28E0EBF8B3C.dita">How to upgrade
       
    74 ROM-based plug-ins securely</xref>. </p> </section>
       
    75 <section><title>File locations</title><p>The Platform Security architecture
       
    76 tightly controls access to executable code by: <ul>
       
    77 <li><p>requiring that all such code, including plug-in DLLs, is located under
       
    78 a directory <filepath>\sys\bin</filepath></p></li>
       
    79 <li><p>restricting access to that directory to a small number of key system
       
    80 processes. </p></li>
       
    81 </ul></p><p>The registration resource file for a plug-in must be readable
       
    82 by ECom, but should not be alterable after installation. For this reason,
       
    83 registration resource files are always installed to the read-only directory <filepath>\resource\plugins</filepath>.</p><p>To
       
    84 build plug-in code to these locations, set the target type in the project
       
    85 file to <codeph>PLUGIN</codeph>. For more information, see the <xref href="GUID-641A276D-F618-50CE-BA5A-658DCC26BAB5.dita">Creating an Implementation
       
    86 Project File</xref> section.  </p> </section>
       
    87 </conbody></concept>