Security Permissions for Roles Running within a Limited Execution Context

This post discusses how to explicitly set permissions on role instance resources for a Cloud Service; Worker (WaWorkerHost.exe), or Web (WaIISHost.exe) process running within a limited execution runtime context.  In situations where we need to access a resource from these processes that requires an elevated set of permissions, the easiest thing to do is modify the .csdef and set the runtime context to elevated.  Sometimes, we can easily avoid this by moving these tasks to a startup script which can run elevated, but there are times when we just cannot do that and the process does not have access to the necessary resources.  Let’s say we would like, or have a requirement, to design to the principle of least privilege requiring us to avoid elevating the entire process and instead set the necessary permissions.  The principle of least privilege is an important design consideration to enhancing the protection of data and functionality from faults or malicious behavior.  We simply need to create a startup script that we can run elevated and as part of it’s role instance initialization the script can assign the the appropriate permissions for our web/worker process.  The question is then under what user context is my role instances running?

When elevated, the process is running under the well known username System, but this is not the case when running within a limited execution context, and this username is not so obvious.  The Windows Azure Role Environment actually makes the Security Identifier (SID) the web/worker processes are running under available as a environment variable.  The environment variable, %WA_CONTAINER_SID%, contains the SID for the user our Web and Worker processes are running under, when running within a limited execution context.  Our elevated startup script can use this to grant the necessary permissions to the limited web/worker role process.

As an example; we could grant permissions to a path on the resource drive that is outside the defined local resources directories.  The following startup script would create a directory on the C: drive, which is commonly the resource disk on Windows Azure Cloud Service, and then grant full control to our web/worker process. 

md C:\MyTest

NOTE: A file system directory on the C: drive is used as a simple example of a machine resource that an elevated startup task can explicitly grant some permissions to a non-elevated worker process.  It is highly recommended that you define and use Local Storage Resources for provisioning local storage.  When Azure is provisioning local resources, permissions for your web/worker role process will be added to these local resources, as part of the role instance provisioning process.  Although not recommended, I know that in some cases, like with legacy code and 3rd party libraries this is not possible, and an approach to creating a directory on this drive along with running in an elevated execution context has been used.

Leave a Reply