Why .NET?

In today's software environment, applications come from many sources and perform many tasks. Trust of the application code is a key requirement because we don't want to risk damage to software or information. A security policy that grants permissions that it shouldn't may allow inappropriate access to sensitive information, or expose the local machine to malicious programs or even just plain buggy code. Traditionally, security architectures have provided isolation and access control based on user accounts, giving code complete access rights within those restrictions and assuming that all code run by a particular user is equally trustworthy. Unfortunately, isolating code on a per-user basis will not sufficiently protect one program from another if both programs are running on the user's behalf. Alternatively, code that is not fully trusted has often been relegated to a sandbox model of execution, where code is run in an isolated environment with no access to most services. A successful security solution for today's applications must strike a balance between the two models of security. It must provide access to resources in order for useful work to be done, and it requires finer control of application security to ensure that code is identified, examined, and given an appropriate level of trust. The .NET Framework security model provides just such a solution.

.NET security

.NET applications are built with managed code. Compilers for languages, such as the Microsoft Visual C#® development tool and Microsoft Visual Basic® .NET development system, output Microsoft intermediate language (MSIL) instructions, which are contained in standard Microsoft Windows® portable executable (PE) .dll or .exe files. When the assembly is loaded and a method is called, the method's MSIL code is compiled by a just-in-time (JIT) compiler into native machine instructions, which are subsequently executed. Methods that are never called are not JIT-compiled. The use of an intermediate language coupled with the run-time environment provided by the common language runtime offers immediate security advantages:

File format and metadata validation
The common language runtime verifies that the PE file format is valid and that addresses do not point outside of the PE file. This helps provide assembly isolation. The common language runtime also validates the integrity of the metadata that is contained in the assembly.
Code verification
The MSIL code is verified for type safety at JIT compile time. This is a major plus from a security perspective because the verification process can prevent bad pointer manipulation, validate type conversions, check array bounds, and so on. This virtually eliminates buffer overflow vulnerabilities in managed code Integrity checking.
Code access security
The virtual execution environment provided by the common language runtime allows additional security checks to be performed at runtime. Specifically, code access security can make various run-time security decisions based on the identity of the calling code.

Why .NET?

.NET security

Related Links