Creating an AppDomain with limited permissions

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…

10

The Locations of the Other Policy Levels

On Monday I wrote about how to recover CasPol to a usable state, if you’ve modified the security policy to disallow CasPol permission to run.  My instructions included deleting %WINDIR%\Microsoft.Net\Framework\vx.y.zzzz\config\Security.config and Security.cch.  I’ve gotten a few emails that correctly pointed out that this only clears the Machine policy level.  Since this is the level where…


Spot the Defect: Modifying the Security Policy in Code

Modifying the CLR’s security policy can be done in your code by interacting with the SecurityManager object.  Specifically, you can access the PolicyHierarchy method which will expose an enumerator over the policy levels, and the SavePolicy method, which will commit your changes to the policy.  However, using these methods can be counter-intuitive sometimes.  Here’s a…

2

Deploying Policy on v1.0 and 1.1 of the CLR

A lot of the time, someone has written an application that won’t run under the CLR’s default security settings and needs to provide a mechanism for their users to modify the policy easily in order to allow their application to run. For Whidbey, ClickOnce solves this scenario, but for v1.0 and 1.1 of the CLR,…

9

Customizable CAS Defaults

One of the nicer new Whidbey features, at least from an admin standpoint, is the ability to customize the default CAS settings.  On v1.0 and 1.1 of the framework running caspol -all -reset resulted in the security policy being reset to hardcoded defaults.  Whidbey will allow users to change what caspol -all -reset means. This…

3