ECom and the Platform Security Architecture

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:

  • The platform security capability model, which protects processes from loading and using DLLs that are less secure than the process itself.

  • Control over software installation, so that insecure software cannot disrupt legitimately installed software.

  • Control over which processes have access to particular files.

For more information on the Platform Security Architecture, see Symbian OS v9 Security Architecture in the Platform security section.

ECom and the platform security capability model

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.

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 How to troubleshoot plug-in loading errors for details of how to investigate this error.

Providers of plug-in DLLs must consider the following with respect to platform security capabilities:

  • If you give a plug-in DLL no capabilities, it can only be used by client processes that also have no capabilities.

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

  • If you want a plug-in to be usable by any program (apart from the kernel and the file server), then the capability setting All -Tcb 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 Symbian Signed for details.

  • Custom resolver 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 ProtServ capability. See How to provide a custom resolver for more details on writing resolvers.

Platform security also allows you to specify that clients should only use plug-in implementations supplied by a particular company. See How to filter implementations by vendor ID for more details.

Installation and upgrade controls

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.

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.

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 Using the ROM-only resolver.

Providers of ROM-based plug-ins should see How to upgrade ROM-based plug-ins securely.

File locations

The Platform Security architecture tightly controls access to executable code by:
  • requiring that all such code, including plug-in DLLs, is located under a directory \sys\bin

  • restricting access to that directory to a small number of key system processes.

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 \resource\plugins.

To build plug-in code to these locations, set the target type in the project file to PLUGIN. For more information, see the Creating an Implementation Project File section.