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 more information, see UID.
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 Software 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. 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.
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?
Copyright ©2010 Nokia Corporation and/or its subsidiary(-ies).
All rights
reserved. Unless otherwise stated, these materials are provided under the terms of the Eclipse Public License
v1.0.