.NET Security Blog : CAS

CLR v4 Security Policy Roundup

shawnfa — Fri, 12 Jun 2009 21:33:00 GMT

Over the last few weeks we’ve been taking a look at the updates to the CLR security policy system in the v4 release of the .NET Framework. Here’s a quick index of those topics:

Overview

Updating code to work with the new model

Implicit uses of CAS policy part 1 (Assembly.Load with Evidence, AppDomain creation with Evidence)
Implicit uses of CAS policy part 2 (loading assemblies from remote sources)
Explicit uses of CAS policy (APIs such as SecurityManager which directly use CAS policy)

Temporarily re-enabling CAS policy during migration

The NetFx40_LegacySecurityPolicy config file switch

Temporarily re-enabling CAS policy during migration

shawnfa — Fri, 12 Jun 2009 21:27:13 GMT

Over the last few weeks we’ve been looking at the changes to security policy in .NET 4, namely that security policy is now in the hands of the host and the operating system.

While we’ve looked at how to update code that implicitly uses CAS policy, loads assemblies from remote sources, and explicitly uses CAS policy, in applications of larger size it may not be practical to update all the code at once. Similarly, you might be able to update the code in your application, but may rely on a third party assembly that is not yet updated for the changes in CAS policy.

If you do find yourself needing to re-enable CAS policy temporarily, in order to move a large code base to the new v4 security APIs bit by bit rather than all at once, or to use an assembly that you don’t control, there is a configuration switch that you can set in order to flip your process back into legacy CAS policy mode.

In order to temporarily enable legacy CAS policy in your process, you’ll need an .exe.config file for your application with the legacy security policy switch set in its runtime section. So, if your application’s entry point is YourApp.exe, you’ll have next to it a YourApp.exe.config file. (You can also use the app.config feature in your Visual Studio project). The file should look like this for any release of the .NET Framework v4 after beta 1:

<configuration>
  <runtime>
    <NetFx40_LegacySecurityPolicy enabled="true" />
  </runtime>
</configuration>

In .NET 4 Beta 1, the switch has a slightly different name:

<configuration>
  <runtime>
    <legacyCasPolicy enabled="true" />
  </runtime>
</configuration>

One thing to note is that this switch must be set on the process-level. So, if you’re using a third party control that uses CAS policy, you may well need to set the switch for both Visual Studio in devenv.exe.config and for your application itself. That way the control will work both in the Visual Studio process during your development, as well as in your process at runtime.

Coding with Security Policy in .NET 4 part 2 – Explicit uses of CAS policy

shawnfa — Tue, 09 Jun 2009 22:14:31 GMT

Over the last few posts, I’ve been looking at how the update to the CLR v4 security policy interacts with how you write managed code against the v4 .NET Framework. So far we’ve looked at the implicit uses of CAS policy, such as loading assemblies and creating AppDomains with Evidence and loading assemblies from remote sources. Now let’s look at how to work with code which was written to work with CAS policy explicitly.

The good news is that explicit use of CAS policy is frequently very easy to spot, as opposed to implicit uses which can be somewhat more subtle. APIs that directly manipulate policy (such as SecurityManager.ResolvePolicy) as well as those that require CAS policy to sandbox (such as AppDomain.SetAppDomainPolicy) fall into this category. Other APIs that explicitly use CAS policy are:

AppDomain.SetAppDomainPolicy
HostSecurityManager.DomainPolicy
PolicyLevel.CreateAppDomainLevel
SecurityManager.LoadPolicyLevelFromString
SecurityManager.LoadPolicyLevelFromFile
SecurityManager.ResolvePolicy
SecurityManager.ResolveSystemPolicy
SecurityManager.ResolvePolicyGroups
SecurityManager.PolicyHierarchy
SecurityManager.SavePolicy

As with the implicit CAS policy uses, the explicit APIs also are obsolete in .NET 4, and will throw NotSupportedExceptions by default:

System.NotSupportedException: This method uses CAS policy, which has been obsoleted by the .NET Framework. In order to enable CAS policy for compatibility reasons, please use the NetFx40_LegacySecurityPolicy configuration switch. Please see http://go.microsoft.com/fwlink/?LinkId=131738 for more information.

Let’s take a look at how code which used these APIs in the past might get updated with new v4 APIs.

Generally, there are three reasons that the explicit policy APIs are being used:

The code wants to figure out what the grant set of an assembly or AppDomain is
The code wants to create a sandbox
The code wants to figure out what a safe sandbox is to setup

The correct way way to update the code calling an explicit policy API in v4 depends upon what it was trying to do by calling the API in the first place. Let’s take a look at each of the reasons for using an explicit policy API in turn and figure out what the replacement code should look like.

Figuring out what the grant set of an assembly or AppDomain is

Sometimes an application or library wants to figure out what the grant set of a particular assembly or domain was and would do so with code similar to:

private PermissionSet GetAssemblyGrantSet(Assembly assembly)
{
    Evidence assemblyEvidence = assembly.Evidence;
    return SecurityManager.ResolvePolicy(assemblyEvidence);
}
 
private bool IsFullyTrusted(Assembly assembly)
{
    PermissionSet grant = GetAssemblyGrantSet(assembly);
    return grant.IsUnrestricted();
}
 
private PermissionSet GetAppDomainGrantSet(AppDomain domain)
{
    Evidence appDomain = domain.Evidence;
    return SecurityManager.ResolvePolicy(appDomain);
}
 
private bool IsFullyTrusted(AppDomain domain)
{
    PermissionSet grant = GetAppDomainGrantSet(domain);
    return grant.IsUnrestricted();
}

This code worked by resolving the assembly or AppDomain’s evidence through CAS policy to determine what would be granted to that particular evidence. There are a few problems here – for instance, the code doesn’t take into account simple sandbox domains, hosted AppDomains, dynamic assemblies, or assemblies loaded from byte arrays. (Take a look at AssemblyExtensionMethods.GetPermissionSet() on http://clrsecurity.codeplex.com for code that does take most of the other considerations into account). These methods also cause a full CAS policy resolution to occur, which is not a cheap operation.

Instead of requiring people to manually jump through hoops in order to recreate the CLR’s security policy system in v4, we’ve directly exposed the grant sets of assemblies and AppDomains as properties of the objects themselves. The above code can be replaced with:

private PermissionSet GetAssemblyGrantSet(Assembly assembly)
{
    return assembly.PermissionSet;
}
 
private bool IsFullyTrusted(Assembly assembly)
{
    return assembly.IsFullyTrusted;
}
 
private PermissionSet GetAppDomainGrantSet(AppDomain domain)
{
    return domain.PermissionSet;
}
 
private bool IsFullyTrusted(AppDomain domain)
{
    return domain.IsFullyTrusted;
}

Which has the dual benefit of being more accurate (these properties read the real grant set that the CLR is using, no matter how it was determined), and also being faster than a full policy resolution.

Accessing the PermissionSet property of an AppDomain or an Assembly does require that the accessing code be fully trusted. The reason is that the permission sets themselves can contain sensitive data. (For instance, FileIOPermission can contain full path information about the local machine in it). Partial trust code, however, can use the IsFullyTrusted property.

Creating a Sandbox

I suspect many people who have read this blog already know what I’m going to say here :-) Instead of using SetAppDomainPolicy to create a sandbox, which suffers from many problems, the replacement API is the simple sandboxing API. I’ve already covered most of the reasoning for this change when I talked about sandboxing in CLR v4, so let’s look at the final reason that code may have been using CAS policy APIs

Figuring out what a safe grant set is to provide a sandbox

Sometimes a host needs to figure out what is a reasonable set of permissions to assign to a sandbox. For instance, even though ClickOnce does not use CAS policy, it still needs to figure out if the permission set that the ClickOnce application is requesting is a reasonable set of permissions for it to have. (For instance, if it’s requesting only the permission to execute, that’s going to be fine, while if an application from the Internet is requesting permission to read and write all of the files on your disk, that’s not such a good idea).

In order to solve this problem in v2, code might look like this:

private bool IsSafeGrantSet(PermissionSet grantSet, Evidence sandboxEvidence)
{
    // Figure out what the CLR's policy system says is safe to give a sandbox
    // with this evidence
    PermissionSet systemGrantSet = SecurityManager.ResolveSystemPolicy(sandboxEvidence);
 
    // We'll consider this safe only if we're requesting a subset of the safe
    // sandbox set.
    return grantSet.IsSubsetOf(systemGrantSet);
}

Since system wide CAS policy (which this code depends upon to determine safety) is deprecated in v4, we need to find a new way to accomplish this goal.

The answer is with a new API called GetStandardSandbox. GetStandardSandbox is used to have the CLR provide what it considers a safe sandbox grant set for an AppDomain that will host code with the specified evidence. It’s the CLR’s way of providing suggestions to hosts who are making trust decisions. One thing that is very important to note is what GetStandardSandbox is not however.

GetStandardSandbox is not a policy API. This isn’t the CLR applying CAS to evidence in order to modify grant set, and the CLR does not take any external factors such as CAS policy into account when returning its grant set. Instead, GetStandardSandbox is simply a helper API for hosts which are trying to setup sandboxes.

With that in mind, the way the above code would be written in CLR v4 is:

private bool IsSafeGrantSet(PermissionSet grantSet, Evidence sandboxEvidence)
{
    // Figure out what the CLR considers a safe grant set
    PermissionSet clrSandbox = SecurityManager.GetStandardSandbox(sandboxEvidence);
 
    // We'll consider this safe only if we're requesting a subset of the safe
    // sandbox set.
    return grantSet.IsSubsetOf(clrSandbox);
}

Similarly, if you are a host trying to setup an AppDomain to sandbox assemblies that are coming from the Internet, you might do so this way:

// Find a safe sandbox set to give to assemblies downloaded
// from the internet
Evidence internetEvidence = new Evidence();
internetEvidence.AddHostEvidence(new Zone(SecurityZone.Internet));
PermissionSet clrSandbox = SecurityManager.GetStandardSandbox(internetEvidence);
 
// Create a sandboxed AppDomain to hold them
AppDomainSetup sandboxSetup = new AppDomainSetup();
sandboxSetup.ApplicationBase = DownloadDirectory;
 
AppDomain sandbox = AppDomain.CreateDomain("Internet sandbox",
                                           internetEvidence,
                                           sandboxSetup,
                                           clrSandbox);

More Implicit Uses of CAS Policy: loadFromRemoteSources

shawnfa — Mon, 08 Jun 2009 21:59:07 GMT

In my last post about changes to the CLR v4 security policy model, I looked at APIs which implicitly use CAS policy in their operation (such as Assembly.Load overloads that take an Evidence parameter), and how to migrate code that was using those APIs. There are another set of assembly loads which cause implicit use of CAS policy, which I’ll look at today – these are loads from remote sources.

For example, in .NET 3.5 the following code:

Assembly internetAssembly = Assembly.LoadFrom(@"http://www.microsoft.com/assembly.dll");
Assembly intranetAssembly = Assembly.LoadFrom(@"\\server\share\assembly.dll");

Will by default load internetAssembly with the Internet permission set and intranetAssembly with the LocalIntranet permission set. That was because the CLR would internally gather evidence for both assemblies and run that evidence though CAS policy in order to find the permission set to grant that assembly.

Now that the sandboxing model has changed in the v4 CLR, there is no more CAS policy to apply the assembly’s evidence to by default, and therefore default behavior of both of these loads would be to load the assemblies with a grant set of full trust.

That creates a problem for code which was written before .NET 4 shipped – this code may quite reasonably be expecting that the above assembly loads are safe because the CLR will automatically apply a restricted grant set to the assemblies if they are coming from a remote location. Now when the code runs in the v4 CLR, the assemblies are elevated to full trust, which amounts to a silent elevation of privilege bug against the .NET 2.0 code which was expecting that these assemblies be sandboxed. Obviously that’s not a good thing.

Instead of silently granting these assemblies full trust, the v4 CLR will actually take the opposite approach. We’ll detect that these assemblies are being loaded in such a way that

They would have been sandboxed by the v2 CLR and
Are going to be given full trust by the v4 CLR

Once we detect an assembly load where both of the above conditions are true, the CLR will refuse to load the assembly with the following message:

System.IO.FileLoadException: Could not load file or assembly '<assemblyPath>' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515 (COR_E_NOTSUPPORTED)) --->
System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=131738 for more information.

This exception is saying “The v4 CLR is not going to sandbox the assembly that you’re trying to load, however the v2 CLR would have. We don’t know if that’s safe in your application or not, so we’re going to fail the assembly load to ensure that your application is secure by default. However, if this is a safe assembly load, go ahead and enable loading from remote sources for this process.”

That leads to the next question -- how do you know if it is safe to enable loadFromRemoteSources in your application? This decision generally comes down to applying these tests:

Do you trust the string that you’re passing to Assembly.LoadFrom?
Do you trust the assembly that you’re loading?
Do you trust the server hosting the assembly (and the network path from the server back to your application)?

If you answered yes to all three questions then your application is a good candidate for enabling the loadFromRemoteSources switch. If you answered no to any of the three questions, then you may need to take further action before enabling the switch and loading the assembly. (For instance, you may have some application logic to ensure that the string being passed to LoadFrom is going to a server you trust, or your application might download the assembly first and verify it has an Authenticode signature that it trusts).

Let’s look at some examples:

The most straight-forward reason that you would want to enable this is in the case that you know what the assemblies you are loading are, you trust them, and you trust the server that they are hosted on. For example, if your application is hosted on a share on your company’s intranet, and happens to need to load other assemblies from other shares on the network, you probably want to enable the switch. (In many cases, this category of applications used to have to fight with CAS policy to get things loaded the way they wanted, now with loadFromRemoteSources set things should just work.)

On the other hand, if you are an application that takes as untrusted input a string which then is passed through to Assembly.LoadFrom, you probably don’t want to enable this switch, as you might be opening yourself up to an elevation of privilege attack via that untrusted input.

Similarly, if your application takes as input an assembly name to LoadFrom, however you trust that input. (Maybe it comes directly from your application’s user, and there is no trust boundary between the user and your app – for instance, the user is pointing you at a plugin they trust and wish to load in the app), you may also want to enable this switch.

Another consideration to take into account when considering loadFromRemoteSources is that this is a process-wide configuration switch. This means that it applies to all places in your code which loads assemblies, not just a single LoadFrom call. If you only trust the inputs to some of your assembly loads, then you may wish to consider not using the loadFromRemoteSources switch and instead take a different approach.

Since the first condition for the NotSupportedException that blocks remote assembly loads is that the load would have been sandboxed by the v2 CLR, one alternate way to enable these loads without setting loadFromRemoteSources for the entire process is to load the assemblies into a domain that you create with the simple sandboxing API.

This will work because even in v2.0, simple sandbox domains never apply CAS policy, and therefore any remote loads in simple sandbox domains would not have required CAS policy to sandbox them. Since the assemblies would not have used CAS policy in v2, the loads are considered safe to use in v4 as well, and will succeed without the NotSupportedException being thrown.

For example, if you want to enable only a subset of LoadFroms to load assemblies in full trust, if you create a fully trusted simple sandbox, then any assemblies loaded into that sandbox would have the same full trust grant set in v2 as in v4. (The full trust grant set of the domain applies to all assemblies loaded into it). This will cause the CLR to allow the loads to proceed in full trust in v4 without having to throw the switch.

// Since this application only trusts a handful of LoadFrom operations,

// we'll put them all into the same AppDomain which is a simple sandbox

// with a full trust grant set. The application itself will not enable

// loadFromRemoteSources, but instead channel all of the trusted loads

// into this domain.

PermissionSet trustedLoadFromRemoteSourceGrantSet

= new PermissionSet(PermissionState.Unrestricted);

AppDomainSetup trustedLoadFromRemoteSourcesSetup = new AppDomainSetup();

trustedLoadFromRemoteSourcesSetup.ApplicationBase =

AppDomain.CurrentDomain.SetupInformation.ApplicationBase;

AppDomain trustedRemoteLoadDomain =

AppDomain.CreateDomain("Trusted LoadFromRemoteSources Domain",

null,

trustedLoadFromRemoteSourcesSetup,

trustedLoadFromRemoteSourcesGrantSet);

// Now all trusted remote LoadFroms can be done in the trustedRemoteLoadDomain,

// and communicated with via a MarshalByRefObject.

As an example in the opposite direction, maybe your application has mostly loads which are safe to have remote targets, however there are a small handful of places that do need to be sandboxed. By creating a simple sandboxed AppDomain for those loads, you can then safely set the loadFromRemoteSources switch for the rest of your process.

// Since this application trusts almost all of its assembly loads, it

// is going to enable the process-wide loadFromRemoteSources switch.

// However, the loads that it does not trust still need to be sandboxed.

// First figure out a grant set that the CLR considers safe to apply

// to code from the Internet.

Evidence sandboxEvidence = new Evidence();

sandboxEvidence.AddHostEvidence(new Zone(SecurityZone.Internet));

PermissionSet remoteLoadGrantSet = SecurityManager.GetStandardSandbox(sandboxEvidence);

AppDomainSetup remoteLoadSetup = new AppDomainSetup();

trustedLoadFromRemoteSourcesSetup.ApplicationBase = GetSandboxRoot();

AppDomain remoteLoadSandbox =

AppDomain.CreateDomain("Remote Load Sandbox",

sandboxEvidence,

remoteLoadSetup,

remoteLoadGrantSet);

// Now all trusted remote LoadFroms can be done in the default domain

// with loadFromRemoteSources set, and untrusted loads can be done

// in the sandbox that we just setup.

(Similarly, if the process is in legacy CAS policy mode, the v4 CLR will have the same behavior as the v2 CLR, and there will be no exception).

Let’s say that you’ve considered the security implications and your application is a good candidate to enable loadFromRemoteSources, how do you go about doing so? Basically, you just provide a .exe.config file for your application with a loadFromRemoteSources runtime switch enabled. So, if your application’s entry point is YourApp.exe, you’ll want to make a YourApp.exe.config. (Or use the app.config file in your Visual Studio project). This configuration file will need to contain runtime section such as:

<configuration>
  <runtime>
    <loadFromRemoteSources enabled="true" />
  </runtime>
</configuration>

This setting will cause the CLR to notice that even though it is going to load an assembly that would have been sandboxed in the v2 runtime, your application has explicitly stated that this is a safe thing to do. Since your application has said that it understands the security impact of loading from remote locations and it is safe in the context of this application, the CLR will then allow these loads to succeed without throwing a NotSupportedException to block them.

CLR 4 Security on Channel 9

shawnfa — Thu, 28 May 2009 23:30:00 GMT

A while back I did an interview with Charles Torre about the changes to security in CLR v4, and he posted it to the Channel 9 videos site yesterday.

I start out talking about the security policy changes I've been covering here over the last week, and then transition into an overview of some of the transparency changes that I'll be talking about once I finish with the policy changes.

(The full video is also available here: http://channel9.msdn.com/posts/Charles/Shawn-Farkas-CLR-4-Inside-the-new-Managed-Security-Model/)

Visual Studio 10 Security Tab Changes

shawnfa — Thu, 28 May 2009 17:00:00 GMT

Kris Makey, who works on the Visual Studio team, has written up a good blog post about the changes you’ll see on the security tab in Visual Studio 10 when it comes to editing permission sets. He covers what the changes are, and some of the reasons why we worked with the Visual Studio team to make those changes.

Coding with Security Policy in .NET 4.0 – Implicit uses of CAS policy

shawnfa — Wed, 27 May 2009 20:46:59 GMT

Last week we looked at sandboxing and the v4 CLR – with the key change being that the CLR now defers exclusively to the host application when setting up sandboxed domains by moving away from the old CAS policy model, and moving instead to simple sandboxed AppDomains.

This leads to an interesting situation when your program calls APIs that assume the presence of CAS policy, either implicitly [for example, Assembly.Load(string, Evidence)] or explicitly [for example SecurityManager.PolicyHierarchy]. These APIs require CAS policy in order to return correct results, however by default there is no longer CAS policy to apply behind the scenes anymore.

Let’s take a look at what happens if these APIs are called, and what should be done to update your code to take into account the new security policy model.

(In addition to this blog post, the CLR security test team is preparing a set of blog posts about how they moved our test code base forward to deal with these and other v4 security changes – those posts will provide additional advice about how to replace uses of obsolete APIs based upon the real world examples they’ve seen).

In general, APIs that assume the presence of CAS policy have been marked obsolete, and will give a compiler warning when you build against them:

Microsoft (R) Visual C# 2010 Compiler version 4.0.20506    
Copyright (C) Microsoft Corporation. All rights reserved.     
    
obsolete.cs(32,1): warning CS0618: '<API Name>' is     
        obsolete: 'This method is obsolete and will be removed in a future     
        release of the .NET Framework. Please use <suggested alternate API>. See     
        http://go.microsoft.com/fwlink/?LinkId=131738 for more information.'     

Additionally, these APIs will throw a NotSupportedException if they are called at runtime:

Unhandled Exception: System.NotSupportedException: This method uses CAS policy, which has been obsoleted by the .NET Framework. In order to enable CAS policy for compatibility reasons, please use the NetFx40_LegacySecurityPolicy configuration switch. Please see http://go.microsoft.com/fwlink/?LinkId=131738 for more information.

(In the beta 1 release, this message is slightly different:)

Unhandled Exception: System.NotSupportedException: This method uses CAS policy, which has been obsoleted by the .NET Framework. In order to enable CAS policy for compatibility reasons, please use the legacyCasPolicy configuration switch. Please see http://go2.microsoft.com/fwlink/?LinkId=131738 for more information.

Let’s take a look at the set of APIs which make implicit use of CAS policy first, and then see what they might be replaced with in a v4.0 application.

The general way to recognize an API which is implicitly using CAS policy is that they tend to take an Evidence parameter which was used to resolve against CAS policy and provide a grant set for an assembly. For instance:

Activator.CreateInstance and Activator.CreateInstanceFrom overloads which take an Evidence parameter
AppDomain.CreateInstance, AppDomain.CreateInstanceFrom, AppDomain.CreateInstanceAndUnwrap, and AppDomain.CreateInstanceAndUnwrap overloads which take an Evidence parameter
AppDomain.DefineDynamicAssembly overloads which take an Evidence parameter
AppDomain.ExecuteAssembly and AppDomain.ExecuteAssemblyByName overloads which take an Evidence parameter
AppDomain.Load and AppDomain.LoadFrom overloads which take an Evidence parameter
Assembly.Load and Assembly.LoadFrom overloads which take an Evidence parameter

It’s important to note that although these APIs all take Evidence parameters, the concept of Evidence itself is not deprecated and continues to exist (and even enhanced in v4.0 – but that’s another show). Evidence itself is still a useful tool for hosts to use when figuring out what grant sets they want to give assemblies. The common thread with these APIs is that they used the Evidence to resolve against CAS policy – and it’s the CAS policy portion that’s been deprecated in v4.

Let’s say that your application is using one of the Evidence-taking overloads of these APIs, and thus had an implicit dependency on CAS policy. Figuring out what to replace the API call with depends upon what your application was trying to accomplish with the API call.

We’ve found that commonly the goal of calling one of these APIs was not to sandbox the assembly being loaded, but rather to access other parameters on the overload which may not be available without also providing Evidence. In these cases, you can go ahead and just drop the Evidence parameter from the API. We’ve ensured that all of the above APIs now have overloads that provide the full set of parameters without requiring an Evidence parameter.

Additionally, in many cases we’ve found that code passes in Assembly.GetExecutingAssembly().Evidence or simply null to the Evidence parameter. In both of those cases, it’s safe to simply call an overload of the API which does not require an Evidence parameter as well.

The other reason to provide Evidence when calling these APIs is to sandbox the assembly in question. The correct way to do this in v4 (and the best way to do this in v2.0 and higher of the .NET Framework) is to simply load the assembly into a simple sandboxed AppDomain. The assembly will then be sandboxed by virtue of the fact that it’s loaded in the sandboxed domain, and you will no longer need to load the assembly with an Evidence parameter to restrict its grant set.

I’ve listed the benefits of using simple sandboxed domains before, and they continue to apply in this scenario. For example, using a simple sandbox rather than an Evidence resolve to sandbox assemblies allows your application:

To be in charge of its own sandbox. The load-with-Evidence route took a dependency on what the grant set that the CLR would give the assembly was. That grant set could change from version to version of the CLR (since each version has independent CAS policies), and even from user to user. This makes supporting your application more difficult than it needs to be – with simple sandboxing there are no external dependencies for grant set resolution – your application is in charge of its own sandboxes
To setup real isolation boundaries – hosting multiple levels of partial trust code within a single AppDomain turns out to be incredibly difficult to do correctly. Further, hosting partial trust code in a domain wtih full trust code that does not expect to be run along with partial trust code also turns out to be problematic from a security perspective. By isolating the partial trust code in its own sandboxed domain, a real isolation boundary is setup for the code and your application is kept much more secure by default.
To have version and bitness independence – I touched on this in the first point, but to reiterate it, your application is no longer dependent upon each version of the CLR’s security policy to be setup in the same way, as well as each bitness of the policy within a single version.

So, to summarize, if you’re using one of the Evidence taking APIs which would have resolved an assembly’s grant set against CAS policy in the past:

Use	Replacement
Passing null, Assembly.GetExecutingAssembly().Evidence, or AppDomain.CurrentDomain.Evidence	Call an overload which does not require an Evidence parameter.
Using a parameter of the API which was only available on an overload taking an Evidence parameter as well.	Call one of the newly added overloads which provides access to your parameter without requiring Evidence.
Sandboxing the assembly being loaded.	Load the assembly into a sandboxed AppDomain, and let the domain do the sandboxing. This will remove the need for the Evidence parameter.

Next time, I’ll look at the explicit uses of CAS policy, and what their replacements should be.

Sandboxing in .NET 4.0

shawnfa — Fri, 22 May 2009 20:54:00 GMT

Yesterday I talked about the changes in security policy for managed applications, namely that managed applications will run with full trust - the same as native applications - when you execute them directly.

That change doesn’t mean that managed code can no longer be sandboxed however - far from it. Hosts such as ASP.NET and ClickOnce continue to use the CLR to sandbox untrusted code. Additionally, any application can continue to create AppDomains to sandbox code in.

As part of our overhaul of security policy in v4, we made some interesting changes to how that sandboxing should be accomplished as well. In previous releases, the CLR provided a variety of ways to sandbox code – but many of them were problematic to use correctly. In the v4 framework, we made it a goal to simplify and standardize how sandboxing should be done in managed code.

One of the key observations we made about sandboxing is that there really isn’t a good reason for the CLR to be involved in the decision as to what grant set should be given to partial trust code. If your application says “I want to run this code with ReflectionPermission/RestrictedMemberAccess and SecurityPermission/Execution”, that’s exactly the set of permissions that the code should run with. After all, your application knows much better than the CLR what operations the sandboxed code can be safely allowed to undertake.

The problem is, sandboxing by providing an AppDomain policy level doesn’t provide total control to the application doing the sandboxing. For instance, imagine you wanted to provide the sandbox grant set of RestrictedMemberAccess + Execution permission. You might setup a policy level that grants AllCode this grant set and assign it to the AppDomain. However, if the code you place in that AppDomain has evidence that says it came from the Internet, the CLR will instead produce a grant set that doesn’t include RestrictedMemberAccess for the sandbox. Rather than allowing safe partial trust reflection as you wanted, your sandbox just became execute-only.

This really doesn’t make sense – what right does the CLR have to tell your application what should and should not be allowed in its sandboxes? In the v1.x release of the runtime, developers had to go to great lengths in order to ensure they got the grant set they wanted. (Eric Lippert’s CAS policy acrobatics to get VSTO working correctly is the stuff of legends around the security team – fabulous adventures in coding indeed!).

As many a frustrated application developer found out, intersecting with the application supplied grant set was only the tip of the iceburg when it came to the difficulties of coding with CAS policy. You would also run into a slew of other problems – such as each version of the CLR having an entirely independent security policy to deal with.

In v2.0, we introduced the simple sandboxing API as a way for applications to say “This is the grant set I want my application to have. Please don’t mess with it.”. This went a long way toward making writing an application which sandboxes code an easier task.

Beginning with v4.0, the CLR is getting out of the policy business completely. By default, the CLR is not going to supply a CAS policy level that interferes with the wishes of the application that is trying to do sandboxing.

Effectively, we’ve simplified the multiple ways that you could have sandboxed code in v3.5 into one easy option – all sandboxes in v4 must be setup with the simple sandboxing API.

This means that the days of wrangling with complicated policy trees with arbitrary decision nodes in them are thankfully a thing of the past. All that’s needed from here on out is a simple statement: “here is my sandboxed grant set, and here are the assemblies I wish to trust.”

Next time, I’ll look at the implications of this on code that interacts with policy, looking at what you used to write, and what it would be replaced with in v4.0 of the CLR.

Security Policy in the v4 CLR

shawnfa — Thu, 21 May 2009 22:03:38 GMT

One of the first changes that you might see to security in the v4 CLR is that we’ve overhauled the security policy system. In previous releases of the .NET Framework, CAS policy applied to all assemblies loaded into an application (except for in simple sandbox domains).

That lead to a lot of interesting problems. For instance, one of the more common issues people ran into was that they would develop an application on their local machine that they wanted to share with other people on the network. Once the application was working on their machine, they would share it out, but nobody could run it over the network because CAS policy provided a lower grant set to assemblies loaded from the intranet than it does to assemblies loaded from the local machine. The usual result was unexpected and unhandled SecurityExceptions when trying to use the application.

Generally, the only solution to this problem was to either manually update the CAS policy on each machine that wanted to run the application, deploy the application some other way (for instance via ClickOnce), or use native code.

One of the worst things about this problem was that the additional pain of not being able to just share a managed app over the network wasn’t actually buying any security. If an application wanted to attack your machine, it could bypass the sandbox that the CLR was setting up simply by being written in native code.

Effectively, running an executable is a trust decision – you’re saying that you trust the application that you’re running enough to execute with the privileges your Windows account has.

That leads to an interesting observation – the CLR isn’t the correct place to be setting permission restrictions for applications that are being launched directly (either from the command prompt, or from Windows explorer for instance). Instead, that should be done through Windows itself using mechanisms like SRP, which apply equally to both managed and native applications.

In the v3.5 SP1 release, these observations (writing managed code to use on the network was harder than it needed to be, and it wasn’t even buying any extra security) led us to relax CAS policy for LocalIntranet applications slightly. We enabled applications that were run directly from an intranet share (and any assemblies loaded from immediately next to that application) to be fully trusted by pretending that it had MyComputer zone evidence instead of LocalIntranet.

In the v4.0 release of the runtime, the CLR has taken that a step further. By default, unhosted applications are not subject to managed security policy when run under v4.0. Effectively, this means any managed application that you launch from the command prompt or by double clicking the .exe in Windows Explorer will run fully trusted, as will all of the assemblies that it loads (including assemblies that it loads from a location other than the the directory where the executable lives).

For applications run from the local machine, there really should be no observable change. However, for applications that are shared out over a network, this means that everything should just work – just as if you had run the application from your computer while you were developing it.

One very important point about this change is that it specifically applies only to unhosted code. In my next post, we’ll look at what v4.0 security policy means for CLR hosts.

.NET 4.0 Security

shawnfa — Thu, 21 May 2009 01:58:00 GMT

The first beta of the v4.0 .NET Framework is now available, and with it comes a lot of changes to the CLR's security system. We've updated both the policy and enforcement portions of the runtime in a lot of ways that I'm pretty excited to finally see available. Since there are a lot of security changes, I'll spend the next month or so taking a deeper look at each of them. At a high level, the major areas that are seeing updates with the v4 CLR are:

Security policy
Security transparency
APTCA
Evidence
AppDomain Managers

Like I did when we shipped the v2.0 CLR, I'll come back and update this post with links to the details about each of the features we added as I write more detailed blog posts about each of them.

Tomorrow, I'll start by looking at probably the most visible change of the group - the update to the CLR's security policy system.

FullTrust on the LocalIntranet

shawnfa — Mon, 12 May 2008 20:49:36 GMT

We released the first beta of .NET 3.5 SP 1 this morning, and it includes a change to the default grant set for applications launched from the LocalIntranet zone. The quick summary is that as of .NET 3.5 SP1, applications run from a network share will receive a grant set of FullTrust by default, making them act the same as if they were launched off of your computer directly. Since this is an issue that I know a lot of people run into, I hope that this change makes it easier to use and deploy managed applications. For people who want to keep their machines working the same as they did for previous .NET Framework releases, you can set the DWORD registry value LegacyMyComputerZone to 1 in the HKLM\Software\Microsoft\.NETFramework registry key.

With the high-level summary out of the way, let's take a look under the hood to see what changed to make this possible :-)

The core of this change is a modification in how we assign evidence to network launched applications. When we see an .exe launched directly off a network share, rather than giving that .exe Zone evidence of LocalInranet, we instead give the .exe Zone evidence of MyComputer. This causes the .exe to match the default MyComputer code group rather than the LocalIntranet group, and in default CAS policy that code group grants FullTrust. (This also explains why the opt-out registry value is named LegacyMyComputerZone)

In addition to the entry point .exe of the application, we'll also extend this MyComputer evidence to any assembly loaded from the same directory as the .exe. So, if you place any managed .dll's immediately next to your .exe, those will also all be given FullTrust by default in .NET 3.5 SP1.

Since we're only including assemblies loaded from the same directory as the entry point application, things will just work for most applications, however more complicated programs that need to load assemblies from different subdirectories or other network shares may not see all of their assemblies get fully trusted by default. For these more types of applications, ClickOnce deployment is the recommended way to elevate to FullTrust.

We've specifically disabled this change for any hosted applications. So this means that if your program uses the CorBindToRuntime API to host the CLR, we won't start trusting assemblies it loads from a share. Similarly, hosts like Internet Explorer will not start trusting controls that it loads into the browser.

To summarize the under the hood changes, assemblies which will now receive Zone evidence of MyComputer and therefore be fully trusted by default are:

Any managed .exe which is launched directly from a network share
Any assembly in that .exe's process which is loaded from the same directory as the .exe itself was.

Assemblies which will not see this change include:

Assemblies loaded from a subdirectory of the share where the .exe was launched from
Assemblies loaded from shares other than the one where the main .exe was launched
Any assembly loaded on a machine with the LegacyMyComputer registry value set to 1
Any assembly loaded into a CLR host, including assemblies loaded into Internet Explorer as controls.
Any assembly loaded from shares by an application that was launched from the "real" MyComputer zone.

CAS and Native Code

shawnfa — Tue, 04 Mar 2008 21:27:41 GMT

CAS is complicated enough to understand when all of the moving parts are written in managed code (and therefore have all the associated managed meta-information like grant sets, etc). However, once native code comes into play things can get even more confusing. Let's take a look at how CAS works when there's native code on the call stack.

For this discussion, lets assume we have a call stack (growing down) like so:

Managed code: M1

Managed code: M2

Native code: N1

Managed code: M3

Managed code: M4

AppDomain: AD

So in this example, M1 calls M2, which calls N1, which calls back to managed code M3 and M4. All of the managed objects live in AppDomain AD.

Full Demands

Now lets consider what happens when M4 triggers a full stack walk for a demand. In this case, the CLR essentially ignores the native code on the stack, and does a stack walk looking at M3, M2, M1, and AD. Intuitively, this is done because the native code doesn't have a grant set associated with it, and therefore including it on a CAS stack walk wouldn't make much sense.

It's important to note however that the stack walk proceeds through N1, rather than stopping at it. So in this case if M3 and M2 are fully trusted, but M1 is partial trust and M4 triggered a FullTrust demand, that demand would fail.

Stack walk modifiers like Assert continue to work just as you would expect as well, so it's perfectly legal for M2 to Assert FullTrust, which would make M4's demand succeed.

Link Demands

Link demands are much more interesting when native code gets involved. In our example, imagine that managed method M3 has a LinkDemand for FullTrust on it. Normally, LinkDemands are evaluated at JIT time against the caller of the method with the demand. But in this case, the caller of M3 is native code which is not JITed (and doesn't have a grant set to evaluate against in any event).

The obvious solution then is to evaluate the LinkDemand against the last managed frame on the call stack before we transitioned to native code. At the time we're JITing this method however, we only know that it's calling a native method -- we don't know what managed code that native code is going to turn around and call later on. In this example, when M2 is being JITed we know that it may call N1, however we don't know that N1 will turn around and call M3 and therefore don't know that M3 has as a LinkDemand to evaluate against M2.

However, it turns out that we don't need to know what M3 is going to LinkDemand of M2. Since M2 is calling N1, it must have UnmanagedCode permission, and since UnmanagedCode permission is never handed out without FullTrust, we can reason that M2 must be fully trusted. If M2 is fully trusted, then it will satisfy any LinkDemand that M3 will require.

With this analysis, we could say that LinkDemands are implicitly satisfied by native code callers. However, that may not be the effect that we want in all cases. For instance, one common scenario might be to expose a managed object via COM Interop to a script. (For instance, make a managed object available via COM to some JavaScript in a web page).

From the CLR's perspective, this script is just native code, so our reasoning would lead to any link demands on methods the script calls being satisfied. However, we may not want the script to satisfy all link demands. In order to solve this problem, the CLR treats calls to managed code from native via COM Interop differently.

If native code uses a COM interface to call a managed method protected with a LinkDemand, then that LinkDemand is evaluated against the AppDomain which the managed object lives in.

Let's go back to our example again, and see how these rules apply. Let's suppose that N1 calls M3 through COM Interop, M3 has a LinkDemand for FullTrust, and the AppDomain AD is also fully trusted. In this case, the call succeeds because the AppDomain's grant set satisfies M3's LinkDemand.

Now let's consider the case where this AppDomain is hosted by Internet Explorer, and therefore has only the Internet grant set. When N1 calls into M3, we'll see that the object M3 is being called on lives in AppDomain AD, and that causes us to look up the grant set of that domain. We then check M3's LinkDemand for FullTrust against the AppDomain's grant set of Internet. Since the AppDomain's grant set does not satisfy the LinkDemand, we throw a SecurityException. Note that this is true even if the last managed frame on the stack (M2) is fully trusted.

If we make one more change to the scenario, and have N1 call M3 via reverse P/Invoke we a different result. Even though the AppDomain is partially trusted, since M3 was not invoked from COM Interop, we allow the call to succeed.

3 Rules for Native Code CAS Evaluation

That's a ton of complexity, but thankfully we can boil it down to three rules depending upon your scenario:

If a full demand is done, native stack frames are ignored and the stack walk proceeds exactly as if there were only managed frames on the stack.
If a link demand is done via COM Interop, the link demand is evaluated against the grant set of the AppDomain that the managed object lives in.
If a link demand is done via reverse P/Invoke, the link demand is satisfied and the call succeeds.

Manifested Controls Redux

shawnfa — Thu, 24 Jan 2008 21:00:00 GMT

Last year, I made a series of posts about a new feature available in the betas of .NET 3.5 which enabled you to specify declaratively the set of permissions that IE hosted managed controls should run with. Since the betas there have been a couple of tweaks to the manifest control model, so those posts need a refresh.

Most notably, the Low Safety (Unrestricted) setting for the Permissions for Components with Manifests URL action is not a part of the final shipping Orcas bits. Instead, the two options are:

High Safety - manifested controls can run with the permissions it requests, but only if those permissions are a subset of the permissions it would have been granted by CAS policy or if the manifests are signed by a trusted publisher.
Disabled - manifested controls may not run at all.

If you're using a machine that had one of the .NET 3.5 betas on it, the Low Safety option will still appear in your Internet Explorer dialog box, however the CLR will treat a value of Low Safety as if it were Disabled.

A lot of times when people look at this feature, they would like a full end-to-end sample of a control in a web page taking advantage of a manifest to elevate its permissions. I've attached a ZIP file containing a sample control to this post.

In order to use this sample:

Create a ManifestControl subdirectory in your wwwroot.
Copy ManifestControl.control, ManifestControl.dll, ManifestControl.dll.manifest, and ManifestControl.html to the ManifestControl directory created in step 1.
Ensure that your web server is setup to allow downloading of .dll, .control, and .dll.manifest files.
Install ManifestControl.cer in your Trusted Publishers certificate store.
Install ManifestControl.cer in your Trusted Root Certification Authorities certificate store. (Once you are done with the sample, the test certificate should be removed from both of these certificate stores)
Navigate Internet Explorer to http://localhost/ManifestControl/ManifestControl.html

Transparency as Least Privilege

shawnfa — Tue, 30 Oct 2007 21:35:29 GMT

In my last post I mentioned that there is a better alternative to RequestRefuse for achieving least privilege. The tool I like to use for least privilege is actually the security transparency model available in v2.0+ of the CLR (and which became the basis of the Silverlight security model).

On the desktop CLR, transparent code cannot elevate the privileges of the call stack in any way. Let's take a quick look at how this is enforced:

Uverifiable code - if a transparent method contains unverifiable code, the CLR injects a demand for SecurityPermission/UnmanagedCode.

Satisfy a LinkDemand - LinkDemands satisfied by a transparent method are converted into full demands

Use the SuppressUnmanagedCodeAttribute - this is really an extension of the LinkDemand rule. the SuppressUnmanagedCodeAttribute converts the full demand for SecurityPermission/UnmanagedCode into a LinkDemand for the same permission. However, since link demands satisfied by transparent code are converted into full demands, the net effect is that SuppressUnmanagedCodeAttribute becomes a no-op.

Assert permissions - Asserts are an explicit attempt to elevate the permissions of the call stack, and are therefore disallowed in transparent code. They are not converted into full demands

Call critical code without going through a TreatAsSafe layer - the treat as safe layer is responsible for validating inputs and outputs of critical code, and transparent code must access critical code via this layer. Attempts to call critical code or access critical data directly are disallowed.

This effectively means that fully trusted transparent code runs "as caller". It won't cause any security demands to fail, however it won't cause them to succeed either. If the caller of the transparent code is allowed to do the security operation it will succeed, otherwise it fails.

What's interesting is that if we take this principal to the extreme, and have the entire call stack be transparent (such as in Silverlight), transparency transitions from running "as caller" to running "as application". This is because each level in the transparency call chain passes the security demand up to its caller, until we hit the top of the stack -- and find the AppDomain. Since all security demands end up going against the AppDomain's permission set, that permission set alone controls what may happen within the domain.

In this way, my fully trusted code will be fully trusted if it is run within a FullTrust domain. However, that same code run within an AppDomain with the Internet permission set (perhaps if it's being used by a control in the browser), will effectively be running with Internet permissions. Any demand for a permission outside of the Internet permission set will be passed along until it hits the AppDomain and fail.

Let's say that you're writing an application that you know will never need to interact with native code. You'd normally do a RequestRefuse for UnmanagedCode permission on your application's assemblies to ensure that it's never accidentally satisfying an UnmanagedCode demand. Instead of doing that, you can make sure that your application assemblies are entirely transparent and that they are run in a domain without UnmanagedCode permission -- perhaps via ClickOnce deployment.

This way you can use ClickOnce to explicitly control the grant set of the applicaiton, and transparency to ensure that you're not accidentally causing an elevation outside of that call stack, even if some of your application is installed in the GAC and fully trusted.

Avoiding Assembly Level Declarative Security

shawnfa — Tue, 02 Oct 2007 19:24:36 GMT

I've written in the past about the three assembly level declarative security actions: RequestMinimum, RequestOptional, and RequestRefuse. Although the CLR has supported these since v1.0, I tend to stay away from using them as much as I possibly can, and also recommend that others avoid them as well. Let me go through each one individually:

RequestMinimum

RequestMinimum is the most common of the three, and in fact is mentioned by a FxCop rule and automatically inserted by the C# compiler in some cases. There are several reasons I don't like to use this security action.

The first problem I have with RequestMinimum is a usability problem stemming from the fact that if your assembly is not granted its RequestMinimum permission set, the CLR will refuse to load it by throwing an exception. If the assembly in question happens to be the entry point of my application, that means the user of my app ends up staring down an unhandled exception dialog (since my code never got loaded, and therefore never had a chance to handle this error more gracefully). If my mother runs an app I give her and it throws a FileLoadException due to insufficient permissions, she's not going to have any idea what to do with that.

Even if the assembly is not the entry point assembly, gracefully handling failure to load due to RequestMinimum means that an application needs a try ... catch around every code path which could potentially lead to loading the assembly in question; that's not something that a lot of applications are setup to do.

The other problem I find with RequestMinimum is that in the case of writing a shared library it's very difficult to figure out what the correct grant set to request is. Unless all of the APIs being exposed require the same set of permissions, having only a single RequestMinimum set doesn't help much. For instance, an assembly like System.dll exposes hundreds of classes each with indivdual permission requirements varying from SecurityPermission/Execution to FullTrust. If we decided to use the minimum grant set of any API in the assembly as the ReuqestMinimum, we've somewhat defeated the purpose of the security action; now I cannot be assured that the assembly loading means that it has the required permissions to work in all cases. On the other hand, if I use the maximum grant set required, the assembly won't load even if an application was only intending to use APIs that would work in the grant set that the assembly is loaded into.

Finally, since security demands go against the entire call stack, even if the assembly in question has all the permissions that it needs to run doesn't mean that all assemblies and AppDomains on the call stack will have those permissions. So even if an assembly does have its minimum grant set met, it doesn't have any guarantee that its APIs will all work without throwing a SecurityException.

RequestOptional

RequestOptional is probably the least commonly used assembly level security action, and with good reason. This security action is somewhat poorly named, and people who use it for the first time often don't realize that it will actually remove permissions from your grant set. In fact, I run across RequestOptional most commonly when helping someone debug a SecurityException that they can't figure out. ("Why does this exception occur? All assemblies should be fully trusted!")

Even once you do understand the full effect of RequestOptional, the fact that it is confusingly named and that most people do not understand it is argument enough for me to stay away. Code readability is extremely important, and if I can expect that the next person to read through my code will be confused by that RequestOptional I stuck on my assembly, that's not a good thing -- especially when it comes to security.

RequestRefuse

I expect this is the most controversial security action to take a stance against. A good number of people probably use RequestRefuse as a least-privilege mechanism. My problem with that is that you're stating "I don't want permissions A and B", however when someone comes along and introduces permission C you haven't refused it, and therefore you still get it. Personally, I believe the CLR has other, much better, least-privilege mechanisms available -- and I prefer to use those whenever possible. (Sounds like the topic of a future blog post :-) ).

Finally, and this should come as no surprise to any regular visitors, I'm a huge fan of the model where every sandboxed AppDomain has exactly two permission sets -- FullTrust and one sandbox grant set. RequestRefuse (and RequestOptional) both detract from this model by creating multiple permission sets within an otherwise homogenous AppDomain. By keeping AppDomains entirely homogenous, it's much easier to reason about security within the domain. And, in my opinion, keeping the security model as simple as possible can only be goodness -- complexity can lead to mistakes in reasoning, which leads to security holes.

So What Instead?

Some of the abilities promised by the assembly level declarative security actions seem to be very useful at first glance. Notably the ability to specify a grant set that the code was tested to run in (which is what RequestMinimum seems to promise) and the ability to run with least privilege (via RequestRefuse).

For RequestMinimum, I think that ClickOnce is a far superior alternative for a variety of reasons. Most importantly, ClickOnce gives the user of the application a nicer experience when the application does not by default meet the minimum grant set. Rather than throwing an exception in the face of a non-developer, a friendly user interface is displayed which may even offer the ability to grant the application the ability to run.

Also, the grant set specified for a ClickOnce application applies to all of the assemblies in the application as well as the AppDomain (hey -- it's my favorite homogenous model again!). This means that you don't have to worry about the scenario where your assembly meets its minimum grant set, but some APIs still fail with SecurityExceptions because another assembly further up the call stack did not meet the minimum grant set.

That covers RequestMinimum -- but what about the least privilege promise of RequestRefuse? As AB might say -- that's another show.