.NET Security Blog : Visual Studio

Visual Studio 10 Security Tab Changes

shawnfa — Thu, 28 May 2009 17:00:00 GMT

Kris Makey, who works on the Visual Studio team, has written up a good blog post about the changes you’ll see on the security tab in Visual Studio 10 when it comes to editing permission sets. He covers what the changes are, and some of the reasons why we worked with the Visual Studio team to make those changes.

Column Guides in Visual Studio

shawnfa — Fri, 07 Jul 2006 10:07:00 GMT

A lot of coding guidelines specify the maximum length for a line of code. For instance in the CLR, we like to keep lines of code under 110 characters long. Visual Studio has a feature which lets you display a vertical line at the column of your choosing to help visually see when a line is getting too long. This does involve mucking in the registry so the usual disclaimers apply.

To enable this feature, set:

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\Text Editor] 
"Guides"="RGB(192,192,192) 110" 

The values passed to the RGB function let you specify the color of the line, and the number following tells Visual Studio at what column to display it. The settings above create a code editing window similar to:

(Click the image for a better look).

You can also create multiple guidelines by adding additional column numbers after the first one.

Visual Studio Tip: Editing Project Files

shawnfa — Wed, 26 Apr 2006 17:00:00 GMT

Earlier I mentioned tweaking project files -- something that a lot of people do just by opening the project file up in Notepad and tweaking it. Although it's a bit hard to discover, you can actually do this right within Visual Studio 2005, saving you from switching between applications, and more importantly buying you color coding and intellisense on the project file.

To enable this, first right click on the project in Solution Explorer and choose "Unload Project".

This will cause the project node to grey out and be marked unavailable. You can now right click on it and choose "Edit <project file name>", which opens the project file up in the Visual Studio XML editor and loads the MSBuild schema up for you.

Once you've made your changes, save the file, right click the project again and chose Reload Project.

Visual Studio will prompt you to close the project document, and assuming there are no errors in the file, the project will reload and your changes will take effect. If there was an error, Visual Studio will give you a dialog indicating which line and column the error was in and a brief description of what went wrong.

In addition to using this for accessing features not available via the UI (as I mentioned in the strong name key post), I also tweak project files to invoke some custom MSBuild tasks that I use in personal projects.

Sharing a Strong Name Key File Across Projects

shawnfa — Mon, 24 Apr 2006 20:00:00 GMT

v2.0 of the .NET Framework deprecated the use of the AssemblyKeyFileAttribute and AssemblyKeyContainerAttribute. Often times, these attributes were used to share a common key file across several projects.

If you try to share key files using the Visual Studio 2005 <Browse ...> function on the signing property page, you'll find that the key file is copied into your project directory. In a lot of cases this is exactly the desired behavior since it helps to group all of the artifacts that go into building your project into one location. However, it is a common requirement that the key file not be copied into every project directory and instead referenced from a single common location. You can still pull this off using Visual Studio 2005:

Step 1: Add the key file to your project using the Add Existing Item menu.

Step 2: In the add dialog, instead of choosing to add the key directly (which will make a copy into your project directory), hit the arrow next to the Add button and choose to add the key as a link.

Step 3: Go to the signing page of the project properties. Your key file should now be on the drop down list of available keys.

Since the key is already a part of the project, Visual Studio will not make a new copy of it. One thing to notice, Visual Studio will reference your key as a relative path from the project file. This may be exactly what you want -- but if you'd rather have a hard coded path, you can open up the project file and change the AssemblyOriginatorKeyFile (and the Include path of the Link to your key).

You'll also want to make sure that on the property sheet of the key file, the Build Action is set to None and Copy to Output Directory is set to "Do not copy" -- You don't want to accidentally start distributing your key file as an embedded resource!

Finally, there are a couple of tweaks you can make for asthetics. After setting up signing, some people like to add the key as a solution item, then edit the project files and add a <Visible>False</Visible> tag to the None tag including the key. This presents the key in the Solution Explorer at the solution level rather than in each individual project.

Personally, I like to see the key file that each assembly will be signed with, but I don't want it cluttering the root level of the project's files. The tweak I make is to edit the project files and change the Link tag to have a Properties prefix. For instance, I might have:

<ItemGroup>
  <None Include="..\App.snk">
    <Link>Properties\App.snk</Link>
  </None>
</ItemGroup>

This puts the key in the properties node of the project, which I think is a more appropriate location for it than the project root.

SN v2.0 Works With PFX Files

shawnfa — Tue, 14 Feb 2006 20:52:00 GMT

One enhancement to the v2.0 SN tool that may not get noticed right away is that it now has the ability to work with PKCS #12 PFX files in addition to SNK files. The logic here is that a self signed certificate stored in a PFX file is the moral equivalent of an SNK key, except that it gives you the added benefit of storing your key in encrypted form rather than in the SNK's plain text format.

This feature should be entirely transparent -- anywhere that SN takes a key file as input, you can now specify a PFX file instead. SN will detect this and prompt you for a password:

C:\Build>sn -R DelaySigned.exe KeyPair.pfx

Microsoft (R) .NET Framework Strong Name Utility Version 2.0.50727.42
Copyright (c) Microsoft Corporation. All rights reserved.

Enter the password for the PKCS#12 key file:
Assembly 'DelaySigned.exe' successfully re-signed

Your password will not echo to the screen as you type it.

There are a few limitations to this feature however. Since it was designed with self signed certificates in mind, SN will not accept a PFX file which contains multiple certificates (there's no way to tell it which certificate you wish to use).

Also, SN will not allow you to redirect standard input and load the password from a pipe. (In this case it gives a rather cryptic error message "Failed to parse the PKCS#12 blob in KeyPair.pfx -- The handle is invalid." ... we'll replace that message with something a bit more descriptive in a future release).

Finally, the PFX file must have a password, even if that password is blank. SN will never attempt to read a certificate with a NULL password.

If you want to create a self signed PFX key, the easiest way is to use Visual Studio 2005. In the project properties Signing tab, tell Visual Studio to create a new strong name key file. VS will show you this dialog:

Selecting "Protect my key file with a password", the default option, creates a PFX file. If you uncheck that option, you'll create a traditional SNK file. VS will enforce that your password be at least six characters long. It also provides the ability for you to change the password of an existing key pair.

Debugging Lightweight CodeGen in VS

shawnfa — Wed, 26 Oct 2005 01:10:00 GMT

Haibo just posted about his debugger visualizer for dynamic methods. This is a pretty sweet piece of code for anyone who uses lightweight code generation and needs to debug the code they've emitted. Basically it adds a visualizer to DynamicMethod objects that enables you to dump out the IL of that method. (He also explains the code he uses to convert from IL bytes to ILDasm style representation, which can be used with the new MethodBody class that reflection exposes)

New Security Features in Visual Studio 2005

shawnfa — Thu, 06 Oct 2005 19:22:00 GMT

Brian Johnson has a new article on MSDN about New Security Features in Visual Studio 2005. Definitely worth a read -- he covers a lot of area, from Application Verifier, to ClickOnce, to PermCalc, right on down to unit testing.

A Closer Look at the Simple Sandboxed AppDomain

shawnfa — Tue, 09 Aug 2005 22:02:00 GMT

Yesterday we took a look at Whidbey's new Simple Sandboxing API. At first glance this API does seem relatively simple, however when you start to look closer at the AppDomain that is created for your sandboxed code, there are a few surprising properties.

You might expect that under the covers this API is doing the grunt work of creating an AppDomain policy level which grants AllCode the specified permission set, and then has a code group for each strong name specified on the FullTrust list in order to provide those assemblies FullTrust. However, this is not how the API works -- it actually uses an entirely different security model than the traditional policy level based one. In fact, there is no AppDomain policy level in the sandboxed domain at all! Instead the sandboxed domain simply keeps track of a set of FullTrust assemblies and a permission set to be granted to all other assemblies and the AppDomain itself. No policy resolution will be done for assemblies loaded into this type of domain.

Why does Whidbey add this second AppDomain security model? Aside from making it trivial for applications to sandbox untrusted code, it's also required for the ClickOnce security model. ClickOnce allows an application to specify the exact set of permissions it should run under. ClickOnce application authors test their applications with these permissions and expect to have exactly their requested permissions at runtime. This AppDomain security model allows for that to occur.

Similarly, Visual Studio's debug-in-zone feature also requires an environment where the permissions it requests are exactly the permissions it gets -- if it were to debug your application with fewer privileges, debug-in-zone could lead to a lot of confusion when operations that are expected to pass start throwing SecurityExceptions.

Finally lets take a look at that evidence parameter to the CreateDomain API. Since a sandboxed AppDomain does not resolve policy and always has a domain permission set equal to the grant set of the assemblies loaded into it, why does it need Evidence? Technically the domain itself doesn't need that parameter, and it won't ever look at it directly. However, the evidence is still stored on the AppDomain's Evidence property. This means that other features which make decisions based upon AppDomain evidence (such as isolated storage), can still work with code executing in a simple sandboxed domain without modification.

Profiling Signed Assemblies

shawnfa — Wed, 27 Jul 2005 00:35:00 GMT

Ian Huff has an entry today about the problems you'll run into when using Visual Studio Team System to profile assemblies that have a strong name signature. He walks through the steps necessary to cause Visual Studio to resign your assemblies after they have been instrumented by the profiler. It's a good page to bookmark if you plan on using the VSTS performance tools with code that gets signed.

Beta 2, Get Yer Beta 2

shawnfa — Mon, 18 Apr 2005 20:21:00 GMT

As I'm sure most of you have seen by now, today we announced the availability of Visual Studio 2005 Beta 2 and SQL Server 2005 April Community Tech Preview. The release is a huge step over the old beta 1 bits, and can be found on MSDN.

One of the nicer aspects of the beta 2 help system is that it is linked to the MSDN Forums site. Forums are sort of a living FAQ, hopefully a nicer extension of the newsgroup model. Currently there's no dedicated security forum, but if any of you feel like we should create one feel free to post a request in the Ideas & Suggestions Forum.

Over the next several weeks, I'll be posting about the many new security features that have appeared since last year's release; but for now I've got a beta to install ... :-)

Finding Out The Current User in the Debugger

shawnfa — Fri, 24 Sep 2004 01:02:00 GMT

Every once in a while, while debugging multi-threaded applications that do impersonation, it becomes useful to figure out the context that the current thread is running under. This is especially useful when debugging server scenarios where connections are farmed out to worker threads which begin their work by impersonating the user logging in. Before Whidbey finding this information wasn't very straightforward, and even when you found out the current user, it was difficult to find out any other security token information.

Thankfully the VS Whidbey debugger team has stepped up with a nice solution to this problem. You can now evaluate the $user pseudo-register in the debugger, and find out all about the context that the current process and thread are running under. In addition to the user name, this variable also shows their SID, session id, login id, impersonation level, and active privileges. In addition to this, information on all the groups that the active user is a member of is listed.

If the current thread is impersonating, then information on the user the thread is impersonating as is also available. Here's what this might look like on a thread that is not impersonating:

Whidbey's New SecurityException

shawnfa — Fri, 30 Jul 2004 19:24:00 GMT

One of the more difficult things to debug with .NET 1.0 and 1.1 is the security exception. With these frameworks generally the only information that you got was the state of the failed permission. Due to the complexity of debugging security problems, most people just gave up and required that their code run in a fully trusted environment. With Whidbey we've done a lot of work to beef up the security exception, and make debugging security issues even easier, in the process making it easier for developers to figure out the minimum set of permissions that their application needs to run under.

Limitations of the Current Implementation

Currently, the SecurityException contains four security specific properties.

GrantedSet provides the set of permissions that are granted to the assembly that failed. This property does not get filled out every time an exception is thrown however.
PermissionState has the permission or permission set that caused the exception to be thrown
PermissionType is also not always filled out, when it is, it should contain if PermissionState is a permission, permission set, or permission set collection
RefusedSet contains the set of permissions that were refused by by the assembly that caused the security exception to be thrown

Generally, PermissionState is the only property that can be depended upon to always have a value. This does not provide for a good user experience.

The Whidbey SecurityException

The Whidbey SecurityException adds several more properties, which together allow developers to figure out what code was causing a security problem. The new properties are:

Name	Type	Description
Action	SecurityAction	the SecurityAction that failed the security check
Demanded	object	the permission, permission set, or permission sets that were demanded and triggered the exception
DenySetInstance	object	if a Deny stack frame caused the security exception to fail, then this property will contain that set, otherwise it will be null.
FailedAssemblyInfo	AssemblyName	AssemblyName of the assembly that caused the security check to fail
FirstPermissionThatFailed	IPermission	the first permission in failing PermissionSet (or PermissionSetCollection) that did not pass the security check
Method	MethodInfo	the method that the failed assembly was in when it encountered the security check that triggered the exception. If a PermitOnly or Deny stack frame failed, this will contain the method that put the PermitOnly or Deny frame on the stack.
PermitOnlySetInstance	object	if the stack frame that caused the security exception had a PermitOnly permission set, this property will contain it, otherwise it will be null
Url	string	URL of the assembly that failed the security check
Zone	SecurityZone	Zone of the assembly that failed the security check

As you can see, there's a ton more data available about the cause of the security exception in Whidbey. However, as I noted above, even the current SecurityException properties don't get filled out properly all the time. As part of the SecurityException enhancement work, we've gone through all the places in the BCL that throw exceptions and ensured that they've filled out as much of the SecurityException data as possible.

So What Does a New Security Exception Look Like?

All of these extra properties provide a lot of information for developers to work with if they catch the SecurityException in their code. But what happens if the exception goes unhandled? The default behavior of spewing exception information to the screen will still provide a lot more information than was provided before. For instance, if I tried to run my ProtectedData sample off a network share, with default policy in place, I'd end up with a SecurityException. The debug spew for that exception would look similar to the following.

First comes the standard stack trace and exception type that failed.

Unhandled Exception: System.Security.SecurityException: Request for the permission of type 'System.Security.Permissions.DataProtectionPermission, mscorlib, Version=2.0.3600.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.
at System.Security.CodeAccessSecurityEngine.Check(PermissionToken permToken,CodeAccessPermission demand, StackCrawlMark& stackMark, Int32 checkFrames, Int32 unrestrictedOverride)
at System.Security.CodeAccessSecurityEngine.Check(CodeAccessPermission cap, StackCrawlMark& stackMark)
at System.Security.CodeAccessPermission.Demand()
at System.Security.Cryptography.ProtectedData.Protect(Byte[] userData, Byte[] optionalEntropy, DataProtectionScope scope)
at CPD.Main() in \\shawnfa-build\c$\blog\ManagedDPAPI\CryptProtectData.cs:line 12

This is followed up by the SecurityAction that failed, the first failed permission, and the details of the demanded permissions. (From now on, I'm going to abbreviate the full assembly names.)

The action that failed was:
Demand
The type of the first permission that failed was:
System.Security.Permissions.DataProtectionPermission
The first permission that failed was:
<IPermission class="System.Security.Permissions.DataProtectionPermission, mscorlib ... "
version="1"
Flags="ProtectData"/>

The demand was for:
<IPermission class="System.Security.Permissions.DataProtectionPermission, mscorlib ..."
version="1"
Flags="ProtectData"/>

Next is a list of all the permissions granted to the assembly that failed the demand:

The granted set of the failing assembly was:
<PermissionSet class="System.Security.PermissionSet"
version="1">
<IPermission class="System.Security.Permissions.EnvironmentPermission, mscorlib ..."
version="1"
Read="USERNAME"/>
<IPermission class="System.Security.Permissions.FileDialogPermission, mscorlib ..."
version="1"
Unrestricted="true"/>
<IPermission class="System.Security.Permissions.FileIOPermission, mscorlib ..."
version="1"
Read="\\SHAWNFA-BUILD\C$\blog\ManagedDPAPI\"
PathDiscovery="\\SHAWNFA-BUILD\C$\blog\ManagedDPAPI\"/>
<IPermission class="System.Security.Permissions.IsolatedStorageFilePermission, mscorlib ..."
version="1"
Allowed="AssemblyIsolationByUser"
UserQuota="9223372036854775807"
Expiry="9223372036854775807"
Permanent="True"/>
<IPermission class="System.Security.Permissions.ReflectionPermission, mscorlib ..."
version="1"
Flags="ReflectionEmit"/>
<IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, ..."
version="1"
Flags="Assertion, Execution, BindingRedirects"/>
<IPermission class="System.Security.Permissions.UIPermission, mscorlib, ..."
version="1"
Unrestricted="true"/>
<IPermission class="System.Security.Permissions.UrlIdentityPermission, mscorlib, ..."
version="1"
Url="file://shawnfa-build/c$/blog/ManagedDPAPI/CryptProtectData.exe"/>
<IPermission class="System.Security.Permissions.ZoneIdentityPermission, mscorlib, ..."
version="1"
Zone="Intranet"/>
<IPermission class="System.Net.DnsPermission, System ..."
version="1"
Unrestricted="true"/>
<IPermission class="System.Windows.Forms.WebBrowserPermission, System ..."
version="1"
Level="Restricted"/>
<IPermission class="System.Drawing.Printing.PrintingPermission, System.Drawing ..."
version="1"
Level="DefaultPrinting"/>
</PermissionSet>

Finally, the assembly that failed the permission demand is listed along with the method that called into the demanding code, and the Zone and URL evidence for that assembly.

The assembly that failed was:
CryptProtectData, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null
The method that caused the failure was:
Void Main()
The Zone of the assembly that failed was:
Intranet
The Url of the assembly that failed was:
file://shawnfa-build/c$/blog/ManagedDPAPI/CryptProtectData.exe

Visual Studio Gets In On The Action

In addition to all the work done in the CLR to make debugging security exceptions easier, Visual Studio 2005 has done quite a bit of work as well. When an unhandled SecurityException is thrown under the VS debugger, Visual Studio will look at all of the extra properties that are populated on that exception, and provide you with context sensitive help to solve the problem.

As you can see in the screen shot, VS will highlight the line that caused the SecurityException, and shows a pop up dialog that tells you the permission that failed and provides several possible solutions for the problem. In this case, there's not a lot of ways to get around the DataProtectionPermission demand, so the options that VS presents include turning this into a ClickOnce application or installing locally. This help is based around the failing permission, so if a FileIOPermission failed, VS might suggest using IsolatedStorage instead.

The View Details link will, oddly enough, open up the View Detail dialog where you can inspect each property of the Security Exception yourself, in order to help you further track down security issues.

Debug-In-Zone

All that's fine and good, but when you develop on your local machine, you end up with FullTrust by default. Forcing developers to modify their security policy to debug is not a good user experience, so again Visual Studio steps up to the plate, this time with a feature called Debug In Zone.

By going to your project properties, and accessing the security tab, you can specify the set of permissions that you'd like to debug your application with. For instance, if your goal is to have your application run with Internet permissions, then just select Internet from the drop down list. You can also create a custom permission set that reduces down to the exact set of permissions that your app needs; the Calculate Permissions button, which will interface with PermCalc will help you with this goal.

With the changes to the SecurityException class and enhancements to the Visual Studio debugger, figuring out the cause of those hard to diagnose SecurityExceptions.

What Happens When My Application Throws An Unhandled Exception

shawnfa — Thu, 15 Jul 2004 21:26:00 GMT

There are several different behaviors that can occur when a managed application throws an unhandled exception. The two most common are to bring up an error dialog box, or to pop up the Visual Studio Just In Time Debugger dialog box.

The first behavior is the default when you install the CLR, but don't install Visual Studio. Installing VS modifies the default to pop up the select-a-debugger dialog. How does the CLR figure out what behavior to use? It checks a registry key, located at HKLM\Software\Microsoft\.NetFramework\DbgJITDebugLaunchSetting. The value of this key lets the CLR know what to do when it encounters an unhandled exception. Possible values are:

Value	Action
0	Bring up the unhandled exception dialog box. (Click OK to terminate ...)
1	Print out the stack trace of the exception and terminate the application
2	Invoke the default managed debugger

If the value is set to 2, then the CLR consults HKLM\Software\Microsoft\.NetFramework\DbgManagedDebugger to determine which debugger to launch. This debugger is expected to be a managed debugger, that uses the CLR debugging interface. The debugger listed in this key will get four parameters, specified using printf style % format characters. The parameters are:

Parameter number	Meaning
1	PID of the process
2	ID of the AppDomain
3	Exception string ("System.OutOfMemoryException"), as a wide character string
4	Event handle to signal when aborting the attach operation

By default, Visual Studio registers the VSJITDebugger.exe program as the debugger, which is what is responsible for displaying the familiar choose-a-debugger dialog box. The default registration for this debugger in Visual Studio 2003 is:

"C:\Program Files\Common Files\Microsoft Shared\VS7Debug\VsJITDebugger.exe" PID %d APPDOM %d EXTEXT "%s" EVTHDL %d

ClickOnce Bootstrapper Manifest Generator

shawnfa — Wed, 07 Jul 2004 20:44:00 GMT

David Guyer, from the VB.Net test team, has released his ClickOnce Bootstrapper Manifest Generator on GotDotNet. This tool allows you to generate manifests that describe any pre-requisites to install for a ClickOnce application. You can find more details in the Powertoys blog.

New Debugger Features for Whidbey

shawnfa — Thu, 01 Jul 2004 20:19:00 GMT

Andy blogs about the new features in the Visual Studio 2005 debugger. Of all these, tracepoints seems the most exciting to me, although life will be made much easier with visualizers and the STL data display.