Last week I covered security transparency in CLR 2.0 by looking at topics like how transparency can reduce your security footprint, using transparency in CLR 2.0, and transparent code behavior in CLR 2.0.

As you may have noticed, the transparency story changes in .NET 4. It would be too much to write about everything that has changed, so I’ll address the high-level points in this post and build on that foundation in future posts.

In the second version of the CLR, which includes .NET 2.0 to .NET 3.5 SP1, transparency’s goal was to separate code into layers to reduce time needed for security audits. The rationale was most code in an assembly is transparent and thus doesn’t require a lot of attention because it doesn’t do anything interesting from the point-of-view of security (like call unmanaged code or unverifiable code). The critical code is what requires careful scrutiny.

.NET 4 has improved security transparency by making it a full-fledged enforcement mechanism for these invariants. Consider one of the differences between the models. Transparent code in CLR 2.0 can still call unmanaged code (through P/Invoke, COM Interop) if it has UnmanagedCode permissions. However, since native code isn’t governed by the permission set of the AppDomain, this is a potentially dangerous operation. This means that you still had to audit transparent code in CLR 2.0 in case it called unmanaged code. In CLR 4.0, an Exception is thrown when transparent code attempts to call native code, regardless of its grant set.

Transparent code still can’t assert for permissions, and it still can’t satisfy a demand for permissions. One change, though, is that in CLR 2.0, LinkDemands were converted to full Demands if a transparent method called a method with that LinkDemand. In CLR 4.0, transparent code cannot satisfy a LinkDemand, and an Exception is thrown.

Another means by which the enforcement is improved is the emergence of a more rigid boundary between transparent code and critical code. In CLR 2.0, transparent code in assembly Foo can call public critical code in assembly Bar. In CLR 4.0, again, an Exception is thrown. The transparency rules are now fully enforced across assembly boundaries. Transparent code cannot call any critical code directly. End of story.

In order for transparent code to call critical code now, it must call it via a method that is marked with the System.Security.SecuritySafeCriticalAttribute. This essentially replaces the need for the SecurityTreatAsSafeAttribute (which I discussed in the CLR 2.0 transparency post). You can think of safe critical code as a gateway for transparent code to call critical code. The restriction is only one way, however—that is, security critical code can call transparent code without problems.

There is so much more to cover with regards to transparency in .NET 4 that I think this is a good stopping point for today. If you can’t wait for more information, you can read the documentation as well as watch a Channel 9 interview of Shawn Farkas, a Senior SDE on the CLR security team, where he digs into the new security rules in .NET 4. Enjoy!