Security issues

• Who can define a property?

• Read and write access rights

• Deletion rights

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 OS, and it does not allow you to explicitly specify the category. Indeed, Symbian OS takes the category to be the value of the process SID.

• The situation before Version 9.1

• Migration issues

• Notes

Before version 9.1 of Symbian OS, 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 OS.

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.

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

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.

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.

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