Server applications have been introduced to the Symbian platform since v9.0 for Platform Security. Principally, they offer a more secure solution to embedded applications.
A server application is an application that contains a server to which other applications can connect. Importantly, the server application runs in a separate process than that of the client (e.g. another application) that launched it. This lets each party protect their own memory and storage/disk space and have flexible security policies (which is in contrast to interactions between DLL-based applications that allow complete access to the memory and disk space of their hosts). The server application system permits applications to establish powerful inter-process communications links. This allows applications and other UI components to observe the principle of least privilege by only requiring capabilities necessary to do their job, and not the capabilities of applications that use them or of components that are used by them. It also allows for better compartmentalisation of data, by restricting access to data caged files to a client/sever interface. Correct use of the server application system can improve the security, stability, robustness, usability and functionality of a platform.
A client can launch one or many server applications; server applications can have multiple clients, though they have a one-to-one relationship when they're running.
Clients and server applications interact through common services, which adhere to a protocol defining the communication channel between the two. This inter-process communication channel also provides a security checkpoint for application capability checking, etc..
Services offer useful functionality to clients, for example, applications often use other applications to send messages, view, edit and create files, these can be considered services, which may be implemented in a number of ways (e.g. a printing service). The client asks the server (via the application containing it) to perform such tasks.
Server applications and clients can each have one or many services. Each service type is identified by a UID, see the Registration and discovery section below.
The Symbian Platform Security system uses capabilities to police who is allowed to do what in the system.
Processes are assigned capabilities in their executables at build time. These capabilities indicate the things that the process is allowed to do, for example, ReadUserData (see TCapability::ECapabilityReadUserData).
Servers can check that their clients have particular capabilities before they carry out client requests. For example, a contacts server may check that a client process has the ReadUserData capability.
DLLs may also be assigned capabilities. This means that the DLL is trusted to be used in a process which has these capabilities. You cannot load a DLL into a process when the process has capabilities that the DLL does not have. DLLs cannot add capabilities to processes, a DLL having a capability does not mean that the DLL can use that capability. The capabilities that a DLL can use depend on the process that it is executing in.
Before the introduction of platform security, application and other UI component interaction was achieved with the following techniques. Embedding allowed one application to use another inside its process. View switching allowed one application to control which views are displayed by another. DLLs allowed static functionality to be added to an application. Plug-in DLLs allowed dynamic addition of functionality to an application.
These techniques are all still available, to some extent, in the application frameworks with platform security. However, those that rely on DLLs for UI component interaction are now limited, by the capability rules described above. To achieve fully flexible relationships between UI components a client/server or other cross process link between components is now required.
For example, consider a server that allows clients to send an SMS message. Clearly this will require its clients to have a network capability. However, it is reasonable for a platform to want the user to decide when SMS messages are sent, no matter which application (with or without capabilities) wants to send them. Therefore, the platform will want to supply a UI component that has the ability to send SMS messages on behalf of other applications, asking the user for confirmation. If such a component were supplied as a DLL, it would have to run in the client applications process and run with the capabilities of that process. This may prevent it from being able to send SMS messages if the client application does not already have that capability. If, however, the component is supplied as a separate application running in its own process with a client/server interface allowing other applications to use it, then it can always ask the user and always send messages, no matter which application originates the request. Note that such cases where the user is allowed to permit actions without capabilities are only valid for "user capabilities".
The Symbian Platform Security system allows processes to have private files, which are only accessible by that process. Any code that is executing within a process, including code loaded in DLLs, can access the files in the process's data cage. Code that is executing in other processes cannot access the files in the data cage, except where the owning process explicitly supports it. A process can allow other processes access to individual files in its data cage by file handle sharing, or by providing an API which encapsulates access to data caged files. Such access to data caged files and data must be granted with care according to the sensitivity of the data.
Consider a memo-pad application that stores a user's memos as files in its data cage. This application wants to be able to send memos in messages, so it links to a "send-as" library. If this send-as library loads the message transports as DLLs in the memo-pad application's process, an evil message transport DLL could access all the memo files, deleting, copying or altering them. If however the send-as library uses IPC connections to the message transports, the memo pad application controls exactly how much these message transports can access, limiting the amount of damage that an evil message transport can do. Similarly, the memo-pad application may offer an API to allow other processes to access the memos. Since the memos are considered to be user data, the access should be limited to processes with ReadUserData capability.
Copyright ©2010 Nokia Corporation and/or its subsidiary(-ies).
All rights
reserved. Unless otherwise stated, these materials are provided under the terms of the Eclipse Public License
v1.0.