Making Sense of Sensor Permissions

In this, my first Sensor and Location Team Blog post, I will discuss sensor permissions.

I’ll cover:

· Clearing up some confusion around sensors and devices

· What are sensor permissions

· What permissions permits

· How the sensor platform uses permissions

The players in this post are shown in the following diagram:

A Point of Confusion:

Before going into the world of sensor permissions I want to first clear up a misconception around the use of the word ‘sensor’ in our platform.

If you haven’t done so, take a look at the Location and Other Sensors Control Panel (internally we just call it the Sensors CPL – a quick short-cut is to simply enter sensors in the start menu search box). This is where you enable a sensor. In reality when you enable a sensor you are really enabling access to a device.

But why is it that the device manager indicates that the device is enabled when the Sensors CPL says it is disabled? They aren’t really contradicting each other; it is just that the sensor platform uses the term ‘enabled’ to mean that access to sensor data is allowed (more about this below).

The vast majority of devices implement only one sensor per device so enabling a sensor is atomic – one permission for the single sensor device. However new devices may have multiple sensors per device. For such a device granting permission to the sensor in the Sensors CPL is actually going to grant permission to all the sensors on the device. The device with multiple sensors will appear as a single sensor device in the Sensors CPL (for example it could be called “Sensor Array” ) even though it will actually expose more than one sensor. You need to be aware that permissions apply to all the sensors on a device. An example of this can be seen on the Sensor Development Kit sold by Freescale. Okay, back to the scheduled blog.

What Are Sensor Permissions?

Sensor permissions control the flow of data between the Sensor Class Extension (which a device driver must have in order to talk to the sensor platform) and the Sensor API.

What Do Sensor Permission Permit?

So why have sensor permissions? It comes down to Personally Identifiable Information or PII. You don’t want to expose personal details by default. Your location based on location sensors or health data (e.g. blood sugar levels based on some as yet developed sensor) are examples of sensor data that expose PII. Once the data is available it can be made available to all apps – some of which could broadcast the data to others. To allow you, the user, to secure your personal data an opt-in model is used. Once you install a new sensor device you need to decide who can get access to the data. You can grant access to all users to the sensor data by checking the check box on the CPL main page or you can go to the User Settings page and choose which users are enabled to access sensor data. The latter is useful in case you don’t want another user of the computer to access sensor data. An example is allowing yourself access to your location but not allowing your children to get (and broadcast) their location from their account.

The sensor platform uses SIDs (security identifiers) to identify users. Associated with the SID is an enable flag. There can be multiple SID/flag pairs depending upon how the permissions were set up in the User Settings page. The sensor permissions are stored in the registry with the format shown in the picture below for a root enumerated sensor:

 

Okay so I’ve established that sensor permissions determine who (which user accounts) gets access to potentially PII sensor data but you can still access certain sensor data even if the sensor is not enabled. What is going on here? The key here is that sensor data is divided into sensor properties and sensor data fields. Only sensor data fields are protected using sensor permissions. If you develop a device driver for a sensor make sure you keep this in mind. Always place PII data in data fields only so users can turn off access to the data. This division between properties and data fields is enforced by the Sensor Class Extension.

How the Sensor Platform Uses Permissions

Device drivers must instantiate the Sensor Class Extension in order to integrate with the sensor platform. The diagram at the top of this post shows the Sensor API talking with the Sensor Class Extension. In reality the Sensor API communicates with the driver via DeviceIoControl() as exposed by IPortableDevice::SendCommand(). To address a sensor the sensor object ID, which is exposed via the WPD_OBJECT_ID property, is passed into SendCommand(). When the driver receives the command the call is forwarded to the Sensor Class Extension. When the Sensor API needs to get sensor data, as opposed to getting sensor properties, the sensor object ID is pre-pended with a string that the Sensor Class Extension uses to identify a sensor data field call. In this case the Sensor Class Extension checks the sensor permissions against the SID of the calling process. If the enable flag is set for that SID the Sensor Class Extension calls ISensorDriver::OnGetSupportedDataFields() and/or ISensorDriver::OnGetDataFields() passing in the actual sensor ID. When the Sensor API needs sensor properties the actual sensor ID is passed to the Sensor Class Extension which then calls the appropriate ISensorDriver call without doing permission checks.

So what goes on when you enable a sensor? (I know, I know, I said ‘enable a sensor’ but I get lazy) The CPL tracks changes in the checkbox states. When there is a change the Apply button is enabled. The User Settings Page works in the same way. Once the Apply button is clicked the magic of UAC (User Account Control) allows the CPL to forward the device path, the SID and the enable flag to an elevated process (dllhost.exe) for each changed checkbox. The process needs to be elevated because data will be written to HKEY_LOCAL_MACHINE. The elevation of privilege provides a level of security since only someone with administrator access can make changes. The code that is executed in dllhost uses a library that maintains sensor permissions - this is the Sensor Permissions Manager. This is shown above just under the Sensors CPL.

The Sensor Permissions Manager is used by the Sensors CPL not only to set sensor permissions in the registry but also to get sensor permissions from all sensor devices. The Sensor Permissions Manager can get all the information it needs from the registry so the CPL doesn’t need to talk to any devices. Even if the device is no longer connected to the computer the device registry is still present until the device driver is uninstalled. This means that you can change sensor permissions on a device that is not even connected.

So how does a loaded sensor driver (i.e. in memory and running) know that the permissions have changed? In this case the Sensor Permission Manager communicates with the device. Using IPortableDevice::SendCommand() the Sensor Permission Manager sends a command to the driver which forwards it to the Sensor Class Extension. The command identifier tells the Sensor Class Extension that the permissions for the device have changed which causes the Sensor Class Extension to query the sensor permissions. There isn’t anything a device driver author needs to do to enable this synchronization (other than include the Sensor Class Extension) so this behavior comes for free.

I hope you’ve found this informative. Many thanks go to other members of our team that helped proof-read this blog and made this complex topic easier to follow.

Thanks for reading,

Kevin

This posting is provided "AS IS" with no warranties and confers no rights.