Security issues
This topic explains the security issues while performing a publish and subscribe.
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
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.
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.
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.