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.

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

\ No newline at end of file