.NET Internal Security as a Viable Alternative

Hi ppl,
Access security and role-based security are the most important vehicles to carry the security through your applications and systems. However, let it be clear that we are not discussing VB or C# security, but .NET security; that is, the security defined by the .NET Framework and enforced by the CLR. Since the .NET Framework namespaces make full use of the security, every call to a protected resource or operation when using one of these namespaces automatically activates the code access security (CAS).Only if you start up the CLR with the security switched off, CAS will not be activated.The CLR is able to
“sandbox” code that is executed, preventing code that is not trusted from accessing protected resources or even from executing at all. Hopefully, anyway. (Didn’t we hear this before when Java came out?) We discuss this more thoroughly in the Code Access Security section later in this chapter.What is important to understand is that you can no longer ignore security as a part of your design and implementation phase. It is a priority to safeguard your systems from malicious code, and you also want to protect your code/application from being “misused” by less-trusted code. This is the sort of situation that viruses take advantage of, like CodeRed’s use of buffer overflows in Microsoft’s IIS server software. For example, let’s say that you implement an assembly that holds procedures/functions that modifies Registry settings. Because these procedures/functions can be called by other unknown code, these can become tools for malicious code if you do not incorporate the .NET Framework security as part of your code. To be able to use the .NET Security to your advantage, you need to understand the concepts behind the security.