Security in Symbian OS
This pages provides the platform with the ability to defend itself against malicious or badly implemented application.The key threats that the security architecture addresses are those that are linked with unauthorised access to user data and to system services. This security model does not address hardware threats. ROM image integrity and unauthorised RAM flashings can be implemented for hardware threat.
Major concept related to Symbian OS security model:
1. Trusted Computing Base
2. Trusted Computing Environment
3. Capability model
4. Process and vendor identification
5. Data caging
6. Software Install
7. Symbian Sign and Capability
1. Trusted Computing Base TCB Several most important software modules are part of the TCB, The kernel, file server, and the software installer — are part of the Trusted Computing Base. They have unrestricted access to the device resources. They are responsible for maintaining the integrity of the device, and applying the fundamental rules of platform security. The rest of the operating system must trust these software to behave correctly.
2. Trusted Computing Environment TCE The Trusted Computing Environment (TCE) is composed of major key Symbian OS components (for example window server) that protect the device's resources from misuse. In Symbian OS, server programs are used to control access to shared resources, so the TCE is made up of the important system servers.
3. Capability model A capability is an access token that corresponds to permission to access sensitive system resources. If a software has the token then it can access sensitive data. To access a system resource, a client program must hold the appropriate capability. If we want to access a particular service then we need to have certain capability. For example, if we want to use BlueTooth services then in our module should have LocalServices capability. The capability is specified in MMP file of Symbian C++ project and the build tools place these in the resulting binary. All types of executable code are assigned capabilities. When a process is created, the kernel reads the capabilities out of the header and associates those capabilities with the process for the remainder of its lifetime.
Here is a small example of particular mmp file.
TARGET ShapeListManager.dll
TARGETTYPE dll
UID 0x1000008d 0xA00001F6
VENDORID 0
SOURCEPATH ..\src
SOURCE Circle.cpp
USERINCLUDE ..\inc
SYSTEMINCLUDE \epoc32\include
LIBRARY euser.lib
LIBRARY estor.lib
CAPABILITY LocalServices
There are two important rules for capability:
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 itself.
The need for this constraint follows from the fact that all DLL code runs at the capability level of the loading process. Note that DLL capabilities are different to capabilities that are attached to executable processes in that they only reflect the level of trust that the loading process can place in them; they don’t actually authorise anything
For DLLs, capabilities are policed by the kernel's DLL loader. They are checked at load time only. Beyond that, all code contained in this DLL can be run freely.
The specific rules by which the loader enforces the constraints described above are as follows:
the DLL capability set must be greater than or equal to the capability set of the loading executable.
an executable can load a DLL with higher capabilities, but does not gain capabilities by doing so. These rules
Prevent malware from being loaded in sensitive processes, for example, a plug-in in a system server
Encourage encapsulation of sensitive code inside processes with no possible bypass The examples below show how capability rules are applied in the cases of statically and dynamically loaded DLLs respectively.
Examples for statically linked DLLs
The program P.EXE is statically linked to the library L1.DLL.
The library L1.DLL is statically linked to the library L0.DLL.
Case 1:
P.EXE holds Cap1 & Cap2
L1.DLL holds Cap1 & Cap2 & Cap3
L0.DLL holds Cap1 & Cap2.
The load fails because L1.DLL cannot load L0.DLL. Since L0.DLL does not have a capability set greater than or equal to L1.DLL, Rule 1 applies.
Case 2:
P.EXE holds Cap1 & Cap2
L1.DLL holds Cap1 & Cap2 & Cap3
L0.DLL holds Cap1 & Cap2 & Cap3 & Cap4
The load succeeds and the new process is assigned Cap1 & Cap2. The capability of the new process is determined by applying Rule 2; L1.DLL cannot acquire the Cap4 capability held by L0.DLL, and P1.EXE cannot acquire the Cap3 capability held by L1.DLL
Examples for dynamically loaded DLLs
The program P.EXE dynamically loads the library L1.DLL.
The library L1.DLL then dynamically loads the library L0.DLL.
Case 1:
P.EXE holds Cap1 & Cap2
L1.DLL holds Cap1 & Cap2 & Cap3
L0.DLL holds Cap1 & Cap2
The load succeeds because P.EXE can load L1.DLL and L0.DLL. Rule 1 does apply but here the loading executable is the process P.EXE not the library L1.DLL: the Rlibrary::Load request that the loader processes is sent by the process P.EXE. The fact that the call is within L1.DLL is here irrelevant. Rule 2 applies as before and P.EXE does not acquire Cap3 by loading L1.DLL
Case 2:
P.EXE holds Cap1 & Cap2
L1.DLL holds Cap1&Cap2&Cap3
L0.DLL holds Cap1&Cap2&Cap4
The load succeeds because P.EXE can load L1.DLL and L0.DLL. Once again, Rule 1 does apply with P.EXE as the loading executable rather L1.DLL, while Rule 2 ensures the P.EXE acquires neither Cap3 nor Cap4.
4. Process and vendor identification
Process and vendor identification can be performed in Symbian OS. It allows servers to control access to their APIs without knowing their requesters and therefore avoid the need of maintaining an access control list.
VendorId() of RProcess class can be used for this.
If an intended use of this method is to check that the Vendor ID is a given value, then the use of a TSecurityPolicy object should be considered. E.g. Instead of something like:
RProcess& process;
TInt error = process.VendorId()==KRequiredVendorId ? KErrNone : KErrPermissionDenied;
this could be used;
RProcess& process;
static _LIT_SECURITY_POLICY_V0(myVidPolicy, KRequiredVendorId);
TInt error = myVidPolicy().CheckPolicy(process);
This has the benefit that the TSecurityPolicy::CheckPolicy methods are configured by the system wide Platform Security configuration. I.e. are capable of emitting diagnostic messages when a check fails and/or the check can be forced to always pass.
SecureId() can be used to check for secure id.
5. Data caging
Data partitioning involves separating code from data in the file system such that a simple trusted path is created on the platform. The central idea is that by “caging” non-TCB processes into their own part of the file system, system files becomes hidden to them.
The file system has the following structure:
\sys\ : is the restricted system area and is inaccessible to non-TCB programs. It contains a subdirectory \sys\bin\ that holds all executables (EXEs, DLLs, .apps, ECom plug-ins etc.). The OS will refuse to run code placed in any other location.
\private\: non-TCB programs have their own restricted view on the file system consisting of the directory sub-tree \private\
\resource\: this directory is public, but is read-only for non-TCB processes. The purpose is to allow read-only files to be publicly shared without compromising their integrity. An example use is by applications, which put their appUI resource files and icon files into \resource\apps\.
Other: directories not under \sys\ or \private\ or \resource\ are public and can be read from and written to by any program. This allows the use of standard file system hierarchies that may be available on removable media.
The software installer program has access to the entire file system, and enforces the above layout by only allowing new installs and updates in the correct locations.
6. Software Install
Phone's Software Install policies decide how software is installed on a device. Application that requires sensitive capabilities are only installed if they are signed with an appropriate certificate. Please visit symbian signed page for more details. It is expected that a developr will only grant such a certificate after having checked that the program is of sufficient quality tested by software test house.
For application that requires only the less important capabilities, and that do not have a certificate, the choice of whether to allow the program to install or not can be offered to the user. The user capabilities are straightforward, so the user can easily understand them.
7. Symbian Sign and Capability
Symbian OS platform enables applications to use the Platform Security architecture in order to gain access to sensitive functionality within the platform. These APIs which give access to the functionalities are protected by a series of capabilities. There are twenty capabilities, and they are split into four groups -
User Capabilities,
System Capabilities,
Restricted Capabilities and
Device Manufacturer Capabilities.
These capabilities should be obtained from Symbian foundation. There are four different ways of Symbian signs. The four signing options -
Open Signed Online,
Open Signed Offline,
Express Signed and
Certified Signed
More information are available from Symbian Sign pages
| Capability Group | Capability Name | Self-Signed | Open Signed Online | Open Signed Offline | Express Signed | Certificate Signed |
|---|---|---|---|---|---|---|
| User Capabilities | LocalServices Location NetworkServices ReadUserData UserEnvironment WriteUserData |
Yes, with user confirmation at install time | Yes | Yes | Yes | Yes |
| System Capabilities | PowerMgmt ProtServ ReadDeviceData SurroundingsDD SwEvent TrustedUI WriteDeviceData |
No | Yes | Yes | Yes | Yes |
| Restricted Capabilities | CommDD DiskAdmin NetworkControl MultimediaDD |
No | No | Yes | No | Yes |
| Device Manufacturer Capabilities | AllFiles DRM TCB |
No | No | No | No | See SDK doc |