Understanding Symbian platform security

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.

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 );

symbian {
   ...
   TARGET.CAPABILITY += AllFiles
}

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:

Data caging and removable media

Copyright note