5 Reasons to Choose Simple Sandboxing

By | April 21, 2006

When it comes time to host some partially trusted code in your application, perhaps as a part of an Add-In model, you’ve got a few options to choose from. How do you decide which is the best way to go? Thankfully the answer to this one is relatively straightforward – choose the new simple sandboxing model whenever possible.

We’ve already talked about why using PermitOnly or Deny to sandbox code is not an effective option. The primary issue is that both of these are simply stack walk modifiers, and have no effect on the grant set of any assembly. Because of that, they can be overridden with an Assert in the sandboxed assembly. The sandboxed code (and I’m using that term very loosly in this context), won’t even have to Assert to satisfy a LinkDemand or an InheritenceDemand since those are done at JIT time and do not involve a stack walk.

In addition to being ineffective against various CAS demands, these stack walk modifiers make life much harder when it comes to protecting sensitive information. Since static variables are shared on an AppDomain level, any static state that your application may maintain needs to be protected against these “sandboxed” assemblies. If you were to create a new AppDomain to sandbox in, the shared state problem goes away because each AppDomain gets a new copy of the static data.Read Full Story

Leave a Reply