Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Background

In .NET 1.0 through 3.5 administrators could administer the runtime security policy through mscorcfg. Aparrently many of these security features have been removed in .NET 4.0,. Furthermore there instructions telling me how to launch this security tool but I can't find it anywhere on my Windows 7 laptop.

enter image description here

Question

  • What does a security pro need to know about Code Access Security (CAS)?

  • Why have these security features been removed from .NET 4.0?

  • How do we secure .NET 4.0 apps?

  • If the security tools for .NET 3.5 and older are actually hidden from administrators, does that mean we are creating security problems for ourselves? Particularly, if we can't see what's going on for older .NET applications won't that create problems down the road?

share|improve this question
add comment

1 Answer

up vote 2 down vote accepted

What does a security pro need to know about Code Access Security (CAS)?

Honestly I would say not a whole lot; until you need to know about it.

Why have these security features been removed from .NET 4.0?

Because the security was complicating, leading to questions like this. It was also an incomplete solution since it was only .NET applications that had this functionality. Take for example, that a .NET Executable run over a network share would run in medium trust. Medium trust would prevent access to a lot of functionality, but it was done in the name of security. It however, did have its flaws.

  1. Native EXEs did not behave this way. If someone was going to write a malicious executable, they probably wouldn't opt to do it .NET. A native executable does not behave differently when run over a network share. However, it did stop a very "cheap-and-simple" means of network applications being useful.

  2. Administering it was downright confusing. Between Code Groups, zones, Strong Names, Application Identity, and permission sets, a lot needed to be known for something that didn't provide enough security.

  3. The concept was born before UAC and AppLocker, where people that were Administrators always had administrative permissions. UAC goes much deeper than a .NET application, it's at the operating system level.

How do we secure .NET 4.0 apps?

Your real goal isn't "to secure .NET apps" but "to secure all apps". AppLocker or SRP are more effective because they apply to any application. .NET, Java, Native, etc.

Additionally, by restricting the user's permission, not the application. Creating a policy application-by-application takes great effort, and even more difficult when you need to start creating exceptions for certain users.

That isn't to say that .NET 4.0 doesn't have a security model at all. .NET 4.0's replacement is Security Transparency, and "hosted" applications like Silverlight, ClickOnce, etc still have CAS-like permission sets applied to them.

Security Transparency relies more on a grant set provided by a sandbox. Take for example, Silverlight. Silverlight will give a different grant-set depending on whether the application is running in-browser (Medium Trust), or out-of-browser, which can have Full Trust. Running out-of-browser takes a users approval to do so, and even then it is restricted by things at the operating system level.

It's up to the developer to know what permission sets he has depending on which sandbox his application is running on. In effect, .NET 4 applications get the same "sandbox" as native applications. Silverlight, ClickOnce, etc get their own sandbox that have greater restrictions.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.