.net, microsoft, security, windows

The end of Code Access Security in Microsoft .NET

7 Comments

In the early days of .NET I remember being hugely impressed by Code Access Security. It gave administrators total control over what .NET code was permitted to run. It’s true that the configuration tool was a little intimidating, but there were even wizards to adjust .NET security, trust an assembly, or fix an application – great idea, that last one.

image

Well, now the truth is out. Code Access Security was too complex for humans to configure. Buried deep in the documentation for .NET Framework 4.0 you can find Microsoft’s confession, under the heading Security Policy Simplification:

In the .NET Framework 4 Beta 2, the common language runtime (CLR) is moving away from providing security policy for computers. Historically, the .NET Framework has provided code access security (CAS) policy as a mechanism to tightly control and configure the capabilities of managed code. Although CAS policy is powerful, it can be complicated and restrictive. Furthermore, CAS policy does not apply to native applications, so its security guarantees are limited. System administrators should look to operating system-level solutions such as Windows Software Restriction Policies (SRP) as a replacement for CAS policy, because SRP policies provide simple trust mechanisms that apply to both managed and native code. As a security policy solution, SRP is simpler and provides better security guarantees than CAS.

The section below, headed Obsolete Permission Requests, is even more damning of the old system:

Runtime support has been removed for enforcing the Deny, RequestMinimum, RequestOptional, and RequestRefuse permission requests. In general, these requests were not well understood and presented the potential for security vulnerabilities when they were not used properly.

It goes on to explain why they did not work, with explanations like this one for RequestOptional:

RequestOptional was confusing and often used incorrectly with unexpected results. Developers could easily omit permissions from the list without realizing that doing so implicitly refused the omitted permissions.

The new .NET Framework 4.0 no longer enforces these obsolete permissions.

Microsoft is right. As far as I’m aware, few used the .NET Configuration tool, and I cannot even find it in Windows 7, even though Visual Studio and all the versions of the .NET Framework are installed. Developers feared, with justification, that tinkering with the settings would simply cause mysterious exceptions that were hard to resolve.

I recall though that Code Access Security was considered a highly strategic feature when .NET was first released. One of the promises of .NET was that applications would be more secure and malware less prevalent. The fine-grained permissions were a selling point versus Java.

The painful lesson is that simplicity is a feature. Of course some things are inherently complex; but technology succeeds when it simplifies rather than complicates the tasks that we face.

7 thoughts on “The end of Code Access Security in Microsoft .NET”

  2. Hi,

    I’m a Program Manager who worked on security in .NET 4. I wanted to make a small clarification – Code Access Security (CAS) itself is still alive and supported; it’s CAS _Policy_ that is no longer supported. This means the permissions themselves and the assert and demand stackwalk modifiers are still supported, and are used in conjunction with new mechanisms we’ve added to the security model to improve the managed code security story.

    We did make obsolete the runtime security policy and its configuration tools as well as some other permission operations that were being misunderstood (with severe consequences). However, there still is a security model (and ASP.NET Medium Trust is still there – it’s just built on our new mechanisms), and we still provide (simpler) mechanisms to safely run code in partially trusted environments. We haven’t given up on security, but, like you said, we did learn some painful lessons and stuck with simplicity for this release. =)

    Thank you,
    Andrew Dai
    Program Manager
    Microsoft Common Language Runtime – Security

  3. I’m new to the concept of CAS and i can’t help wondering about its success rate. Is it that efficient against malware?

  4. Thanks Andrew for your explanation, but now – how does one change the security model to “Full Trust” (I need to do this for Local Intranet.)

    Angus.

    1. True, but it is a security feature. In other words, it was introduced for security reasons, pushing developers to create applications that run correctly without local admin rights.

      Tim

Comments are closed.