What's New in .NET Framework 2.0 Security

From Guidance Share

J.D. Meier, Alex Mackman, Blaine Wastell, Prashant Bansode, Chaitanya Bijwe

What's New in 2.0

.NET Framework version 2.0 introduces many new security features. The most notable enhancements are:

• Full trust assemblies now satisfy any code access security demands. In .NET 2.0, any fully trusted assembly will satisfy any demand, including a link demand for an identity permission such as a System.Security.Permissions.StrongNameIdentityPermission that the assembly does not satisfy.
• Enhanced security exception information. The System.Security.SecurityException object has been enhanced to provide more information in the case of a failed permission.
• DPAPI managed wrapper. In the .NET Framework version 1.1 you had to use P/Invoke to access the Win32 Data Protection API (DPAPI) functions. In the .NET Framework version 2.0, you no longer need to use P/Invoke. Instead, you can use the new ProtectedData class. ProtectedData contains two static methods: Protect and Unprotect. To use DPAPI to encrypt data in memory, you can use the new ProtectedMemory class. Note that managed code requires the new DataProtectionPermission to be able to use DPAPI.
• Secure string type. The System.Security.SecureString type uses DPAPI to ensure that secrets stored in string form are not exposed to memory or disk sniffing attacks.
• XML encryption. The System.Security.Cryptography.Xml.EncryptedXML class can be used to secure sensitive data, such as database connection strings, that must be stored on disk.
• Programming of ACLs and ACEs. You can now program access control lists (ACLs) and access control entities (ACEs) directly from managed code by using the System.Security.AccessControl namespace.
• Programmatic Active Directory management. You can now perform management tasks for Microsoft Active Directory® directory service by using the System.DirectoryServices.ActiveDirectory namespace. Data in the directory can be accessed with the System.DirectoryServices namespace
• Security context for secure asynchronous code. It is now easier to write secure asynchronous code. The System.Security.SecurityContext class allows you to capture the security context of a thread, including code access security markers such as permit and deny and the thread impersonation token, and restore the context on another thread.
• Secure communication between hosts. .NET Framework version 2.0 provides a set of managed classes in the System.Net.Security namespace to enable secure communication between hosts. This allows you to implement both client and server-side secure channels by using SSPI or SSL. These classes support mutual authentication, data encryption, and data signing.
• Remoting TCP channel. The System.Runtime.Remoting.Channels.Tcp.TcpChannel class now uses SSPI to support both encryption and authentication. This makes it easier to develop secure remoting without the need for custom code.
• Remoting IPC channel. The new System.Runtime.Remoting.Channels.Ipc.IpcChannel class is ideal for communication between components on the same physical computer. The underlying implementation uses named pipes that can be secured with ACLs.
• Simple sandboxing. In .NET Framework version 1.x, to set up a sandboxed application domain (for example, to host untrusted code), you had to create an application domain policy level, create a series of code groups, and define the permission sets that would be granted to each one. In .NET Framework version 2.0, you can use a new overload of the static AppDomain.CreateDomain method to perform all of this work.
• Global assembly cache means full trust. Assemblies in the global assembly cache are always granted full trust, regardless of the local computer's security policy.
• Full trust means full trust. Full trust assemblies are never granted any code access security protection.
• Security transparency. You can now mark assemblies with the System.Security.SecurityTransparentAttribute to let the common language runtime (CLR) know that your code will not perform security-sensitive code access security operations, such as asserting permissions or using stack walk modifiers to escalate privileges. If your code or any code you call attempts such operations, a security exception is generated. This is particularly useful if your code loads third-party plug-ins.
• Loading code for inspection only. The new Assembly.ReflectionOnlyLoadFrom method allows you to load code purely to examine its members. The loaded code is not allowed to run.
• OleDB provider supports partial trust. The System.Data.OleDb managed provider no longer requires full trust. Code just requires the OleDbPermission. This allows partial trust developers to access non-SQL databases. For ASP.NET applications, this permission is not granted by medium trust policy, although you can create custom ASP.NET policy files to allow partial trust ASP.NET applications to use OLE DB data sources.
• SMTP code access security permission. The new System.Net.Mail.SmtpPermission is used to determine which code can send e-mail.