Security is an important aspect of software development nowadays, and C# in its very architecture has this feature, present in various forms. There are some holy-water droplets to drink before eating the topic to self-satisfaction. And those include
- Permissions
- Type-safety
- Security Policy
- Principal
- Authentication
- Authorization
The .NET Framework offers code access security and role-based security to help address security concerns about mobile code and to provide support that enables components to make decisions about what users are authorized to do. These security mechanisms are designed to have a simple, consistent model so that developers familiar with code access security can easily use role-based security, and vice-versa.
Permissions
There are three kinds of permissions : Code permissions, Identity Permissions & Role-based permissions . The namespace System.Security.Permissions is responsible for it and provides support in implementing custom permission classes also.
The primary uses of permissions are as follows:
- code can request the permissions it needs to access resources or perform operations
- the runtime can grant permissions to code, based on characteristics of the code's identity, on what permissions were requested, and on how much the code is trusted
- code can demand that its callers have specific permissions.
Type-safety
Type-safe code accesses only the memory locations it is authorized to access. It cannot, for example, read values from another object's private fields. Type-safe code accesses types only in well-defined, allowable ways. During Just-In-Time (JIT) compilation, an optional verification process examines the Microsoft Intermediate Language (MSIL) in an attempt to verify that the MSIL is type-safe. This process is skipped if the code has permission to bypass verification.
Code that is not verifiably type-safe can attempt to execute if security policy allows the code to bypass verification. However, because type-safety is an essential part of the runtime's mechanism for isolating assemblies, executing unverifiable code can cause problems that crash other applications as well as the runtime itself. Also, security cannot be reliably enforced if the code violates the rules of type-safety.
Security Policy
Security policy is the configurable set of rules that the Common Language Runtime(CLR) follows when it decides what it will allow code to do. Administrators set security policy, and the CLR enforces it. The CLR ensures that code can access only the resources and call only the code that security policy allows it to access.Whenever an attempt is made to load an assembly, the runtime uses security policy to determine which permissions to grant to the assembly. After examining information called evidence that describes the assembly, the runtime uses security policy to decide how much the code is trusted and, therefore, what permissions to grant to that assembly. Evidence includes, but is not limited to, the code's publisher, its site, and its zone. Security policy also determines which permissions to grant to application domains.
Principal
A principal is a user or an agent that acts on the user's behalf. .NET Framework role-based security has support for three kinds of principals:
- Generic principals represent unauthenticated users and the roles available to them.
- Windows principals represent Windows users and their roles (or their Windows NT/Windows 2000 groups).
- Custom principals can be defined by an application in any way that is needed for that particular application. They can extend the basic notion of the principal's identity and roles. However, the application must provide an authentication module and types that implement the principal.
Authentication
Authentication is the process of discovering and verifying the identity of a principal by examining the user's credentials and validating those credentials against some authority. The information obtained during authentication is directly usable by your codeA variety of authentication mechanisms are used these days , many of which can be used with .NET Framework role-based security. Some of the most commonly used mechanisms are Basic, Digest, Passport, operating system (such as NTLM or Kerberos), or application-defined mechanisms
Authorization
Authorization is the process of determining whether a principal is allowed to perform a requested action. Authorization generally occurs after authentication, and it uses information about the principal's identity to determine what resources the principal can access. .NET Framework role-based security can be used to implement authorization.
Security Tools for C#
Now, I would like to draw attention towards the Security Tools provided by .NET for its applications. These are command-line utilities that help perform security-related tasks and test your components and applications before we deploy them.Assembly Generation Utility (al.exe)
Al.exe takes as its input one or more files that are either in MSIL format or are resource files and outputs a file with an assembly manifest.For more details , see Online MSDN.
Code Access Security Policy Utility (caspol.exe)
The caspol utility enables users and administrators to modify security policy for the user policy level and the machine policy levelFor more details, see Online MSDN.
Software Publisher Certificate Test Utility (Cert2spc.exe)
The Software Publisher Certificate test utility (Cert2spc.exe) creates a Software Publisher's Certificate (SPC) from one or more X.509 certificates. Note that Cert2spc, like Makecert, is for test purposes only. A valid SPC is obtained from a Certification Authority (CA) such as VeriSign or Thawte.For more details, see Online MSDN.
Certificate Manager Utility (certmgr.exe)
The Certificate Manager utility manages certificates, certificate trust lists (CTLs), and certificate revocation lists (CRLs). Certmgr performs the following basic functions:
- Displays certificates, CTLs, and CRLs to the console.
- Adds certificates, CTLs, and CRLs, from one certificate store to another.
- Deletes certificates, CTLs, and CRLs, from a certificate store.
- Saves an X.509 certificate, CTL, and CRL from a certificate store to a file. For more details, see Online MSDN.
Certificate Verification Utility (chktrust.exe)
The ChkTrust utility checks the validity of an Authenticode�-signed file. If the hashes agree, ChkTrust verifies the signing certificate.For more details, see Online MSDN.
Certificate Creation Utility (makecert.exe)
Makecert (the X.509 Certificate Creation utility) generates a X.509 certificate, which ca
n be used for testing purposes only. It creates a public and private key pair for digital signatures and associates it with a name that you specifyFor more details, see Online MSDN.
Permissions View Utility (permview.exe)
Use the PermView command line utility to view the minimal, optional, and refused permission sets requested by an assembly. By default, permission requests are dumped to the console. For more details, see Online MSDN.
PEVerify Utility (peverify.exe)
The PEVerify utility is provided to assist developers generating MSIL (i.e., compiler writers, script engine developers, etc.) in determining whether their MSIL code and associated metadata meets type-safety verification requirements.For more details, see Online MSDN
Secutil Utility (SecUtil.exe)
The Microsoft .NET Common Language Runtime security system provides mechanisms for restricting the actions of code based on its associated evidence. Two types of evidence, strong names (also called shared names) and Authenticode� publishers, are based on cryptographic keys and digital signature technology. As a result, we have high assurance concerning this evidence for a given assembly.For more details, see Online MSDN.
Set Registry Utility (setreg.exe)
Setreg (the Set Registry utility) changes registry settings for public key cryptography.For more details, see Online MSDN.
File Signing Utility (signcode.exe)
Signcode (the File Signing utility) signs a portable executable (PE) file with requested permissions to give developers more detailed control over the security restrictions placed on their component. You can sign a component or an assembly. If you are distributing an assembly rather than individual components (i.e., .dlls or .exes), you should sign the assembly, not the individual components. If signcode is run without any options, it launches a wizard to help with signing.For more details, see Online MSDN.
Isolated Storage Utility (storeadm.exe)
Use the StoreAdm command line tool to manage isolated storage The tool provides three simple functions that are typically used one at a time namely /LIST , /REMOVE and /QUIET.
For more details, see Online MSDN.
