Security +issues

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.