Understanding Symbian platform security

Platform security is the collective name for a group of technologies whose primary function is to control application access to data and system services.

Platform security gives the user confidence that an application can only do the things it claims it needs to do. For example, a simple game may be refused network access or access to a user’s personal data.

There are three interrelated components of platform security:
  1. The capability model: this says that every process on the device runs with a set of capabilities. Access to certain system services and resources is only permitted by processes that possess specific capabilities.

  2. Process identity:

    • Every independently certified EXE on the device has a globally unique secure identifier. All servers are able to examine the identifier of their client processes, so a server may know exactly which EXE is requesting a given service.

    • Every independently certified EXE on the device may have a vendor identifier that securely identifies the organization that created it.

  3. Data caging: different parts of the file system are restricted, so only processes with specific capability sets, or secure identifiers, can read and/or write particular directories.

User and system capabilities

Every binary in the system has a capability field that defines the capabilities it has requested at build time. The capability field is a bitfield in which each bit represents a single capability. Each capability is logically independent of all the others, so having any one capability does not imply ownership of any other, and there is no logical hierarchy of capabilities.

Capabilities are divided into user and system capabilities. User capabilities are designed to be meaningful to the end user. They are defined for activities that could cost the user money (such as using the network) or violate their privacy (such as accessing the address book). Users can be given the option to grant these capabilities to an application.

The list of user capabilities can vary depending on the specific security policy chosen by the device manufacturer, but the following capabilities are typically user grantable:

  • NetworkServices: the ability to make phone calls, send e-mails, and so on.

  • LocalServices: the ability to use short-link network services such as Bluetooth.

  • ReadUserData: the ability to read the user’s private data.

  • WriteUserData: the ability to modify or create the user’s private data.

  • Location: get access to the device’s location.

  • UserEnvironment: access to information about the user’s environment, including the ability to record audio and use the camera.

System capabilities are not expected to be meaningful to the end user, so users are not given the option to grant them. Some system capabilities allow access to services at a lower level than user capabilities, thereby providing backdoor access to activities already protected by a user capability. For example, direct access to comms device drivers could provide a backdoor to access the network, and direct access to application private data could provide a backdoor to access user data. Additional capabilities are defined for activities that could affect the integrity of the system as a whole, and for certain other quite specialized activities such as digital rights management.

A subset of system capabilities is given below:
  • ReadDeviceData: the ability to read system settings (such as IAP settings).

  • WriteDeviceData: the ability to modify or create system settings.

  • CommDD: access to communication device drivers.

  • DRM: access to content protected by some form of digital rights management.

  • AllFiles: read access to all file system, and write access to application private data.

  • TCB: read and write access to the part of the file system where binaries are stored. TCB stands for 'trusted computing base'. The TCB capability enables the code possessing it to assign any set of capabilities to any binary on the device. So TCB-capable code is able to subvert the whole security model, and must be trusted to the highest degree.

Capability example

Most capability checks take place when an application makes a request of a server. The server can find out the capabilities of their clients, and use this to decide whether or not to service a request. This decision can sometimes depend on the values of the request parameters, as in the following code fragment that creates a file server session and attempts to read from the z:\sys directory.

// Create a file server session.
RFs fs;
User::LeaveIfError( fs.Connect() );

// Add the session to the cleanup stack
// before calling a leaving function.
CleanupClosePushL( fs );

// Retrieve information about directory contents into a CDir object.
// The call to GetDir() instantiates the CDir.
_LIT( KDirectory, "Z:\\sys" );
CDir* dir = 0;
User::LeaveIfError( fs.GetDir(KDirectory, KEntryAttMaskSupported, ESortNone, dir) );

// Add the CDir to the cleanup stack.
CleanupStack::PushL( dir );

// Use the CDir to retrieve information about
// the directory contents.

// Clean up.
CleanupStack::PopAndDestroy( 2, &fs );
As \sys is a protected directory this code will fail the file server's capability check if it is run from an application without the AllFiles capability. The server will complete the request with a KErrPermissionDenied error code (-46). To resolve the error you request the AllFiles capability in the application's project file (.pro):
symbian {
The requested capability is not user grantable, so the application developer needs to interact with the Symbian Signed certification process.

DLL capabilities

DLLs also have capabilities, represented in the same way and referring to the same privileges. Note that the capabilities of a DLL do not affect the capabilities of the process that loads it: process capabilities are entirely defined by the capabilities of the EXE.

The rule for DLL capabilities is: a binary cannot load any DLL that has fewer capabilities than itself. This ensures an EXE can trust that the code it is linking to will not abuse the privileges derived from the EXE. The DLL is trusted not to abuse the privilege it has been granted, and so may safely be loaded into processes running with that capability level. The rule is enforced by the program loader.

Process identity

Every EXE in the system contains a 32-bit secure identifier value, referred to as the SID. A SID cannot be changed. When an EXE is launched, the SID is copied from the EXE into the process. If the same EXE is launched multiple times, all the processes will have the same SID.

You can specify the SID of an application using the TARGET.SID variable in the project file. More commonly a SID is not explicitly specified. In this case the value of the SID defaults to the same as the value of the TARGET.UID3 variable.

There is a protected range of SIDs (from 0x00000000 to 0x7FFFFFFF) that is managed by Symbian Signed. EXEs that contain SIDs in the protected range must be signed by an approved authority (this is enforced by the software installer at install time). This means that code running on the device can be assured that protected SIDs were properly assigned from the global SID-space. So protected SIDs are globally unique, and can be used to identify individual applications.

If an application has a secure identifier in the protected range, the system is able to protect it from other applications. This means that it can store private data in its own private directory that is inaccessible to other applications, that other applications are not able to impersonate it, and that other application install packages are not able to alter it. Note that processes with the AllFiles capability can access private directories belonging to other applications. However, AllFiles is only granted to very trusted applications.

Data caging

Data caging is the term used to describe the practice of restricting access to certain parts of the file system. Data caging protects read-only resources from accidental or intentional modification by unauthorized code, and provides each EXE with its own private data area.

Data caging is enforced by the file server on a per-directory basis. The following top-level directories have some restrictions placed on them:

Directory Capabilities required for read access Capabilities required for write access Comments
\sys\ AllFiles TCB All binaries are stored under \sys\bin\. The loader will only load binaries from this location. Hashes of binaries stored on removable media are stored under \sys\hash\.
\resource\ None TCB Read-only resources (such as bitmaps) go here.
\private\ AllFiles, or a SID equal to the subdirectory name AllFiles, or a SID equal to the subdirectory name Application private data storage. This contains a subdirectory for each EXE that requires it: the directory name is the SID of the EXE, for example: \private\101f7663\.

Data caging and removable media

Binaries can be stored on removable cards. If the card is inserted into a reader attached to a PC, we could directly alter the capabilities inside the binaries. To prevent this, when binaries are installed to a removable drive, the installer calculates a hash of the binary, and stores the hash on the internal drive, under \sys\hash\. Then when the loader loads any binary from a removable drive, it recalculates the hash of the binary and checks that it matches the hash retrieved from the internal \sys\hash\ directory. If it doesn’t match, it fails to load. So:
  • Any binaries on removable media that have not been through the installer will not be run, because the hash will not be found.

  • Any binaries on removable media that have been altered post-install will not be run, because the hash will not match.

Copyright note

This topic is based with permission on a Symbian Foundation wiki article Platform Security which is part of the series The Fundamentals of Symbian C++. The version used was that available at http://developer.symbian.org/ on 3 November 2010. The content in this page is licensed under the Creative Commons Attribution-Share Alike 2.0 UK: England & Wales License (http://creativecommons.org/licenses/by-sa/2.0/uk).