Using SecAnnotate to Analyze Your Assemblies for Transparency Violations – An Example

SecAnnotate (available in the final .NET 4 SDK, and in beta form here) can be used to analyze your assemblies, especially APTCA assemblies in order to find transparency violations without needing code coverage from a test case.  Instead, the static analysis provided by SecAnnotate is valuable in ensuring that your assembly is fully correct from…

0

SecAnnotate Beta

One of the design goals of the security transparency system in the CLR is that it should be as static as possible and not rely on dynamic state (such as the call stack) to function.  A fallout of this is that we can write tools to analyze assemblies and find transparency violations in the assembly…

0

Differences Between the Security Rule Sets

In my last post I talked about the two different security rule sets supported by the v4 CLR.  At a high level, level 1 is the v2.0 security transparency model, and level 2 encompasses the updated v4 security transparency model.  Digging down a little deeper, it’s interesting to look at some of the exact details…

0

Transparency Models: A Tale of Two Levels

Earlier this week, we looked at how the v4 CLR continued the evolution of the security transparency model that started in v2 and started evolving with Silverlight in order to make it the primary security enforcement mechanism of the .NET 4 runtime. The result is that the v4 transparency model, while having roots in the…

0

Transparency as Enforcement in CLR v4

Now that we know the basics of security transparency, let’s look at how it evolved over time.  In .NET v2.0, many of the transparency rules we previously looked at were in place, with the exception of some of the inheritance rules that were introduced for the first time in the Silverlight transparency implementation. However, in…

0

Bridging the Gap Between Transparent and Critical Code

Last time we looked at the set of operations that can only be performed by security critical code. One interesting observation is that just because you are doing one of these operations does not mean that your method in and of itself is security sensitive. For instance, you might implement a method with unverifiable IL…

0

Transparency 101: Basic Transparency Rules

One of the biggest changes in the .NET 4 security model is a move toward security transparency as a primary security enforcement mechanism of the platform. As you’ll recall, we introduced security transparency in the v2 release of .NET as more of an audit mechanism in order to help make the surface area of APTCA…

1

CLR v4 Security Policy Roundup

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 Security Policy in the v4 CLR Sandboxing in .NET 4.0 Updating code to work with the new model Implicit uses…

3

Temporarily re-enabling CAS policy during migration

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…

4

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

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…

1