Windows Mobile 5.0 Role security
I've just submitted a new post to my security column (https://www.microsoft.com/uk/msdn/security/default.mspx), but it takes a couple of weeks to hit the web through that route. So I might as well post it here too.
Here is the unedited version:
Introduction
In my last entry on this column I described the code signing security architecture of Windows Mobile and explained that this forms the first line of defense against running malicious code on the device. However, relying on just the digital signature of executable code is not enough to form a complete or particularly granular level of security for a device. In addition to code signing Windows Mobile also enforces role based security to protect certain assets on the device. In this post we will explore the different facets of the role model implemented on Windows Mobile 5.0 Smartphone and Pocket PC devices.
Certificate Security Recap
First we need to recap the code signing process: When any executable module (e.g. .EXE, .DLL. .CPL etc) is presented to the Windows Mobile OS by the program loader, the code signature is extracted and tested against a number of certificate stores and the device policy to determine which ‘mode’ or code group the module will execute in. For Smartphone there are two code groups: Normal – execute with access restrictions to certain API’s and other assets; and Trusted – execute with full access to all assets on the device. Windows Mobile 5.0 Pocket PC has one code group: Trusted.
Code groups are maintained at process granularity which means that DLL’s loaded into a process space must execute in the same code group as the exe. Therefore there are some restrictions that the loader enforces when loading DLL’s, for example an exe running in the Trusted code group cannot load a DLL that resolves to the Normal code group, otherwise the DLL would automatically receive an elevation of privileges. Conversely a Trusted code group DLL loaded by an exe running in the Normal code group will force the DLL into the Normal code group to match the containing process.
Enough of the recap lets think about roles on the device.
Do we need Roles?
Why do we need anything beyond the code signing security? Consider the situation where a system process is used to perform operations on behalf of some non executable content. One very clear example of this is when installing a CAB file on the device. A CAB file is not executable content so the program loader will not be invoked when this file is loaded; however a CAB file can contain installation instructions that require access to assets that are considered restricted and only available in the Trusted code group. For example a CAB file can include instructions to change registry keys such as the HKLM\Security or file operation instructions that affect the \Windows directory.
CAB files are processed by WCELOAD.exe application that is signed and runs in the Trusted code group so all assets are available to the process on both Pocket PC and Smartphone. But the CAB file could arrive on the device from any source; through email, from a web download or from removable media. In this situation code signing security does not provide protection against script based instructions that are interpreted by an application running in the Trusted code group, we need something a little more granular.
On a desktop system the solution to these type of issues is often implement in terms of user impersonation against object security or Access Control Lists (ACL’s), however Windows Mobile doesn’t understand the concept of object level security and we only ever have one user. So the solution implemented by Windows Mobile is role based access.
Role based security requires the OS to protect system assets (files, reg keys, code operations etc) by asserting that the process or operation requesting access has a role flag matching or exceeding the requirements of that asset. So we need a set of role flags, a way of associating role flags with all assets that need protection, and a way of associating role flags with a specific operation.
Role Flags
Let’s start with role flags. Role flags are implemented as a bit mask so there are theoretically up to 32 possible roles recognized by Windows Mobile – that’s 32 bits of a single 4 byte value. However today there are eleven publicly documented:
SECROLE_OEM
SECROLE_OPERATOR
SECROLE_MANAGER
SECROLE_USER_AUTH
SECROLE_ENTERPRISE (added with AKU2)
SECROLE_USER_UNAUTH
SECROLE_OPERATOR_TPS
SECROLE_KNOWN_PPG
SECROLE_TRUSTED_PPG
SECROLE_PPG_AUTH
SECROLE_PPG_TRUSTED
Full details of these flags are available in the SDK documentation or at MSDN online.
For most developers and users the important roles are SECROLE_USER_UNAUTH, SECROLE_USER_AUTH and SECROLE_MANAGER as these can be considered somewhat equivalent to the desktop Guest, standard user and Administrator accounts respectively.
Applying Roles to Assets
These flags need to be applied to both the assets and the applications that require access in order for the OS to manage access correctly. For assets such as registry keys, files and directories the roles can be stored in database form using the ‘path’ to the reg key or file as a lookup for the role. This database is called the metabase and is initially configured by the OEM when building the device image. The contents are not limited to just the security role, but can also include other information such as registry key data type, min / max values, default values and local specific strings. The role enforcement is applied within the OS code that accesses these resources, for example when calling a registry function or using a file IO function, the roles will be checked.
The OEM’s configuration, and any changes requested by the operator, is applied during cold boot of the device, however it is possible to query and update many of these values through the Metabase Configuration Service Provider. This service provider is available via Client Provisioning XML and can be accessed via the RapiConfig SDK utility, DMProcessConfigXML API call or via WAP push provisioning.
If you are adding new assets to the device, role base protection can be extended through this service provider to include your new assets by using simple XML.
For more details about provisioning and updating the metabase see the SDK documentation or MSDN online or take a look at my blog site.
Applying Roles
Now we have the role flags defined and we have the metabase that describes which roles are required for which assets, the last step is to assign a role to an operation or a ‘message’ that causes an operation to take place. This information obviously needs to be provided in a way that can be trusted, for example it’s not acceptable for a message to just declare ‘hey, I’m running in the manager role’!
There are two ways that a role is assigned to an operation or to a message: either through the certificate used to sign the message; or by examining the source of a message and deriving the role from the source.
First let’s consider how the role is derived from the source of the message.
When a message originates from a running process the security role is derived from the source of the operation by determining which code group the process is running in. For example consider a call to DMProcessConfigXML, used to apply XML configuration to the device, from an application that is running in the Normal code group. In this situation the XML received by DMProcessConfigXML is applied with the role mask of SECROLE_USER_UNAUTH, and the metabase is consulted as each change is applied to determine if appropriate permission exist before the values are read or written. Conversely if the process that calls DMProcessConfigXML is running in the Trusted code group then the XML is applied with the role mask SECROLE_USER_AUTH.
In other situations the message can be received through some form of push protocol such as SMS, and in this situation the message can also be signed with a certificate to validate the origin of the message and to verify that the content of the message is unmodified since it was sent. Now we have a certificate available that can directly validate the origin of the message by looking in the cert stores of the device to find an equivalent public key that allows us to validate the message. In addition to the certificate information and public key, each entry in the certificate store can also have a corresponding role mask. For signed messages, when the signing certificate for the message is identified, the role mask is also retrieved and used to process the message.
Verifying Application Installation
This type of message signing is common when an operator is using Over the Air (OTA) provisioning, but it is also used for application installation. Going back to the example of application installation I used earlier, for this purpose there is another, special certificate store called the SPC (Software Publisher Certificates). Every certificate that is installed on the device has an associated role mask, but for most stores this is ignored. When the WCELOAD process opens a CAB file for installation, it firsts looks to see if the CAB is signed. The CAB signature is validated against the SPC store and the role mask of the matching certificate is retrieved. This role mask is then used for all file and registry operations resulting from the installation of that CAB file and the application of any settings required by the CAB.
Getting at the Manager Role
If you take a look at the default metabase your will see that many assets require the manager role to modify and in some cases even to read their values. For example by default all of the certificate stores require manager role to manipulate their content.
This leads application developers to a problem: imaging your application needs to make SSL / HTTPS connections to a server as part of its normal operation. During installation of the application via cab file you deploy the main application files signed with a certificate rooted in the unprivileged store (execute with minimum permissions! Good practice on any system) and a small configuration application signed with a certificate in the privileged store, used during installation and configuration to update privileged assets. Part of this configuration application will need to install a new certificate into the root certificate store for silent setup of an SSL session by the main application. But this configuration app, even though it’s running in the Trusted code group will only have the SECROLE_USER_AUTH role and will fail to update the root store because the metabase requires SECROLE _MANAGER! And there is no way you can change the role mask for your process as its determined system wide for all Trusted execution apps.
So how can you solve this issue? There are two ways. Another aspect of security on Windows Mobile is that of Policies. There are a number of registry keys on the device that define the security policy that is applied on the device. I will cover the details of these settings in my next post but to give you an example, these policies configure information such as whether a 1 or 2 tier security policy is enforced on Smartphone, what permissions are enabled through RAPI (remote API), how unsigned applications and CAB’s should be dealt with.
One of these policies is called the Grant Manager policy. This is a role mask used to elevate other roles to the manager role thus avoiding the need to change large sections of the metabase to enable another role to access them. This policy defines a role mask in the registry that indicates which other roles should be considered and applied as if they were Manager – it’s a bit like the Administrators group on a desktop Windows operating system, adding someone to that group elevates them to administrator privileges without changing the individual object permissions.
Using this technique for certificate installation is a bit of overkill and potentially unsafe as all applications running in the Trusted code group would then be elevated to manager role on the device. Additionally you still need to find a way of changing the Grant Manager policy, which itself is a Manager operation in the first place.
A better solution would be to talk to your operator and have them sign a CPF (special CAB file containing just XML provisioning) with an operator certificate that has the manager role flag assigned already. That way the security model remains intact and the operator remains in control of the privileged content of the device.
And Finally …
Pretty much everything to do with security on Windows Mobile is configurable. The metabase, security policies, roles assigned to certificates etc.
What I have described here is generalized to the default settings that Microsoft recommends to its OEM and operator partners. However the final security model found on your retail device is defined by your OEM and Operator, and can vary significantly from the default. It’s always worth checking the actual device settings and join your operator’s developer program to ensure you get the latest and most accurate information for your device.
There is still more to Windows Mobile security. I will cover device Policies in the next article to complete this part of the OS security.
Marcus