Symbian3/PDK/Source/GUID-F395C299-6C79-5A0E-8FCF-7931D8405E8A.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-F395C299-6C79-5A0E-8FCF-7931D8405E8A" xml:lang="en"><title>Description</title><prolog><metadata><keywords/></metadata></prolog><conbody>
       
    13 <p>Server applications have been introduced to Symbian platform since v9.0
       
    14 for <xref href="GUID-4BFEDD79-9502-526A-BA7B-97550A6F0601.dita">Platform Security</xref>.
       
    15 Principally, they offer a more secure solution to embedded applications. </p>
       
    16 <p>A server application is an application that contains a server to which
       
    17 other applications can connect. Importantly, the server application runs in
       
    18 a separate <xref href="GUID-E6F08B67-8DBC-5896-946D-BD0D27F82FE2.dita#GUID-E6F08B67-8DBC-5896-946D-BD0D27F82FE2/GUID-AC0E13F3-5DFE-5060-BE09-B76A08632B5E">process</xref> than
       
    19 that of the client (e.g. another application) that launched it. This lets
       
    20 each party protect their own memory and storage/disk space and have flexible
       
    21 security policies (which is in contrast to interactions between DLL-based
       
    22 applications that allow complete access to the memory and disk space of their
       
    23 hosts). The server application system permits applications to establish powerful
       
    24 inter-process communications links. This allows applications and other UI
       
    25 components to observe the principle of least privilege by only requiring <xref href="GUID-F395C299-6C79-5A0E-8FCF-7931D8405E8A.dita#GUID-F395C299-6C79-5A0E-8FCF-7931D8405E8A/GUID-049F04BC-546E-53F9-8212-C0DC6D5B94C2">capabilities</xref> necessary
       
    26 to do their job, and not the capabilities of applications that use them or
       
    27 of components that are used by them. It also allows for better compartmentalisation
       
    28 of data, by restricting access to <xref href="GUID-F395C299-6C79-5A0E-8FCF-7931D8405E8A.dita#GUID-F395C299-6C79-5A0E-8FCF-7931D8405E8A/GUID-8CACFFD5-51FF-5902-B4B5-2DBA506A3CD9">data
       
    29 caged files</xref> to a client/sever interface. Correct use of the server
       
    30 application system can improve the security, stability, robustness, usability
       
    31 and functionality of a platform. </p>
       
    32 <p>A client can launch one or many server applications; server applications
       
    33 can have multiple clients, though they have a one-to-one relationship when
       
    34 they're running. </p>
       
    35 <section id="GUID-A3712A05-A6A1-549F-98E6-5E9DEC37006C"><title>Services</title> <p>Clients
       
    36 and server applications interact through common services, which adhere to
       
    37 a protocol defining the communication channel between the two. This inter-process
       
    38 communication channel also provides a security checkpoint for application
       
    39 capability checking, etc.. </p> <p>Services offer useful functionality to
       
    40 clients, for example, applications often use other applications to send messages,
       
    41 view, edit and create files, these can be considered services, which may be
       
    42 implemented in a number of ways (e.g. a printing service). The client asks
       
    43 the server (via the application containing it) to perform such tasks. </p> <p>Server
       
    44 applications and clients can each have one or many services. Each service
       
    45 type is identified by a UID, see the <xref href="GUID-F7CC81CE-E823-5196-944A-5F7524411A08.dita">Registration
       
    46 and discovery</xref> section below. </p> </section>
       
    47 <section id="GUID-049F04BC-546E-53F9-8212-C0DC6D5B94C2"><title>Capabilities</title> <p>The
       
    48 Symbian <xref href="GUID-4BFEDD79-9502-526A-BA7B-97550A6F0601.dita">Platform Security</xref> system
       
    49 uses capabilities to police who is allowed to do what in the system. </p> <p>Processes
       
    50 are assigned capabilities in their executables at build time. These capabilities
       
    51 indicate the things that the process is allowed to do, for example, <codeph>ReadUserData</codeph> (see <codeph>TCapability::ECapabilityReadUserData</codeph>). </p> <p>Servers can check that their clients have particular capabilities
       
    52 before they carry out client requests. For example, a contacts server may
       
    53 check that a client process has the <codeph>ReadUserData</codeph> capability. </p> <p>DLLs
       
    54 may also be assigned capabilities. This means that the DLL is trusted to be
       
    55 used in a process which has these capabilities. You cannot load a DLL into
       
    56 a process when the process has capabilities that the DLL does not have. DLLs
       
    57 cannot add capabilities to processes, a DLL having a capability does not mean
       
    58 that the DLL can use that capability. The capabilities that a DLL can use
       
    59 depend on the process that it is executing in. </p> <p>Before the introduction
       
    60 of platform security, application and other UI component interaction was achieved
       
    61 with the following techniques. Embedding allowed one application to use another
       
    62 inside its process. View switching allowed one application to control which
       
    63 views are displayed by another. DLLs allowed static functionality to be added
       
    64 to an application. Plug-in DLLs allowed dynamic addition of functionality
       
    65 to an application. </p> <p>These techniques are all still available, to some
       
    66 extent, in the application frameworks with platform security. However, those
       
    67 that rely on DLLs for UI component interaction are now limited, by the capability
       
    68 rules described above. To achieve fully flexible relationships between UI
       
    69 components a client/server or other cross process link between components
       
    70 is now required. </p> <p>For example, consider a server that allows clients
       
    71 to send an SMS message. Clearly this will require its clients to have a network
       
    72 capability. However, it is reasonable for a platform to want the user to decide
       
    73 when SMS messages are sent, no matter which application (with or without capabilities)
       
    74 wants to send them. Therefore, the platform will want to supply a UI component
       
    75 that has the ability to send SMS messages on behalf of other applications,
       
    76 asking the user for confirmation. If such a component were supplied as a DLL,
       
    77 it would have to run in the client applications process and run with the capabilities
       
    78 of that process. This may prevent it from being able to send SMS messages
       
    79 if the client application does not already have that capability. If, however,
       
    80 the component is supplied as a separate application running in its own process
       
    81 with a client/server interface allowing other applications to use it, then
       
    82 it can always ask the user and always send messages, no matter which application
       
    83 originates the request. Note that such cases where the user is allowed to
       
    84 permit actions without capabilities are only valid for "user capabilities". </p> </section>
       
    85 <section id="GUID-8CACFFD5-51FF-5902-B4B5-2DBA506A3CD9"><title>Data caging</title> <p>The
       
    86 Symbian <xref href="GUID-4BFEDD79-9502-526A-BA7B-97550A6F0601.dita">Platform Security</xref> system
       
    87 allows processes to have private files, which are only accessible by that
       
    88 process. Any code that is executing within a process, including code loaded
       
    89 in DLLs, can access the files in the process's data cage. Code that is executing
       
    90 in other processes cannot access the files in the data cage, except where
       
    91 the owning process explicitly supports it. A process can allow other processes
       
    92 access to individual files in its data cage by file handle sharing, or by
       
    93 providing an API which encapsulates access to data caged files. Such access
       
    94 to data caged files and data must be granted with care according to the sensitivity
       
    95 of the data. </p> <p>Consider a memo-pad application that stores a user's
       
    96 memos as files in its data cage. This application wants to be able to send
       
    97 memos in messages, so it links to a "send-as" library. If this send-as library
       
    98 loads the message transports as DLLs in the memo-pad application's process,
       
    99 an evil message transport DLL could access all the memo files, deleting, copying
       
   100 or altering them. If however the send-as library uses IPC connections to the
       
   101 message transports, the memo pad application controls exactly how much these
       
   102 message transports can access, limiting the amount of damage that an evil
       
   103 message transport can do. Similarly, the memo-pad application may offer an
       
   104 API to allow other processes to access the memos. Since the memos are considered
       
   105 to be user data, the access should be limited to processes with <codeph>ReadUserData</codeph> capability. </p> </section>
       
   106 <section><title>See also</title><ul>
       
   107 <li><p><xref href="GUID-940F3F6E-BA9C-5E19-9AC5-D848B5E175FB.dita">Application
       
   108 Architecture Overview</xref></p></li>
       
   109 </ul></section>
       
   110 </conbody></concept>