Description

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.

Services

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.

Capabilities

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".

Data caging

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.

See also

Application -Architecture Overview

+ + + + + +Description +

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.

Services

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.

Capabilities

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".

Data caging

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.