diff -r 80ef3a206772 -r 48780e181b38 Symbian3/SDK/Source/GUID-3B6E25F7-C1A8-461F-97F7-421DB559BC98.dita --- a/Symbian3/SDK/Source/GUID-3B6E25F7-C1A8-461F-97F7-421DB559BC98.dita Fri Jul 16 17:23:46 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-3B6E25F7-C1A8-461F-97F7-421DB559BC98.dita Tue Jul 20 12:00:49 2010 +0100 @@ -1,81 +1,81 @@ - - - - - -Process -identification -

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.

- -

Secure Identifier -(SID)

-

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.

-

Vendor Identifier -(VID)

-

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.

-
Secure inter -process communication -

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?

      -
      • -
    -
    • -
-
+ + + + + +Process identification +

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

    • +
+

Secure Identifier +(SID)

+

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.

+

Vendor Identifier +(VID)

+

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.

+
Secure +inter process communication +

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?

      +
      • +
    +
    • +
+
 \ No newline at end of file