A Closer Look at the Simple Sandboxed AppDomain

Yesterday we took a look at Whidbey's new Simple Sandboxing API.  At first glance this API does seem relatively simple, however when you start to look closer at the AppDomain that is created for your sandboxed code, there are a few surprising properties.

You might expect that under the covers this API is doing the grunt work of creating an AppDomain policy level which grants AllCode the specified permission set, and then has a code group for each strong name specified on the FullTrust list in order to provide those assemblies FullTrust.  However, this is not how the API works -- it actually uses an entirely different security model than the traditional policy level based one.  In fact, there is no AppDomain policy level in the sandboxed domain at all!  Instead the sandboxed domain simply keeps track of a set of FullTrust assemblies and a permission set to be granted to all other assemblies and the AppDomain itself.  No policy resolution will be done for assemblies loaded into this type of domain.

Why does Whidbey add this second AppDomain security model?  Aside from making it trivial for applications to sandbox untrusted code, it's also required for the ClickOnce security model.  ClickOnce allows an application to specify the exact set of permissions it should run under.  ClickOnce application authors test their applications with these permissions and expect to have exactly their requested permissions at runtime.  This AppDomain security model allows for that to occur.

Similarly, Visual Studio's debug-in-zone feature also requires an environment where the permissions it requests are exactly the permissions it gets -- if it were to debug your application with fewer privileges, debug-in-zone could lead to a lot of confusion when operations that are expected to pass start throwing SecurityExceptions.

Finally lets take a look at that evidence parameter to the CreateDomain API.  Since a sandboxed AppDomain does not resolve policy and always has a domain permission set equal to the grant set of the assemblies loaded into it, why does it need Evidence?  Technically the domain itself doesn't need that parameter, and it won't ever look at it directly.  However, the evidence is still stored on the AppDomain's Evidence property.  This means that other features which make decisions based upon AppDomain evidence (such as isolated storage), can still work with code executing in a simple sandboxed domain without modification.

Comments

• Anonymous
  August 20, 2005
  The comment has been removed
• Anonymous
  August 22, 2005
  In order to pull that off, the ClickOnce app needs to have permission to read from the internet and write to a folder it can load assemblies from.
  
  Partial trust ClickOnce apps do not have permission to discover where they're executing from -- this means they won't know where to write that assembly to. That prevents them from being able to load any code they want under their permission set.
  
  
  However, there's no need for them to connect to the Internet -- why wouldn't a malicious app just include the untrustworthy code in its install?
  
  -Shawn
• Anonymous
  August 22, 2005
  While we're on the topic of AppDomains ...
  One feature of AppDomains that many people don't know about...