Sometimes it is useful for security reasons to obtain more information about server or application processes, and identify an application and even its vendor uniquely.
To verify an application's identity, use RApaLsSession
to retrieve the application's name and Unique Identifier (UID),
and compare them against known information.
For information, see Application UIDs.
Use the TApaTaskList
class
to get a list of currently running applications.
In the platform security architecture there are two different identifiers for applications: Secure Identifier (SID) and Vendor Identifier (VID).
Every executable has its own Secure Identifier (SID), which is
used to identify the running process launched from the executable. It can
also be used to determine which private directory a process can access. SID
is stored in the executable binary, so it has the same security as any executable
code. The SID value is not relevant for dll
.
SID values are requested from the Symbian Signed web site. The Sofware Installer ensures that no two applications have the same SID value on a particular target device.
To retrieve the SID of a process, use the RProcess::SecureId()
method . During inter process communication, use the TSecurityPolicy
class to specify a security policy consisting of both capability and
SID checks.
For information on how to define the SID in the mmp
file,
see secureid
in the Symbian OS Library. If SID
is not specified in the mmp
file, the value of UID3 is used
as the SID.
In addition to SID, signed applications have a Vendor Identifier (VID) which can be used to identify the source of the application. Applications from one vendor usually share a common VID, but the vendor may have different VIDs for different product families. VIDs can also be used to group servers and clients into logical groups providing services to each other.
Note that the VID cannot be reused for any other entity. For example,
the Nokia VID (0x101FB657
) is property of Nokia.
For information on how to define the VID in the mmp
file,
see vendorid
in the Symbian OS Library.
Authentication can be done in different ways. The server can decide
to request (or not to request) capabilities from the client. The client's
options are more limited, the server is usually authenticated by name. The ProtServ
capability allows
the server to insert an "!" in front of its name, indicating that the server
can be trusted. Nameless servers are also possible, but no client can connect
to them without a handle to the server. The server can also authenticate the
client with SID and VID.
Every server should define the following security policies:
Which capabilities are required by the calling application
Which SID and VID are required by the calling application
What actions are possible or must be done with the information provided:
Can input data be trusted?
Is user acceptance needed for this operation?
Can this server act as a proxy towards other components?