Security -issues

Who can define a property?
Read and write access rights
Deletion rights

Who can define -a property?

One of the most important attributes of a property -is the category to which it belongs. A category is represented by a UID value.

The -general rule is that the (category) UID must be the same as the Security ID -(the SID) of the process in which the code that is performing the define operation -is running. In effect, this forms a data cage, preventing a process from defining, -or "occupying", another process's property.

You define a property -using the overload of RProperty::Define() with the signature:

static TInt Define(TUint aKey, TInt aAttr, const TSecurityPolicy& aReadPolicy, const TSecurityPolicy& aWritePolicy, TInt aPreallocate);

This function was introduced in V9.1 of Symbian platform, and it does not allow -you to explicitly specify the category. Indeed, Symbian platform takes the -category to be the value of the process SID.

The situation before Version 9.1
Migration issues
Notes

The situation before Version -9.1

Before version 9.1 of Symbian platform, you had to explicitly -define a category using the overload of RProperty::Define() with -the signature:

static TInt RProperty::Define(TUid aCategory, TUint aKey, TInt aAttr, const TSecurityPolicy& aReadPolicy, const TSecurityPolicy& aWritePolicy, TInt aPreallocate)

This function was introduced in V9.0 of Symbian platform.

It -was also possible to specify a category, known as the system category, which -was reserved for system services. This category was identified by the KUidSystemCategoryValue UID; -a process required the WriteDeviceData capability, (ECapabilityWriteDeviceData), -to use it.

This overload is still available, but from V9.1 there are -restrictions that govern its use, and it is recommended that, if possible, -users of Property & Subscribe services should migrate to using the version -of RProperty::Define() that does not require the category -to be specified.

Migration issues

Processes -that use the 9.0 version of RProperty::Define() must now -have the WriteDeviceData capability to define a property with an explicitly -specified category (including the system category), provided that the SID -of the process is less than the value KUidSecurityThresholdCategoryValue.

A -process that has a SID value greater than KUidSecurityThresholdCategoryValue cannot -explicitly specify a category. This is an absolute rule that cannot be -overridden regardless of the capabilities assigned to that process.

The -logic here is that all new .exe s require a SID to be -assigned, and that this value will be greater than KUidSecurityThresholdCategoryValue. -This means that an associated process is forced to define properties with -category values that are the same as the process SID. Older .exe s -are expected to have SID values that are less than KUidSecurityThresholdCategoryValue, -and means that an associated process can continue to explicitly specify a -category, using the 9.0 version of Define(), but must have -the WriteDeviceData capability.

Ideally, all older .exe s -should be migrated to use the 9.1 version of Define().

The -following diagram shows the "category space".

- -

The KUidSecurityThresholdCategoryValue value -effectively forms a threshold value. Processes with a SID value below -this threshold can define a category that is different from their SID, provided -they have the WriteDeviceData capability. Processes with a SID value -above this threshold value can only define a category that is the same as -the SID - regardless of capability.

Notes

When we -refer to the SID of the process, we also mean the SID value assigned to the -associated .exe installed on the device. By older or -younger processes, we are referring to the age of the associated executables.

Read and write -access rights

Access rights to a property are set when the property -is defined.

The process defining the property can specify the rights -of access to that property. In particular, it can specify a security policy -to control read access (i.e. retrieval of the property) and a separate security -policy to control write access (i.e. publication of the property).

Access -to a property is governed by a pair of security policies, instances of TSecurityPolicy objects. -These define the combination of capabilities and/or vendor Id and/or Secure -Id that a process must possess before being allowed to write to, or read from, -a property. Any attempt to access a property by a thread whose owning process -does not have sufficient capability, will fail with KErrPermissionDenied.

The -security policies are passed to the RProperty::Define() function -when the property is defined.

Deletion rights

Only -the owning process, i.e. the process that defined the property, is allowed -to delete that property.

+ + + + + +Security +issuesThis topic explains the security issues while performing a publish +and subscribe. +

Who can define a property?
Read and write access rights
Deletion rights

Who can define +a property?

One of the most important attributes of a property +is the category to which it belongs. A category is represented by a UID value.

The +general rule is that the (category) UID must be the same as the Security ID +(the SID) of the process in which the code that is performing the define operation +is running. In effect, this forms a data cage, preventing a process from defining, +or "occupying", another process's property.

You define a property +using the overload of RProperty::Define() with the signature:

static TInt Define(TUint aKey, TInt aAttr, const TSecurityPolicy& aReadPolicy, const TSecurityPolicy& aWritePolicy, TInt aPreallocate);

This function was introduced in V9.1 of Symbian platform, and it does not allow +you to explicitly specify the category. Indeed, Symbian platform takes the +category to be the value of the process SID.

The situation before Version 9.1
Migration issues
Notes

The situation before Version +9.1

Before version 9.1 of Symbian platform, you had to explicitly +define a category using the overload of RProperty::Define() with +the signature:

static TInt RProperty::Define(TUid aCategory, TUint aKey, TInt aAttr, const TSecurityPolicy& aReadPolicy, const TSecurityPolicy& aWritePolicy, TInt aPreallocate)

This function was introduced in V9.0 of Symbian platform.

It +was also possible to specify a category, known as the system category, which +was reserved for system services. This category was identified by the KUidSystemCategoryValue UID; +a process required the WriteDeviceData capability, (ECapabilityWriteDeviceData), +to use it.

This overload is still available, but from V9.1 there are +restrictions that govern its use, and it is recommended that, if possible, +users of Property & Subscribe services should migrate to using the version +of RProperty::Define() that does not require the category +to be specified.

Migration issues

Processes +that use the 9.0 version of RProperty::Define() must now +have the WriteDeviceData capability to define a property with an explicitly +specified category (including the system category), provided that the SID +of the process is less than the value KUidSecurityThresholdCategoryValue.

A +process that has a SID value greater than KUidSecurityThresholdCategoryValue cannot +explicitly specify a category. This is an absolute rule that cannot be +overridden regardless of the capabilities assigned to that process.

The +logic here is that all new .exe s require a SID to be +assigned, and that this value will be greater than KUidSecurityThresholdCategoryValue. +This means that an associated process is forced to define properties with +category values that are the same as the process SID. Older .exe s +are expected to have SID values that are less than KUidSecurityThresholdCategoryValue, +and means that an associated process can continue to explicitly specify a +category, using the 9.0 version of Define(), but must have +the WriteDeviceData capability.

Ideally, all older .exe s +should be migrated to use the 9.1 version of Define().

The +following diagram shows the "category space".

+ +

The KUidSecurityThresholdCategoryValue value +effectively forms a threshold value. Processes with a SID value below +this threshold can define a category that is different from their SID, provided +they have the WriteDeviceData capability. Processes with a SID value +above this threshold value can only define a category that is the same as +the SID - regardless of capability.

Notes

When we +refer to the SID of the process, we also mean the SID value assigned to the +associated .exe installed on the device. By older or +younger processes, we are referring to the age of the associated executables.

Read and write +access rights

Access rights to a property are set when the property +is defined.

The process defining the property can specify the rights +of access to that property. In particular, it can specify a security policy +to control read access (i.e. retrieval of the property) and a separate security +policy to control write access (i.e. publication of the property).

Access +to a property is governed by a pair of security policies, instances of TSecurityPolicy objects. +These define the combination of capabilities and/or vendor Id and/or Secure +Id that a process must possess before being allowed to write to, or read from, +a property. Any attempt to access a property by a thread whose owning process +does not have sufficient capability, will fail with KErrPermissionDenied.

The +security policies are passed to the RProperty::Define() function +when the property is defined.

Deletion rights

Only +the owning process, i.e. the process that defined the property, is allowed +to delete that property.

\ No newline at end of file