Oftentimes in an application, it's necessary to run untrusted code. The CLR lets you do this safely by placing the code in its own AppDomain and sandboxing the AppDomain to have a limited set of permissions. Usually setting up the AppDomain with the Internet permission set allows you to feel confident in executing arbitrary managed code. Doing this is relatively easy, here's a code snippet that takes advantage of last week's GetNamedPermissionSet method in order to create a sandboxed AppDomain:
The code is pretty straight forward. First I create a code group that grants AllCode no permission (similar to how the other policy levels create their root code group.) The reason for this is that I'd like the flexibility of having multiple code groups on this AppDomain if necessary, and I can only have one root code group. By setting the root code group to AllCode -> Nothing, I can then chain as many child code groups as I want onto that root.
In this case, the only child code group I create assigns AllCode the permission set named in the parameter of the method call. Once this policy is set up, I create an AppDomain PolicyLevel, and assign the code groups to that level.
At that point, the only thing left to do is create the AppDomain and set its policy level. This is easily done with the CreateDomain and SetAppDomainPolicy methods of the AppDomain class.
One important point to note is that setting the AppDomain policy must be done before any code is loaded into the AppDomain, and may only be done once. As soon as code gets loaded into the AppDomain any changes to the security policy of that domain will no longer have any effect.
Another point is that this sandbox could be made even more secure by assigning some evidence to the AppDomain itself. For instance, if I was planning on creating an AppDomain with the Internet named permission set, I might assign the AppDomain some evidence including Internet zone and a URL.