Security and Microsoft .NET

This article has been excerpted from book "The Complete Visual C# Programmer's Guide" from the Authors of C# Corner.

The .NET Framework security system is built to provide protection as software undergoes the metamorphosis to multiple mobile components. The .NET security system provides a fine-grained, extensible policy and permission system so that people can run more powerful software code without compromising the system to security-related risks. The .NET security system enables administrators to create robust security policies at all levels because administrators are not forced to determine the trust of users at runtime.

As you will see later, .NET security policies are completely customizable. Developers can focus mainly on the application logic rather than delving into security details. Thus they do not need to deal with security at the core level. Security is handled capably by the CLR in the .NET Framework. Developers can use and extend .NET security at any time.

Security, an essential part of the .NET Framework, starts immediately after a class is loaded in the .NET runtime memory area; the framework performs many initial verification checks to ensure that the code is accessing memory in a controlled way. Then the framework controls code access to the resources via code access security.

In the .NET Framework, all code is essentially type safe because it references only memory blocks that have been reserved for its use and it accesses objects only through valid, exposed interfaces. From a security point of view, referencing only designated memory allows multiple objects to safely share a single address space and allows the accessing of objects only through their exposed interfaces, thus ensuring that security checks connected with these specific interfaces are not omitted.

The .NET Framework's security model checks code security not only during load time but also during runtime. It also allows security checks based on the identity of the code and of the user. Security policies established and maintained by administrators or developers govern the access to resources granted to a given assembly.

The .NET Framework's security model has six major areas:

type safety and verification, which ensures that code accesses memory in a controlled way;
code signing, which ensures that code has not been tampered with after release by establishing an identity for the code;
cryptographic services and data signing, which protect application data;
code access security, which, based on the caller's identity and origin, provides permission to access resources;
role-based security, which controls code access based on the user's identity; and
isolated storage, which persists data in a safe way on a client computer.

Figure 22.3 depicts some significant features of the code access security mechanism.

Figure 22.3: Code Access Security in Action

Figure 22.4 outlines some significant features of the role-based security mechanism.

Figure 22.4: Role-Based Security in Action

The CLR associates strong typing in the metadata, like members, parameters of methods, array elements, return values of methods, and static values, with strong typing in the MSIL code, like local variables and stack slots. This two-way strong-typing enforcement ensures type safety. Thus, regardless of the language used to develop the program, the resultant executable files or or DLLs are sure to be type safe, because they are all ultimately MSIL code. The CLR verifies all of the loaded code before it is run. On demand, you can skip this verification process by explicitly trusting an assembly through the use of policies.

The .NET Framework security solution is based on the notion of managed code, with security rules imposed by the CLR. Most managed code is verified to ensure type safety and the predictable behavior of other security properties. In a verified code block, a method declared to accept an Int16 value, for example, will disallow a call attempt with a 16-byte parameter as unsafe. Verification also ensures that execution flows only to recognized locations (e.g., method entry points), a process that prevents execution from jumping to an arbitrary location.

The verification mechanism prevents nontype-safe code from executing and catches many common programming errors before they cause damage. Well-known system vulnerabilities, such as access to memory that has not been initialized and the arbitrary transfer of execution control, are completely disallowed. This mechanism benefits users because the code they run is checked prior to each execution. It also benefits developers, who will find that many common, security-related bugs that have traditionally caused trouble during development are now identified during the verification process and thus prevented from damaging system resources.

Besides preventing unauthorized users from accessing the system, the framework further protects application code and data by enforcing security restrictions on managed code. These restrictions arise from the six-pronged approach to security found in the .NET Framework. Let's delve into the details of these six .NET security areas mentioned earlier.

Type-safe code can read from or write to allowed memory locations only. During Just-In-Time (JIT) compilation, the MSIL code and metadata are examined to verify that the MSIL code is genuinely type safe and well formed. You can skip this verification if you set your policies that way.
Code signing sets an assembly's uniqueness so that other external processes cannot change the assembly. With strong-named assemblies, each file in the assembly loaded at runtime is hashed and that hash value is compared to the hash value stored in the manifest for that file. If the hash values do not match, the system refuses to load the file and throws an exception. As an alternative or as an added precaution, you may want to sign strong-named assemblies by using Microsoft Authenticode. This is useful in environments where a trust hierarchy is already in place and certificates are required. For example, Microsoft ActiveX controls are expected to have certificates that are downloaded and run inside Microsoft Internet Explorer.
Cryptographic services and data signing (encryption of data) classes of .NET help you to offer a secure environment for your data by providing nearly all of the common cryptography algorithms. Thus, you can encrypt and decrypt your data with various cryptography algorithms.
Code access security permits code to access protected resources as long as code really has the requested permission (the right to access protected resources). Your code has a permission set that is constructed according to the active security policy. When your code accesses system resources, the system checks the code for the required permission.
Role-based security allows the system to make decisions about a user's authority to access resources based on the user's identity and role membership information, which is determined by the code.
Isolated storage, a virtual file system for data storage, is isolated per assembly and user. For example, Web-based applications downloaded from intranet or Internet sites may not have access to the ordinary file system. Such applications can have their data, files, and directories stored in this isolated virtual file system. You can limit the size of isolated storage.

Conclusion

Hope this article would have helped you in understanding Security and Microsoft .NET. See other articles on the website on .NET and C#.

The Complete Visual C# Programmer's Guide covers most of the major components that make up C# and the .net environment. The book is geared toward the intermediate programmer, but contains enough material to satisfy the advanced developer.

Security and Microsoft .NET

Reactions

Comments