How -is the Comms Database secured

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 - + + + + + +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