Windows Tip Sheet

.NET Security Woes

Network executables and DLLs must enter .NET Framework's zones of trust for them to work right.

Having just written an application (the new Windows-based ScriptVault client on www.ScriptingAnswers.com) in VB.NET, I ran smack into some annoying behaviors of the .NET Framework. Annoying, but secure, so it’s worth understanding how the .NET Framework is set up to help protect you and your users from malicious code.

The problem was this: When users copied my application’s executable to their My Documents folder, it wouldn’t run. Copied to their Desktop folder, however, it ran fine. Whaaaat? It turns out, however, that their My Documents folder was redirected to a network drive, so the .NET Framework saw the executable coming from the less-trusted “Intranet Zone” on the Desktop; when the executable was in the more-trusted “Local Zone,” it ran fine. When in My Documents, the application would just crash with an exception that had nothing to do with my code and was less than specific about what the actual problem was.

A good way to figure this out is to open the .NET Framework Configuration console. Right-click “Runtime Security Policy” and select “Evaluate Assembly.” Browse to the executable or DLL you’re concerned about, and select “View permissions granted to the assembly” and click Next. If your results are anything but “Unrestricted,” you’ll be able to see where the restrictions are coming from and act accordingly. Assemblies must at least have “Execute” permissions in order to run, and applications with a GUI need appropriate permissions to utilize the Windows UI. Additional permissions can restrict disk, Internet, registry, Active Directory and other permissions; applications that unexpectedly crash may be trying to perform an operation (like saving user preferences to the registry) which is restricted by a .NET security policy.

More Resources

  • Read more about the configuration console here.
  • Learn to explicitly trust an assembly here.

Micro-Tips
Different versions of Windows and the .NET Framework have different default values. I say, forget ‘em: Deploy your own policy, instead. Use the .NET Framework Configuration console to create your own policy and deploy it via Group Policy, so that your .NET execution security will be fully under your control.

About the Author

Don Jones is a multiple-year recipient of Microsoft’s MVP Award, and is an Author/Evangelist for video training company Pluralsight. Don is also a co-founder and President of PowerShell.org, a community dedicated to Microsoft’s Windows PowerShell technology. Don has more than two decades of experience in the IT industry, and specializes in the Microsoft business technology platform. He’s the author of more than 50 technology books, an accomplished IT journalist, and a sought-after speaker and instructor at conferences worldwide. Reach Don on Twitter at @concentratedDon, or on Facebook at Facebook.com/ConcentratedDon.

comments powered by Disqus
Most   Popular

SharePoint Watch

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.