{"id":2156,"date":"2010-01-20T10:51:05","date_gmt":"2010-01-20T09:51:05","guid":{"rendered":"http:\/\/www.itwriting.com\/blog\/2156-the-end-of-code-access-security-in-microsoft-net.html"},"modified":"2010-01-20T10:51:05","modified_gmt":"2010-01-20T09:51:05","slug":"the-end-of-code-access-security-in-microsoft-net","status":"publish","type":"post","link":"https:\/\/www.itwriting.com\/blog\/2156-the-end-of-code-access-security-in-microsoft-net.html","title":{"rendered":"The end of Code Access Security in Microsoft .NET"},"content":{"rendered":"

In the early days of .NET I remember being hugely impressed by Code Access Security<\/a>. It gave administrators total control over what .NET code was permitted to run. It\u2019s 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 \u2013 great idea, that last one.<\/p>\n

\"image\"<\/a> <\/p>\n

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\u2019s confession<\/a>, under the heading Security Policy Simplification:<\/p>\n

\n

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.<\/p>\n<\/blockquote>\n

The section below, headed Obsolete Permission Requests, is even more damning of the old system:<\/p>\n

\n

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.<\/p>\n<\/blockquote>\n

It goes on to explain why they did not work, with explanations like this one for RequestOptional:<\/p>\n

\n

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.<\/p>\n<\/blockquote>\n

The new .NET Framework 4.0 no longer enforces these obsolete permissions.<\/p>\n

Microsoft is right. As far as I\u2019m 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n","protected":false},"excerpt":{"rendered":"

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\u2019s 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 \u2013 … Continue reading The end of Code Access Security in Microsoft .NET<\/span> →<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2,55,75,97],"tags":[104,586,810],"class_list":["post-2156","post","type-post","status-publish","format-standard","hentry","category-net","category-microsoft","category-security","category-windows","tag-net","tag-microsoft","tag-security"],"_links":{"self":[{"href":"https:\/\/www.itwriting.com\/blog\/wp-json\/wp\/v2\/posts\/2156","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.itwriting.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.itwriting.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.itwriting.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.itwriting.com\/blog\/wp-json\/wp\/v2\/comments?post=2156"}],"version-history":[{"count":0,"href":"https:\/\/www.itwriting.com\/blog\/wp-json\/wp\/v2\/posts\/2156\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.itwriting.com\/blog\/wp-json\/wp\/v2\/media?parent=2156"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.itwriting.com\/blog\/wp-json\/wp\/v2\/categories?post=2156"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.itwriting.com\/blog\/wp-json\/wp\/v2\/tags?post=2156"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}