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 Curriculum Director for IT Pro Content 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.