diff -r 4816d766a08a -r f345bda72bc4 Symbian3/PDK/Source/GUID-B89D2828-0FEE-5206-97D2-C7D4BBD35799.dita --- a/Symbian3/PDK/Source/GUID-B89D2828-0FEE-5206-97D2-C7D4BBD35799.dita Tue Mar 30 11:42:04 2010 +0100 +++ b/Symbian3/PDK/Source/GUID-B89D2828-0FEE-5206-97D2-C7D4BBD35799.dita Tue Mar 30 11:56:28 2010 +0100 @@ -1,13 +1,127 @@ - - - - - -How is the Comms Database securedThis topic describes the security issues that govern access to the Comms Database.

Symbian OS uses platform security capabilities to protect the data in the Comms Database. The CommsDat API accesses the Comms Database through a client/server mechanism. Capabilities are policed at the client/server interface.

All elements in the Comms Database can have an access level. This means that all tables, records, columns, and fields can have an access level. The access level defines the type of access that elements offer to tools and applications. The access level available to tools and applications also depends on the platform security capabilities assigned to those tools and applications.

Access levels

The CommsDat API offers tools and applications 5 access levels to an element :

  • hidden : the element contains data that must not be seen.

  • private : the element contains private data. For example, username or password data.

  • protected write : the element contains data that must be protected from most processes. For example, this can be data set by network operators.

  • basic read-only guard : this access level is not used by the CommsDat API but exists for backward compatibilty with the legacy CommDb.

  • default : the element has no explicit access level.

The CommsDat API uses the flag bits defined by the TCDAttributeFlags enum to indicate the levels of access to an element. The bits are known as the access control attributes of an element.

Tools and applications use the CommsDat API functions CommsDat::CMDBElement::SetAttributes() and CommsDat::CMDBElement::ClearAttributes() to set the access control bits in the iElementId member of CMDBElement and to set the access levels into the element in the Comms Database.

How platform security capabilities work with access - levels

Tools and application processes without capabilities cannot write to the Comms Datababase. Processes without capabilities cannot damage the integrity of data in the Comms Database. Platform security makes sure that processes without capability cannot deny use of the database to other clients.

To read or write elements in the Comms Database, tools and application processes must have the correct platform security capabilities. The following table lists the combination of capabilities and access levels to read and write elements.

Access

Capability needed to read data

Capability needed to write data

hidden

This is indicated by the ECDHidden bit set in the in the iElementId member of an element.

None

WriteDeviceData

Private

This is indicated by the ECDPrivate bit set in the iElementId member of an element.

ReadDeviceData

WriteDeviceData + ReadDeviceData

Protected write

This is indicated by the ECDProtectedWrite bit set in the iElementId member of an element.

None

WriteDeviceData + NetworkControl

Basic read-only guard

This is indicated by the ECDNoWriteButDeletee bit set in the iElementId member of an element.

None

WriteDeviceData

Default

None of the TCDAttributeFlags bits set in the iElementId member of an element.

None

WriteDeviceData

Tools and applications that have the capability to change the access control attributes must follow data access control protocols.

Tools and applications must also have WriteDeviceData capability to use database functions. For example, to open a transaction to write to the database.

The platform security settings are cumulative. For example, to change an element that is marked private and has protected write access in the database requires:

  • the ECDPrivate bit and the ECDProtectedWrite bit to be set set.

  • the tools and application process to have the WriteDeviceData, ReadDeviceData and NetworkControl capabilities.

Changing the access attributes for each session

Tools and applications can choose to change the access levels of elements for the period of a session. For example, tools and applications can choose to view elements that have the hidden access level. Tools and applications set an attribute mask to change the access levels of elements for a session.

An attribute mask does not change the access levels of elements in the database. The functions that set an attribute mask do not make a call to the Comms Database and do not check the capabilities of the process of the tool or application. An attribute mask does not remove platform security checks. For example, a tools or application process without NetworkControl capability can not update elements protected with ECDProtectedWrite.

The most common use for this behaviour is to view elements that are hidden.

For example, to view hidden records, call the session function CommsDat::CMDBSession::SetAttributeMask() and pass the value for hidden to this function. The attribute value for hidden is the enum value ECDHidden.

Use the session function CommsDat::CMDBSession::ClearAttributeMask() to clear an attribute mask.

Platfom Security \ No newline at end of file + + + + + +How +is the Comms Database securedThis topic describes the security issues that govern access to +the Comms Database. +

Symbian platform uses platform security capabilities to protect +the data in the Comms Database. The CommsDat API accesses the Comms Database +through a client/server mechanism. Capabilities are policed at the client/server +interface.

+

All elements in the Comms Database can have an access level. This means +that all tables, records, columns, and fields can have an access level. The +access level defines the type of access that elements offer to tools and applications. +The access level available to tools and applications also depends on the platform +security capabilities assigned to those tools and applications.

+
Access levels

The +CommsDat API offers tools and applications 5 access levels to an element :

    +

  • hidden : the element +contains data that must not be seen.

    • +

  • private : the element +contains private data. For example, username or password data.

    • +

  • protected write : the +element contains data that must be protected from most processes. For example, +this can be data set by network operators.

    • +

  • basic read-only guard +: this access level is not used by the CommsDat API but exists for backward +compatibilty with the legacy CommDb.

    • +

  • default : the element +has no explicit access level.

    • +

The CommsDat API uses the flag bits defined by the TCDAttributeFlags enum +to indicate the levels of access to an element. The bits are known as the +access control attributes of an element.

Tools and applications use +the CommsDat API functions CommsDat::CMDBElement::SetAttributes() and CommsDat::CMDBElement::ClearAttributes() to set +the access control bits in the iElementId member of CMDBElement and to set the access levels into +the element in the Comms Database.

+
How platform +security capabilities work with access levels

Tools and +application processes without capabilities cannot write to the Comms Datababase. +Processes without capabilities cannot damage the integrity of data in the +Comms Database. Platform security makes sure that processes without capability +cannot deny use of the database to other clients.

To read or write +elements in the Comms Database, tools and application processes must have +the correct platform security capabilities. The following table lists the +combination of capabilities and access levels to read and write elements.

+ + + +

Access

+

Capability needed to read data

+

Capability needed to write data

+ + +

hidden

This is indicated by the ECDHidden bit set in the in the iElementId member +of an element.

+

None

+

WriteDeviceData

+ + +

Private

This is indicated by the ECDPrivate bit set in the iElementId member +of an element.

+

ReadDeviceData

+

WriteDeviceData + ReadDeviceData

+ + +

Protected write

This is indicated by +the ECDProtectedWrite bit set in the iElementId member +of an element.

+

None

+

WriteDeviceData + NetworkControl

+ + +

Basic read-only guard

This is indicated +by the ECDNoWriteButDeletee bit set in +the iElementId member of an element.

+

None

+

WriteDeviceData

+ + +

Default

None of the TCDAttributeFlags bits +set in the iElementId member of an element.

+

None

+

WriteDeviceData

+ + + +

Tools and applications that have the capability to change the +access control attributes must follow data access control protocols.

Tools +and applications must also have WriteDeviceData capability +to use database functions. For example, to open a transaction to write to +the database.

The platform security settings are cumulative. For example, +to change an element that is marked private and has protected write +access in the database requires:

    +

  • the ECDPrivate bit +and the ECDProtectedWrite bit to be set +set.

    • +

  • the tools and application +process to have the WriteDeviceData, ReadDeviceData and NetworkControl capabilities.

    • +
+
Changing the +access attributes for each session

Tools and applications can choose +to change the access levels of elements for the period of a session. For example, +tools and applications can choose to view elements that have the hidden access +level. Tools and applications set an attribute mask to change the access +levels of elements for a session.

An attribute mask does not change +the access levels of elements in the database. The functions that set an attribute +mask do not make a call to the Comms Database and do not check the capabilities +of the process of the tool or application. An attribute mask does not remove +platform security checks. For example, a tools or application process without NetworkControl capability +can not update elements protected with ECDProtectedWrite.

The +most common use for this behaviour is to view elements that are hidden.

For +example, to view hidden records, call the session function CommsDat::CMDBSession::SetAttributeMask() and +pass the value for hidden to this function. The attribute value for hidden is +the enum value ECDHidden.

Use +the session function CommsDat::CMDBSession::ClearAttributeMask() to +clear an attribute mask.

+ +Platfom Security + + \ No newline at end of file