WebCast NOTES: Partial Trust Development with Visual Studio 2005

On Wednesday March 1, 2006 I conducted part one of a five part series titled “Security on the Brain”.  The goal of this series of WebCasts is to examine some of the tools and security features that have been incorporated into either the .NET Framework 2.0 or Visual Studio 2005.

In this latest WebCast I talked about setting up a design and development environment that would better simulate a partial trust environment.  Partial trust is not new to .NET as this has been around since .NET Fx 1.0.  This concept is known as Code Access Security and as a result all application runs in a sandbox environment by default.  Now many of us may not notice this because if we are deploying our application to run on the local machine then by default the application will belong to MyComputer Zone which will grant your application a Full Trust permission set.  Full Trust means that your application will have no limitation on invoking system resource APIs in the .Net Framework.  

Even if Code Access Security model grants your application the permission to invoke system resource APIs such as a File IO call, the application is still required to pass the principal object to the File System to determine if the thread (identity of the logged on user) has the necessary resource permission such as read or write. 

For those have deployed an application on a Network share or on an internal Web Server you would have notice that some of the system resources calls that worked in your development environment fails when the application was deployed.  This is because your application is no longer running in the MyComputer zone but rather the Local Intranet zone which is running under partial trust by default.  Therefore, many of the system resource APIs such has File IO, Unmanage code, SQLClient and many other are now prohibited by default. 

Visual Studio 2005 introduced a new featured called Debug in Zone.  By enabling Debug in Zone via the security tab of the property page of your application you will be able to emulate a partial trust environment such as Local Intranet Zone.   Therefore, when you develop and debug your application you will a notice a new and improved Security Exceptions being raised if your application does not have the permission to call the system resource API.  This will greatly speed up your development lifecycle by avoiding the Trail and Error paradigm.  When you combine this with such tools like permcalc it will provide nice environment to speed up and support your testing efforts.  However, these tools are only estimates and are not meant to replace your testing stage in the software development lifecycle.  Rather they are tools that will greatly support and augment your testing environment. 

Permcalc is a really cool tool that can be called via the cmd prompt of the .NET Framework 2.0 SDK or integrated within Visual Studio 2005.  Permcalc will interrogate the IL and metadata by created a simulated call stack on the granted assembly or dependencies in order to determine the permission set your application will require at runtime.  When you run permcalc (Calculate Permission) from the Security tab of your application property page the estimated permission set will be displayed on the permission table.  As a result, you will be able to see the default permission set for the zone your application will be debugged in, and the additional permission your application may require.  I really like this integrated view to immediately determine the gap between the granted permission and required permission.

I recommend the reading of an excellent article that nicely summarized the new Security features in Visual Studio 2005. 

For those still new to Code Access Security here are a couple of good resources to assist your learning.

• https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/THCMCh08.asp

• https://www.gotdotnet.com/team/clr/SecurityPolicyBestPractices.htm

• https://msdn2.microsoft.com/en-us/library/c5tk9z76.aspx

   

Now the skill testing question—for those that attended the webcast-- is:  We know that Code Access Security uses an evidence base model to determine to the permission set your application will be granted at runtime.  If the evidence of your application places it in more than one Code Group which permission set will your application be granted?  Please email me via my blog the answer.

A recording of yesterday webcast will be available at:

• https://msdn.microsoft.com/canada/securityonthebrain/

Comments

• Anonymous
  March 02, 2006
  On Wednesday March 1, 2006 I conducted part one of a five part series titled “Security on the Brain”. ...
• Anonymous
  March 02, 2006
  If an application falls into multiple code groups, the permisssion it is granted is the intersection of the permisssions of those code groups.
• Anonymous
  March 02, 2006
  ASP.NET 2.0 Security Training Modules and
  Videos!!! [Via: dansellers ]
  ASP.NET Podcast Show #38 -...