|
|
|
Platform Security is completely new to UIQ developers as the UIQ 3 release is based on Symbian OS v9. For details on Symbian OS Platform Security see the section on Platform Security in the Symbian Developer library.
Each application (.exe) or application extension (.dll) using sensitive system resources needs to be assigned a set of capabilities granting access to these resources.
The capabilities are assigned to the program binaries but are enforced on and checked for the process instantiated from the binary executable. Some principles of the Symbian OS security architecture are:
Every process has a set of capabilities,
The capabilities of a process never change,
A process cannot load a DLL with a smaller set of capabilities than the process itself.
Capabilities are built into the executable by specifying the CAPABILITY keyword in the project MMP file as described in the Application Building section.
Some capabilities can be granted by the user at application install time or when a system service is requested by the application. Capabilities can also be granted when the application has passed Symbian Signed testing and has been digitally signed. Note that not all capabilities can be granted by the user. Some capabilities require approval from Symbian Signed.
Capabilities are grouped into two main categories:
User capabilities: Covers protection of resources that can easily be understood by a phone owner and thus granted by the user at application installation time,
System capabilities: Not presented to the user because the implication is not easily understood by the typical mobile phone user. Requires applications to be signed by Symbian Signed, see below.
For more information on capabilities see the "Platform Security Engineering guide" in the Developer Library.
Application data has been separated from application code to provide a simple, trusted path on the platform. An application's stored data can be hidden from other applications.
The file system has the following structure:
\sys : This is the restricted system area which is only accessible for highly trusted system processes,
\sys\bin : Holds all executables such as EXEs, DLLs and plug-ins. The OS will not run code placed in other locations,
\private : Each application has its own private view of the file system consisting of \private\
\resource : A public read-only directory to allow files to be publicly shared without compromising integrity. An application should, for example, put its UI resource files and icon files in \resource\apps.
Other directories are public and can be read from or written to by any program.
An application installation package can install files in, or below, another application's \private\<SID>\import directory if such a directory exists.
This mechanism is used, for example, when installing the registration resource files into the private path of the apparc server process, as in the example of the .pkg file.
With the introduction of Platform Security an application needs to be verified and signed before it is granted access to some of the capabilities it requires. The Symbian Signed scheme, run by Symbian, is the process of getting an application tested and signed.
For more information on Symbian Signed, see the website http://www.symbiansigned.com.
New for Symbian OS v9.1 is that signing SIS files is mandatory for applications to be able to run on Symbian OS phones, and thereby on UIQ 3 phones. Read more about this in Symbian OS Tools and Utilities Installation guide.
This change is reflected in the emulator that is provided with the UIQ 3 SDK. By default, only signed SIS files can be installed on the emulator. In order for developers to test applications on the emulator the SIS file must be signed by using the SignSIS tool.
As a service to developers, the UIQ 3 SDK includes three sets of
certificates and keys to use when preparing applications for testing on the
emulator. The certification files are located at \epoc32\tools\cert.
IMPORTANT: These certificates will only work on the emulator. For applications to run on a phone, these certificates must NOT be used. Instead, the SIS file must be signed by Symbian.
Which certificate to use depends on the whether the application UID is in the protected range and whether system capabilities are required. One way of finding out which certificate you need is to test them one at a time in the following order:
First try NoCaps.cert and NoCaps.key.
These files just provide a dummy certificate to sign SIS files that only have user
capabilities or no capabilities at all.
This certificate is used just because only signed SIS files can be installed.
Second try AllUserCaps.cert and AllUserCaps.key.
These files block the "Grant capabilities" dialog when one or more user certificates are
defined in binaries that are included in the SIS file.
Third try AllCaps.cert and AllCaps.key.
These files are used to install SIS files that include binaries with system capabilities.